When should you start autocompleting a search in autocomplete search field?

Question

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?

^{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.

Answer 1

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.

Answer 2

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.

Answer 3

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).

Answer 4

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.

Answer 5

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.

Answer 6

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.

Answer 7

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?