Webフォームのベストプラクティスのリストから何かを見逃しましたか？
だから私は最近フォームに適用するためのベストプラクティスのリストをまとめており、そこには相反する研究がたくさんあります。私はブログからHCIカンファレンスレポートまで、あらゆるものを調べてきました。それで問題は、私が何かを逃した、または研究を通して明らかに反駁された何かを含んでいたのでしょうか？
フィールドラベル
以下はテーブルであるはずですが、UXはそれらを適切にレンダリングしていないようです
ラベル配置
Short form with simple/short labels = On top or to the left, but right aligned
Short form and complex/long labels = To the left and left aligned
Long form and simple labels = To the left, but right aligned
Long form and complex labels = To left and left aligned
- ラベルはタイトルのケースではなく文のケースを使用する必要があります。人間の目が読みやすいからです。
- 同様の理由で、太字テキストもフォームラベルに使用しないでください。
必須フィールド
- フォームの上部にある必須インジケータの意味を説明する凡例
- フォームフィールドラベルの後に表示されるアスタリスク（標準インジケーター）
- アスタリスクは、理想的には色で強調表示する必要があります-慣例により赤
- エラーを見逃すのは簡単で、色覚異常の人には難しいなどの理由で、色のみに依存しないでください。
- オプションのフィールドを示すためにアスタリスクを使用して、アスタリスクの意味を混同しないでください
- まず、オプションとしてマークされたフィールドは、通常は避ける必要があります
- 次に、フィールドラベルの後に完全なWordが表示されます。 （オプション）
ボタン
- 送信ボタンはフォームの下部に表示され、右揃えになっている必要があります
- リセットボタンは実際の人には役に立たないので、誤ってクリックしたときに迷惑になるので避けてください。
- 完了までのパスをできるだけ可視化します-1つのボタンは、選択の余地がないため、負荷が少なくなります。
グルーピング
- 関連するフィールドは論理的にグループ化する必要があります
- フィールドセットを使用して3つ以上のフィールドをグループ化することを検討してください
エラー
- 色だけに依存しないでください-すべてのエラーはテキストの説明を伴う必要があります
- フォームの上部に、フォームに修正が必要なエラーがあることを示すメッセージが表示されます
- 特定のフィールドの問題を説明する各フィールドの個別のエラーメッセージは、ラベルとフィールドの上に表示されます。
- ユーザーがメッセージを解決するときに、可能な場合はクライアント側の検証によってメッセージを削除する必要があります
- エラーメッセージが適切な長さであり、フォームの幅が広すぎない場合、メッセージはラベルとフィールドの右側にも表示されます。
リストを選択
- 3つ以上のオプションに使用する必要があります-これより少なく、ラジオボタンを使用する必要があります
- 15を超えるオプションは常に Chosen プログレッシブ拡張スクリプトを使用する必要があります
- Chosen を使用する場合、フォーム内の他の選択リストはそのスタイルを維持する必要があります
- それらは非常に重く、目を引くので、控えめに使用してください
- 選択リストの最初のオプションはプレースホルダーでなければなりません
- プレースホルダーは、アクションとして書き直されたラベルを反映する必要があります
ラベルとしてのプレースホルダー（ala Apple store）
- フォームを送信する前に確認することが困難になるため、これらは避けてください。
- フィールドにフォーカスが与えられると、それらはわずかにフェードするはずです
- ユーザーがテキストを入力してキーアップをトリガーしたときにのみ非表示にするプレースホルダー
日付フィールド
- カレンダーの日付ピッカーを使用して強化する必要があります
フォームの成功
- フォームが正常に完了したときに確認ページにユーザーをリダイレクトします
成功時のリダイレクトにより、「送信された情報を再送信するかキャンセルしますか？」などのメッセージが表示されなくなります。また、ユーザーによるページの更新と再投稿のトリガーを停止します。
アクセシビリティ
- キーボードのみのユーザーに論理タブオーダーを提供します。
- スクリーンリーダーユーザーのすべてのコントロールにラベルを提供します。
あなたはこれらのリンクでより多くの情報を得ることができます：
http://www.jimthatcher.com/webcourse8.htm
http://www.afb.org/section.asp?SectionID=57&TopicID=167&DocumentID=2375
ユーザーインタラクション
- 寛容なフォーマット：ユーザーがさまざまなフォーマットや構文でテキストを入力できるようにし、アプリケーションにそれをインテリジェントに解釈させます。 （ ジェニファー・ティドウェル）
- 入力ヒント：空のテキストフィールドの横に、何が必要かを説明する文または例を配置します。 （ ジェニファー・ティドウェル）
- 適切なデフォルト：必要に応じて、ユーザーが希望する値を最もよく推測してフォームフィールドに事前入力します。 （ ジェニファー・ティドウェル）
フォームを整理する
- フォームが複数のページに分割され、フォームが非常に長い場合、またはフォームを段階的にまたは特定の順序で実行するのが自然な場合は、ウィザード（プログレスバー付き）を使用します。
- レスポンシブ開示 または Responsive_Enabling ：フォームの一部がめったに実行されない場合は、必要になるまでこの部分を非表示/無効にすることができます。
テスト中
- フォームでいくつかのユーザーテストを実行します。完了までにかかる時間を測定し、ドロップアウトを測定して、あいまいさを取り除きます。
- さまざまなブラウザーやさまざまなデバイス（例：タッチデバイス）でのフォームの外観と動作を確認します。
いいリスト。 JavaScriptを使用していないユーザーがフォームをどのように機能させる必要があるかを詳細に説明するだけで追加できます。
JavaScriptを使用しないユーザー
- たとえば、ラベル、日付ピッカー、インラインエラーなどのプレースホルダーには、特定のスクリプトなしの代替手段が必要です。
すべての質問に対する答えは1つではありません
あなたが言うように、研究はここで矛盾します。私には、これらの問題に対する一方向の答えはありません。これらの多くは、それらが使用される状況により依存していると私は言うでしょう。リストのすべての項目をチェックして完了したと考えるのではなく、一連の一般的なアイデア（ Pau Giner 回答など）を適用する方が良い場合があります。
フレンドリーになる
私は1つの一般的なルールを追加します：ユーザーに親切にします。
たとえば、there are errors in the formと言って障害を与えないで、代わりにalmost there! can you fill in that field as well?のように言います。別の例は、フォームに問題があると言った後、フィールドに入力したことを記憶することです。
しかし、これも例にすぎません。私には、そのような一般的なルールを覚えておく方が良いでしょう。
例を示すための少しのニュアンス
まず、オプションとしてマークされたフィールドは、通常は避ける必要があります
特にフィールドのセットと組み合わせて使用する場合は、必須フィールドとオプションフィールドの両方にマークを付けると非常に良い場合があります。また、たとえば、> Advanced optionsセクションのすべてのオプションフィールドを非表示にすることができます。
送信ボタンはフォームの下部に表示され、右揃えになっている必要があります
これは、フォーム全体の外観、およびラベル、フィールド、およびページの残りの配置方法によって異なります。 Daniel Newman とも言われています。
フォームの上部に、フォームに修正が必要なエラーがあることを示すメッセージが表示されます
特定のフィールドの問題を説明する各フィールドの個別のエラーメッセージは、ラベルとフィールドの上に表示されます。
「エラー」が1つしかない場合は、一般的な「フォームにエラーがあります」とユーザーに任せるのではなく、そのエラーの詳細を直接上部に示します。
[選択]プレースホルダーは、アクションとして書き換えられたラベルを反映する必要があります
その件名についてはより複雑な答えがあります。 [必須のドロップダウンリストのデフォルトオプションは何ですか？ を参照してください。
[ラベルとしてのプレースホルダー]フォームを送信する前に確認することが困難になるため、これらは避けてください。
短いフォーム（最大5つのフィールド）では、問題である必要はなく、よりクリーンなフォームを作成できます。また、入力するフィールドについて常にフィードバックがある場合は、送信する前にすべてをチェックする必要が少なくなります。
[日付フィールド]カレンダーの日付ピッカーを使用して拡張する必要があります
希望する日付に依存します。本当に1日の精度が必要ですか？たとえば、将来的に何かを思い出させるように人々に依頼する場合、tomorrow, Saturday, next weekのリストでも十分です。
フォームが正常に完了したときに確認ページにユーザーをリダイレクトします
確認ページは常にthing successfully addedとは限りませんが、追加されたものを表示することもできます（ここに回答を投稿するときなど）。リダイレクト部分（更新警告を防ぐ）は良いことですが。
お役に立てば幸いです。
非常に、非常に役立つ投稿。私がお勧めする唯一の変更：
ボタン
送信ボタンはフォームの下部に表示され、右揃えになっている必要があります
送信ボタンの配置はフォームのスタイルに依存すると私は主張します。多段階の「ウィザード」では、次/続行/送信を右揃えにすることに同意します。ただし、より単純なフォーム（特にボタンが1つしかない場合、戻る/前のボタンがない場合）では、ボタンを入力フィールドと左揃えにして、視覚的な固定を最小限に抑え、ユーザーの視覚パスを追跡する必要があると考えています（出典： "フォームボタンを配置する方法" ＆ "フォームのボタンを配置する最良の方法" ）。
また、このセクションに追加するには、送信ボタンに決して「送信」というラベルを付けないでください。むしろ、それらはタスク固有でなければなりません...例「アカウントの作成」、「今すぐ購読」など（出典： "フォームのボタンで送信と言ってはいけない理由） ）
一般的でありながらフォームデザインに適用できるいくつかのデザイン原則：
不要なものを避けます。フォームの目的とは無関係の情報を尋ねないでください。特定の形式を要求する代わりに、柔軟な入力、構造化入力、または空白入力アプローチを使用します。
情報を整理します。レイアウトに関するほとんどの原則はすでにコメントされています。
ユーザーにガイダンスを提供します。ユーザーは、何を、なぜ、どのように答えるかを明確にする説明が必要です。
故意に物事を難しくしないでください。オプションを非表示にしたり、ユーザーを強制的に選択したりしないでください（ニュースレターの購読など）。代わりに利点を説明してください。
数か月前、私はそれらの原則について投稿しました。詳細と例は http://pauginer.tumblr.com/post/7080830292/form-design で入手できます。
フォームをデザインする方法よりも、収集するデータについて、いくつか追加できます。
ユーザーについて知っておくべきことが1つだけある場合は、それについて尋ねます
多くのWebページおよびサービスは、ユーザーについて知る必要がある2つのことの1つだけであることが多い場合に、ユーザーに関するあらゆる情報を要求します。たとえば、未成年者に不適切なコンテンツを提供している場合、本当に尋ねる必要があるのは「16歳以上ですか？」だけです。 -私の名前、メール、電話番号、生年月日を要求しないでください。
ユーザーがすでにデータを送信している場合は、再度要求しない
ユーザーが何度もデータを入力するのは面倒なだけではありません。ユーザーに複数回の送信を行わせる場合、同じデータを入力して重複レコードを作成する可能性は常にありますわずかに異なる。 John Smithが1つのフォームで「John William Smith」を送信し、次のフォームで「John W Smith」を送信するとします。これらの重複したレコードは、あなたの両方にとって重大な頭痛の種となりますandユーザーは、さらに将来のことです。
ヒューリスティックからデータを推測できる場合は、それを試してください
特定のデータを示唆するユーザーに関する他の情報がある場合は、フォームのオプションを適切にデフォルト設定してみてください。たとえば、ユーザーがフランスのIPアドレスから接続している場合は、「国」を「フランス」に設定します。ユーザーにソフトウェアのダウンロードを提供し、ユーザーエージェントがLinuxの使用を提案している場合は、デフォルトでLinuxバージョンを提供します。
個人的には、必須フィールドを示すためにアスタリスクを使用しません。デフォルトでは、すべてのフィールドが必須です。追加のオプションフィールドの横に「（optional）」と入力します。
両側で検証：
ux用のクライアント側。理想的には、html5属性だけでこれを実現できます。
サーバー側、検証用;すべてのフォームコントロールを検証して、フォーム送信が確実に成功するようにします。
ボタン
input:reset要素は"cancel"のラベルで使用でき、shouldを使用できます。また、input:submitボタンとは明らかに異なるように見える必要があります。多くの場合、キャンセルボタンは追加機能を実行する必要があります（たとえば、ユーザーを前のページ/ステップ/状態/何にでも戻す）機能の一部は、すべてのデータのフォームをクリアすることも必要です。