相互に関連するドロップダウンの選択を処理する方法は？
（とりわけ）3つのドロップダウンを含むフォームがあり、それぞれに約5-10の選択肢があります。これらのドロップダウンの選択は密接に関連しており、一部の順列は無効になります。これは、ユーザーがドロップダウンの1つで選択を変更すると、他の2つのドロップダウンの現在の値が無効になる可能性があることも意味します。
私の設計ドキュメントでは現在、「無効な組み合わせが選択された場合、エラーが表示されるはずです」と述べています。 」.
これがこれに対処するための最良の方法であるとは確信していませんが、これ以上の代替案は考えられません。それらをすべての有効な組み合わせを含む単一のドロップダウンに組み合わせることを考えましたが、これも扱いにくい場合があります。
誰か他の解決策を持っていますか？
ドロップダウン間で順序を決定できる場合、解決策は比較的簡単です。
各ドロップダウン選択は、次の（ダウンストリーム）ドロップダウンの選択をリセットします。また、そのドロップダウンの現在の選択に合わせて使用可能なフィールドを更新します（許可されていないオプションはまったく表示されません）。
たとえば、古い地図サイトを考えてみましょう。州、都市、そして道路の順に選択します。州を変更した場合、以前に選択した都市を失うことになります。
明確な順序なしがある場合、次のことができます。
既存の選択と競合する新しい値の選択を禁止します。
これらのオプションは、選択する前であっても、ドロップダウンで（入力したとおりに）「弱く」できると思います。「ローライト」（あなたが言うように）そのような問題のある新しい値ですが、ユーザーがそれらを選択できるようにします。
その後、ダイアログボックスを表示して、新しい値に問題があることを説明できます。
ユーザーは以下を選択できます。- 警告を無視してオーバーライドします。つまり、新しいオプションが選択され、他のドロップダウンで以前に選択されていた競合する値がリセットされます。
- 警告に注意し（ダイアログを閉じる）、別の値を選択します。
。
とにかく、ダイアログには「選択を記憶する」チェックボックスがなければならないので、次回はユーザーを悩ませることはありません。
垂直方向のスペースの不足の問題があるかもしれないと理解していますが、私は間違いなくドロップダウンを使用しないを試して、代わりにリストタイプの要素を使用しようとします（複数またはラジオ入力グループを選択します） ）-これにより、他のグループのオプションに影響を与える1つのグループで何かを選択しているときに発生する変更をユーザーに表示できます。
また、私は少なくとも次のいずれかを試みます。a）最も一般的な選択セットへのショートカットを提供b）すべてをリエンジニアリングすることを試みます。このインターフェースは「シンプル」とは言えませんが、スムーズに実行できます:)
これは何度も見られ、無効な組み合わせを「許可しない」ことは明らかですが、いくつかの欠点があります。
- 中間ステップがすべて「許可されていない」ため、有効な組み合わせに移行するのが難しい場合があります。例えば選択肢A/BとC/Dがあり、AはCでのみ許可され、BはDでのみ許可されている場合、どちらのドロップダウンも他の選択肢に切り替わらないため、ユーザーはA + CからB + Dに切り替えることができません。これは、より複雑なシステムでは特に問題になる可能性があり、ユーザーが許可されていない可能性のある組み合わせをユーザーがよく知らない場合は、法的な中間ステップを見つけることは試行錯誤に要約することができます。
- 禁止の理由は不明瞭で、選択が無効である理由をユーザーに通知したい場合があります。
私が提案するのは、無効な選択を許可しないことです。あなたの仕様はそれらが禁止されるべきであると言っていません。ローライトは同じではありません。違法な選択を法的な選択と区別することにより、強調を解除し、それらを選択できるようにします。これを、不正な組み合わせが選択されたときに表示されるメッセージ領域と組み合わせて、理由を示し、代替案を提案します（ユーザーが次のステップに進むことを許可しません）。
選択肢をシーケンスに分解できる場合、これはすべてnullとvoidになります。選択肢を順番に提示し、各選択肢が提示されるときに不正な選択肢を許可しない方がはるかに理にかなっています。
いくつかの選択肢が無効な場合は、表示しないでください。これにより、ユーザーにエラーが表示される可能性が低くなります。
これがWebアプリの場合は、JavaScriptを使用して、選択に応じて無効な選択肢を排除します。最初のドロップダウンを使用した後、適切なオプションを使用して2番目のドロップダウンを段階的に公開します。 3番目は同上。サーバー側を検証し、サーバー側の検証後に検証されない場合にのみ、エラーを表示します。 JavaScriptが無効になっているユーザー、または意図的にフォームをバイパスしようとしているユーザーにのみエラーが表示されます。
デスクトップアプリの場合は、同じ種類の原則を使用します。