リアルタイム検証、良いまたは悪いUX
写真にあるように、ユーザーが入力を開始したときにリアルタイム検証を行ったサインアップフォームがあります。
これがユーザーエクスペリエンスに悪影響を与えるかどうかはわかりません。また、この種の検証に関するリソースも見つかりませんでした。
回答
nngroup.comから引用するには：
7.入力が完了する前にフィールドを検証しない
...入力を完了する
機会が与えられる前にエラーメッセージが表示されるのは煩わしい場合があります。
入力が完了する前に検証を開始しないでください
ユーザーが正しい値を入力し始めると、入力中にエラーが表示されないはずです。入力は次の場合に完了したと見なされます
- 入力フォーカスが失われた（別のフィールドに移動）、または
- フォームが送信されても、（入力した押したときなどのautoSubmit）または
- しばらく入力を受け取らなかった後（たとえば、最後の入力イベントから3秒後）。
入力中に入力エラーをすぐに表示することは非常に気が散り（入力を開始するときに「少なくとも3文字が必要」）、ほとんど役に立ちません。
検証エラーはその場で削除する必要があります
フィールドが検証され、いくつかのエラーが表示されたら、ユーザーは、フィールドを離れたりフォームを送信したりするときではなく、編集された値が正しいとすぐにエラーが消えることを望んでいます（エラーがある限り、おそらく無効になります）表示）。
これは、フィールドが再び汚れたときにフィールドからすべてのエラーを削除する（そして、後で送信またはフォーカスが失われたときに再検証する）か、フィールドが変更されるたびに自動的に再検証することで実現できます。
ユーザーがフィールドの要件を満たしていないときに赤い検証メッセージを継続的に表示するのではなく、（1）ユーザーに期待されることを伝えるヒントを表示し、（2）緑の「要件を満たした」メッセージを表示するのが良い方法です。ユーザーが有効な値を入力しました。入力がOKになるとすぐに緑色になります。
入力フィールドのタイプによって異なります。
- メールフィールドの場合：
あなたはあまりにもびくびくしたくありません。ユーザーにメールアドレスの入力を終了させます。ユーザーが入力を開始した瞬間に入力フィールドが赤になり、エラーテキストが表示されると、ユーザーを苛立たせます。
正しいアプローチは、ユーザーが入力を終了できるようにし、ユーザーがフォーカスをそのフィールドから移動したときに、見栄えが良いかどうかを検証して表示するか、例外テキストがある場合はそれをスローすることです。
- ユーザー名とパスワードのフィールドの場合：
ユーザー名とパスワードのフィールドは、入力要件が最も厳しいため、送信前に検証する必要があります。したがって、ユーザーが入力を開始するときに、何が受け入れられ、何が受け入れられないかをリアルタイムで明確に示します。
記事へのリンク：
https://designmodo.com/ux-form-validation/
https://uxmovement.com/forms/why-users-make-more-errors-with-instant-inline-validation/
不完全な応答を適切に処理すると、リアルタイムの検証が機能します。
「reara」は電子メールアドレスを開始する有効な方法であるため、与えられた例は悪いUIです。リアルタイム検証で不完全な応答を拒否できる例は、「reara @@」です。その場合、リアルタイム検証は完了を待たずにそれを拒否できます。
一般に、応答を有効にすることができる追加の入力がない場合は、エラーメッセージを表示する必要があります。これを検出するのがどれほど難しいかは、ケースごとに異なります。あなたが辞書を持っているなら、それはかなり簡単です。正規表現では、それほどではありません。
もちろん、不完全な入力のコンテキストで適切な適切なエラーメッセージを表示するのに役立ちます。たとえば、「メールアドレスには@記号を1つだけ含める必要があります」。
不完全な応答を処理できない場合、たとえば、特定のフィールドを有効にするためにサフィックスを入力することが常に可能である場合は、他の回答で提案されているように、完全な入力を待つ必要があります。
ライブで検証するのは良いことです。ただし、このような検証では、次の2つのケースを区別する必要があります。
- 最後に何かを追加することで有効にできる入力、および
- 最後に何かを追加しても有効にできない入力。
後者の場合はエラーメッセージがすぐに表示されますが、前者の場合は入力が完了するまで待つ必要があります。
しかし、どうすればお互いを区別できますか？
現在のツールを考えると、これは少し注意が必要ですが、独自の正規表現エンジン（または検証用の他の種類の有限状態マシン）を作成している場合は、次のように実現できます。
- エンジンが正規表現の終わり（ゴール状態）に達した場合、一致がありました。
- エンジンが文字列の終わりに達した場合、後で一致する可能性があります。
- エンジンがどちらにも到達できなかった場合、一致することはありません。
問題は、ほとんどのプログラミング言語が文字列の終わりに到達することについて何も示さないことです。また、既存の正規表現エンジンへのマイナーな変更ですが、独自のエンジンをロールすることは、これまでのすべてのユーザーインターフェイスデザインプロジェクトの範囲外であることはほぼ間違いありません。
簡単な答え3〜4つのフィールドがあるログインページの場合、ユーザーが[送信]をクリックしたときに検証を追加するのはまったく問題ないと思います。
長い形式では、入力が上記のフィールド以外の他のフィールドにある場合に検証チェックがトリガーされます。
これはJavascriptで実行可能です
ライブ検証の問題に関する記事を書きました：
つまり、フィードバックの提供が早すぎて、ユーザーが回答を入力する前に行われることが多いか、ユーザーが回答の入力を終えて次の質問に答える次のフィールドに集中すると、フィードバックが遅すぎるということです。
代わりに以下に焦点を当てます。
- 明確で簡潔なラベル、ヒントテキスト、エラーメッセージ
- 些細な間違いを許す
- 準備ができたら、ユーザーがフォームを送信できるようにします
このようにして、ユーザーにエラーメッセージが表示されることはめったになく、表示される場合は、エラーメッセージが表示されることを期待しているときに表示されます。