web-dev-qa-db-ja.com

さまざまなタイプの検索基準用の単一の検索ボックス

ユーザーが特定のホテルを検索してプライベートリストに追加できるシナリオがあります。これまではホテル名で検索を行っていましたが、今度はホテルもIDで検索したいという要望がありました。 UIは次のようになります。

enter image description here

簡単にするために、同じ検索ボックスを使用して、「名前またはIDで検索」というラベルを付けることを検討しました。これにより、次の結果が返されます。

enter image description here

さて、上記の例では、ユーザーが26A5Cで入力すると、通常、次の場合に一致する結果のリストが表示されます。

  1. 26A5Cシーケンスを含むIDを持っている
  2. ホテル名に「26A5C」という文字列を含めます（例：「Bellisimo 26A5Cリゾート」）

しかし、ユーザーが「26A5Cベラ」と入力すると、何が表示されると思いますか。彼らは期待するでしょう：

  1. 26A5Cで始まるIDと「Bella」で始まる名前のすべてのホテル？
  2. 名前に「26A5C」と「Bella」の文字列を含むすべてのホテル？
  3. 上記の両方（次のワイヤーフレームを参照）

enter image description here

技術的な観点から見ると、開発チームが単一の検索ボックス機能を実装することは困難です。ホテルID用とホテル名用の2つの検索ボックスを個別の結果リストで実装する方が簡単です。だから私が今持っているオプションは次のとおりです：

  1. ホテル名とIDの両方の単一の検索ボックス（実装が難しく、UXが向上）
  2. 2つの検索ボックス：1つはホテルID用、もう1つはホテル名用（実装が簡単で、UIが乱雑）
  3. ユーザーが検索タイプを選択するための2つのラジオコントロールを備えた単一の検索ボックス：ホテルIDまたは名前（UIは＃2よりもきれいですが、開発時間は＃2と同じですが、ユーザーにとっては余分なクリック）

上記の状況を踏まえて、最善のアプローチは何だと思いますか？私が言及したもの以外に他のオプションはありますか？助けてくれてありがとう！

searchfilteringsearch-results
6
radu.luchian

私の意見では、UXの観点からのここでの明白な答えは、ボックスが「そのまま機能する」ということです。ラジオボタンもダブル検索フィールドもありません。あなたが述べたように、それはそれから技術的な実装の挑戦になります。

この検索の目標の1つは高速であることを前提としています。

高速なクエリを使用すると、入力中にユーザーに結果を提供できます。ユーザーへのこの視覚的なフィードバックにより、あいまいなケースのいくつかが削減されます。

すばやく動作する検索サービスは、結果を事前に計算します。 「トライ」と呼ばれるデータ構造があり、これは基本的に「ユーザーが最初の文字に「A」を入力した場合、これらを与えます。アードバークホテル、アダージョ、アラウィッシュアンダーウォーターホテルなど」。次に、ユーザーが「A」の後に2番目の文字を入力すると、既に返されたセット内のみを検索します（Aの後にA、Aの後にB、Aの後にCのように、すべての可能な組み合わせが含まれているためです。したがって、追加の検索ではサーバーへの追加の要求は必要ありません。

私が得ていることは、あなたのインターフェースがデータのローカルサブセットにアクセスでき、そのデータをローカルで検索できるようにする必要があるということですORはデータセット全体にアクセスして検索を行う完全にローカル。

通常のWebサイトの場合、サーバーはこのファイル（またはファイルのセット）を定期的に計算します。ページにアクセスするユーザーは、ファイルを動的にロードし、即座に結果を表示する準備ができています。ユーザーが2文字または3文字を超える文字を入力すると、結果の検索はサーバーではなく、そのユーザーのコンピューターでローカルに行われ、ユーザーは結果を待つ必要があります。

その他の注意事項：

また、ユーザーが探しているものを見るとすぐに、入力を停止してクリックするので、「ユーザーが「26A5Cベラ」を入力した場合は問題にならない」ということも覚えておいてください。

ローカル検索データ構造を作成したときに、名前とIDの両方で各ホテルに「インデックスを付ける」必要があります

これが消費者向けサービスの場合は、ユーザーがIDを入力しない限り、結果ボックスでIDを非表示にしてください。見栄えがよくなります。

私が微妙に述べたように、伝統的に、ユーザーが2つまたは3つ以上の文字を入力するまで、ユーザーが入力している間は結果の検索を行わないでください。これにより、分析されるデータが削減されます。

これらのデータファイルの事前計算は通常、サーバー上の「cron」ジョブによって行われますORファイルへの各リクエストが受信されると、サーバーはファイルを取得し、ビルドされた日時を確認します。ビルドが長すぎる（先週など）場合、ユーザーにファイルの既存のファイルを戻し、接続を強制終了して、ファイルを再計算し、この新しいバージョンに置き換えて、最新の状態に保ちます。

これは、try ..に関するパフォーマンスに関する情報です。パフォーマンスは、データと、使用しているプログラミング言語に基づいています。これが技術的に見える場合でも、実際にはそうではありません。コンセプトが変わらないことを思い出してください。Aを検索すると、この結果のチャンクが返されます。Bを検索すると、この別の結果のチャンクが返されます。 http://ejohn.org/blog/javascript-trie-performance-analysis/http://en.wikipedia.org/wiki/Trie

2
user353877