Yahoo!のユーザーインターフェイスブログ（YUIBlog）

アコーディオンパターンの調査の結果

数ヶ月前、 我々は"アコーディオン"ナビゲーションコンポーネント上で私たちの現在の考え方を共有し 、そして私たちはに組み込むのはデフォルトで、現在の慣行、および他のガイドラインを決定するためにアンケートを取るためにこのブログを読んで、ウェブ開発者やデザイナーのコミュニティを尋ねたアコーディオンのパターンとアコーディオンYUIコンポーネントに入力を提供しています。

私は結果を確認し、勉強になりましたいくつかの時間を持っていたし、我々は、パターンの"ベータ"版を書き、それを共有する準備として、私はコミュニティとそれらを共有したいと思ったので、さらに別れすることなく、ここに結果が（この調査は厳密に科学的とみなされるべきではないことに注意してください）​​。

答えた人

回答者は、自分自身に次の方法を特定した。

• デザイナー21.4パーセント
• 開発者32.1パーセント
• ハイブリッド（デザイナーと開発者の両方）42.3パーセント
• 上記4.2％なし

用語間の違い

すべての回答者全体の圧倒的な多数派が合意した

• アコーディオンとアコーディオンメニューは、同じこと（73％）を意味
• アコーディオンとツリーコントロールは、2つの異なるもの（89％）です。

多くのコメンターは、これらの線に沿って、アコーディオンと木の違いを説明した："ツリーコントロールは、一般的に、一般にアコーディオンで存在していない階層の深さを意味する。"

小さい大半はアコーディオンや折りたたみ可能なパネルが同じもの（60％）を参照していることだ。

これらの多数派は、ロール間で一貫した。

アコーディオンのプレゼンテーション

固体過半数（68％）、アコーディオンが（そして実際にはパターンがよくWeb上で立証されている）水平方向だけでなく垂直方向に配置することができると言った。 人々は、水平方向のアコーディオンのラベルを垂直および/または回転書かれるべきことを示唆した。

さらに大きな大多数（72％）アコーディオンが2つだけのレベルを（これはアコーディオンと木の区別と揃う）持つことができる言った：

わずかに過半数（53％）アコーディオンの他のアコーディオン内にネストされる可能性があるという。 使用してのようなもの - 書かれたコメントは、質問の文言はそのようなあなたが十分に樋している場合"、などの提案をする、いくつかは、それは確かに可能ですが、必ずしも望ましいことだと答えるにつながった、これは一般的にひどいということが可能であるが、ことが示唆さ非常に多くのタブと、それらが複数の行に折り返さ有する。"

これは、自称デザイナーや開発者が対辺を取ったの質問の一つであった。 デザイナーの64％は、彼らが、することができないのに対し、開発とハイブリッドの57％は、アコーディオンを入れ子にすることを合意した。 （Abovesのいずれも折半することにしていない！）

私が推測しなければならない場合、私は開発者（およびハイブリッド）、より親密になぜ"あなたがそれをすることができた..."の観点を、設計者はより多くのを表現しているかもしれない一方の多くを表現されている可能性よりも、どのように接続していることでしょうね"...しかし、それはいけない"の視点。

アコーディオンは、どのように振る舞うべきか

小さな大多数（54％）アコーディオンが一度に開くように複数のパネルのために許可する必要があることと考えています。 両方の動作をオンラインで見つけることができる、私たちの印象は、この動作は設計上のスペースと毛布のルールつの方法または他のよりもアコーディオンの目的の制約の詳細を依存することになる。

この問題はまた、アイデンティティの線に沿って、しかしあいまいな方法で分割する。 デザイナーと開発者とAbovesの基本は、複数のパネルが少し大きめの多数派で大丈夫であることを合意しながらハイブリッド車は、小さな大多数が一つのパネル枚ごとのルールを好んだ。

はるかに大きい大多数（73％）アコーディオンが完全に閉じた状態（つまり、常にオープンつのパネルがあることが必要がないこと、ですが）持つことができると考えています。 唯一の外れ値はAbovesの車でのアクセスは常に一つのパネルが開いてなければならないという立場のために60％を破ったということです。

いくつかのコメンターは、それがデフォルトでオープンつのパネルを持つこと、そしてそのパネルのいずれかの最初の、最も最近に使用されるものであることが良い習慣であることが示唆された。

別の大多数（76％）ではなく、一貫性のあるサイズに制約されず、必要に応じてアコーディオン全体のサイズが変更できると考えています。 （もちろん、コンテキストは、それが有効な選択肢やアコーディオンが一貫性のあるサイズを維持することであってもデザインの制約となる場合がある、そのようなモバイルデバイスの画面として、があります。）

非常にわずかな過半数（51％）アコーディオンのクリックで開く必要があることを示唆した（のようなホバーではなく）とほぼ同じ大き少数（45％）がかかっていると述べた。 興味深いことに、より少ない4％アコーディオンは原則としてホバーで開くはず明記して喜んでだった。

思考のためのおいしい料理をたくさん提供されるこの問題について書かれたコメントは、次のような：

パネルを開くと、明示的なアクションを要求する必要があります。 アコーディオンは、複数のパネルを持っている場合、ホバーで開くと、耳障りな体験かもしれない。 そのパネルを開くには"クリック"ではなく、パネルに何があるかの概要の詳細を伝えるためにツールチップを使用して、明示的にユーザーを持っている。

各アコーディオンの構成によって異なります。

私は一緒にこれらの例を入れて[ 複数 、 ロールオーバーは ]、その開発者が実際に各ユースケースのために"ベストフィット"を使用することができます。

また、別のルールでロールオーバーを使用するオプションがあるはずです：（1つは、ほとんど開いている）または（要素がマウスオーバーのみでオープンする必要がある）。

高度な用途に、アコーディオンは、ドラッグ＆ドロップ操作中にホバーで開く必要があります。 他のすべての状況では、ホバーが意図的であることを信頼することはできません。

アクセシビリティ

最後に、我々はアコーディオンを持つ任意の既知のアクセシビリティの問題のためのオープンエンドの質問の釣りを要請し、偉大な答えの多くを得た。 （この例の問題については、ほとんどの人は全体のラベルをクリッカブルだけでなく、小さなアイコンが作ることが重要であることに合意した。）

ここではアコーディオンでのアクセシビリティに関する他の洞察力のサンプリングは、次のとおりです。

私はそれがアコーディオンの相互作用は、高度な相互作用であると仮定しても安全だと思います。 アクセシビリティの問題の多くが発生する可能性があります。

1. 内容はパネルの後ろに隠れているので、人々はそれを見つけることができる。
2. パネルを開く/閉じるためにクリック可能な領域またはトリガーのサイズに応じて必要な手先の器用さの問題がある可能性があります。

javascriptが（ジャバスクリプトとのそれらのための"ちらつき"が生成される可能性があることが）使用できない場合アコーディオンはすべてのパネルを開く必要があります。

それは、隠されたパネルのコンテンツがDOMに存在するか、またはパネルを開いたときに取得されるかどうかによって異なります。 それが取得されている場合、フォーカスは新しくオープンしたパネル上に配置する必要があります。

要素の内容はAJAXを（ちょうどtabviewのアプローチのように）使ってロードされますが、場合も、私は本当にタイトルがクリッカブルになるはずと信じて、特別に現実はその時々の開発者（持っているはず）/（したい）の制御にその動作をカスタマイズする。 ここにある例のリスト私はYUI 2.xのに基づいて、アコーディオンウィジェットの実装用に作成された、それはおそらくバブルYUIの拡張子から最も使用されるコンポーネントの一つです。

我々は、アコーディオンの"ラベル"は、完全なブログ投稿へのリンクだったケースを持っていた、などアコーディオン、クリック可能なことができませんでした。 その場合には、我々は仕事をするJSを使用してソースにアイコンを書きました。 アイコンが十分に大きい場合及び/またはアクセスキーが付属して、私は大きな困難が表示されていない提供...

アコーディオンは、サーバをより少ないスペースへのコンテンツのフィッティング多くの目的を制御します。 これは視覚的な問題になるので、それは単にコンテンツのすべてを読み、それが視覚的にアコーディオンのように表示されているという事実を無視するように、スクリーンリーダーのための罰金となります。 それは、パネルを展開するためにクリック可能なようにアイコンで十分です。 そこにラベル全体がパネルを展開できるようにする設定オプションがあるか、またはその機能を追加する公共"オープン"または"拡大"機能を呼び出すラベルにリスナーをアタッチする実装の開発者に任さすることができます。

ちょうどタブ付きビューとしてアコーディオン考える。 パネル全体のラベル領域は、クリック可能なはずですが、それは他のコントロール（例えば、"却下"または"閉じる"ボタン）が含まれている場合、私は唯一のラベル（テキスト）クリッカブルに、または少なくともclikable面積しかインタラクティブにまで拡大を示唆コントロール（ボタンがクリック可能でなければならない"の後に"下のボタンを含むキャプションのすなわち、上記の面積、および）。

ドラフトのパターンを解放する

ある評者は、（公正な警官、あなたは私に言わせれば）調査の人為的な制約に疑問を呈した。

私はこの調査を好きではなかった。 質問は、柔軟性が不十分でした。 デザイナー/開発者として、私はすべてのインターフェイス要素が特定のサイトまたはWebアプリケーションに合わせて調整する必要があると考えています。 黒と白の質問をすると、プロジェクト間の明らかな違いの余地を残していません。 同じルールが別のアプリケーションのための全く不適切であるかもしれない間、いくつかのプロジェクトは、厳格なルールが必要です。 ほとんどの部分で、私は、その結果"それは依存する"ですべての質問に答えたことができます。

パターンだけ優しく推薦するとYUIのコードは、柔軟かつ強力になるので安心。 調査はそうであっても、人々の選択肢を制限するのではなく、意見や嗜好を収集するために設計されていない厳格なルールがないというフィードバックが便利です。

私たちは、ベータ版公開しましたアコーディオンパターン Yahoo!のデザインパターンのライブラリにして。 もしパターンの詳細なフィードバックを与えるためにしたい場合は、自由形式の方法で、立ち寄りまたは関連をご覧ください。 フォーラムの議論を。

会話して下さい： Bloglinesの | テクノラティ

共有し、拡張する： del.icio.usでブックマーク | Diggそれ！ | のreddit！