郵送先住所フォームの最適な設計/注文/レイアウト
On 2月 2, 2021 by admin郵送先住所フォームに関して、標準はありますか?次のフィールドを収集する必要があります。
- 住所行1
- 住所行2
- 市区町村
- 郵便番号(またはzip)
- 州(または州)
- 国
国と州はドロップダウンになります。 (国に依存している州)
つまり、私の質問は、フィールドを標準の郵送フォームと同様のレイアウトにする方がよいかどうかです。つまり、
address line 1 address line 2 city province postal code country
または次のようなより論理的な順序:
address line 1 address line 2 city postal code country province
コメント
- 'サポートしている国の数を教えてください。それらすべて?それは違いを生む可能性があります。
- ほとんどすべてがそうです。上司は、国/州をドロップダウンにすることを決定しました
- すべての国が市の後に郵便番号を持っているわけではありません。したがって、サポートしている国がすべて同じ方法で住所をフォーマットしていることがわかっている場合を除いて、'それらを1行にまとめることはしません。
回答
ルーク・ウロブレフスキーは、UXMattersで国際住所フォームに関する記事を書きました。ユーザー調査から抽出されたいくつかのベストプラクティス、パターン、規則がリストされているので、その記事を参照することをお勧めします。ルークは、 Webフォームデザイン:このトピックもカバーする空白。
彼の記事の終わり近くで、彼はまた、一般的であらゆる種類の入力をサポートするAmazonのフォームを強調しています。アマゾンはあなたのフォームデザインのためにいくつかの研究をするのに良い場所でしょう。
のアドレスフォームのデザイン
コメント
- これは完璧にはほど遠いです。CityとZipは必須であり、米国の住所のようにフォーマットされます。ほとんどの郵便サービスはおそらく最終的にそれを提供するでしょう。フォームの誤った検証を満たすために、意味のないデータや有効なデータの繰り返しを入力した場合でも。しかし、その出力は、フォームにどのように入力しても、正しくフォーマットされたノルウェーの住所ではありません。
- この例も私には非常に悪いようです。たとえば、ここスイスには、"家の名前"しかない小さな村があります。さらに進んでいくと、通りの名前がまったくない場所があります。そのような話については、 medium.com/@oquidave/ … を読んでください。
回答
これらのフィールドが「必要」だと言うと、私は怖がります。ノルウェーの住所にこれらすべてのフィールドを必要としないことは確かです。
住所入力をその多くのフィールドに分割すると、ユーザーが住所を強制的に入力しようとすると問題が発生するだけではありません。別の国向けに作成されたフォームですが、住所データを正しい住所に再フォーマットするにはどうすればよいですか?
このフォームのノルウェーの住所をこれらのフィールドに強制する必要があると思いますか?また、「都市」はいつ、 “postal code(or zip)”、 “province(or state)”フィールドには、これらの値の一部がランダムに割り当てられます。ラベルを正しい順序で印刷するにはどうすればよいですか?
<Name> <Street-name> <house-number> <4-digit-post-code> <uppercase place name> NORWAY
例
Ola Normann Karl Johansgate 13b 0599 OSLO NORWAY
次のいずれかを使用することをお勧めします:
Name: [ text line input ] Address: [ multiline ] [ text area ] Country: [select box or text line input]
なぜそれよりも複雑にするのですか?これは、あらゆるタイプのアドレスに対して完全に機能し、使いやすいはずです。
(何らかの理由でアメリカ人が自分の住所を正しく記入できない場合は、米国が国として選択されたときに米国固有のフォームを作成し、他の人に簡単な名前/住所/国のフォームに記入してもらいます)
コメント
- すべての住所が国内の場合でも、住所には複数行のテキストボックスを使用することをお勧めします。人々は文字通り何世紀にもわたって自由形式のアドレスを書いてきました、そしてメールはアメリカ人でさえ配達されます:-)。現在、集計とレポートの目的で十分な信頼性を備えた自由形式の住所から都市と地域の情報を抽出するアルゴリズムがあります。複数のアドレスフィールドは不要になりました。このすべてのタブ操作と強制装着からユーザーを救います。
- @MichaelZuschlagこの位置をサポートするリソースを知っていますか?私は'また、人々は一般的に、一部のUIデザイナーよりも、手紙に何を書く必要があるかについての知識が豊富であり、それらのUIデザイナーに何かを示したいと考えています。
- 何世紀にもわたる手書き/タイプの封筒に加えて、Googleマップの成功は、'が実現可能であることを示唆しています。Luke Wは、ユーザーが住所を完成させるために住所部分ごとに個別のラベルを表示する必要はないが、'は個別のフィールドも削除するまでのロジック( uxmatters.com/mt/archives/2008/06/ … )。調査は知りませんが、非常に単純なユーザビリティテストでは、ユーザーが1つのフィールドでより高速であり、エラーの数が増えないことを確認する必要があります。
回答
これらのフォームは私を苛立たせます。ほとんどの場合、彼らは必要以上の情報を求めています。英国についてはわかりませんが、英国で必須なのは家番号と郵便番号だけです。それだけです。しかし、それは国によって異なります。
それで、実際には、この混乱全体を、それを解決し、すべてを最新の状態に保つ誰かにアウトソーシングするのはどうですか?QASはかなりのことをしているようですよくできました。インタラクティブデモをご覧ください。また、WOO、私が言ったように、英国のルックアップには、家番号と郵便番号のみが必要です。
コメント
- これはかなりクールなツールです!テストした2番目のアドレスに対して約20のオプションがあり、リストを検索する必要があり、余分なクリックはありません。 ' 2つのテキストボックスと2つのドロップダウンをフォームに入力する必要があるので、それほど面倒ではありません。自分のアドレスでも失敗しました。ユニット番号をタウンハウスコンプレックス。
- 確かに、バックアップ方法なしで番号/郵便番号だけに依存することで、新しい郵便番号を持つ人を除外します(新しい郵便番号が登場し、Royal MailPAFデータベースが世界中にリリースされます) isn '常に最新であるとは限りません-選択したサブスクリプションサービスによって異なります。)
- 外部サービスのコンサルティングの問題は、'フォームに依存関係を導入すると、アクセシビリティの問題が発生するだけでなく、アドレスを入力するだけでは直感的ではなくなる可能性があります。 LukeWは、彼の本の中でこの分野に関する彼の研究について少し話しています。
- フォームを制限する必要はありません'。すべてのフィールドを使用可能にしてください。ただし、住所の直後にZIPを配置し、必要に応じて残りを自動入力することができます。 (ところで、なぜアドレスに常に2行あるのですか…誰かがその2行目を使用することはありますか?)
- 実際にはこれは真実ではありません。 Royal Mail は、"地域"要素を必須として指定します。それでも、
"123 / AA1 1AA"
宛てのメールはおそらくそこに届きます。ただし、町を指定してほしいのです。
回答
1:住所1行目
2:郵便番号と都市
3:国とプロビデンス(サポートされている場合にのみプロビデンスを表示)
3行目の下に「セカンダリアドレスを設定」というリンクを配置し、押すと、1、2、3行目のような複製されたフォームが表示されますが、「住所行2」という見出しが付いています。
回答
複数の国をサポートしていない場合は、ルークがソリューションに示したように、選択した国のデフォルトを表示するための最良の方法です。
もう一度、住所の形式は必ずしもすべての国で同じではありません。
そのため、アプリがサポートする国を調査する必要があります。
インドなどの単一の国に限定されている場合は、国をデフォルトのままにします。選択し、次のように設計します。
まず、インドでの郵便番号の機能を理解します。インドの郵便番号は6桁です。
PINコードインディカの最初の桁領域をテストします(合計9つの領域、それぞれが最小3と最大12の状態をカバーします)。 2桁目はサブリージョンを示し、3桁目はリージョン内のソート地区を示します。最後の3桁は個々の郵便局に割り当てられます。
明らかに、郵便番号に基づいて州を選択することはできません。または、そのようなサービスを探すか、自分の考えをサポートするために社内で開発する必要があるかもしれません。このようなサービス、最大状態ドロップダウンメニューの選択オプションを最小化するためにフィルターを適用できます。
これが明確になったら、フィールドを次のように入力します。
住所行1 (これは、インド人が住所、フリーテキストを書き始める一般的な方法です)
住所2行目(はいの場合、これらのラベルを通りの詳細、エリア、ランドマークなどに固有にする必要がありますか?-避けると言います)
州(これは次のフィールドのオプションを減らすのに役立ちます)
都市(テキストの選択/フリー-たとえば、調査によって異なります-サービスが制限されている場合州内の大都市または上位都市へ)
Zip
国(自動入力)
回答
Stein G. Strindhaugのアイデアは気に入っていますが、複数行のテキスト領域には2つの問題があります。国際住所の場合。
- ユーザーは、住所の一部(家番号や郵便番号など)を入力するのを忘れることがよくあります。住所の各部分に個別に入力すると、ユーザーは必要なすべての住所情報を入力できます。
- 複数行の住所テキスト領域は、住所をパッケージまたは請求書に印刷し、印刷しない場合にのみ使用できます。住所の別々の部分が必要です。外国の住所のどの部分が通りで、どの部分が地域であるかを確認するのは非常に難しいことがよくあります。したがって、たとえばフォワーダーのデータベースに住所を入力する必要がある場合は、別々にする必要があります。番地/地域/郵便番号への複数行のテキストフィールドは、多くの外国の住所では困難です。この問題により、外国の住所の形式に関する幅広い知識がない場合、住所が正しいかどうかを確認することもできなくなります。 。
コメント
- ユーザーが"を忘れた場合"住所の一部、自国の郵便局が寛容であるか、'ゲッティンにあまり興味がないgメールが配信されました。ノルウェーの郵便サービスは非常に寛容です。私は(最終的には)本質的に私の名前に宛てられたScientificAmericanを受け取りました。オスロ;ノルウェー;これは、"無効な"入力を破棄する非常に詳細なアドレスフォームが原因でした。
- 実際には" state "や" regionなどの存在しない情報をアドレスから抽出するのは難しいそのような情報が含まれていない私の住所からの"(ヒント:ノルウェーには州がなく、行政区画はで使用されていません'住所・アドレス)。そのような情報を(アメリカのフォームがよく行うように)ノルウェーの住所に追加すると、混乱が生じ、おそらく配信が遅れます。とにかく、なぜそのような情報をデータベースに分割する必要があるのでしょうか。アドレスには大きな文字列フィールドで十分です。
- アドレスを複数のフィールドに分割することを主張する場合は、本当にすべての国のアドレス形式に関する幅広い知識が必要です。正しい形式で元に戻すことができます。自由形式のフィールドがある場合、ユーザーはフォーマットされているはずの'と同じようにフォーマットするため、アドレスフォーマットに関する開発者の知識は必要ありません。必要なのは、配送ラベル/封筒ウィンドウに事前にフォーマットされた住所用の十分なスペースがあることを確認することだけです。
- > > ユーザー"が住所の一部を"忘れた場合、郵便サービスは国が寛容であるか、'メールの配信にあまり関心がありません。またはパッケージが返送されます'世界の反対側の起源。ほとんどの国際フォワーダーは、パッケージを送信するために特定のデータを必要とします。このデータは、システムに入力する必要があります。
- 自由形式のテキスト領域で自分のアドレスをめちゃくちゃにして、パッケージが返されるほどひどい場合は、支払う;アドレスが多くの無関係なフィールドに分割されてから、認識できないほど混乱したものに再構成された場合、それは私のせいではありません!国際郵便に必要な情報は1つだけです。国の名前です。郵便が正しい国にある場合は、ローカル部分をローカル形式でフォーマットする必要があります。
コメントを残す