今日は、 Yandex.Shell呼び出しインターフェイスのような、一見明白なものをどのように作成したかについてお話したいと思います。 驚いたことに、作業中に、ほとんどの携帯電話で長年機能が改善されていないという事実を誰も真剣に考えていないことに気付きました。 そして、この間に世界は前進しました。 それがどのように作成されたのか、どのような課題に直面し、どのような決定に至ったのかを振り返ります。
短く理解しやすい英語の「ダイアラー」という言葉は、調和のとれた、切れない耳のロシア語に相当するものをまだ獲得していない。 辞書を見ると、翻訳として猛烈な「ダイヤラー」が提供されます。 しかし、生きた言語では、「ダイヤラー」、「ダイヤラー」、「ダイヤラー」という言葉がより定着しました。 私たちの内部キッチンの一部として、私たちは後者のオプションを使用することに慣れています。これはこの記事で順守します。
私たちは、このセグメントに長い間まったく新しいものが登場していないという事実から、シェル用に独自のダイラーを作成する必要があるという考えに至りました。 その時点でiPhoneやAndroidに存在していたネイティブディーラーとサードパーティディーラーは、非常に説得力があり、美しいものでした。 しかし、機能の面では、それらはすべて、スマートフォン以前の時代の通常の携帯電話ですでに見たものからそれほど遠くありません。 お気に入りリスト、コールログ、T9などの通常の期待される機能のすべてをダイヤラーに提供するだけでなく、さらに先へ進む、つまり、まだ市場で出会っていない開発を導入する必要がありました。
この目標を達成することの利点は、対応するものとは異なり、Yandex.Dilerが当初ロシアおよびその他のYandexの存在する国に合わせて作成されたという事実でした。 さらに、長い間開発されてきたユーザーサービスはYandexの強みであり、ディーラーの機能を改善したいと考えたのは彼らの助けがあったからです。
しかし、まず最初に。
無限のアドレス帳
最初のタスクの1つは、ユーザーが必要な組織に電話するために必要なクリック数を最小限に抑える必要性でした。 実際、ユーザーに知られていない組織を含むさまざまな組織への電話は、最も人気のある電話使用シナリオの1つであり、現在もそうです。
策定されたタスクには、ユーザー行動のステレオタイプの完全な再考が含まれます。 これまで、適切な組織への呼び出しは、一連の一連のアクション全体を暗示していました。 小さな例を考えてみましょう。 最寄りの薬局に電話する必要がある場合、どのアクションを完了する必要がありますか？ さまざまなオプションが可能ですが、明らかに、それらには次のものが含まれます。
-ポジショニング（まず、私はどこにいますか？）;
-特定の地域の薬局を検索します。
-薬局の選択;
-彼女の連絡先情報を検索します。
-電話番号のコピーまたは手動転送。
-実際に呼び出し。
おそらく、私たち一人一人は、これらすべての行動を委託するために、多かれ少なかれ馴染みのあるシナリオを開発してきたでしょう。 ここでは、基本検索（モバイルとデスクトップの両方）、マップ、ナビゲーターなどが私たちの助けになります。 問題は、これらのすべてのサービスについて、通話に関連するすべてのものがせいぜい二次的なものであるということです。 このため、薬局に電話をかける必要から直接電話に至るまでの道のりは非常に長く厄介です。
これで、薬局の電話の可用性がアドレス帳の任意の番号と同じレベルになる場合...既成の参照情報をクラウドからダイバー自体に実装および/またはロードするというアイデアが空中にあることにすでに気付きました。
これで、連絡先リストはユーザーの個人的な連絡先に限定されなくなります。 ユーザーが自分の連絡先に加えて名前またはタイトルを入力すると、最も人気のあるYandexユーザーのクエリに基づいた検索基準を満たすプロンプトが表示されます。 これらのプロンプトはすでに電話機にダウンロードされているため、すぐに発行されます。 プロンプトの1つを選択すると、ユーザーには現在の場所を考慮して、広範なYandex.Directoryデータベースから最も近い組織の対応するリストが提供されます。
ユーザーは、見つかった組織をすぐに呼び出すか、そのカードを事前に調べることができます。 カードは通常、電話、住所、地図の場所、ウェブサイトなど、できる限り有益です。 これらの連絡先は、ワンクリックで即座に組織カードを使用したり、自分の連絡先に追加したりできます。
特定の薬局の選択を決定するために、アイデアからコールまでのすべての方法は、実際には1つのポイントに落ちます。 そして、マシンができることはすべて、車に任せましょう。
薬局の例に戻って、このパスがどのように進むかを見てみましょう。
1.ダイヤラーの[連絡先]タブに移動します。
2.「薬局」という単語を入力し始めます。 「up」の後、プロンプトには「pharmacy」という単語だけでなく、「pharmacy」という単語に関連する最も人気のあるクエリも表示されるため、長時間ダイヤルする必要はありません。
3.目的のプロンプトを選択します。 私たちは、自分の場所からの距離でソートされた、自分に適した薬局のリストに分類されます。
4.電話。
または電話しないでください。 そして、他の通信手段を使用したり、このカードを連絡先に追加するために、連絡先カードにアクセスします。
Yandex.Directoryなどの強力なデータベースをダイラーに接続すると、ユーザーのアドレス帳がインタラクティブになり、場所によってローカライズされ、実際には無限になりました。 無限のアドレス帳の可能性を習得すると、ユーザーは次の2つのルールを優先して、行動のステレオタイプを徐々に変更し始めます。「電話をかけたい場合はダイヤラーに行く」。 検索ウィジェットでも、ブラウザでも、カードでもなく、すぐにダイラーに。 とても自然です
不明な番号の特定
食欲には食事が含まれます。 そして、この可能性-未知の数の識別-は以前のものと密接に関連しています。 アドレス帳をYandex.Directoryと統合することの利点を認識したので、通話中に未知の番号のIDを自動的に判別することを望んでいました。 ユーザー間のこの機能の関連性を過大評価することは困難です。 未知の番号からコールが着信すると、ダイヤラはその番号を傍受し、ディレクトリ内でそれを見つけて、呼び出し元の組織の名前を表示します。
ただし、この場合、解決できない問題に直面しています。 システムにシェルを埋め込むことなく、着信コールの標準ウィンドウを置き換えたり、変更したりすることはできません。 一部のディーラーでは、この問題は、標準の呼び出しにポップアップする着信呼び出しの独自のウィンドウを使用して解決されます（または、バイパスされます）。 ただし、これは安定性に悪影響を及ぼす非常に信頼性の低いアプローチです。 そして、私たちにとっての安定性は、決して犠牲にすることのできない要因です。
そのため、発信者に関するデータをディレクトリからロードするという考えを一時的に放棄しなければなりませんでした。 しかし、未知の番号を特定するという同じ考えを実現することを妨げるものは何もありませんでしたが、すでに通話ログに記録されていました。
ディーラーは独自の通話記録を持っています。 標準機能（通話の組み合わせ、通話時間など）に加えて、番号の定義を追加しました。 番号が不明であるがYandex.Directoryで見つかった場合、対応するジャーナルエントリは、より快適で有益な外観になります。 このように決定された数の詳細なカードは、2回のクリックで自分の連絡先にすばやく追加できます。
もちろん、無限のアドレス帳を使用してこれらの番号を検索したか、キーボードから入力したかどうかに関係なく、着信、不在着信、発信のすべての種類の通話について話します。
携帯電話会社のロゴ
実装する価値があると思われた次のことは、モバイル事業者の特定における支援です。 ソビエト後のスペースにいる非常に多くのユーザーにとって、彼らが呼び出すオペレーターの数を知ることは基本的に重要です。これは呼び出しのコストに直接影響するからです。 または、たとえば、あなたの友人は異なるオペレーターからの2つの番号を持っているので、彼はメガホンだけで彼に電話するように頼みました。
また、すべてのモバイル事業者のすべてのコードを暗記できる人はほとんどいないため、この小さいながらも楽しい追加機能を導入することにしました。 Dylerは、すべての携帯電話にモバイルオペレーターを定義し（可能な場合）、番号の前（連絡先カードなど）にある対応するオペレーターのアイコンに置き換えます。
文字変換検索
ディーラーの助けを借りて解決できる次の問題は過去に根ざしています。 最初の電話が登場したとき、連絡先はラテン語だけでなくキリル文字でも入力できるアドレス帳にありました。 今日、この問題はさらにいくつかの要因によって悪化しています。
残念ながら、アドレス帳に連絡先が存在する方法は、常に私たちだけに依存するわけではありません。 いくつかの連絡先を自分で入力し、その他は電子メールアカウントから継承し、その他はソーシャルネットワークから継承します。 昨日入力された連絡先もあれば、最初のNokia 3310を購入した世紀初頭の輝かしい時代から保存された連絡先もあります。すべてのユーザーが異なるアカウントの連絡先をまとめるのに苦労するわけではありません。 誰もがこの接触またはその接触がキリル文字またはラテン文字でどのように記録されているかを確実に言うことができるわけではありません。
これ以降、ユーザーは連絡先がどのレイアウトで書かれているかを考えてはならないと判断しました。音訳された検索では、連絡先と入力方法の「検索可能性」を確認する必要があります。 セットのレイアウトに関係なく、検索結果は即座に表示されます。
略語で検索
文字変換を扱った後、ユーザーが熱心に混乱する別のことに注目しました。 上記と同じ理由で、ユーザーの連絡先はフルネームと小口の両方で入力できます。 私たちは、両方の方法で連絡先を探すようにダイラーに教えました。 [Vanya]のリクエストで、[Catherine]-すべてのKatyaのリクエストで、彼はすべてのIvanovを見つけます。 スクリーンショットは、検索の仕事を最もよく示しています。
好奇心reader盛な読者がすでに気付いているように、最後の2つの可能性を組み合わせて、[Vova]の要求ですべてのVladimirsが存在することを証明します。
これらの機能（音訳された検索と省略名による検索）の両方は、上記のiPhoneおよびAndroidのディーラーでは実装されていません。アメリカとヨーロッパの市場とは無関係であるため、問題自体が作成者の表面になかったからです。 また、サポートされているすべてのロケールに対するこれらの関数の実装、特に略語による検索は非常に問題が多いでしょう。 私たちはロシアで使用されている名前に満足し、それらのほとんどでこの機能をサポートしようとしました。