Delay on keystroke when search as you type

Question

I'm deploying an instant search on my windows app. At the first implementation, when the user type a key, the search engine make a query and return the results. I thought that that wasn't too much efficient, because when the user want to search for a long word, each char makes a query, so i made the search start a bit delayed, to let the user write the full word before it starts to query and load results at the table. More efficient, less glitch when the rows are reloaded.

Its a good practice anyway? There is any convention about it? I'm seeking for a case study about how much milliseconds that delay should be, but I dont find anything. Short one, and the application will make a lot of queries when the user type slowly. Long one, and the user will perceive like the application is slow loading data.

Answer 1

Yes, this is excellent practice. It can even improve the responsiveness of your application, because doing the actual search on every key press can cause delays in itself.

I have build a component (that we're using all over the place for this and similar purposes) that basically sets two times: a minimum time to wait for more input, and a maximum time from the first input to start performing the action. The minimum timer is reset with each edit of the input, the maximum time is only reset on the triggering of the action (the search, in your case.) That way, you avoid the situation you describe. Response to this setup in the applications I have build has been very good.

I guess the ideal timings depend on the exact use case and the audience, but I'm using values in the range of 0.1s for the minimum wait, and 0.8s for the maximum.

Answer 2

I don't actually know about any case studies, but here's what I did when I made an "instant search" in my webapp and why.

I never start any queries automatically after a few characters were typed in. In my opinion search boxes that to this are quite fiddly and annoying. Instead I only submit the query once the user hits enter.

For those who might not know that you can hit enter to submit, I added a little search icon (magnifying glass) inside the search box, which also submits if you click it. Some less experienced users always search for a "submit search" button to click and might be a bit confused if they can't find any.

Answer 3

I am not sure I understand the logic behind delaying the display of the keystroke. Remember your key stroke is the primary action which the user performs (the resultant search results are secondary) and the user would expect an immediate response to the primary action he has performed. A delay in the response would just confuse him.

However with regards to the delay in showing the search results, I recommend going with either of these approaches :

• Your responses dont have to be immediate. The Jquery Token Input (an autocomplete plugin itself recommends a delay of 300 millseconds). So a short delay is not going to frustrate the user. However I do recommend showing a in progress indicator which informs the user that search results are being retrieved. To quote this smashing magazine article

Ideally the results will be displayed immediately, but a progress indicator (searching…) should be used for system feedback. Fidelity (below) displays one where the results will eventually be displayed.

• Since one of your challenges is that there is a scope for a lot of results with each character being added, I recommend allowing the user to scope his results so that the results are both specific to what he is looking for and you also are sending a lesser number of queries out. Here is an example of Google and photobucket do it

UI Patterns For Mobile Apps: Search, Sort And Filter

Designing for the Mobile Web: Special Considerations

Answer 4

I don't have any studies for auto-complete in particular, but perceptible latency for a user interface is thought to be at 100 milliseconds. At that point, the user feels that they are in control and the interface is responsive.

With that in mind, there are a few factors you should consider.

• How quickly will your query return on slow internet connections/slower computers?
• How are you optimizing delivery of the data? Is it compressed? JSON? HTML?
• How much processing power is required for unpacking the returned data?
• How many concurrent connections can your database/server handle if multiple users are in play?
• Can the data be cached without hitting the database?
• Are the results finite enough that they even might be stored on-page?

In general, I would delay lookup until at least 2 characters have been typed, make the lookup an asynchronous request, cache popular queries to avoid a DB hit, and use a JSON format and compress it. And, as Mervin mentioned, if there is a delay for any reason, use a loading icon to let the user know that something is happening. I haven't ever experimented with an intentional lookup delay beyond the two character limit, but I suspect that anything beyond 100 milliseconds round trip wouldn't pass the "it feels responsive test".

Update: On re-reading your question, I see that I missed that it's a Windows app rather than a web app. Most of the advice still applies, however.

Answer 5

The main problem with delays is that they are not adaptive to the environment (in this case to the user differences).

That is why I have a rule "Using time delays for controlling something is always wrong."

The most proper solution in this case is simply to make request on every keystroke.

If your requests are not fast enough - I mean guaranteed 20..50 requests per second, you have to organize the requests in asynchronous way - I mean in separate thread and refresh the proposal window when the request returns, allowing the user to type in the same time. This way, the delay will be introduced automatically and will depend on environment, not on predefined constants.

One common trick in such situation is to request only several first matches of the query, and to request the remaining only if the user scrolls through the proposal window.

If the matching algorithm is good enough, the user will choose one of the first proposals in most cases.

Answer 6

You can make your input field adaptive to the user. That is, as the user types the first few characters you measure how fast they did it. As the user keep typing you wait until he/she slows down relative to their initial speed (which indicates a finished request or at least a pause in thought) and submit your instant search request. This will allow you to provide the best experience to both fast and slow typers.