入力ウィジェットの検証

Question

[これは使い古された古い質問かもしれません-申し訳ありませんが、どうすれば検索できるかわかりません。]

まず、背景。（これはまだ質問ではありません。）ユーザーが数値を入力できる入力ウィジェットを備えたGUIがあるとします。そして、ユーザーにキーボードでの入力を許可しているとします。規定された選択リストや、既存の値を調整するための+/-ボタンだけで制限することはありません。

とりわけ、おそらくユーザーの入力を検証して、適切な範囲にあることを確認したいと思うでしょう。たとえば、ユーザーがモーターの希望速度を入力している可能性があります。これは0〜1500 RPMの範囲に制限されています。

現在、検証を実装するための2つの一般的なアプローチがあります。

ユーザーが何かを入力できるようにしますが、[OK]をクリックした後、入力が無効な場合は、警告ダイアログをポップアップして、ユーザーにキャンセルまたは再試行を強制します。
そもそもユーザーに無効な入力をさせないように工夫してください。

また、数字キーの入力のみを許可し、実際の値を確認する前に[OK]がクリックされるまで待機するなど、さまざまな組み合わせを実行できると思います。

最初のケースでは、その警告ダイアログは間違いなく厄介です。プログラマーがそれをコード化するのは追加の作業であり、ユーザーが停止して考え、次に何をすべきかを理解しなければならないことは、ユーザーにとっての割り込みです。（OK？キャンセル？または何？）

しかし、2番目のケースでは、微妙な潜在的な問題もあります。現在の値が、たとえば160であると仮定します（これは十分範囲内です）。ユーザーがそれを170に変更したいとします。ユーザーがこれをクリックして、テキストカーソルを1と6の間に設定し、7と入力してから、前方削除キーを押して6を削除するとします。

しかしもちろん、これはダイアログが一瞬1760と表示することを意味します。これは範囲外なので、この入力シーケンスは許可されません。

したがって、多くの点で一般的に友好的と思われる2番目のケースでは、ユーザーが入力を許可されているものに、この種の奇妙な隠れた制約があります。時々、そのような入力方法を使用しているとき（もっと良い例を思い出したいのですが）、それは、ミニチュアの即興の頭の体操のパズルのようなものであり、私が持っている値を必要な値に変更するのに十分なほど合理的な最小限のキーストロークのシーケンスを理解します瞬時に表示される値が許可されていない中間状態を通過する。

それで、今、質問：（1）これら2つのかなり異なるスタイルの入力検証には名前がありますか？（2）私が述べた2つを超えて、それらの間に他のトレードオフはありますか？そして、（3）2番目の方法が優先される場合、あまり頻繁に出てくることが予想されない、またはユーザーが我慢しなければならないことを説明したので、時々小さなパズルを解かなければならないという問題があります。または何？

Michael Lai · Accepted Answer

検証に関する文献や記事のほとんどはフォーム入力のコンテキストにありますが、ウィジェットのほとんどと同じようにそれらのほとんどを処理できると思います。

たとえば、これはNNgグループの記事で、フォームのエラーを報告する方法に関するいくつかのガイドラインがあり、説明したいくつかの概念を適用しています。

ユーザーが値を入力しているときに（それを防止するか、無効にするように促すことによって）ユーザーに即時フィードバックを提供する例は、インライン検証、相互作用は入力のポイントで発生します。グラフィカルユーザーインターフェイスの前は、入力コントロールの多くが物理デバイスだったため、値を入力できないようにする行為は、物理的な動作を模倣しているようです（たとえば、ボリュームコントロールをさらに回すと、最大レベルまたは最小レベルを示します）。

パスワード設定は一般的な設計パターンであり、強力なパスワードの基準をユーザーが確認できるようにしたり、ユーザーが入力フィールドにパスワードを入力しているときにパスワードの相対的な強度を示したりすることで、ユーザーエクスペリエンスが向上します。これは、ユーザーが情報を入力している最中であることを示していますが、ユーザーがタスクの完了を示していないため、タスクの完了を妨げていません（送信ボタンをクリックする以外の方法がない場合もあります）。。

私はあなたのウィジェットの複雑さによって（そしてそれが私がそうすべきでないと私が思うウィジェットであるなら）典型的なインライン検証ではなく最後に検証したい理由があるかもしれないと思います。多数の入力フィールドがあり、ユーザーがそれらをすばやく処理できるようにしたい場合、他の入力フィールドに依存関係があるときに一度に1つずつ問題に対処すると、混乱を招く可能性があります。たとえば、あるフィールドの入力が別のフィールドに依存している場合、あるフィールドでエラーが発生すると、戻って別のフィールドを修正する必要があります。これはユーザーの混乱を招く可能性があります。なぜなら、彼らはすでに1つのフィールドを完了していて、戻ってもう一度やり直す必要があるためです（つまり、完了ステータスは最終ではありません）。

うまくいけば、これはあなたの最初のいくつかのポイントに答えました。最善の解決策は、使用しているデータを本当に理解し、ユーザーと徹底的にテストすることだと思います。そうすれば、ユーザーが嫌うことのないものを思いつく可能性が非常に高くなります（そしておそらくユーザーは気に入ることでしょう）。ユーザーが我慢して喜んで何をしようとしているのか本当にわからないので、うまくいけば、それらの要件に基づいて設計する必要はありません。

Cristian Negraia · Answer

入力の許容範囲を最初から表示するか、リアルタイムで検証することをお勧めします。 OKが押された後にのみ入力を検証するのは悪いUXです。 2番目の部分では、1760や17000のような幅の範囲ではない値を使用入力に入力させ、入力を赤でマークし、[OK]ボタンを無効にすることができます。これは、表示された許容範囲がユーザーにリアルタイムで通知され、要件を尊重するように入力を修正するのに役立ちます。

別のオプションは、ユーザーが戻って修正を入力するときに入力を自動的に削除することですが、値がim test 160、165、170などのようにいくらか増分的である場合は機能しません。

dirtydevil · Answer

私はクリスチャンに同意します。最初にテキストフィールドの入力範囲を表示することをお勧めします。別の方法は、「プレースホルダーテキスト」で入力範囲を指定することです。それでも、ユーザーが無効な数値を入力した場合は、ボックスを赤色で強調表示することをお勧めします。ユーザーにエラーを明確かつ適切なタイミングで通知することは、ユーザビリティヒューリスティックの1つです。テキストボックスに入力して、[OK]ボタンをクリックした後でのみテキストが無効になることに気付くと、どれほどイライラするか想像してみてください。

プログラマーにとって難しいことは理解できますが、この機能を実装しやすくするためにJSで使用できるモジュールがたくさんあります。