大規模な階層データセットを表示および検索するUX
ユーザーが階層構造をナビゲートできるWebデスクトップサイトを構築する。ノードには2つのタイプがあり、それらをAとBと呼びます。AはタイプAまたはBの子を持つことができます。Bは常にリーフノードです。
現在、タイプAは150kまで、タイプBは225kです。
トップレベルには約8kのノードがあります。そこから下がるだけです。各ノードにドリルダウンし、ノードを検索し、ノードを選択/選択解除する機能が絶対に必要です。
ノードの数はかなりクレイジーです。これが単なるリストである場合、検索を強制して結果の数を制限することが私のアプローチです。私たちが木を持っているという事実は、物事をもう少し難しくします。
このタイプのシナリオに適したユーザーエクスペリエンスモデルは何ですか？
これはUX形式であるため、ユーザーのニーズを把握するのに役立ちます。つまり、ノードの性質とは何か、ユーザーがノードに対して何を試行する必要があるか、およびその理由です。また、ユーザーがノードをフィルタリングできる追加のデータがありますか？それは単一レベルの階層ですか、それとも無制限の階層ですか（AはAの子を持つAの子を持つことができます-ファイルシステム上のフォルダのように） 。
余談ですが、ある調査によると、70の類似アイテムはおおよそ視覚的に調べなければならない量であり、ユーザーが検索/フィルタリング機能を使用する可能性が高いということを示唆しています。
これらの詳細がないと、包括的な答えを提供することは困難ですが、ツリー検索のアプローチは次のようになります。
- 先行入力検索フィールドがあります。
- 入力されたクエリはリーフと照合されます。一致しないアイテムは非表示になります。
- フィルタリング後、子のないノードも非表示になります。
ユーザーがリーフだけでなくノードも検索できる場合は、クエリに一致するノードを保持します。
Ux関連ではありませんが、AngularJSを使用してそのような振る舞いを正確に実装しましたが（250項目を超えることはほとんどありませんが）、非常に簡単でした。
最後の「ヒント」は、ノードの選択/折りたたみに伴う肉体的な労力を考慮することです-折りたたみがより一般的なアクションであると想定できるため、ノード（およびその隣の折りたたみアイコン）をクリックします。ノードを折りたたんだり展開したりする必要があります。これにより、ユーザーはそのようなアクションに対して大きなクリック領域を提供できます。ノードの選択は、各ノード/リーフの横にある（はるかに小さい）チェックボックスを使用して行うことができます）。選択がより一般的である場合は、ノードクリックを使用して選択し、折りたたみアイコンを使用して折りたたみます。
ノードがタイプAまたはBである場合、検索する人にとってそれは重要ですか？つまり、ツリー構造を表示する必要がありますwithin検索ですか？そうでない場合は、uxパターン "ファセット検索"または "ファセットナビゲーション"。私の意見では、これは特に、探しているものを知っている「パワーユーザー」にとっては便利なuxパターンですが、アーカイブの内容を発見したいだけの人にとってもそうです。
抜粋 "Design Patterns：Faceted Navigation" at alistapart、もともとはO’Reillyが発行し、ファセットナビゲーションのコンセプトの背後にあるアイデアとメカニズムを説明しています。
そして、これが Moritz StefanerのWebサイトでの作業例 です。ニューヨークタイムズのアーカイブ（260万ページ）の一部を閲覧できます。
そして、ドイツのテレビ局Deutsche Welleは、ビデオアーカイブにファセット検索を使用しています over here 。
また興味深い： " Filters vs. Facets：Definitions " by Nielsen Norman Group。
あなたが言及したもののような巨大な木では、それをどのように表示しても、フィルターされた木でも探しているものを見つけるのは非常に困難です。
私は同様の問題（数万のノードと100万を超える葉）に遭遇し、結局、大きなツリーの場合、フィルタリングはUIの観点からは意味がないと判断しました。
代わりに、大きなツリーを検索すると、結果のフラット化されたリストが表示され、場合によっては、ツリー内のこのノードが存在する場所（パンくずのようなもの）が示されます。
これは、状況のUIと技術的な問題の両方を解決する、私たちが思いついた唯一のソリューションでした。
現在、私は同様の状況にあります。木を掘るのはうまくいかないことに私たちは同意します。エンドユーザーがナビゲーションについて考えるとき、ツリーのメンタルモデルを念頭に置いていますか？あいまい検索についてはどうですか？これは、今日の開発者に提案されたものです。入力フィールドに入力すると、システムはパターンを認識し、値とともに正しいノード/プロパティ/何でも表示します。このようなもの;
あなたはドレスをタイプすると、システムはあらゆる種類のドレスを思い付きます。したがって、タブまたはクリックして「ドレス-ショート」を選択し、クエリを続行します。コロンの付いたぎこちないマークアップのように見えます。パワーユーザーは、ユーザーがsome-nodes：valueと入力したかどうかを認識し、システムは使用可能な結果をポップアップします。また、ノードタイプAおよびB内のエンティティの（最も検索された）プロパティのファセット検索も実装すると思います。
あなたの質問は私には十分に明確ではありませんでした。できる限り返信いたします。
この場合、いくつかのアプローチを一緒に適用するのが最も使いやすいと思います。私はそれを銀行システムで行い、複雑な商品/取引などを見つけるときに肯定的な反応を得ます...
私はこれら3つの組み合わせを使用します
- オートコンプリートテキスト領域：アイテムの名前だけでなく、ツリーメニューの見出しも提供することが重要です。人が何かを覚えている方法を推測することしかできません。
- 詳細な検索領域：どのような情報を探しているのかわかりませんが、詳細な検索では、メイングループ、日付、可能なトランザクション、類似の要素などを選択できます。
- ツリーメニューがメインコンテンツになります。それはバックエンドで別の方法でグループ化できますが、ユーザーが見たものは何でもそれについて人々が物事や話をする方が良いです。そうでなければ理解できません。 （ショップはバックエンドで「ユニット」と呼ぶことができますが、フロントでは、「ショップ」の下で呼び出し、ラベル付け、タグ付け、グループ化する必要があります）
優先したいのなら、ツリーメニューに行きます。 Amazonは、この種の相互作用の良い例です http://www.Amazon.com/ 。