web-dev-qa-db-ja.com

レコード内のレコード内に関連レコードを作成して、複雑なデータ入力をどのように処理しますか?

私が扱っているデータベースは、複数の(非階層的な)方法(ドキュメント、人物、場所、イベントなど)で互いに関連しているオブジェクトで構成されています。

新しいレコードを作成するには、ユーザーは他のオブジェクトのさまざまな選択リストから選択するか、新しいオブジェクトレコードを作成する必要があります。これにより、新しいオブジェクトレコードの作成などにつながる可能性があります。

いずれにしても、ユーザーがレコードの作成を完了するのに長い時間を要し、後で情報を追加する必要がある場合があります。

詳細については、スクリーンショットをご覧ください。

relationship overkill

クリックして拡大

この問題を解決する方法がわかりません。ウィザードが制限的である可能性があります。必要なときにスライドアウトするサブフォームはどうですか?ナビゲーターとしてのツリーレイアウト?助言がありますか?

ご意見ありがとうございます。

12
Christine

この状況を次のように説明します:動的なネストされたワークフロー

  • Dynamicワークフローのネストの深さを事前に知ることができないためです(ユーザーは新しいオブジェクトを作成しないか、複数の運送業者と人物を作成する場合があります)。
  • Nestedキャリアを作成するためのワークフローと、次に人が入れ子になるためです。

動的なネストにより、この種のワークフローをウィザードでレイアウトすることが難しくなります。

ネストされたワークフローの一般的なUXは、スタックモーダルです。これは、親ワークフローで進行を行う前にサブワークフローを完了する必要があるため、モーダルウィンドウが適切なブロック動作を提供してこれが確実に行われるようにするためです。以下は、Microsoft Windowsインターフェースからの積み重ねられたダイアログです。

stacked

スタックされたモーダルは視覚的な混乱を作成するため、一般的に優れたレイアウトではありませんが、 X階層 では、機能と使いやすさが美学よりも優れているため、通常はワークフローをネストしてデザインを選択すると、 。

5
tohster

私は非常に強力ないくつかの「柔軟な」データベースを使用してきました。しかし、ユーザーインターフェイスに関して言えば、私のユーザーがそれを処理できる唯一の方法は、そのようなシステムのエキスパートであり、私のユーザーは誰もいなかったということです。

説明したシステムはユーザーフローの定義であると考えるのではなく、システムがユーザーフローをまったく定義していないと考え、フロントエンドを構築して、ユーザーが自然にフローするようにしても、いくつかの部分をスキップして、後で埋めるようにします。ただし、ユーザーの自然な流れを理解し、それをガイドする必要がありますが、その作業はまだ完了していないようです。

データを見るための高度な方法を提供する必要があり、タブのオプションが多すぎる場合、ファイルフォルダーやファイルなどの左側のアイデアのツリー構造は、物事とやり取りする快適な方法です。私は常にツリーの上に「すべて展開」および「すべて折りたたむ」ボタン/リンクを含めますが、それは厳密に必要なわけではありません。この種のインターフェースを理解して効率的に使用できるユーザーはほとんどいないことに注意してください。

1
Guy Schalnat

データの作成と使用は通常、プロセスのさまざまな部分であり、これを認めることでシステムを簡略化できます。

  • データの作成は、基本的にはOwnerAuthor、およびPlaceロールの基になるオブジェクトを作成する、低レベルの単純な操作です。おそらく、OwnerAuthorPersonオブジェクトによって再生され、PlaceAddressになる可能性があります。

  • データを使用することは、ユーザーが有用なシステムで何をするかであり、情報の断片間を接続します。 Information Carrierはそのようなコネクタのようです。これは、システムの説明された部分が行うべきことです。

説明したようなインターフェイス、基本的にはデータベースGUIを使用すると、基礎となるデータに慣れていないため、ほとんどのユーザーにとって低レベルになります。スクリーンショットにあるように、ユーザーがDocumentについて考えるとき、OwnerではなくAuthorPersonについて考えます。これらの両方の基礎となるオブジェクト。ユーザーには不明な情報が含まれますが、データモデルで必要になる場合があります。

したがって、「ドキュメントへの情報の接続」のプロセスでユーザーがPersonを作成することを強制/許可すると、メンタルモデルが一致せず、エラーが発生しやすくなる可能性があります。

だから私の提案は、作成と使用を分割することです:

  1. システムの別の部分に基本データオブジェクトPersonAddressPictureなどを作成します。

  2. ドキュメント作成ページは、接続を作成するだけに簡略化できるようになりました。できれば、スクリーンショットにモーダルダイアログのスタックが表示されないようにするために、同じページのすべてのものを作成してください。既存のデータを選択することだけが目的の場合は、これで可能になります。

  3. 新しいデータを作成する必要がある場合は、それをシステムの他の部分で行い、ドキュメントの作成に戻って、手動または自動で選択フィールドを更新します。

ほとんどの新しいドキュメントに対して新しいデータを作成する必要がある場合、既存のデータのインポートや、ほとんどのリレーションがテキストフィールドに削減されるほどデータモデルを単純化するなど、解決する必要のある情報の問題がある可能性があります。 Addressがそのようなケースである可能性があります。詳細なデータ分析なしでは知るのは難しいです。

0
ciscoheat