Difficult in the obvious: how we made the call interface to Yandex.Shell

Today we want to talk about how they created such, as sometimes it seems, an obvious thing, like the call interface in Yandex.Shell . To our surprise, during our work, we realized how long no one had seriously thought about the fact that in most of the phones it had not functionally improved for many years. And the world for this time has gone forward. It is time to take a retrospective look at how it was created, what tasks we faced and what solutions we came to.

The short and understandable English word “dialer” has yet to acquire a harmonious, non-hearing Russian equivalent. If you look in the dictionary, then as a translation you will be offered a furious “dialer”. However, the words “dialer”, “dialer” and “dialer” got accustomed in a living language. As part of our internal cuisine, we are accustomed to use the last option, and we will stick to it in this post.

We came to the idea that we need to create our own dealer for our shell, starting from the fact that nothing really new appeared in this segment for a long time. The native and third-party dealers that existed at that time in iPhones and Androids were very convincing and beautiful. But in terms of functionality, all of them are not far removed from what we have already seen in ordinary mobile phones of the pre-smartphone era. It was necessary not only to endow our dealer with a complete set of usual expected functions, such as the list of favorites, call log or T9, but also to go significantly further, namely, to introduce into it developments that have not yet been encountered in the market.
')
Our advantage in achieving this goal was that, unlike its counterparts, Yandex.Dayler was created initially sharpened for Russia and other countries of Yandex presence, which enabled us to take into account the interests and behavioral peculiarities of “our” users. In addition, long-developed custom services are the strength of Yandex, and it is through them that we expected to improve the functionality of our dealer.

But first things first.

Infinite address book

One of our first tasks was the need to minimize the number of clicks the user needs to call the organization he needs. Indeed, calls to various organizations, including those unknown to the user, have been and remain one of the most popular scenarios for using the phone.

The formulated task assumes a complete rethinking of the user's stereotype. Until now, the call to the right organization meant a whole range of sequential actions. Consider a small example. If I need to call the nearest pharmacy, what actions will I have to take? There are various options, but obviously, they will somehow include:

- positioning (for a start, where am I?);
- search for pharmacies in a given area;
- choice of pharmacy;
- search for her contact information;
- copying or manually transferring a phone number;
- actually call.

Probably, each of us has long ago developed more or less familiar scenarios for the accomplishment of all these actions. Here, elementary search (both mobile and desktop), maps, navigator, and a lot of other things come to our aid. The problem is that for all these services everything connected with making a call is a function at best secondary. And because of this, the path from the emergence of the need to call the pharmacy to, directly, the call is quite long and thorny.
Now, if the phone of the pharmacy were of the same level of accessibility as any number in our address book ... You already understood that the idea to implement and / or load ready-made reference information from the cloud into the dialer itself was in the air.

We decided that from now on the list of contacts will no longer be limited to personal contacts of the user. As the user enters a name or a name, in addition to his own contacts, he is now replaced with tips that match the search criteria based on the most popular requests from Yandex users. These prompts are issued instantly since they are already downloaded to the phone. When you select one of the prompts, the user is given the appropriate list of the nearest organizations from the extensive Yandex.Reference base, taking into account his current location.

The user can immediately call any of the found organizations, or pre-examine its card. A card is usually as informative as possible: with a telephone, an address, position on a map and a website. Any of these contacts can be instantly, in one click, use or add an organization card to your own contacts.
All the way from the idea to the call comes down, in fact, to one point - to decide on the choice of a specific pharmacy. And all that a machine can do, let the machine do.

Let us return to our pharmacy example and see how this path is now traversed.

1. Go to the dealer, tab "Contacts".

2. We start to type the word "pharmacy". You don’t have to type for a long time, because after the “an” the prompt gives out not only the word “pharmacy”, but also some of the most popular queries related to the word “pharmacies”.



3. Select the desired hint. We fall into the list of suitable pharmacies, sorted by distance from our location.



4. We call.

Or do not call. And go to the contact card to use any other means of communication or add this card to your contacts.



Connecting a powerful database such as Yandex.Seeber to the diler made the user's address book interactive, localized by location and, in fact, endless. Once having mastered the possibilities of an endless address book, the user gradually begins to change the stereotype of behavior in favor of a simple two-two rules: “if you want to call, go to the dealer”. Not in the search widget, not in the browser, not in the cards, but immediately to the dealer. It's so natural.

Definition of unknown numbers

Appetite comes with eating. And this possibility - the definition of unknown numbers - is closely related to the previous one. Realizing the advantages of integrating the address book with the Yandex.Directory, we wanted more, and in the first place - automatic identification of the identity of an unknown number during a call. It is difficult to overestimate the demand for this function among users. A call comes in from an unknown number, the dialer intercepts the number, finds it in the directory and displays the name of the calling organization.

However, in this case, we are faced with an unsolvable problem. Without embedding our shell in the system, we cannot replace or make any changes to the standard incoming call window. In some dilers, this problem is solved (or rather, it is bypassed) with the help of its own window of the incoming call, which emerges over the standard one. However, this is a very unreliable approach, bad for stability. And stability for us is the factor that we could not sacrifice in any way.

Therefore it was necessary for a while to abandon the idea of ​​loading data about the caller from the Directory. But nothing prevented us from embodying the very same idea - identifying unknown numbers - but already in the call log.
The diler has its own call log. In addition to standard features (call consolidation, duration, etc.), we added the definition of numbers to it. If the number is unknown, but is found in the Yandex.Manager, the corresponding journal entry takes on a more pleasant and informative look. A detailed card of such a determined number can be quickly, in two clicks, added to your own contacts.



We are talking, of course, about all types of calls: incoming, missed and outgoing, regardless of whether you were looking for these numbers using the infinite address book or just typed from the keyboard.

Logos of mobile operators

The next thing that seemed worthy of our implementation is help in identifying mobile operators. For so many users in the post-Soviet space, it is crucial to know which operators call the numbers, because this directly affects the cost of the call. Or, say, your friend has two numbers from different operators, and he asked to call him exclusively on Megaphone.

And since few people can name all the codes of all mobile operators by heart, we decided to introduce this small but pleasant addition. The dialer determines the mobile operator for all mobile phones (if possible) and inserts the icon of the corresponding operator in front of the number (for example, in the contact card).

Transliterated Search

The next problem that can be solved with the help of our dealer is rooted in the past. At the time when the first phones appeared, in the address book of which contacts could be entered not only in Latin, but also Cyrillic. Today, this problem is exacerbated by several other factors.

Unfortunately, the way in which contacts exist in our address books does not always depend only on us. Some of the contacts we enter ourselves, others are inherited from email accounts, and others from social networks. Some contacts were added yesterday, others are stored from those glorious times of the beginning of the century, when we bought our first Nokia 3310. Not every user takes the trouble to combine contacts from different accounts. Not everyone can say with certainty how one or another of his contacts is recorded - in Cyrillic or Latin.

We decided that the user should no longer think about the layout of one or another contact — the transliterated search should ensure the “findability” of any contact and with any input method. Search results are displayed instantly and regardless of which layout is used for typing.

Search for diminutive names

Having dealt with transliteration, we turned to another thing in which users are willingly confused. For the same reasons described above, user contacts can be entered either by full name or by diminutive ones. We taught the dealer to look for contacts in both ways. On request [Vanya] he will find all Ivanov, on request [Ekaterina] - all Cats. The best job search will illustrate a screenshot.



As the inquisitive reader has already realized, combining the last two possibilities, we get that, on the request of [Vova], all of Vladimir will be found, which should have been proved.

Both of these functions (transliterated search and search by diminutive names) were not implemented in the aforementioned iPhone and Android dilers, simply because the problem itself did not lie for their creators on the surface due to their irrelevance for the American and European markets. And the implementation of these functions, especially search by diminutive names, for all supported locales would be very problematic. We were content with the names used in Russia and tried to make support for this functionality for most of them.