オートコンプリートを使用した住所の入力
ユーザーが多数のアドレスを入力する必要があるWebアプリケーションがあります（少数のユーザーが他の人のアドレスを入力しています）。オートコンプリートを使用して処理を高速化し、重複を減らします（データベースには市内のほぼすべての道路が含まれています）。ほとんどの場合、ユーザーが入力している通りは既に存在しますが、まれに、ユーザーが定期的に入力するだけでバックエンドが新しく作成することができない場合があります。
アドレス部分ごとに別々のinputフィールドを使用しています（enterまたはtab-場合によってはspace-次に移動します）。通りは知られていない可能性があります。近所はおそらく不明であり、市はおそらくそうではありません。「一般的なケース」では、ユーザーは合計約5文字とその他すべて（通り、近所、市、州、国）を入力すると予想します、郵便番号）は彼のために自動入力されますので、彼は番号に進み、補完することができます（毎回異なります）。
私の国の問題は、住所の「自然な」順序が次のとおりであることです。
St. Foo 123/456 ...
の代わりに：
Foo St. 123/456 ...
フィールドの順序を設定するにはどうすればよいですか？私は 別の質問 で表示順序を変更することはお勧めしませんが、最初に「タイプ」（ストリート、アベニューなど）を維持すると、ユーザーはすべての入力に時間を費やすことになります時-「ストリート」フィールドが彼のために自動入力できるとき。ただし、不明なアドレスを入力するときは、そのフィールドを入力する必要があるため（データベースに正しく保存できるようにするため）、フィールドに戻る必要があります。
いくつかの可能性（実装の難易度はさまざまですが）について考えましたが、使いやすさの点でどれが最良かについてフィードバックをお願いします。
- 「ストリート」フィールドがフォーカスされ始めます。ユーザーがドロップダウンで何かを選択すると、「番地」がフォーカスされます（「タイプ」が自動入力されます）。代わりに次のフィールドに移動しようとすると（新しい通りが作成されます）、フォーカスは「数値」に進むのではなく、「タイプ」に戻ります。
- ...そして「タイプ」から離れると、「ストリート」をスキップして「数値」に移動します。または：
- ...そして「タイプ」から離れると「ストリート」に戻り、次に離れると「数」に戻ります。
- 「ストリート」フィールドはフォーカスを開始し、フォーカスサイクルは通常どおりです。ユーザーが新しい通りに入ると、「タイプ」フィールドに赤い境界線が表示され、ユーザーはいつ、どのように戻ってそれを埋めるかを決定します。
- 「type」と「street」に単一のフィールドを使用し、ユーザーが入力する可能性のあるいくつかの組み合わせ（「Av Foo」、「Av。Foo」、「Avenida Foo」、「A。 Foo」、「Foo」）。
その他の提案も歓迎します。
最後のオプションは、タイプとストリートに単一のフィールドを使用することです。とはいえ、3つのオプションを見て、それぞれの長所/短所を確認しましょう。
「ストリート」フィールドがフォーカスされ始めます。ユーザーがドロップダウンで何かを選択すると、「番地」がフォーカスされます（「タイプ」が自動入力されます）。代わりに次のフィールドに移動しようとすると（新しい通りが作成されます）、フォーカスは「数値」に進むのではなく「タイプ」に戻ります。
たとえば、49番街と49番街の両方が存在する都市の場合はどうなりますか？ユーザーがストリート名フィールドに「49」と入力した場合、「タイプ」フィールドには何が自動入力されますか？このシナリオの後半を実装する方法がわからない（「彼が代わりに次のフィールドに移動しようとした場合（新しい通り
作成されます）その後、フォーカスは「タイプ」に戻ります））が、これはユーザーに不整合を引き起こす可能性があります。フォームを一度使用して、既知の場所を入力すると想像してください（つまり、フォーカスは「ストリート」から移動します）次に「番地」に変更します。次に、フォームをもう一度使用して番地名を入力します。フォームの動作はどちらの場合も異なるため、混乱する可能性があります。
「ストリート」フィールドはフォーカスを開始し、フォーカスサイクルは通常どおりです。ユーザーが新しい通りに入ると、「タイプ」フィールドに赤い境界線が表示され、ユーザーはいつ、どのように戻ってそれを埋めるかを決定します。
ユーザーが（故意に）新しい通りの名前を入力している場合、実際にはそうではないのに、何らかの形でエラーが発生していることを示します（通常、赤はフォームでエラーが発生したことを示します）。 -彼は新しい通りの名前を追加しているだけです。
「type」と「street」に単一のフィールドを使用し、ユーザーが入力する可能性のあるいくつかの組み合わせ（「Av Foo」、「Av。Foo」、「Avenida Foo」、「A。 Foo」、「Foo」）。
おそらく実装するのに最も問題がありますが、最高のものでもあります：
これにより、ユーザーは部分文字列検索でストリートを柔軟に識別できます。時々、通りの名前は紛らわしい-つまり、通りの名前「チェリーヒントンロード」では、誰かが「チェリーロード」、「ヒントンロード」、または「チェリーヒントン」しか覚えていないかもしれません。これは、前述の49th Avenue/49th Streetの問題も処理します。
「タイプ」の配置に柔軟性を持たせます。なぜなら、あなたの国の標準的な住所表記はTypeである可能性があるからです。名前。数字なので、多くの場合、Webフォームはアメリカ人を対象としており、人々は独自の標準を使用する方法を学びます。これにより、ユーザーは、希望する形式について混乱している場合でも、フォームを正しく使用できます。
ほとんどの場合、ストリートタイプとストリート名が自動的に関連付けられます。記入するフォームフィールドが1つ少なくなり、繰り返しになりますが、人々の潜在的に悪い記憶を説明しています。誰かが通りをFoo Stと覚えているが、実際にはオプションとしてFoo Avenueしか存在しない場合.. :)
最も柔軟な方法は、Googleマップで使用されます。 49番目のテストサンプルを入力してみると、3番目のバリアントに似ていることがわかります。それはあなたが探しているものですか？
しかし、別の問題があります-このようなユーザーフレンドリーなソリューションは、開発者がそれを実装するのが大変になる可能性があります。また、シンプルで適切に構造化されたフォームを使用すると、プログラミングが簡単になり、製品を顧客に迅速に届けることができます。アプリケーションが正確な住所を受け取ることは重要ですか？または、おおよその値を取得してから、バックエンド手順を実行して修正するか、データベースから最も類似したアドレスを見つけることができます。正確さを求めて苦労することもありますが、それだけの価値はありません。あなたにとって何が最も価値があるかを決定します。