私は、外部の顧客に販売される会社のWebアプリの重要な部分を再設計するという難しい課題を抱えています。この機能の背後にある一般的な考え方は、企業が内部の従業員が購入できるようにする複雑なアイテムを作成する方法を求めているということです。
これは、顧客が作成できる使用可能な構造です。一部の顧客がすでに悪いデータを持っているため、残念ながら、これは今の状態のままでなければなりません。
この機能を使用すると、顧客ごとに異なるニーズと目標がありますが、多くの顧客は非常に複雑なアイテムを作成しており、200以上の親レベルのオプションセットがあります。
ツリーにリストされている各アイテムには、それらに関連付けられている特定のフィールド(名前、画像、説明、値など)があります。つまり、アイテムを選択してデータを編集する必要があります。私はいくつかの異なる方向(ノードツリー、リストツリー、ミラー列、および本文のコンテンツ領域にすべてのセクションと入力フィールドがある)を試しましたが、誰かがこれについてある程度の経験があるか、いくつか提供できることを望んでいましたフィードバック。
ノードツリー
リストツリー
ミラーカラム
体に露出したすべてのもの
情報の提示のために設計する場合、基礎となるデータ構造と異なるデータセット間の関係にできるだけ密接にインターフェイスを適合させることを試みることが重要です。一般的には、関係をできるだけ単純にすることが目的であり、意味がある場合はデータ構造の組み合わせを使用することも意味する場合があります。
ただし、提供した情報のみに基づいて、データ構造が各ポイントで複数の可能な接続と分岐を持つWeb /マップに似ていることがわかった場合、ノードツリーはおそらく良い戦略です。 Millerカラムの場合、あまり深く掘り下げないトップレベルアイテムの幅広いリストを参照していることになります。また、リストツリーは、特定のタイプの構造に対して最適ではないという犠牲を払って、柔軟性を提供します。別の考慮事項は、完全な構造/階層を提示することがユーザーが特定の決定を行うのに役立つかどうか、またはそれがコンテンツに移動するための単なる手段であるかどうかです。
純粋に設計の観点から判断するのが難しい場合は、ユーザーが一般的な操作を実行するために必要なナビゲーションの量をシミュレートして、情報を整理する方法がどれだけ少ないかを確認することもできます。ほとんどのアイテムをクリックして配置したり、画面間を移動したりできます。
また、これは暫定的な解決策のようですが、データ構造を設計する新しい方法は、情報を提示するためのより簡単な解決策を提供します。したがって、おそらく、これを行うためのコストと労力、およびこのソリューションに多くの注意を払う価値があるかどうかについても考慮する必要があります。