私はこの階層構造を持っています。わかりやすくするために、これを郵送先住所と呼びます。
国
- 市
- - 通り
- - - 住所 #
--------アパート#
各アパートメントに設定を提供する必要がありますが、データ設計では国レベルで設定を定義でき、下位レベルでオーバーライドされない限り、下位レベルに「伝播」します。したがって、設定x
はどのレベルでも定義できますが、アパートメントで有効な設定は、階層で最も近い場所で定義されたものになります。
現在、私はOrigin
フィールドと一緒に設定を表示することでこれを解決しています:ユーザーが階層内のアイテムを選択すると、そのレベル以上で定義された設定には、設定を指定するフィールドも含まれますが定義されている(1つのアパートが選択されている例):
setting Origin value
deliver mail country (U.S.) xxx
take out trash street (Elm street) yyy
wash the dishes apartment # (3a) zzz
ただし、このソリューションは私の顧客(アプリを注文したマネージャー)の混乱を混乱させます。
彼らは単にデザインを理解することができません。簡単に言うと、この設計に対処するよりも、各アパートメントに同じ設定を入力するほうがよいでしょう。彼らは、通り全体を担当するものを修正するだけでなく、アパート間で設定をコピーしたいのです。
現在、最終的なソリューションとして、構造全体を1つのスプレッドシートにフラット化するExcelエクスポート/インポートを要求しました。これは、明らかに、この(フラット化された)構造が理解できるためです。
顧客が理解できるようにこのデータを提示するためのより良い方法は何ですか?
ユーザーがメリットを享受できるアフォーダンスを提供しているように見えますが、意味のある用語で説明しています。伝播と階層の概念を使用するのではなく、より一般的な「このようなすべてに適用する」パターンを使用するように設定します。
機能のプレゼンテーションは次のようになります。
これはバックエンドからエレガントではありません。複数の設定が存在し、特定性によってランク付けされるCSSスタイルのソリューションではなく、その時点で階層をたどって、個々のアパートメントに設定を適用します。新しい設定は、その階層内に追加された新しいアパートメントのデフォルトにはならないため、ユーザーにとってより多くの作業を意味します。
ただし、これは彼らの期待に沿ったものであり、方法を学ぶ必要がないので、これは彼らにとってははるかに認知的の仕事になると思われます継承の観点から考えること。彼らがあなたの現在の提案に対してこれを強く押し戻しているなら、これは良い妥協かもしれません。
もう1つのポイントは、「設定」が「タスク」または「アイテム」と呼ばれるもののように見えることです。私にとって、「設定」は構成オプションを指します。これがさらに混乱を引き起こしているかどうかを確認したい場合があります。
それぞれのデフォルト値をハードコードするか、「設定」ページを追加して、ユーザーがそうできるようにします(つまり、mail = xxxを配信し、trash = yyyを取り出し、dishes = zzzを洗います)。
アパートメントを表示するときは、それぞれの値と、値がオーバーライドされたレベルを示すいくつかのリストを表示します。以下のテキストを使用していますが、アイコンの使用を検討し、元のデフォルト値を使用する場合は空白のままにすることを検討してください。
「ゴミ出し」の値をクリックするとダイアログが表示されます。値または「空」のインジケーター(私は--
)ダイアログがクリックされたら、ユーザーがインライン編集できるようにします。
ごみを出します
これは、ユーザーが必要とするカスタマイズの量によって異なります。
顧客が最低レベルでも高度なカスタマイズを必要とする場合、すでに提示されている表形式のアプローチが目的に役立ちます。
カスタマイズのレベルが低い場合、つまり下位レベルの例外がほとんどない場合は、階層のグループ化アプローチに利点があります。実装例は添付の通りです。 Excelベースの表形式のアプローチは、それほど便利ではないかもしれません。 サンプルXMLファイル