データのツリー表現が不人気になるのはなぜですか？
IDEのような専門的なソフトウェアについてではなく、OSのGUIとWebインターフェースについて質問しています。
数年前、Windows、Gopher、その他のインターフェース、およびこのようなデータモデルにファイルマネージャがありました。
Windowsファイルマネージャの例
Gopherの例。
現在、オペレーティングシステムやアプリケーションでツリービューを表示することはほとんどありませんが、通常、タグ、キーワード、またはツリー構造の1レベルのみを表示します。
ツリービューが不人気になった理由
人々は一般に「現実の世界」で階層構造を使用していません-それは彼らに強いられてきたものであり、過去の技術的名残です。
理解する必要があるのは、人々が物事を認識して整理する方法です。私たちの脳は階層的な働きをしません（大量の熱を発生させない限り）。代わりに、類似性-外観、匂い、味、触感などの類似性によって物事を認識します。Appleを見て、それがAppleであることがすぐわかります。必ずしもする必要はありません。それについて考えてください。ある意味で、それは一次元的な考え方です。
類似性で認識しているので、類似性で整理するのも妥当だと思います。これは、階層構造では実現できないことです。 2つのドキュメントは非常によく似ていますが、ツリーの3〜4のブランチが異なる場合があります。階層的な世界では、これらのドキュメントは非常に遠くにあります。また、標準的な階層構造を定義することも困難です。1つのドキュメントが、ツリー上の2つ以上のパスで適切に記述されている場合があります。
したがって、より適切な方法はドキュメントを「クラスター化」することです。厳格な構造に適合するドキュメントを選択するのではなく、ドキュメントに適合するファジー構造を作成します。各ドキュメントにいくつかの記述子（タグ）を作成し、これらを編成の基礎として使用できます。
タグの大きな利点は、タグが比較的将来に対応できることです。ツリーは、将来のドキュメントのクエリ方法を知っていると想定して機能します。デューイシステムの場合、これは問題ありません。同じ方法で、引き続き本にクエリを実行して、本棚の場所を見つけるからです。しかし、デジタルドキュメントの場合、将来どのようにクエリを実行するかを予測することはより困難になる可能性があります。文書のセマンティックな説明を作成することで、単に検索するのではなく、文書を説明するための構造が存在するため、将来どのようにクエリを実行するかは重要ではありません。
木にはいくつかの問題があります：
- ツリーは単一の分類法です。これには、ユーザーのメンタルモデルが、ドメインのソフトウェア開発者のメンタルモデルと一致する必要があります。
- ツリーでナビゲートするには、ブランチを選択せずにツリーを展開するために高精度のマウス精度が必要です。これは、タッチインターフェイスで管理することも非常に困難です。
- 木をナビゲートするには、通常、ルートから目的のリーフに移動するために、相互作用/クリックを繰り返す必要があります。
- 葉の詳細を表示すると、分類法やその他の興味深い枝や葉の幅広いコンテキストがわかりにくくなることがよくあります。これが、多くのマルチペインファイルエクスプローラが作成される理由です。
そうは言っても、木の有用な用途はまだたくさんあります。かつて、木は「使い過ぎ」で、今ではそのパターンの適用にはもう少しバランスがあると思います。
Perception：複雑さの低い（「娯楽」）アプリケーションの新しい市場が爆発的に発展しました。したがって、減少しないツリーの使用であっても、パーセンテージが減少し、「モダンな」UIとUXの変更を検討する上での役割は少なくなります。
Alternatives：階層の1つの機能（高速検索可能性）は、主にインスタント検索に置き換えられました。これを実装するための計算能力とアルゴリズム能力があり、特定の大規模な検索プロバイダーは、これを効率的に使用するために巨大なユーザーベースをトレーニングします。
（ナビゲーションが高速である場合、多くの場合それで十分であるので）人気になった別の代替手段は、ブレッドクラムスタイルの階層インジケーターです。
Fluid ubiquitous data：タクソノミーにはメンテナンスと親しみが必要です。最近のテクノロジーにより、より多くのデータにアクセスできるようになり、変化の速い（ユーザーが作成したなど）データにアクセスできるようになりました。
ツリーの分類法には、（サブ）中央定義権限と、データが変更された場合のメンテナンスが必要です。検索はそのコストを排除します。
一方、多くの長期実行タクソノミは「初期スキュー」に悩まされます[引用が必要]、元のデータに非常によく適合しますが、現在のデータ用に再構築するとより効率的になる可能性があります。ただし、thatは分類法に精通していないため、ユーザーに悪影響を及ぼします。
searchおよびtagsは、多くの場合、階層的な概念モデルに取って代わりました。コンテンツ作成側とコンテンツ消費側の両方に実際の利点があるためです。
ただし、ツリー階層は、UIに表示される概念モデルとして時代遅れになることはほとんどありません。多くの場合、それは正しい概念モデルです（たとえば、基礎となるファイル/ディレクトリシステム）。 gmailのようなラベル分類システムは、階層分類システムよりも柔軟性がありますが、いくつかの点で、フォルダー階層の具体性が理解しやすくなります。
めったにない？私はいつも彼らに会います。
現在開いているウィンドウの半分にはツリービューが含まれており、残りの半分はコンソールウィンドウまたはSEがロードされたこのWebブラウザーです。
コンテキストによっては、ツリービューが非常に役立つ場合があります。自分が「時代遅れ」であると考え、違うことをしているのを見られる以外に、目的を変えてねじれた方法を見つけようとする人が増えているというだけのことです。
もちろん、ツリービューが不適切に使用された（場合によっては使用された）場所もありますが、同じことがすべてに当てはまります。
私の見解では、木が行う最も価値のあることはこれです：
- 現在のもの
- 現在のものの詳細
- もっと詳しく
- 詳細...
- 別の無関係なもの
- その詳細
- 驚くべき詳細
- もっと詳しく
つまり、いくつかの異なるもののdetailを一度に表示できます。
IMHO-これはあまり有用な属性ではありません。ほとんどの場合、最も関連性の高い単一のビューのみを表示することで、より良いUXが得られます。そのため、ツリービューの最近の置き換えは次のようになります。
- 現在のもの
- 現在のものの詳細
<戻る