interaction design - Guidelines for autocomplete widgets

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.

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.