32

I'm deploying an instant search on my Windows app. At the first implementation, when the user types a key, the search engine makes a query and returns the results. I thought that that wasn't too efficient, because when the user wants to search for a long word, each character 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 loads the results in the table. More efficient, less glitch when the rows are reloaded.

Is this a good practice anyway? Is there any convention about it? I'm seeking for a case study about how much milliseconds that delay should be, but I didn't find anything. A short one, and the application will make a lot of queries when the user types slowly. A long one, and the user will perceive the application as slow in loading data.

Improve this question
2
  • 1
    To anyone interested, this is often called "input debouncing". It refers to a system filtering out "spurious" inputs before accepting an input as definitive. A way of implementing it is by having the function call wrapped in a short timer, say, 500ms, and have the timer reset every time the function is called. The function will only do real work once the timer reaches the specified limit. It is also a good idea, depending on context, to also filter out short inputs (a single char search is often not enough to be a meaningful).
    – sleblanc
    Mar 9, 2015 at 16:14
  • There is also throttling, which has a similar effect, but is often more responsive: in this case, throttling will limit the interval between function calls to a certain limit. The function call is still wrapped in a timer, but now, the first time the function is called, it is executed, then the timer is started. If another function is called while the timer runs, a flag is set so that the timer will apply the function once, when the timer runs out. Then, the function will run and start its timer. The process continues until the wrapper function is not called while the timer is running.
    – sleblanc
    Mar 9, 2015 at 16:17

6 Answers 6

Reset to default
18

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.

Improve this answer
4
  • 1
    I have also used this method in the past. I chose my timings based on (guestimated) average typing speeds. So, say a user types at least 3 characters per second. Then, I'd set the lower limit to 1/3 seconds. My personal rule of thumb was to set the upper limit to 5*lower limit (i.e. 5/3 seconds) -- 5 being about the average word length.
    – Brendon
    Feb 9, 2013 at 0:22
  • @Brendon I've also seen cases where it explicitly doesn't start searching until some fixed number of characters (typically 3) have been entered (as opposed to a delay based on possible typing speed).
    – TripeHound
    Jul 28, 2017 at 12:39
  • Do I understand correctly that with the delays of 0.1s and 0.8s: If a user is typing 5 letters, with just less than 0.1s between each letter, the search will only be performed 0.1s after the last letter is typed? And If the user types 50 letters with just less than 0.1s between each letter, searches will be performed already after 8-9 letters, even if the user is still typing, resulting in 5-6 searches happening in total? And obviously if the user types 5 letters with 0.5s between each letter, a search is performed with every letter typed?
    – Thorbear
    Dec 1, 2020 at 16:58
  • 1
    Yes, exactly Thorbear.
    – André
    Dec 1, 2020 at 20:06
14

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.

Improve this answer
3
  • 1
    I also read (in a MCI-script at university no link, sorry), that actions which are faster than 80 milliseconds will be perceived as non-casual (like they happend before a user caused them). So don't make things too fast ;)
    – K..
    Feb 8, 2013 at 11:06
  • Yup, i saw that you focused on web applications, but nevermind, those are good points to consider on this topic.
    – dbalboa
    Feb 12, 2013 at 8:05
  • I agree with waiting until at least two, maybe three letters are typed first before looking anything up. In my apps previously I have just searched every two characters typed rather than delaying with a timer.
    – nik0lai
    Mar 21, 2013 at 13:21
5

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.

enter image description here

  • 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

Improve this 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.

Improve this answer
1
  • 5
    It's not really an instant search then if you have to hit Enter to get any results; that's just a traditional search.
    – JonW ♦
    Feb 8, 2013 at 10:22
2

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.

Improve this answer
1

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.

Improve this answer
7
  • I think this rule is too simplistic. Maybe you mean, "Using time delays alone for controlling something is always wrong." If you're saying that time delays cannot be a tool in the toolbox for anticipating the user's needs and desires, then your apps will be less adaptive.
    – LarsH
    Mar 12, 2013 at 21:20
  • This rule is proved by all my experience in more than 15 years of work on different engineering and software problems. Although it does not means that one never should use time delays. Sometimes there is nothing else possible, so we are forced to use this only option. But even in these rare cases, it is nevertheless wrong. :)
    – johnfound
    Mar 12, 2013 at 23:32
  • OK. My 28 yrs experience in software and UI dev disagrees. So does biology -- clocks (timed delays) are often used, in combination with other strategies, to great effect in adapting to the environment.
    – LarsH
    Mar 13, 2013 at 1:44
  • I can't remember some bio process that to depend on time delays in order to control things. There is always some feedback and event driven control. You can't make "adapting to the environment" using hard delays. Using time delays, depending on some conditions is not actually the same, because the delay is not used for control in this case, but the algorithm that compute the needed time. The time delay is just a mediator to some event driven control.
    – johnfound
    Mar 13, 2013 at 4:57
  • That's why I suggested that you meant "Using time delays alone for controlling something is always wrong." I assume that "depending on some conditions" is exactly what the OP is describing without explicitly stating this; key events do drive the process, but delays are also part of it.
    – LarsH
    Mar 13, 2013 at 13:20

Your Answer

By clicking “Post Your Answer”, you agree to our terms of service and acknowledge that you have read and understand our privacy policy and code of conduct.

Not the answer you're looking for? Browse other questions tagged or ask your own question.