$ USDで1ドルの金額を受け入れるアプリケーションがあります。残念ながら、一部の人々は米国の外国人/訪問者であり、ピリオドの代わりにカンマを使用して金額を入力します。彼らは、米国の形式XXX、XXX.00ではなくXXX.XXX、00として数値をフォーマットします。予想されるさまざまな形式が問題を引き起こしています。テキスト入力フィールドにフィールドプレフィックスとして「$」が表示されていて、「USD」というプレースホルダーがあるにもかかわらず、人々は依然として間違ったフォーマットを入力しています。
例:
_Expected US: 345.60
User Enters: 345,6
accounting.js translates to: 3456.00
_
その後、ユーザーは$ 3456.00を支払います。これは明らかに良くない大きな間違いです。この時点で、入力したテキストを変更しようとするのは非常に悪いことだと思います。代わりに、ユーザーにフォーマットを正確に(正確に)入力するように強制する必要があります。テキストフィールドの下に、フォーマットとエラーメッセージを簡単に追加できます。テキストフィールドの下に、例を使用して正しいフォーマットを詳しく説明しています。
正しい形式を入力するように強制した場合:
注:この時点でのみ、USD $形式に強制されます。 10進数は99%が一般的ですが、トランザクションを実行するために必須ではありません。 /^\d*(\.\d{2}$)?$/
のように、正規表現を使用して警告を表示しています。
ユーザーの期待と魔法について少し話しましょう。
ユーザーは特定の期待を持ってツールにアクセスしますが、すべてのユーザーの期待が同じというわけではありません。あなたはこれを直接目にしています。文化、育成、人生の経験はすべて、ユーザーがツールを操作する方法を形作り、潜在的に満たす可能性のある膨大な数の期待を開きます。
ただし、ほとんどすべてのユーザーが期待することの1つは、奇術師や魔術師がトリックを行うとき(たとえば、カードデッキからカードを選ぶとき)、幻想家は常に自分のカードを正しく推測することです。
別の言い方をすると、ツールが何かを自動化し、ユーザーが入力しようとしたものを推測する場合、その推測を正しく行う必要があります、またはユーザーが失望したり失望したりします。
あなたが述べたように、彼らは過充電になるかもしれません、あなたのシステムが彼らの明白な欲求なしに彼らが入力したものを変更し、金額を増やした場合、あなたは過充電に対して法的責任を負わせ、あなたをトラブルに巻き込むかもしれません。
推測するか推測しないか。それが問題です。したがって、2つのアクションコースから選択できます。
オプション1:入力内容を分析し、修正します
この場合、表示されているすべてのEdgeケースに対応できるソリューションを探す必要がある場合があります。 accounting.jsがテキストを正しく再フォーマットしない場合は、さらにカスタムを行う必要がある場合があります。
正規表現を入力します。
あなたがする必要があるのは、遭遇する可能性のあるすべてのパターンを理解することです。それらは正しいものであり、変更が必要なものです。一般的なケースを見てみると、
- ###.###,## > ###,###.##?
- ###,###,## > ###,###.##?
- ######,## > ###,###.## or ##,###,###?
かなり速くトリッキーになります。これを行うには、十分なテストを行って、テストと置換パターンが正しく機能しているかどうかを確認する必要があります。また、新しいパターンが出現しないように注意する必要があります。
同様に、パターンの1つがコンテンツを誤って変更した場合、ユーザーはあなたが金額を更新したことに気付かない可能性があります(または、更新された値が意味するものであることを確認するように依頼すると、重要な変更を見逃す可能性があります)。間違った金額を支払う。さらに、あなたが彼らのためにそれをしたなら、あなたは合法的にフックになっているかもしれません。
オプション2:適切なフォーマットに誘導する
このオプションは、少し作業が少なく、多くの観点から安全です。また、快適なユーザーエクスペリエンスが得られる可能性も高くなります。
ここでも、奇妙な形式の文字列を探します。ピリオドが多すぎ、カンマの間の桁数が多すぎ、カンマが最後の2つの数字の文字列を区切っています。
私が提案するのは、ライブフィールド検証の実装を使用して、入力が正しくフォーマットされていることを確認することです。彼らが奇妙な何かを入力したら、ボックスからクリックするか、フォームを送信して送信し、探しているテストにフラグを付けるために文字列を処理してください。テストに失敗した場合は、フィールドの横または下にメッセージを表示します(メッセージの表示方法については、 これらの画像の一部 を参照してください)。
何も自動的に変更しないでください。自分で変更するように依頼してください。
彼らが正しい変更を行ったかどうかをできるだけ早く確認します。たとえば、フィールドからフォーカスを外した場合に、送信ボタンを再度押す前にこれを行うのが理想的です。問題がなければ、エラーを正常に修正したことを伝えるメッセージを(緑や青などのわかりやすい成功色で)表示します。彼らがそれを再試行して修正する必要がある場合は、エラーメッセージを再表示し、チェックしたことを示しても、まだやらなければならないことがある。
Oops, looks like it's still not quite right. <error mitigation message follows.>
このようにして、彼らはまだやらなければならないことがあり、フォームがフォローアップアクションを明示的に要求していることを知っています。
編集:結論として...
目の前のユースケースと、ユーザーがエクスペリエンスを予測可能かつ理解しやすくするために実装できると思うオプション(または2つを組み合わせたもの)を検討してください。
2つを組み合わせる興味深いオプションは、@ jjwdesignがコメントで取り上げたマスキングです。フォームは、最初からユーザーに慣例を実行する方法を案内し、フィールドに微妙な___,___.__
を表示するか、ユーザーが値を入力するときに句読点を追加/変換する場合があります。注意する必要があるのは混乱するような方法でこれを行わないでください。このページのコメント全体で指摘されているように、ユーザーの入力を上書きすると混乱を招く可能性があります。
幸運を!
別のオプションは、テキストフィールドがすべての非数値文字を無視し、適切なフォーマットを自動的に表示することです。
例えば:
User enters '3' -> Text field displays '0.03'
User enters '4' -> Text field displays '0.34'
User enters ',' -> Text field displays '0.34' (no change)
User enters '5' -> Text field displays '3.45'
User enters '6' -> Text field displays '34.56'
Showユーザーが視覚的に期待していることとshowマシンがユーザーの解釈する方法入力。
ブレインストームへの私の貢献は次のようになります。
これで、ユーザーが金額を入力すると、スクリプトが機能せずに、システムが入力を自動的に解釈する方法が表示されます(おそらく、コンマとドットを拒否するスクリプトを除く)。
-
入力を確認する方法を提供する限り、基本的には何でも行うことができます。私は個人的に、入力フィールドの隣に、少なくとも部分的に書き出された金額を動的に表示します。
[ 123.45 ] (123 US dollars, 45 cents) [ 123,45 ] (123 US dollars, 45 cents) [ 123,456.78 ] (123 456 US dollars, 78 cents) [ 123,456 ] (123 456 US dollars, 0 cents)
([]
には入力が含まれ、()
には検証が含まれます。数千の区切り文字としてあいまいでないスペースを使用していることに注意してください。)
私が提案する入力を解釈する方法が最良の方法であるとは言いませんが、あなたは即座の検証を提供します。私にとって(小数点の代わりに小数点のコンマがある国から)、,XX
をセントとして扱うのは直観的ですが、他の人にとっては、,XXX
は単位を意味します。即時検証が提供されるため、害が生じることはありません。
注:ユーザー入力(疑わしい場合は後で実際に書き込んだ内容を確認するため)と検証(ユーザーが見たものと解釈した内容が解釈であるかどうかを確認するため)の両方を送信し、一貫性があることを再確認してください。フォームが送信されます。
ドル用とセント用の2つのフィールドを作成できます。この方法では、フォーマットロジックは必要ありません。データベースに保存するときに、英数字以外の文字を取り除くことができます。
Locale はこの質問についてです。ユーザーが米ドルを処理する必要があるという事実は、この特定の通貨単位(米国)の「所有者」のロケールで処理することを意味するものではありません。日付形式は、値がレンダリングされたロケールを知らなくても、さまざまなロケールがあいまいな方法で値をレンダリングする方法のもう1つの例です。
人間がロケール情報を処理することを期待する方法は、プログラマーとして常に予測できるわけではない多くの要因に依存します。あなたができることは、彼らが彼らがソフトウェアを経験しているロケール、または彼らがしなければならないそのロケールのどの側面を知るための十分な情報を彼らに与えることです扱う。 HTMLでの1つの方法は、ローカライズされた placeholders をレンダリングすることです。これは、予期される入力形式を示します。
あなたは誤った金額を誤って処理する人々について懸念を表明しました。リクエストを処理する前に、最終確認をユーザーにリクエストすることをお勧めします。入力された金額を分析し、それが異常な形式である場合、en_US
とは異なる小数点とグループ化の区切り文字を使用しているため、正しい金額を入力したかどうかをユーザーに尋ねるメッセージを常に表示できます。
UXソリューションは、ユーザーが慣れている形式に関係なく、ユーザーがエラーを発生させないようにすることです。これ以上何もない。何も少ない。
正規表現タイプのソリューションを検討することをお勧めします。
- コンマの後に2桁あることを確認します(必要に応じて0を追加します)
- その後、すべての非数字を取り除きます
- 次に、小数点を追加します。
345,6 becomes
345,60 becomes
34560 becomes
345.60
プロセスやバックエンドツールに関係なく、ユーザーにとっては簡単です。彼らが(345.60の代わりに)345,6を入れることを期待しているなら、それらを許可します。
私がベルギーで使用している銀行サイトでは、10進表記のみを入力でき、桁区切り記号は入力できません。
10進表記にはsingleコンマまたはsingleドットのいずれかを受け入れますが、他に何も入力できません。
それらが入力フィールドをどのように処理するかについて、さらにいくつかのテストを行いました。
,
または.
を1回だけ使用できます。桁区切り記号は使用できません。4,
と入力した場合、4,,
と入力しても何も起こりません。4,000.
と同じように、.
を追加することはできません。4000.00
または4000,00
と入力すると、両方が4000,00
に変換されます4,000
は4,00
に変換されます-これは銀行のサイトでは確かに問題ですが、1000の区切り文字を入力する人にのみ発生し、人々が使用しているOPの場合とは異なります10進表記のコンマ。コピーと貼り付けは許可されていないので、1000の区切り文字を入力したい人だけが使用できます。これは通常、読みやすさのためだけに行われますが、何人で行うかをテストする必要があるかもしれません。一般的に、エラーを回避しようとします。それらは、私の意見では最後の手段のUIです。エラーを回避するためにシステムロジックで処理できるものがあれば、それが解決策となります。また、それらを特定のフォーマットに強制することも避けてください。彼らが使用するフォーマット、マイクロインタラクションを予想して、それを中心にシステムを設計してください。
あなたへの質問...人々はこのフィールドに小数を入力する頻度はどれくらいですか?
私の提案は、ユーザーが最初にそれを見たときにデフォルトとして表示されるように数値をデフォルトの形式にして、ユーザーの入力がドル記号と小数点の間に入るようにすることでしょうか?この方法で実装すると、ユーザーの入力はすべて金額として解釈され、ユーザーが小数を入力しない場合は、そこで停止できます。
ただし、小数の金額を考慮する必要がある場合は、ユーザーが「。」と入力するまで小数の金額が変更されないようにすることができます。キーボードで、その時点でフィールドの小数部を入力します。特定の問題を解決するには、「、」を同じように扱うことができます。ユーザーがキーボードで「、」を押すと、小数部に入力されます。
したがって、ユーザーの操作は次のようになります...
以前、ドイツのユーザー向けのアプリに問題がありました。私はドット表記に固執し(コンピューターの場合)、すべてのコンマをドットに変換するjsを作成しました(1000s区切り文字を入力する必要はありません。jsはそのための空白を表示します)。コンマがバックエンドサーバーに到達しないようにしたかったのです。
ユーザーによるさまざまな応答がありました。何も言及しなかった人もいます(例:非ドイツ語)。驚いた人もいましたが、それに順応しました(例:ブルームバーグユーザー)。一部のユーザーは混乱し、カンマについて質問しました(例:Excelのみのヘビーユーザー)。
警告:これはまさに私がやったことです。私は、そのようなアプローチが良いことだと判断できるUXの人ではありません。
私は数値入力フィールドにautoNumericを使用する傾向がありますが、コンマとドット/ピリオドの両方を受け入れるように常に設定します。桁区切り記号はなく、小数点記号として呼び出すものは何でも受け入れます(真剣に、誰でもinput?)残念ながら、カンマを使用して数値を貼り付けるときに小数点記号としてカンマを受け入れるように設定しても、ドロップするだけです(私は現在問題を書いています)...しかし、少なくともキーボード入力では正しく動作します
入力には、単一のドットの後に正確に2桁が続き、コンマは必要ありません。ただし、ユーザーがフィールドに複数のドットとコンマを入力できるようにします。ユーザーがボックスの外側をクリックしたときにこれらの要件が満たされていない場合は、入力を拒否し、テキストエラーを表示して、ユーザーが手動でカンマを削除し、ドットとセントの数を入力する必要があります。
「入力は.XXで終わる必要があります($ XXXX.XXなど)」というフィールドの前にメモを配置できます。
ユーザーがカンマを入力したが手動でそれらを削除せざるを得ない場合、ユーザーはカンマが受け入れられたと想定する可能性はありません。また、ドットとセントの金額が必要なため、ユーザーは入力にセントが含まれていることを確認する必要があります。