一般に、ユーザーが入力したとおりにユーザー入力を受け入れる必要があります。ユーザーがそのようにしたのは、正当な理由がある可能性があります。たとえば、ユーザーが外国の住所を入力し、アプリが国内の住所のようにフォーマットしようとしてそれを台無しにしたとします。少なくとも、ユーザーは慣れ親しんだ方法で入力を入力したため、入力を変更すると、クロスチェックが困難になる可能性があります。
ただし、いくつかの例外があります。
不完全な入力にデフォルトを追加します。ユーザーが省略した入力(たとえば、年から日付、単位からディメンション)を追加すると、アプリが入力をどのように解釈しているかについての適切なフィードバックが得られます。これにより、ユーザーはデフォルトを使用するようになり、入力がより効率的になります。
他のあいまいさを解決します。ユーザーのフォーマットが自由に解釈できる場合は、明確なフォーマットに変更してください。たとえば、海外のユーザーがいる場合は、「9-8-09」を「Sep 8 2009」(または「9 Aug 2009」)に変更して、アプリが月と日をどのように見なすかについてフィードバックを提供することができます。
何も指定されていない場合は、区切り文字を追加します。長い英数字の文字列(電話番号、クレジットカード番号、シリアル番号など)に標準または任意の区切り文字を自動的に追加すると、ユーザーがより簡単にクロスチェックできる入力表示が提供されます。ユーザーは、高速にするために、または標準の区切り文字でさえ受け入れることを拒否するサイトによるWebの悪用の犠牲者であるために、区切り文字なしで文字列を入力する場合があります。
スペル、文法、および大文字と小文字の修正。ユーザーはこれを高く評価することがよくありますが、それをオーバーライドする手段もある場合に限ります。一部のユーザーは、人称代名詞として「i」を使用することを好みます。
フィールドが複数のユーザーによって使用されている場合は、おそらくユーザーの大多数に対応する標準的な方法で値を自動的にフォーマットする必要がありますが、フォーカスが離れるときではなく、値がバックエンドに格納されるときに行う必要があります。分野。たとえば、ユーザーが15:30の時間を入力した場合、ユーザーがページを表示している限り、15:30のままにする必要があります。ただし、次にユーザー(任意のユーザー)がデータを取得するときは、午後3時30分として表示されます(ほとんどのユーザーが時間の表示に慣れている場合)。
このようなバックエンドの書式設定は、空白のトリミングに適用されるため、すべてのユーザーがフィールドで一貫して検索、検索、および並べ替えを行うことができます。空白の値(または無効な値)をデフォルトに置き換えることは、ユーザーがその値を取得することを予期しない可能性があるため、おそらくお勧めできません。例外は、明らかに空白==なし==ゼロの状況で、数値フィールドの空白を0に変更することですが、これも、フィールド自体ではなく、バックエンドに格納するときに行う必要があります。空白があいまいな場合(たとえば、0を意味する場合や、「わからない」を意味する場合)、上記の2番目の箇条書きが適用され、フォーカスが失われたときにフィールドで自動修正することができます。
もちろん、ユーザーがデータ型をフォーマットする必要がある方法が異なる場合は、ユーザーグループごとに異なる方法でデータ型を表示するアプリのさまざまなバリエーションを使用するか、データ型のフォーマットを作成することができますユーザーの好みですが、それは本当に別の問題です。