How and why we rethought the search input field of Yandex

We have already talked twice about our search tips: the first post came out already in 2012, the second one happened quite recently.

Search tips - one of those things that the company can be proud of, so we do not seem shameful to talk about them often. Today we will talk about the functional changes in search clues that occurred in 2017. It's not just about the changes in the interface, but also about the interesting statistics and technological challenges that it has set for us.

1. “Expanding” input field

By the beginning of 2017, many messengers already possessed "rubber" input fields. A person who writes a long enough text, of course, wants to be able to see if not the whole text, then at least a considerable part of it.

Surprisingly, the search engines completely ignored this trend. But long queries make up a significant part of the stream. Say, queries containing more than seven words make up 10% of the entire flow of queries to Yandex!

In general, query length is a very interesting feature. The proportion of long requests is an indicator subject to pronounced seasonality caused by the educational needs of schoolchildren and students. Therefore, on the graph of the share of long queries all holidays, weekends and summer holidays are clearly visible. But even after deducting this effect, it is noticeable that requests are gradually becoming longer: for example, in the summer of 2017 the proportion of long requests was 20% higher compared to the summer of 2016. The graph below shows the dynamics of changes in the share of long requests in the flow of requests to Yandex, the value corresponding to the beginning of 2016 is taken as one.

In addition to the fact that users often specify long queries, it is also important that they often change the wording of an already specified query. We can say that the text editing script in the search line is in demand.

Based on this, we really wanted to introduce the so-called. expanding input field: a field whose size would increase in the process of entering text when this would be necessary.

The idea is quite simple, but we spent about six months to bring it to production. At first we got too excited about this idea and significantly expanded it by inventing a separate page for entering a request , which completely covered the current screen, contained a wide input field, full-text hints, and so on. Fortunately, I still have one screenshot of this page, so I can demonstrate it to you:

When we turned on the display of the input page to a small number of users, it turned out that this page was not clear to them. They stopped asking questions from the search page, tried to do it from the Yandex main page and so on. So we had to shut down the experiment ahead of time!

Such results were just another confirmation of the general rule: if you implement a simple idea, you should not change too much. Therefore, we tried to rethink the concept and move iteratively. The first successful solution was to implement the basic idea and at the same time differ as little as possible from the current production. Some things, however, had to be changed: for example, the expanding input field does not correlate well with the triangular shape of the search arrow, so we needed an animation that turned the search button into a rectangular one.

The result was a solution that Yandex users can now use on the results pages of a large search, image search and video search:

I must say that this implementation is one of the best ever implemented team in the mobile Yandex. We managed to influence even how often users use the search engine!

2. Historical tips

Another fact of objective reality: users often ask the same requests. If we take the queries of the median user, we will see that he sets more than half of his queries again.

If so, you can simplify the input queries that were asked by this user in the past. Let us say, to prioritize showing in queries those requests that the user has already entered.

It should be noted that this idea was already implemented in desktop Yandex a long time ago: after entering the second character, a number of historical cues are shown in purple if their beginning coincides with the current input.

On mobile, however, this was not possible. So we rushed to solve it, at the same time having dealt with a number of problems that are also relevant for the desktop, so that in the future we are waiting for quite significant changes related to the historical demands on the desktops.

1. Users do not always want their past queries to be remembered. For example, there are secret requests. Therefore, it is necessary to give the opportunity to turn off the query history in general, and in addition to give the opportunity to delete specific prompts.

   
   
   

2. What to do with the display of historical clues in connection with the removal? Suppose a user deleted some query - should a new, earlier one come in its place? But then the user may need to make several hundred deletions to destroy all the necessary hints. Maybe just to always show the last 10 tips, and not to update their list during the removal process? But then after reloading the page, the user will see some new historical clues, and he may not be ready for this.

   
   
   

3. Historical requests must be delivered and updated very quickly. Say, right after a certain query is set, it should appear among the historical clues. It can be said that the just specified query is not really needed, since No one will need to set the current request again, but without it, the functionality of historical prompts will be completely incomprehensible to the user, so we have very serious requirements for the backend of personal prompts.

   
   
   
4. It is required to understand what is the entity for which the query history is saved. Should historical queries differ for different services, or should they coincide? Do you need to store history for each specific browser, or should you try to store it also for logged-in users so that the query history is available on all devices?

In other words, the simplest idea is overgrown with a fair amount of nuances when it comes to implementation.

We decided that the composition of the prompts should not change from request to request. For example, if ten prompts were initially displayed to the user, and then he deleted five of them, then the next time he should see only the five remaining queries. This behavior will cause the least surprise in most situations.

As for the history storage, we decided that the historical cues should differ in different services, because the queries in the large search and the requests to the video service are essentially different requests. We keep the history for logins, so that, say, a user on the desktop will have access to requests from his mobile device, if he is logged in both there and there.

Now historical queries are available on all of our main search services, as well as on Yandex.Market. Below, for example, my historical tips on Yandex.Maps and Yandex.Video are presented.

3. Sajest in applications and services

In 2017, we turned our attention to Yandex applications. It was obvious that the hints in them lagged behind the web version in its development, and this is unacceptable! After all, users of our applications should receive the best user experience.

Our main search applications are Yandex . Browser and Yandex application .

The Yandex application could already boast word-by-word hints and some rich answers, but there was no full-text input in it. Yandex.Browser, in turn, contained only full-text hints. At the same time, our Browser is a unique program, because the omnibox is located in the lower part of the screen, therefore, the search hints in it should be displayed "inverted".

As a result, we, together with the application development teams, managed to implement everything that was needed. In Yandex Browser, word-by-word hints are located directly above the omnibox, which is very convenient and allows you to quickly type search queries, since Sadzhest is located as close as possible to the keyboard, which focuses the person at the time of entry. The Yandex application now implements an advanced from a visual point of view sadzhest. It is to this solution that we will gradually arrive in other applications, and in the web version of Yandex.

I would like to say more about the tips in the Market. We managed to literally introduce all the best that was in the big sadget into the Market: word-by-word and full-text hints, history and crosses to remove it, and to do it both in the web version and in applications.

Consistent interfaces help users: they do not need to get used to new unfamiliar mechanics. The user experience gained in the Search is also useful when using our other services, and this is clearly seen on the metrics.

At the same time, there are platforms that we cannot influence. Say, many users enter their requests through the omnibox of mobile Chrome. It turned out, however,

that the sadzhest in Chromium can do quite a lot: pictures, special text, and so on, see the ParseSuggestResults method in the sources . Thanks to this, it turned out to be possible to provide users of mobile Google Chrome, who chose Yandex search as the main, all the possibilities of our rich sadjest: factual answers, weather, traffic jams and so on.

This is one of my favorite implementations. It's great that the creators of Chromium provided all these possibilities! Of course, it's a shame that now it is impossible to implement a word sadst in Chrome.

4. Facts in the tips

The ability to respond to a user request directly during its entry is fascinating. This possibility arises when we understand the semantics of the query well. In this regard, I would like to talk about a few interesting introductions in Video.

An extremely important class of video requests - series. We know the names of all the TV shows and understand how requests for them are arranged. Query texts can often be divided into logical parts: the name of the series, the number next to the word "series", the number next to the word "season." It is logical to combine such logical parts within one word-by-word hint. If earlier on entering the “game of thrones” we could show the sequels “1”, “1 season”, “7” and “5”, and the numbers could relate to both the series and the seasons, now we have added more structure:

Another example of understanding a request is the ability to move a user to a page that is guaranteed to contain the answer he needs. For example, when a user enters the query "terminator", we understand that he is most likely referring to the film from 1991, and when he enters the query "terminator 3" - we are quite clearly talking about the 2003 film. Therefore, it is possible, in addition to the actual requests, to show in the sadget and a direct link to the desired movie.

When you click on the corresponding item, the user will be taken to a specially prepared, beautiful service page. In this case, you can be sure that Yandex will find the right answer.

Future

What is the future of search tips?

Of course, we will continue to work on "transactional". It's great when the search engine can give an answer even while entering a query, allowing the user to skip the query job phase, wait for the search results to load, view them, and so on. We need to continue to enrich the tips and solve as many tasks as possible before entering the request.

Naturally, you need to continue to work on the data. After the previous article, we received a few questions about how the sadzhest inside is arranged. In future publications, we will return to this topic and describe what algorithms and data structures are required to make good hints, responding to 100,000 requests per second, processing each request in less than 50 milliseconds and at the same time searching among the possible 1.5 billion options. We have a lot to say about the predictions of the request frequencies and the formation of the correct tops - however, it is also clear that much can be improved in these areas.

Search tips are one of the functionally and technologically complex interface parts of the search results page. It is extremely important that all code that is responsible for user interaction, calculates metrics, and so on, is loaded and executed as quickly as possible. Of course, here we are faced with standard programming problems for a huge number of browsers, OS versions and devices themselves. Therefore, the development and testing of search tips is a very interesting topic and, I hope, we will also have publications and speeches about this.

And, of course, we have a lot to do in terms of mobile development. The Sajest in the Omnibox is not the same as the Sajest in the search line, since he should cope well not only with entering queries, but also with searching for bookmarks, history, entering links. Sajest in universal applications and widgets should also allow you to search for applications, files and contacts in your phone, as well as be able to interact with them.

All this will deal with a team of search tips in the new year. I hope that in a year we will again be able to write another article and tell you what happened!