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.

What guidelines exist when working with autocomplete widgets? I'm hoping for general guidelines that apply across different application types: web, desktop, and mobile.

A response to a Search as you type thread included the following relevant items:

  • Never update the search input with one of the results unless the user requests it.
  • Provide keyboard and mouse access for selecting results.
  • Look-behind is a nice complement to look-ahead.

I've observed a few other practices:

  • Highlighting the searched-for term
  • Returning the count of matching items
  • Providing an action indicator upon selection (but not activation) of an autocomplete entry
  • Offering the originally typed text in the autocompletion list

In addition, the following questions may be asked when providing suggestions:

  • How many hints/suggestions should be provided?
  • How do you resolve those that should be displayed when many are available?
  • Should suggestions take into account likely spelling or typing errors?

Any responses discussing more complicated syntaxes like boolean expressions would also be helpful.

share|improve this question

3 Answers 3

Implementing a somwwhat generic autocomplete at the moment so some thinking/findings so far.

As I see it there are two types of autocomplete. On that is an actually a hidden dropdown and an other that is a text field. The dropdown autocomplete is used when you want to restrict the inputs but don't want a dropdown with hundreds of items. Used for example when selecting airports to fly from/to. The text field is used more for suggestions when searching.

In the first case I think you want to update the input. Since it has to be an valid input anyways. In this case it's important that it's clear what is your suggestion and what is the user input.

Restrict the number of shown results. The users focus is imputing text into the field. If they have to scan through a long list of options, you could as well use a dropdown. Not having to move ones eye focus and placing less burden on the users memory is probably a good thing as well.

Although I see one useful property of long lists. If I don't remember what I'm searching for. A long list will allow me to go through it and recognize(hopefully) what I'm looking for.

To choose what is shown in the list is probably on of the things that takes the most domain knowledge. Google seems to do it by search popularities, airlines by how big the airport is. T

As for look behind I'm a bit torn. It's easier to remember the first letter of a word than the third. So most of the time this probably what your users are doing. So matching anywhere in the string might give many unwanted results. Power users, who has learnt that 'ac' is faster than 'st' for 'stack' might have use for it. Matching against all words in sentences is probably also a good idea. As then you give more options for recognition.

share|improve this answer

Google does some pretty extreme A/B testing, and auto-complete is a core product.

I think that's about as good as you will get when it comes to proven guidelines.

share|improve this answer

There are no general guidelines that work across all platforms and all applications, take for example Google web search and selecting a person from a list of coworkers - in both cases an auto-complete widget may be appropriate but every detail of the implementation will be different.

The only thing you can do is evaluate the specific needs of every application (not platform, who cares if the form you are filling is in a web browser or a dialog box) and have usability test to see what features you need (users misspell options often -> you need to take spelling error into account).

Let me quote from an old interview with Tim Lister (one of the authors of Peopleware):

Cramblitt: What do you think about the reliance on best practices?

Lister: I get chills when I hear that phrase. From my point of view there are some pretty good practices, but no best practices because that implies generic software development. All projects are related to the domain they’re in. A best practice for defibrillator software is not the best practice in another domain. I’d like people to think about patterns – abstracting their work and recognizing the patterns they’re in, good and bad, and making informed decisions to promote those patterns or replace them.

share|improve this answer
2  
That's a rather semantic response. Perhaps the asker could have worded their question "Patterns for autocomplete widgets"? Would that have elicited a different response? The asker has already identified that there are patterns/practises/guidelines for this domain. He seems to simply want more. –  cottsak Nov 2 '10 at 8:01
    
OP says he wants "general guidelines that apply across different application types: web, desktop, and mobile". I think that point here is that there are no such guidelines. The guidelines you use depend very heavily on the context. –  Bennett McElwee Nov 13 '11 at 10:01

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.