10

Let me first say, we validate every field on the server side, so this a question about client-side usability.

What is the conventional wisdom on exactly when to validate and format html form input fields using javascript?

As an example, we have a phone number field. We allow numbers, spaces, parentheses, and hyphens. We want the field to have ten digits. Also, we want the field to look like (123) 456-7890, even if the user doesn't type it that way.

It seems like we can

  • Validate and format it when the user exits the field.
  • Validate and format on every character entered.
  • Intercept keystrokes and prevent the user from entering characters that are wrong.
  • Some combination of the above (e.g. format on entry and validate on exit, prevent on entry and format on exit, etc.)
  • [Added] Wait and do all the validation and formatting when the user clicks submit.

I've seen it done all of these ways, but I can't find information about what is best (or even generally accepted) from a usability perspective, and more importantly, why.

[Edit: Some clarification]

We are absolutely not enforcing any format standards. When I say format, I mean we'll use javascript to rewrite things so they look nice. If the user types 1234567890, we'll change it to (123) 456-7890. There are no "formatting rules" that can fail.

I distinguish this from validation because if they don't type enough numbers, we have to make them fix it.

I guess I should rephrase the question as "what is the conventional wisdom on exactly when to validate and exactly when to format...?

Good info in the answers so far!

EDIT: I'm accepting my own answer below in the hopes that others will find the link as helpful as I did.

4

9 に答える 9

2

ユーザーがフィールドを終了するときに検証してフォーマットします。

はい。検証またはフォーマットのルールが失敗した場合は、非侵襲的なフィードバックをユーザーに提供します。非イナシブとは、アラートまたはモーダルダイアログボックスをポップアップしないことを意味します。これにより、ユーザーは何かをクリックする必要があります。むしろ、検証またはフォーマットが失敗したフィールドの隣または下にメッセージを動的に表示します。

入力したすべての文字を検証してフォーマットします。

いいえ、使い勝手が悪いと思います。代わりに、フォーマットルールまたは検証ルールが何であるかに関するツールチップまたはその他のヒントをユーザーに提供します。たとえば、「必須」フィールドの場合、実際にはどこにでもあるアスタリスクがあり、フォーマットのあるフィールドの場合は、予想されるフォーマットが何であるかをユーザーに事前に知らせます。

キーストロークをインターセプトし、ユーザーが間違った文字を入力できないようにします。

ユーザーが無効な文字を入力できないようにする場合は、非侵襲的に入力をブロックした理由をユーザーに伝えます。また、フィールドの焦点を盗まないでください。

したがって、私にとっての一般原則は次のとおりです。

  1. 検証とフォーマットのルールについて事前にユーザーに通知します。
  2. ユーザーが目撃されていると思い込まないでください。そのため、Webアクセス可能性とスクリーンリーダーを念頭に置いてください。（イントラネットなど、ターゲットオーディエンスが限られているWebサイトを開発している場合を除きます。）
  3. 非侵襲的なフィードバックをユーザーに提供します。つまり、失敗するたびにユーザーにアラートボックスやモーダルダイアログをクリックさせないでください。
  4. どの入力ボックスが検証またはフォーマットルールに失敗したかを明確にし、入力が失敗した理由をユーザーに伝えます。
  5. フィードバックを提供するときは、マウス/ポインタのフォーカスを盗まないでください。
  6. キーボード指向のユーザーがフィールドに入力したときにタブを押して次の論理入力/選択フィールドに移動できるように、タブの順序を覚えておいてください。
于 2008-09-22T19:15:15.877 に答える
1

さまざまなオプションを説明するつもりでしたが、既存の js フレームワークを使用して入力マスクを処理するだけでも有益な場合があります。ここでは、さまざまなオプションの概要を説明します

于 2008-09-22T18:54:31.873 に答える
1

bmb は、任意の形式を受け入れ、それを目的の形式 (xxx) nnn-xxxx に変更していると述べています。それはとても良いことです。問題は、A) フォーマットの変更、および B) 検証のタイミングです。

A) ユーザーがフィールドを出るときにフォーマットの変更を行う必要があります。すぐに面倒で、後で変更を表示するという目的をまったく無効にします。

B) 検証は、フィールドを終了するとき、またはフォームを送信するときに最も適切に実行されます。すぐにイライラし、ユーザーを混乱させます。複数の画面を含む長く複雑な形式では、修正を容易にするために、コントロールを終了するときに検証を行うことをお勧めします。短いフォームでは、フォームへの記入の流れを壊さないように、送信時にそれを行います。これは実際には判断が必要なため、可能であれば実際のユーザーでテストしてください。

とにかく実際のユーザーで作業をテストすることが望ましいですが、そのための予算やアクセスがない場合は、迅速で汚い「ユーザー」テストがこのような決定に役立ちます。ソフトウェアの開発に携わっていない少数の人々(実際のエンド ユーザーにできるだけ近い人) を集めて、フォームに記入するように依頼することができます。エラーを取得するために具体的に入力するように指示し、それを修正するのを見てください。彼らの思考プロセスを推測する必要がないように、彼らが何をしているかを声に出して話してもらいます。彼らがどこに問題を抱えているか、何が彼らを最も混乱/苛立たせているように見えるかを探します。

于 2009-09-17T19:11:52.763 に答える
0

最初の 3 つのオプションは本当に面倒だと思います。何かを入力している最中に中断されることほど悪いことはありません。

ユーザーの主な目標は、できるだけ早くフォームを通過することであり、フォームを遅くするようなことをすることは、フォームを完全に放棄するもう 1 つの理由にすぎません。

また、クレジット カード番号や電話番号などの入力を強制されるのも嫌いです。これは、フォームを満たすのに最適な形式です。可能な限り、ユーザーに何かを入力するためのボックスを提供するだけで、書式設定を処理させないようにします。

あなたの電話番号の場合、好きなように入力させ、気に入らないものはすべて取り除き、必要な形式にまとめ直してください ( (124) 567-8901 )。できません。

何かを特定の形式で検証する必要がある場合は、フォームを送信するときに検証してから、問題のあるフィールドを強調表示します。

于 2008-09-22T18:52:28.710 に答える
0

フィールドごとに異なります。しかし、電話番号のようなものについては、一般に、誰かが数字以外を入力することさえできないようにすることは非常に良いことです。

そうすれば、入力時に 1-800-HELLOWORLD の電話番号が正しく表示されないことに気付き、フィールドが数字のみを受け入れることに気付くでしょう (入力フィールドの横にある種の情報フィールドで強調表示することもできます)。

これは、扱いにくいモーダル ダイアログ、ポップダウン エラー フィールド、入力後にサーバーが生成するメッセージの表示よりも、はるかに直感的で使いやすいように思えます。

もちろん、最終的なクライアント側の検証と、それを構築するための最終的な技術要件とのバランスを常に取ってください。たとえば、ページが送信される前に Ajax を使用して画像のアップロードを検証するという道をたどり始めると、かなり長い道のりになる可能性があります。

編集：また、聴衆を考慮してください。技術志向の強い人は、インターネットへの非 Ajax アプローチに慣れている人よりも、「動的な」フォームを受け入れる傾向があります。

于 2008-09-22T18:54:05.273 に答える
0

私が見た中で最も使いやすい検証方法は、入力フィールドの横に値が無効であることを示すインジケーターを表示することです。このようにして、ユーザーが入力しているときに中断することはありませんが、ユーザーは有効なエントリを入力したかどうかを継続的に確認できます。最後に「ああ、戻ってフィールド1を修正する必要があります」と言われるだけで、情報を長い形式で入力する必要があるのは嫌いです。

ユーザーの入力に応じてインジケーターを表示/非表示にすることができます。値が無効な場合は警告アイコンを使用し、値が無効な理由を説明するツールチップをアイコンに設定します。

画面のスペースがある場合は、「有効」や「XXX-YYY-XXXX の形式である必要があります」などのテキストを入力するだけでかまいません。

キーストロークごとの検証を行うときは、貼り付けられたテキストもキャッチする必要があることに注意してください。

これに加えて、そもそも無効なキーストロークが入力されないようにする必要があります。

于 2008-09-22T18:58:34.233 に答える
0

ユーザビリティのベスト プラクティスについては、How To Design The Perfect Form (より正確にはContext & Assistance ) とBeautiful Formsを読むことをお勧めします。

フォーム検証フレームワークについては、fValidatorとiMaskの組み合わせを確認してください。これらは補完的であるため、完全に連携して動作します。

于 2009-09-17T19:44:40.733 に答える
0

個人的には、終了時の書式設定と検証は、ユーザーにとって最も煩わしいことではないと思います。好きな形式で番号を入力してもらい (電話番号には多くの形式があります)、好きな形式に変更します。好みの形式でデータを処理できる場合は、好みに合わせることをユーザーに強制しないでください。

また、入力が完了していないときの検証メッセージは煩わしく、特定の文字をテキスト フィールドに入力できないのは非常に煩わしいものです。

私が考えることができる唯一の例外は、「この値は利用可能ですか」という状況 (一意のユーザー名の作成など) です。その場合、即時のフィードバックは非常に便利です。

于 2008-09-22T18:55:58.607 に答える