My Geocode

ガイド

オートコンプリートで「もしかして」候補ボックスを作る

· 約3分で読めます · My Geocode · #autocomplete#ux#forms#addresses

「もしかして」ボックスが最もうまく機能するのは、控えめに表示され、短いリストを示し、どの候補も合わなければ邪魔にならないように消える場合です。オートコンプリートのエンドポイントは、まさにこのパターンのために作られています。

リクエスト

GET /v1/autocomplete?q=Baker Stret&limit=4
{
  "status": "ok",
  "query": "Baker Stret",
  "suggestions": [
    {"text": "Baker Street, London, UK", "place_id": "abc123"},
    {"text": "Baker Street, York, UK", "place_id": "abc789"}
  ]
}

クエリに「Stret」のような入力ミスがあっても、妥当な候補が返ってこなくなるわけではない点に注目してください。エンドポイントは不完全な入力でも機能するように作られており、それこそがそもそも候補ボックスの目的だからです。

2つ目の例：候補がまったくない場合

入力ミスの有無にかかわらず、すべてのクエリで有用な一致が得られるわけではありません。

GET /v1/autocomplete?q=Zzqxlm Nonexistent Rd&limit=4
{
  "status": "ok",
  "query": "Zzqxlm Nonexistent Rd",
  "suggestions": []
}

この場合の空のsuggestions配列は正しいレスポンスであり、リクエストに何か問題があったことを示すものではありません。良い一致がないだけの入力に対して、空のドロップダウンや目に見えるエラー状態を表示するのではなく、ボックスが控えめに消えるように設計してください。

リストを表示する

各候補のtextフィールドを表示するラベルとして使い、クリックされた候補にplace_idを結び付けたままにしておきます。後で完全な住所を解決する際には、表示テキストを解析し直すのではなく、この識別子を渡すからです。

任意のままにしておく

このパターンで最も重要なのは、特に操作を処理するクライアント側のJavaScriptがないサイトでは、候補がクリックされたかどうかにかかわらず、フォーム送信時に入力欄が入力された住所をそのまま受け付けることです。選択肢のいずれかが選ばれるまで送信をブロックする候補ボックスは、役に立つ後押しを厳格な必須要件に変えてしまい、候補のリストに正当に含まれていない住所はどれも送信できなくなります。

テストする価値のあるエッジケース

候補ボックスを主にテストした文字体系とは別の文字で書かれた住所や、翻字された地名は、ほとんどの住所データベースに実際に含まれており、一致しない他のクエリと同じく「通常のテキストにフォールバックする」扱いを受けるべきです。珍しい入力に候補がないからといって、入力自体が無効だと考えないでください。正しい対応は、多くの場合、顧客が入力したとおりに送信させることだけです。

リクエストを制限する

limitは小さな数に設定してください。候補ボックスには通常3〜5件で十分です。リストが長いと、ひと目でざっと確認するという目的が果たせなくなるからです。呼び出しにデバウンスを設定して、入力が少し止まった後にだけリクエストが送られるようにし、1セッションあたりの合計リクエスト数を低く抑えてください。

セッションあたりのコスト

一般的な住所欄では、訪問者が入力したり修正したりする間に、訪問者1人あたり数回のオートコンプリートの呼び出しが発生し、それぞれが1リクエストです。相当なトラフィックがあるフォームでも、すべてのキーに含まれる、またはキーなしで1つのアドレスから利用できる1日あたりの無料リクエスト2,500件のごく一部です。

よくできた候補ボックスは、入力ミスを控えめに見つけ、認識できないものには口を出しません。フィールドの定義の詳細は住所オートコンプリートのドキュメントにあります。

ガイドのその他の記事

· 4分で読めます

住所と郵便番号を照合する

住所と郵便番号をそれぞれ個別に解決して実際に示す内容を比較することで、注文の発送前に番地と郵便番号の不一致を見つけます。