Take the 2-minute tour ×
User Experience Stack Exchange is a question and answer site for user experience researchers and experts. It's 100% free, no registration required.

We're implementing an Autocomplete search field on a website we're working on. However the question arises:

At what point should you start showing the autocomplete results?

mockup

download bmml source – Wireframes created with Balsamiq Mockups

There are a few options that we have:

  1. Start showing results immediately when the user starts typing (could get in the way if people are typing accidently, plus there's possibly a server hit to do so here)
  2. Wait until two characters have been entered so that you can then be more confident that people are typing in this field intentionally (risks not returning autocomplete answers for two-digit queries such as C#)
  3. Add a delay of x ms before returning results (if so, what is the ideal delay?)

Is there an ideal way of doing this? I'm concerned that flashing up results too quickly will annoy people (just as with hoverover menus and the like), but not presenting the results quickly enough negates the purpose of having autocomplete in the first place.

share|improve this question
    
I would argue that results should be available from the first letter and instant (without a delay). –  JohnGB Mar 12 '13 at 15:52
1  
Possible duplicate: ux.stackexchange.com/questions/34360/… –  André Mar 12 '13 at 16:01
    
@André you may be right, I missed that one when researching the question, however mine is slightly different in that it's not assuming that delay is the way to do it but is looking for alternatives. However if a delay is the best idea then the answers on that question would be of good use. –  JonW Mar 12 '13 at 16:59

7 Answers 7

up vote 11 down vote accepted

Perhaps a hybrid approach would make sense. What I'm thinking would be to link the delay to the number of characters already entered, with a longer delay for fewer characters.

If a user has only typed 'K', they're probably going to type a lot more, so an instant suggestion would return more results (less likely to have their target at the top), risk more flickering (as they keep typing), and increase server hits (since they're likelier to keep typing regardless. If that's all they're going to type, they'll pause and the autocomplete they might already be expecting would kick in.

By the time they've typed 'Kittens on Skat', the reverse of all of the above is true, so a shorter-to-zero delay would be more appropriate.

share|improve this answer
1  
Yes! +1. Autocompleting immediately can be a negative user experience. –  LarsH Mar 12 '13 at 20:54
    
Yes, I like this idea. I think finding the happy balance between when to show suggestions and when to let the user just 'get on with it' would be a tricky, but useful exercise. It also gets past one of my concerns that by displaying results immediately there is a possibility that the user thinks those suggestions are the results, rather than just the first X results matching the criteria. Typing 'K' is going to return A LOT of results, so we'd have to decide how many to suggest. This suggestion negates that risk to an extent. –  JonW Mar 15 '13 at 9:59

Generally typeahead/autocomplete is instant, and to avoid confusion I'd recommend sticking with the standard of autocompleting instantly after a single character.

For no reason other than convention I'd suggest keeping an instant, one character autocomplete; every search bar I have within reach acts this way, including Google.com, Google Chrome, iTunes, Visual Studio, SQL Server Management Studio, Google Search on Android...and if Microsoft, Apple and Google all agree on something, they often have a reason. Not that you should blindly follow convention, but conventions are comfortable and low friction so you generally need good reasons to start breaking them.

Any delay you add risks making users question whether it's working; is it really an autocompelte field? It autocompleted before, why isn't it now?.

Depending on how (and how well) your autocomplete works, users might actually expect results to be instant or to come after one letter; after months of work with Chrome I've learned what website it will bring up when I type "t" (twitter) "g" (gmail) or u (ux.stackexchange). If I had to wait or type an extra letter it would slow that workflow down. As long as the autocomplete results are not automatically inserted, meaning you have to manually clear them, there's little danger in being a bit overzealous.

However if you have something more than just autocomplete, like Google Instant's search, you might insert a bit of delay to avoid swapping out large areas of the screen (or performing slow/data intensive operations) repeatedly during ordinary searches. Google Instant waits for maybe a few hundred milliseconds before showing "instant" results, and Google Search History only records events where you stopped typing for three seconds. Three seconds is probably overly conservative in most cases, but it's interesting to note that the more "important" events (autocomplete, then display results, then log as history) each take considerably longer. Autocomplete is not as annoying and has little downside, so it displays instantly. Displaying results requires more of a screen refresh and more network traffic, so it's a bit slower. Logging the history is more "permanent" so to avoid clutter/misleading results the timer is quite conservative.

share|improve this answer
    
Ben nailed it. Perhaps this: show results instantly, and have the top 100 (or 1000, whatever number makes the most sense for what you're doing) results cached so it doesn't require a server hit. –  William Newton Mar 12 '13 at 15:52
    
Citations needed? You might be right, but my experience with Firefox search box is that the autocomplete doesn't start showing results until at least a half second after I start typing. Now maybe some of that is latency, but I actually find it more helpful, if I know that I'm trying to type kitten, that the browser doesn't waste time (and my attention) trying to show me ketchup, kitsch, and kites. When I pause is when I'm more likely to want and appreciate autocompletion. That pause might only be 1/2 sec, but it makes a difference, both for UX and for wasted server traffic. –  LarsH Mar 12 '13 at 20:52
    
@LarsH given that the Firefox address bar does autocomplete instantly I think that situation is either latency or more related to my final paragraph; more dangerous/expensive actions taken slower. Firefox autocomplete otherwise totally fires on first character, zero delay. –  Ben Brocka Mar 12 '13 at 21:11
1  
I can see a case for the address bar autocomplete having different delay characteristics than the search box autocomplete. –  LarsH Mar 12 '13 at 21:14
    
Note that the jquery tokeninput plugin has a default delay of 300ms "between the user finishing typing and the search being performed" (loopj.com/jquery-tokeninput) The right answer varies depending on the use case, but I would disagree with the characterization that generally autocomplete is instant; especially when the OP's topic is web-based search terms. –  LarsH Mar 13 '13 at 13:34

I suggest setting a limit of characters.

You need to decide what number of characters is proper in your case. Autocomplete feature should limit the list to a number of selectable results, and if a user is presented a list of, say 100 elements, then it is not usable at all.

For example, if there are 400 items starting from "a", displaying the whole list of 400 items is useless, as user would have to - literally - slash his way through them. If the second letter limits it to about 20, you can think about using this limit.

Of course adjusting it letter by letter is not recommended, except situations, where there would be totally different number of options starting from one letter than starting from another letter - but I believe these situations are rare (e.g., if you have ingredients list, including both ingritients names and E-123 symbols). I think the rational number of the options to show would be up to 10, maybe 15.

Of course you can use another approach and use some statistical information for the items to appear on the list, so that when someone types "a" only some items starting from "a" appear (this is used by Google for example - the algorithm is more complicated, but in general it's like this - as you type in more letters, different suggestions appear). This method, however, can be used for searching through a lot of data which (from its nature) is quite chaotic, and there is no point in organizing it. Whenever users expect the data to be organized, the statistical approach may lead to confusion (e.g. users may expect "Smits" appear together with "Smith" while it is not allowed to be displayed due ot statistical algorithm).

share|improve this answer

As with all design questions, it depends on the context and the domain.

With an autocomplete box, what you're trying to do is distract the user (in a good way) by showing him or her a 'short circuit' to their planned task. If you do this right, the user will find the element they want and quickly complete their submission. If you it wrong, you make the user try and resume their task, whilst they keep looking between text box and search matches until something comes up. This is still better than no autocomplete at all, but it's slightly suboptimal.

The question, then, is 'when can I guess what a user means?'. That depends on your domain - at what point can you start guessing reliably? In certain domains, you may have certain terms appear with disproportionate regularity, so you can be fairly sure than when a user enters the first letter of one of those terms, they're likely to be matched. Similarly, if the user already has a history of searches, you can be fairly sure that they're looking to perform the search again (presuming there's value to repeat searches - again, this depends on your context).

That being said, I have observed user tests with autocompletes that appear immediately, even when they yield suggestions that aren't appropriate, and I haven't seen any major fallout from this. This suggests that all else being equal, err on the side of being faster.

share|improve this answer

In addition to what others have said I'll describe a UI behavior that's often annoying in this context: Sometimes as a person types, the auto-complete keeps changing for almost every typed letter. Re-flashing this way adds something like a flicker that I've seen users report as intensely annoying.

I'm not sure what the right solution is but something to keep in mind. Perhaps a limit on how often you refresh?

share|improve this answer

Just as Ben Brocka said, I would say also instant. To add to this, I would also say if you have ever used Intellisense in Visual Studio or a similar product you notice it is also instant - based on the first character you enter. This is very helpful because as a user I would want to know what is available based on the first character I enter. If by chance I dont know how to "put words" to what I am looking for, searching instantly by the first character is convenient to help me formulate my words.

share|improve this answer
1  
Yes, Intellisense is very useful and works great with instant feedback, however the pool of potential results is much smaller and it's designed in part to speed up typing and improve accuracy so you can 'just get on with it'. It's a slightly different use-case from a standard website Search where you don't really know what it is you're looking for when you start searching, and the list of results could therefore be huge as a result. –  JonW Mar 13 '13 at 9:23

Something I consider very important before finalizing an approach. Who/what is the (biggest) end user group of your application?

It is stupidity, imho, to delay an auto complete by 'time'. I type extremely fast and hate websites which think my typing is slow and popup autocomplete after I have keyed in the term. Then again, I love those specific travel websites, which will popup Birmingham as soon as I type B in the search box.

One other thing to keep in mind is the network latency. Are you going to be dealing with end users at extremely slow internet speeds? I would completely avoid this if this app were for a place which had extremely slow connections.

I made a web app for an automobile assembler and they used a lot of seals in their components. Since the data entry operators were extremely efficient, I had written an algorithm to find real 'words' typed in fields (really simple to do in java) and then auto complete Ex SealABC SealXYZ etc. So IMO this is an ideal way to do. YMMV.

share|improve this answer

Your Answer

 
discard

By posting your answer, you agree to the privacy policy and terms of service.

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