大規模な階層の場合-チェックボックスツリーまたは「ガイド付きツリー構築」
環境
私のWebベースのアプリケーションには 音楽ジャンルの階層 があります。ツリーには約1.5kのジャンルがあり、ツリーの深さは最大で約4レベルです。
私のアプリケーションでは、ツリーから「許可」されているジャンルを選択できます。これをモデル化するためにチェックボックスツリーを使用しました。ツリー全体がレンダリングされ、ユーザーが「許可」したいノードがチェックされます。これがスクリーンショットです：
（私は大きなチェックボックスツリーの問題に集中したいと思います。階層がジャンルをナビゲートする正しい方法であるかどうかについて別の議論があります-私がこのようにそれをした理由は2つあります：（1）見つけやすい検索が提供されていないジャンル（2）ジャンルが許可されていない場合、アプリケーションは許可されている最も具体的な親ジャンルを探します。このメンタルモデルをUIに保持したかったのです）。
大規模な階層構造のチェックボックスツリー：懸念事項
これからは、チェックボックスツリーについて抽象的に説明します。
このような大きな構造にチェックボックスツリーを使用することに対する私の懸念は次のとおりです。
- 非常に多くのノードが提示されることによる認知負荷の増加
- ユーザーは選択したい特定のノードを検索する必要があります
- 遅い（IEのような遅いJSエンジンでは）
ここで、「大きな階層」とは、1k以上のノードを持つツリーです。
代替案-ガイド付きツリー構築
私が頭の中で思いついた代替案は次のとおりです：
空白のツリーから始めるか、適切なデフォルトルートノードを選択します。
ノードを選択したら、ノードを追加するためのアフォーダンスを提供します。クリックすると、推奨される子のリストが表示されます。これは、「モデル」または「テンプレート」ツリーがUIによって理解されていることを示唆しています。上記のジャンルツリーの場合、同じ階層を使用できます。これは、 提案 子ノードの。または、ユーザーは希望するノードを入力することもできます。
すべてのノードをツリーから削除できます。
したがって、ツリーにあるすべてのノードが選択されます（ジャンルツリーの場合、「許可」）。
それ以外の場合、ノードの数を追加すると2 * Nが必要になるため、一括追加モードが必要になります。ここで、N =追加されたノードの数です。
別の代替案-フラット化されたリストの構築
アルバムの代替ジャンルを決定するために内部で使用されるモデルはツリーを使用しますが、これは必ずしもUIで表す必要はありません。代わりに、リストビルダー/デュアルリストアプローチを採用できます。
いずれかのソリューションの要件
- ユーザーが任意に決定した値を持つノードは、追加または削除できます
- どのノードにも選択するいくつかの方法が必要です（チェックボックスツリーではこれがチェックされていますが、後者ではこれは単にツリー内にあります）。
私はこれを考えすぎていますか？チェックボックスツリーだけでいいですか。
ツリートラバーサルとノード選択（少なくとも「クラシック」実装では）は、インタラクションデザインの観点から見ると、面倒で面倒な作業です。
ちょっと考えてみましょう：
階層をフラット化するスマートフォンスタイルをListbuilderパターン（更新されたバージョンでは、図に示されているバージョンはかなり古風です）。後者は、ナビゲートするのと同じリストで選択を追跡するのが難しい場合があるためです。
左のリストは、ジャンルコレクション全体になります（本当に、それだけ大きい必要があるのでしょうか？）。 ワンウィンドウドリルダウンパターン に従います。各レベルで、ジャンル（および、存在する場合はそのサブジャンル）を追加するか、（もちろん、最下位レベルは別として）さらにドリルダウンして、Birdbrainのようなものをここに置くことができます。 http://pttrns.com/lists 。
right listはフラットリストで表される許可されたジャンルであり、ジャンル階層はブレッドクラムのような「メタデータ」としてメタデータとともに表されます例えばのようなフォーマット上記と同じリソースからのInstacast（ http://pttrns.com/lists ）。
あなたはチェックボックスツリーを使うべきですが、速いものを見つけてください。
残念ながら私はあなたに速いものを指摘することはできません-しかし私は他の誰かがそうすることを望みます。私は過去にIEで同様の速度の問題を解決しました。根本的な問題は、大部分が実際にクリップ/非表示または画面外にあるウィジェットを表示するコストです。これは、ユーザーがスクロールするときにDOM要素を再利用するJavaScriptによって解決できます。これにより、「4000要素を超える」複雑なウィジェットが100しかない場合と同じくらい高速になりました。誰かがチェックボックスツリーについてこれを解決したことを願っています。
編集
チェックボックスツリーはよく知られています-または、少なくともツリーとチェックボックスの両方はよく知られているため、ユーザーにとってはわずかな飛躍です。一方、ツリー構築インターフェースには、それに関する指示が必要です。ノードとリーフの両方を追加/削除すると、ツリー構築ソリューションはさらに混乱します。特に、ツリー内の非リーフノードの意味をユーザーに混乱させます。それは、そのノードに含まれるすべてのものを意味しますか、それともそのノードの下に明示的に追加されたものだけを意味しますか。非リーフノードを追加するときは、そのノードの下にあるものを表示する方法が必要です（「ヒップホップ」を追加したいのですが、「コンテンポラリー」の下に「ヒップホップ」がありますか？）。したがって、ツリーを構築するためにツリーから選択したくなる場合があります。ツリーがすでに作成されていて、ツリー内の適切な場所を選択するだけの場合は、はるかに簡単です。
より高速なチェックボックスツリーが見つからない場合は、ある時点で master-details を使用してツリーのレベルを分割すると、十分なパフォーマンスが得られます。 2つの部分が並んでいます。例として、50個のノードを持つトップレベルツリーがある場合、それを使用して、それぞれに約50個のノードがあり、リクエストに応じて構築される50個のチェックボックスツリーから選択できます。その戦略を使用すると、ツリー要素のオープン/クローズを無効にしてすべて開くことができるため、左右両方のツリーがスクロール可能なインデントされたリストになります。これにより、クリックして選択する量が減りますが、見栄えがよく、スムーズに機能するには、高速なチェックボックスツリーよりも多くのTLCが必要になります。