Webサイトでのフォーム入力の代替ツリービュー
現在、ツリービューの形式のデータ構造があります。例えば。
現在、折りたたみ可能なアコーディオンビューを使用して、データを入力する各フィールドを表示しています。
シナリオ-私は約1000までのフィールドと最大約11レベルの深さまで持っていますが、入力するのに平均して約30のフィールドがあり、それは動的でオプションであるため、最大1000フィールド（最悪ケースシナリオ）選択した要件/シナリオによって異なります。基本的にはローン処理システムであるため、特定の銀行では多くの情報が必要です。これは動的なフォームジェネレーターであり、CONTEXTは親ノードを使用して構築されます。
これは主に検証に使用されます。たとえば、間違った国コードを選択した場合、検証エラーを表示する必要があります。また、それがCustomer Maryのアドレスではなく、Customer Johnに属していることを知る必要があります。 CONTEXTを表示します。顧客のJohnが2つのアドレスを持っているなど、複雑なシナリオが考えられます...
状況を表示するためのより良い方法を考えることができないため、現在、すべてが表示されています。問題の内容に応じて、最大1000フィールドですが、Angular UI binding /一度に表示されるフィールドが多すぎる場合のレンダリング。
UXや設計の代替案に関して、助言をいただければ幸いです。
本当に、本当に、本当に何百ものノードを持つツリービューを使用する必要がある場合、それはそれだけである必要があります。非常に基本的なツリービューで、それ以上のものはありません。
この状況は避けられない場合があります。ツリービューは、ページのリロードを待たずに複雑な階層をすばやくナビゲートしたいエキスパートユーザーによく使用されます。
このシナリオでは、アコーディオンを使用しないことをお勧めします。すでに複雑なツリービューをさらに複雑にオーバーロードしています。
1つの代替方法は、ナビゲーションにツリーを使用し、ノードを表示および編集するためのワークスペースを含めることです。その良い例が、Microsoftレジストリエディタです。これは、Windowsのシステム設定の複雑な階層を専門家ユーザーがナビゲートするためのツールです。
ツリーは左側に表示され、ノードエディタは右側のパネルです。特定のノードに関連する警告がある場合は、アイコンを配置できます（例：!）重要なノードの横。
私はさらにお勧めします：
- ユーザーがノードをすばやく見つけられるように、オートコンプリート付きの検索ボックスを追加します。
- エラーのあるノードのキューを処理するようにユーザーに要求する場合は、障害のあるノードの上にパネルを追加します。ノードをクリックすると、正しいツリーノードに移動し、ユーザーがアクションを実行できるようになります。これにより、ユーザーは巨大なツリーをスクロールしなくても、簡単なワークフローでキューを処理できます。
次のアプローチでは問題を解決できないかもしれませんが、現在の実装がユーザーにとって圧倒的であることはかなり確実です。それは多くのパフォーマンスの問題を追加します。また、一度に多くのデータを確認したい場合も理解が困難です。
80:20ルールから始めましょう。
私は何かを設計するとき、私のソリューションがユーザーの80％または要件の80％に完全に適合することを確認します。残りの20％は無視しませんが、80％を考慮して構築された合理化されたシステムに大きな影響を与えることなく、それらのニーズを満たすための回避策または代替策を提供するように努めます。言い換えると、確率ではなく、可能性を考慮して設計する傾向があります。これは、UIのある時点での1000フィールドの最悪のシナリオにほぼ対応しています。間違いなく1000フィールドはAngularに複数のバインディングを作成し、パフォーマンスへの大きな打撃にもなります。
情報アーキテクチャまたは階層を確立します。
当然、UIでデータ構造を複製する必要はありません。可能な1000フィールドをカテゴリーに分離しようと思います。私はそれらの間の共通の特徴を見つけ、それに応じてそれらをグループ化しようとします。これは私の最初のレベルのフィルタリングを提供します。私はフィールドを管理可能なセットに持ってきて、おそらくそれらを編集可能なグリッド（たとえば、連絡先情報）に表示します。私はあなたの場合はわかりませんが、一般的に、あなたが操作して編集するコアデータには、データを豊かにするのに役立つ多くの属性と修飾子がありますが、絶対コアにドリルダウンできます。連絡先情報の例を取り上げました。
ユーザーロールシステム
あなたが述べたように、あなたが行動する必要がある1000のフィールドがあるでしょう。私は、すべてのタイプのユーザーが常にすべての1000を編集できるわけではないという直感を持っています。効果的なユーザーロール管理は、各ユーザーロールに対して責任を分離し、情報アーキテクチャをより適切に設計するのに役立ちます。
表示オプション
また、情報アーキテクチャに基づいて、同じデータを表示したいビューのセットを作成できます。この方法でも、パフォーマンスに影響を与えることなく、すべてのフィールドの編集を許可できます。たとえば、ローン処理システムでは、ユーザーは連絡先住所の管理、連絡先EMIと財務管理、さまざまな支店やノーダルオフィスの管理などに取り組んでいる場合があります。これらのビューや他の多くのビューには、ユーザーにコンテキストを維持し、一度に小さなデータチャンクで作業する方法。これは全体的なパフォーマンスの改善にも役立ちます。
強力な検索
さまざまなフィールド間の依存関係の知識を使用して高度な検索を提供することにより、システムを強化できます。これは、ユーザーがいつでも操作できる管理可能なデータセットを取得するのに役立ちます。
私の提案はあなたの特定の問題を解決しないかもしれませんが、それらのすべては共通の特徴を持っています。ユーザーへの負担を減らし、システムへの負担を軽減するために、データを分類しようとしています。正直言って申し訳ありませんが、コメントでシステムを詳しく説明できれば、後でこの回答を編集できるかもしれません。