描かれたツリー構造の直感性/ UXをどのように改善できますか？
バックグラウンド
このアプリケーションには、顧客/ユーザーツリー構造があります。ツリーのレベルで署名された役割に応じて、スーパーユーザー（システム）がすべてを表示し、顧客（例：フォード）は、自分自身とその下のすべての分岐/ノードを確認します。
顧客ノードには、顧客用とユーザー用の2つのブランチがあります。以下の画像はそれをより完全に説明しています：
ご覧のとおり、すべての顧客ノードは同じ構造で、CustomersノードとUsersノード。ブランチをノードに展開し、検索するノードを選択する検索/フィルター機能もあります。ノードを選択すると、ツリービューの右側のシートにノードコンテンツのテーブルが表示され、 "Create new customer"などのユーザーアクションが提供されます。 -）または "新しいユーザーの作成"。
問題
ただし、問題は、ツリーのどのノードが顧客でどのノードがユーザーであるか、およびUsersおよびCustomersノード。現在存在する唯一の良いフィードバックは、階層関係の通信であり、ノードはその階層的住居に応じて内側と外側にシフトします。もちろん、これはすでにツリー構造の性質です。
質問
この件について、ご意見をいただければ幸いです。
- ツリーの構造とノードのタイプを明確に伝えるにはどうすればよいですか？
- 問題を適切に解決した同様のツリー構造を見たことがありますか？
- アイコンを使用する場合、Customer-iconをから直感的に区別するものユーザーアイコン？
私が持っているこれらのクエリのいずれかについて、有益なフィードバックやニースUXの提案を提供できると思われる場合は、どうぞよろしくお願いします。
画像を見ると、いくつかのことが頭に浮かびます。
- 階層をフラット化します。階層が深く、（深い）ツリーが使いにくい
- 異なるレベルで同じノードを繰り返すため、ツリーは不明確です。繰り返しを取り除く。私にとって、これが実際に何を意味するのかは明らかではありません。ツリーウィジェットでネットワークを表現しようとしていますか？
- ツリーを使用する必要がある場合は、視覚的なヒントを使用して特定のレベルのノードを接続するツリーを使用してください。 GMノードの親が何であるかを本当に判断できますか？
補遺
私があなたを正しく理解している場合、各顧客がユーザーと他の顧客の両方を持つことができる顧客ノードのデータ構造を表示する必要があります。正しい？
ツリーを大幅に簡略化する1つの方法は、ツリーに現在ある中間レベルを取り除くことです：UsersおよびCustomersアイテム。これらはツリー全体で繰り返されるため、役立つ以上の混乱を招きます。顧客を他の顧客の直下に置くと、ツリーはすでにかなり単純になります。ただし、もちろん、顧客とユーザーを区別する必要があります。別のアイコンを使用し、ツリーでユーザーの上に顧客を並べ替えると役立ちます。ファイルマネージャーでフォルダーとファイルを区別する方法を比較します。
download bmml source – Balsamiq Mockups で作成されたワイヤーフレーム
さらに1つのステップは、顧客とそのユーザーの表示を分離することです。ここでは、ツリー内に顧客があり、その隣のリストにユーザーがあります。
もちろんこれはすべて、循環する顧客関係がないことを前提としています。そうしないと、ツリーの深さが無限になります。その場合は、実際のツリー階層ではなくネットワークがあり、おそらくそのように表示する必要があります。
たぶん、ツリーコントロールは必要ありません。ツリーコントロールは、階層を任意の深さに編集するユーザーに最適です（たとえば、ファイルフォルダーを作成および移動するときなど）。ユーザータスクが何であるかはわかりませんが、いくつかの可能性があります。
I＃1。既知のエンティティの選択
UIの目的が既知のエンティティ（顧客など）を選択してさらに作業することである場合、ツリーは選択を行うのに厄介な方法になる可能性があり、ユーザーは多くの無関係な情報を「ドリルダウン」する必要があります。ユーザーが次のサブセットを入力する検索ダイアログについて考えてみましょう。
エンティティ識別子（またはサブストリング）
ユーザーでも顧客でも
ユーザーまたは顧客は誰ですか
これにより、ユーザーが選択できる一致のリストが生成されます。これは、エンティティ名ADMVOなど、ユーザーが探しているものを知っている場合に最適です。検索IDの空白に「ADMVO」と入力すると、目的の結果が得られます。 「ADMVOが再び顧客になったのは誰か」と考える必要はありません。それにもかかわらず、ユーザーが識別子を思い出せないが、エンティティが顧客または他の誰かのユーザーであることがわかっていて、ユーザーがそれを見ると認識できる場合にも使用できます。 「欲しいエンティティがフォードのユーザーの顧客であることを知っている」、「顧客のユーザーの顧客のすべての顧客を取得する必要がある」などの複数レベルの関係の観点からユーザーが考えていないことを想定しています。 GMの。」それは人間にとって実行不可能なようです。
I＃2。ネットワーク探索
UIの目的がエンティティ間の関係の調査と編集である場合、UIは関係の構造に依存します。あなたの例は、階層がまったくなく、関係のネットワーク構造があることを示唆しています。これは、特定のエンティティ（Volvoなど）が複数のブランチ（たとえば、Fordの顧客であり、GMのユーザーでもあり、システムレベルのユーザーでもある）に表示される場合に当てはまります。異なるブランチに同じ「リーフ」が表示されるツリーによってユーザーが混乱するのではないかと思います。ツリーのメタファーを壊します。
UI＃2aネットワークが比較的スパースな場合（エンティティ間の接続が多くない場合）、ユーザーがズームできるノードリンク図を検討してください。パン、フィルター。リンクの矢印は、誰が誰の顧客/ユーザーであるかを示し、矢印の形状（たとえば、白抜きと塗りつぶし）または線（たとえば、実線と破線）は、関係タイプ（ユーザーまたは顧客）をコード化できます。ツールパレットには、新しいリンクを追加するためのポインターツールが用意されており、移動または削除するリンクを選択できます。
UI＃2bネットワークがノードリンク（多くの相互接続）に対して密度が高すぎる場合は、正方形のグリッドを検討してください。列と行の下。行のエンティティは、上部にあるエンティティの潜在的なユーザー/顧客です。エンティティの各ペア間の関係のグリッドコードタイプのセル。ユーザーはグリッドをパンおよびフィルターできます。ユーザーは任意のセルを選択し、メニューコマンドを使用して関係を変更できます。
＃2aと＃2bの両方で、ユーザーはエンティティを選択し、その詳細（属性）を表示するウィンドウを開くことができます。
I＃3。子の比較と編集
UIの目的が特定のエンティティの子（ユーザーまたは顧客、あるいはその両方）の属性を調査および編集することである場合は、3つのペインを持つマスター/詳細UIを検討してください。上部ペインには、単一のエンティティ（UI＃1を使用して選択された可能性がある）の属性が表示されます。次のペインにはユーザーとその属性が表形式のレイアウトで表示され、最後のペインには顧客とその属性が表形式のレイアウトで表示されます。
ユーザーは、ユーザーまたは顧客の属性を表で直接表示、比較、編集できます。テーブルをエキスパンダーに配置すると、ツリーのように、ユーザーは必要に応じて顧客またはユーザーを表示または非表示にできます。ユーザーは、選択したエンティティを1つの子ペインから別の子ペイン（別の親エンティティの別のウィンドウの別のペインを含む）にカット/コピー/貼り付けすることで、関係を編集できます。
UI＃2と同様に、ユーザーはいずれかの子ペインで任意のエンティティを選択し、そのエンティティの詳細（たとえば、itsの顧客）のウィンドウを開くことができますとユーザー）。