Yandex検索入力フィールドを再考した方法と理由

検索のヒントについては既に2回話しました。 最初の投稿は2012年に、 2番目の 投稿は最近発生しました。

検索のヒントは企業が誇りに思うものの1つであるため、それらについて頻繁に話すのは恥ずべきことではないと思います。 今日は、2017年に発生した検索ヒントの機能変更について説明します。 これは、インターフェイスの変更だけでなく、彼女が私たちに提示した興味深い統計と技術的課題にも焦点を当てます。

1.「拡張」入力フィールド

2017年の初めまでに、多くのインスタントメッセンジャーにはすでに「ゴム」入力フィールドがありました。 もちろん、十分な長さのテキストを書いている人は、テキスト全体ではなくても、少なくともその大部分を見たいと思っています。

驚いたことに、検索エンジンはこの傾向を完全に無視していました。 ただし、長い要求はストリームの重要な部分を構成します。 たとえば、Yandexへのクエリの合計フローの10％を占めるのは、7単語以上のクエリです！

一般に、リクエストの長さは非常に興味深い特性です。 長いリクエストのシェアは、学童と生徒の教育リクエストによって引き起こされる顕著な季節性の影響を受ける指標です。 したがって、長いクエリのシェアのグラフでは、すべての休日、週末、夏休みが明確に表示されます。 ただし、この効果を差し引いた後でも、リクエストが徐々に長くなっていることがわかります。たとえば、2017年の夏には、長いリクエストの割合が2016年の夏よりも20％高くなりました。 以下のチャートは、Yandexへのリクエストのストリーム内の長いリクエストの割合を変更するダイナミクスを示しています。2016年の初めに対応する値が単位として採用されています。

ユーザーがしばしば長いクエリを要求するという事実に加えて、特定のクエリの表現を頻繁に変更することも重要です。 検索行のテキストを編集するスクリプトは需要があると言えます。

これに基づいて、いわゆる 入力フィールドの拡張：必要に応じて、テキストを入力するプロセスでサイズが大きくなるフィールド。

アイデアは非常に単純ですが、私たちはそれを実稼働に持ち込むために約6か月を費やしました。 最初は、このアイデアに非常に興奮し、現在の画面を完全にカバーし、広い入力フィールド、フルテキストヒントなどを含む別のリクエスト入力ページを作成し、大幅に拡張しました。 幸いなことに、私はまだこのページのスクリーンショットを1つ持っているので、それをあなたに示すことができます：

少数のユーザーに対して入力ページの表示をオンにしたとき、このページはユーザーには理解できないことがわかりました。 彼らは検索ページからの要求を停止し、Yandexメインページからこれを実行しようとしました。 そのため、実験を予定より早く停止する必要がありました！

このような結果は、一般的なルールのもう1つの確認になりました。単純なアイデアを実装するときは、あまり変更しないでください。 したがって、私たちは概念を再考し、繰り返し移動しようとしました。 最初の成功した決定は、主なアイデアを実装することであり、同時に現在の生産と可能な限りほとんど違いがありませんでした。 ただし、いくつかの点を変更する必要がありました。たとえば、拡大する入力フィールドは、検索矢印の三角形とうまく相関しないため、検索ボタンを長方形に変更するアニメーションが必要でした。

結果は、Yandexユーザーが大規模な検索、画像による検索、およびビデオによる検索の結果のページで使用できるソリューションです。

この実装は、SajestチームがモバイルYandexで実装した中で最高のものの1つであると言わなければなりません。 ユーザーが検索エンジンを使用する頻度に影響を与えることさえできました！

2.歴史的な手がかり

客観的な現実の別の事実：ユーザーはしばしば同じクエリを要求します。 ユーザーの中央値のリクエストを取得すると、リクエストの半分以上を再度設定していることがわかります。

その場合、過去にこのユーザーが要求したクエリの入力を簡素化できます。 優先順位で、ユーザーが既に入力したリクエストを表示するとしましょう。

デスクトップYandexでは、このアイデアは非常に長い間実装されていると言わざるを得ません。2番目の文字を入力すると、一定数の履歴ヒントが表示され、現在の入力と一致する場合は紫色で強調表示されます。

ただし、モバイルではこれは不可能でした。 そこで、私たちはそれを解決するために急いで、同時にデスクトップにも関連する多くの問題を整理し、将来、デスクトップ上の履歴リクエストに関連する非常に重要な変更を待っています。

1. ユーザーは、常に過去のリクエストを記憶しておく必要はありません。 たとえば、秘密のリクエストがあります。 したがって、一般にクエリ履歴をオフにする機会を与え、さらに特定のヒントを削除する機会を与えなければなりません。

   
   
   
   
   
   
   

2. 削除に関連する履歴プロンプトの表示はどうしますか？ ユーザーがいくつかのリクエストを削除したと仮定します-新しい、より早いリクエストが代わりに来るべきですか？ ただし、必要なヒントをすべて破棄するために、ユーザーは数百の削除を行う必要がある場合があります。 削除プロセス中にリストを更新するのではなく、常に最新の10個のヒントを表示するだけなのかもしれません。 しかし、その後、ページがリロードされた後、ユーザーにはいくつかの新しい歴史的なヒントが表示され、このために彼は準備ができていないかもしれません。

   
   
   
   
   
   
   

3. 履歴クエリは、非常に迅速に配信および更新する必要があります。 要求が行われた直後に、それが歴史的な手がかりの中に現れるべきだと言ってください。 設定されたクエリは本当に必要ではないと言うことができます。 現在のリクエストを再度尋ねる必要はありませんが、それなしでは、履歴プロンプトの機能はユーザーにとって完全に理解できないため、個人プロンプトのバックエンドには非常に深刻な要件があります。

   
   
   
   
   
   
   

4. クエリ履歴が保存されるエンティティを理解する必要があります。 履歴クエリはサービスごとに異なるべきですか、それとも一致する必要がありますか？ 特定のブラウザごとに履歴を保存する必要がありますか、それともすべてのデバイスで要求履歴にアクセスできるように、ログインしたユーザーに対しても履歴を保存する必要がありますか？

   
   
   
   
   
   
   

言い換えると、実装に関しては、最も単純なアイデアにはかなりのニュアンスが伴います。

プロンプトの構成は、リクエストごとに変わるべきではないと判断しました。 たとえば、最初にユーザーに10個のプロンプトが表示され、その後5個のプロンプトが削除された場合、次回は残り5個のクエリのみが表示されます。 この動作は、ほとんどの状況で最も驚くことではありません。

履歴の保存に関しては、大規模な検索の要求とビデオサービスの要求は本質的に異なる要求であるため、履歴のヒントはサービスごとに異なる必要があると判断しました。 ログインの履歴は保持されるため、たとえば、デスクトップユーザーは、あちこちにログインしている場合、モバイルデバイスからのリクエストにアクセスできます。

これで、Yandex.Marketだけでなく、すべての主要な検索サービスで履歴クエリを利用できます。 以下に、例えば、Yandex.PicturesとYandex.Videoに関する私の歴史的なヒントを紹介します。

3.アプリケーションとサービスのサジェスト

2017年に、Yandexアプリケーションに目を向けました。 それらのヒントが開発中のWebバージョンの背後にあることは明らかであり、これは受け入れられません！ 結局のところ、最高のユーザーエクスペリエンスを享受できるのはアプリケーションのユーザーです。

主な検索アプリケーションは、 Yandex BrowserとYandexアプリケーションです 。

Yandexアプリケーションは、単語ごとのヒントといくつかの豊富な回答をすでに誇っていましたが、全文入力はありませんでした。 Yandex.Browserには、フルテキストヒントのみが含まれていました。 同時に、ブラウザはユニークなプログラムです。これは、アドレスバーが画面の下部にあるため、検索ヒントが「逆さま」に表示されるためです。

その結果、アプリケーション開発チームと協力して、必要なものをすべて実装することができました。 Yandex.Browserでは、口コミプロンプトはアドレスバーのすぐ上にあります。これは非常に便利で、次のように検索クエリをすばやく入力できます。 Sajestはキーボードの近くにあり、入力時にユーザーの注意が集中します。 Yandexアプリは、サジェストの観点から視覚的な進歩を実装しています。 この決定により、他のアプリケーションやYandexのWebバージョンが徐々に登場します。

また、マーケットのヒントについても述べたいと思います。 わずか1か月で、私たちは大規模な最高の最高のものを市場に紹介することができました：単語ごとのヒントとフルテキストのヒント、その削除のための履歴とクロス、そしてWebバージョンとアプリケーションの両方でこれを行いました。

一貫性のあるインターフェイスはユーザーを支援します。ユーザーは新しいなじみのないメカニズムに慣れる必要はありません。 検索で得られたユーザーエクスペリエンスは、他のサービスを使用する場合にも役立ちます。これは、メトリックに明確に表示されます。

同時に、影響を与えられないサイトがあります。 多くのユーザーがモバイルChromeアドレスバーからクエリを入力するとします。 しかし、判明したのは、

Chromiumのsajestは非常に多くのことを行うことができます。写真、特別な種類のテキストなど、sourceのParseSuggestResultsメソッドを参照してください。 これにより、Yandexをメイン検索として選択したモバイルGoogle Chromeのユーザーに、豊富なsjestのすべての機能（事実の回答、天気、交通渋滞など）を提供することができました。

これは私のお気に入りの実装の1つです。 Chromiumの作成者がこれらすべての機能を提供してくれたことは素晴らしいことです！ もちろん、今のところ、Chromeで単語ごとの野さを実装することは不可能です。

4.ヒントの事実

ユーザーのリクエストを入力中に直接応答する機能は魅力的です。 このような機会は、リクエストのセマンティクスをよく理解しているときに発生します。 この点で、ビデオのいくつかの興味深い実装についてお話したいと思います。

ビデオクエリの非常に重要なクラスは、テレビ番組です。 すべてのシリーズの名前を知っており、それらについてのクエリがどのように配置されているかを理解しています。 クエリテキストは、多くの場合、論理的な部分に分割できます。シリーズの名前、単語「series」の横の数字、単語「season」の横の数字です。 単一の単語プロンプトのフレームワーク内でこのような論理部分を結合することは論理的です。 以前に、「ゲームオブスローンズ」を入力することで、続編「1」、「シーズン1」、「7」、「5」を表示でき、数字はシリーズとシーズンの両方を参照できるようになりました。

リクエストを理解するもう1つの例は、ユーザーが必要な応答を含むことが保証されているページにユーザーを移動する機能です。 たとえば、ユーザーが「ターミネーター」というクエリを入力すると、1991年の映画を意味する可能性が高く、「ターミネーター3」というクエリを入力すると、2003年の映画について話していることになります。 そのため、実際のリクエストに加えて、目的の映画への直接リンクをスジェストに表示することが可能です。

対応する要素をクリックすると、ユーザーはサービスの特別に用意された美しいページに移動します。 この場合、Yandexが正しい答えを確実に見つけることができます。

未来

将来、検索候補が待ち受けているのは何ですか？

もちろん、「トランザクション性」に取り組み続けます。 クエリの入力中でも検索エンジンが答えを出すことができ、クエリの設定段階をスキップしたり、検索結果の読み込みや表示などを待機したりできるようになると便利です。 リクエストを入力する前に、引き続きヒントを充実させ、できるだけ多くの問題を解決する必要があります。

当然、データの操作を継続する必要があります。 前の記事の後、サジェストがどのように内部に配置されているかについていくつかの質問を受けました。 将来の出版物では、このトピックに戻り、1秒あたり10万件のクエリに応答し、各クエリを50ミリ秒未満で処理し、同時に15億件の検索を可能にする良いヒントを得るために必要なアルゴリズムとデータ構造について説明しますオプション。 クエリの頻度を予測し、適切なトップを形成することについて伝えるべきことがありますが、これらの領域で多くの改善が可能であることも明らかです。

検索ヒントは、検索結果ページの機能的および技術的に洗練されたインターフェイス部分の1つです。 ユーザーとの対話、メトリックの計算などを担当するすべてのコードが、可能な限り迅速にロードおよび実行されることが非常に重要です。 もちろん、ここでは、膨大な数のブラウザー、OSバージョン、およびデバイス自体の標準的なプログラミングの問題に直面しています。 したがって、検索ヒントの開発とテストは非常に興味深いトピックであり、これについての出版物とスピーチも期待しています。

もちろん、モバイル開発に関してはやるべきことがたくさんあります。 アドレスバーのサジェストは、検索行のサジェストと同じではありません。 クエリの入力だけでなく、ブックマーク、履歴、入力リンクの検索にもうまく対処する必要があります。 ユニバーサルアプリケーションとウィジェットのサジェストは、携帯電話でアプリケーション、ファイル、連絡先を検索し、それらとやり取りできるようにする必要があります。

このすべては、新しい年に検索のヒントのチームによって処理されます。 1年後にまた別の記事を書いて、すべてがうまくいったことを伝えられることを願っています！