ラジオボタンに必要なインジケーターは必要ですか？
簡単な質問です。フォームにラジオボタンのセットを表示するときに、必須フィールドインジケーター（例：*）が必要ですか？
警告、1つのラジオボタンが既に選択されています。
技術的には実際にフィールドの質問が必要ですが、1つの選択が常に選択されるという事実は、それが必要であることを視覚的に示す必要性を否定しますか？
目下の問題は、正しいアスタリスクマーキングルールの問題でも、ラジオボタンコントロールの背後にあるメタファーの文字どおりの解釈でもないようです。
むしろ、説明との矛盾は次のように見えます。2つのラジオボタン選択インスタンスが必須としてマークされている一方で、要件は事前入力された選択によってすでに満たされています。ただし、本当の要件は、ユーザーが何かを選択するのではなく、意味のある選択を行う必要があることを私に思わせます。
それでは、まずが実際に発生することを確認し、、次に適切なUIプレゼンテーションについて考えます。
事前に入力されているが必要な選択は、一時的に不注意なユーザーが実際に選択するものではない「既定の」選択に同意する場合があるため、問題になる可能性があります。設計上の問題は、の場合よりも少なくなります。「続行するには、古い選択を行う必要があります」、および必要な選択に関する厳密な規則に準拠していますが、 "利便性のために事前に入力されているラジオボタンの選択が実際に希望するものであることを確認してください"。
はい、requiredを示すアスタリスクは、他の人が書いたように技術的に冗長です。しかし、ユーザーがこのページで正確な情報を提供することが重要である場合（そしてが必要が示唆すること）、ラジオボタンを含め、すべての選択肢を不確定な開始状態で提示します。何も事前に入力しないでください。
これにより、初めてのユーザーが一連のフォームに遭遇したときに、アクション「キャンセル」と「保存」を呼び出す前に、すべてのフォームに入力、チェック、および選択（「署名、封印、配信...」）する必要があります。 'それらを利用できるようになります。
ラジオボタンコントロールの物理的なメタファーが「モグラ叩き」動作のタイプを示唆している場合でも、ラジオボタンタイプコントロールのセットを最初は選択されていない状態で提示することは、私の心にはまったく問題ありません。 、他のすべてのものは飛び出します」のようなものです）。ただし、これは単なる比喩であることを忘れないでください。ある種の開発キット、またはAxure RPなどのプロトタイプアプリケーションで作業している場合、そのようなUIコントロールは通常、最初はブラックボックスの動作を備えたライブラリ「ウィジェット」として提供されます。これは不幸な制約ですが、多くの場合、オーバーライドできます。プログレッシブ開示が行われている場合、つまり、さらに下のページに表示される選択肢のセットが以前のラジオボタン設定に依存している場合、ラジオボタンセットをnil状態に戻す「クリア」関数を追加することもできます。
UIの例を見てみると、すべてのフォームが必須であることがわかります。
それらを繰り返しマークする効果（*）は、制約がすべてに共通しているように見えるため、洗い流されます-実際のフォームが長く、単純にするための抜粋を提示している場合、またはフォームがさらにいくつかのページで構成されている場合を除きますどの強制選択がオプション選択と混在しています。
したがって、ユーザーを次の2つの方法で監視します。
集合的な見出しのサブキャプション "すべての選択が必要です"。すべての選択が本当に必要な場合は、不明確にしないでください。
最後の選択までのすべての選択が行われるまで、「保存」を無効にします。 「キャンセル」をアクティブのままにします。これは、ユーザーがフォームを安全に終了できる方法です。
上記により、行動を促すフレーズがブロックされる理由をユーザーに明示的に口頭で伝えます。さらに、可能性のあるすべての選択を初期状態で不確定状態にして、ユーザーに-適切に-意図的に目的を提供するように強制します。自動操縦モードでの選択。
最初にと言ったことに注意してください。上記は、初めてユーザーがフォームを見つけなければならないカルトブランチの状態を説明しています。ユーザーがアプリケーションに私の設定を記憶するように指示できる機能がある場合、すべての選択が固定され、（必要に応じて、または単にそのままにして）編集できますその後の訪問。
お役に立てば幸いです。最高の成功！
ユーザーがフィールドに何かを通知する必要がある場合にのみ、フィールドを必須としてマークする必要があります。この例では、ユーザーがフィールドの値を変更する必要がないため、フィールドにマークを付ける必要はありません。
必須フィールドで事前選択またはデフォルト選択を行う場合、ユーザーの観点から要件を解釈することには潜在的な問題があります。ユーザーに適した選択肢がなく、フィールドが必須である場合、ユーザーがこれに該当することを示すことを許可していません。
通常の方法では、絶対に必要なフィールドのみを必須にし、フィールドが必須の場合は、ラジオボタンを使用してすべての潜在的な可能性が確実にカバーされるようにします（「その他」を使用するなど）。
事前入力情報は、ユーザーからいくつかの情報があり、プリファレンスの強力な指標を提供する場合に最適に機能します。そうでない場合、ユーザーが実際に読んだことの確認を必要とするときに、すでにデータが入力されているフィールドをスキップして、詳細を記入。
私が読んでいることから、オプションのフィールドのみをマークする方がユーザーにとっては簡単です。あなたが示したことから、すべてが必要なので、なぜ*のノイズを追加するのですか？そのモデルに切り替えることで、問題は解決されます。
保持する必要がある場合は、ラベルの最後に配置して、色を灰色に変更します。