Rules for Autocomplete

Posted on March 19, 2019

Autocompleting text with known values seems like an easy problem to solve, but so so so many UIs get it wrong. I see this frequently enough that, rather than complain about them individually, I though I’d just write down the set of rules they often break.

There may be cases where some of these rules aren’t the best thing to do, but there should be a good reason for breaking one of these rules (for example, some of these rules don’t apply if a field must be filled with a value from a fixed set, like the list of US states). Following these rules should always result in at very least a sane experience:

Exact matches always come first. If the user types in an option exactly, other options must always go below the one matching what they typed.

Besides exact matches, prefix matches come first. If I type “Fr” I want “Fresno” not “San Francisco.”

After prefix matches, it can fall back to substring matches. Starting with substring matches would almost always be the wrong thing to do since users start typing words at the beginning not somewhere in the middle.

If there are no substring matches, it can optionally fall back to subsequence matching. This is only useful in some cases.

If there are no subsequence/substring matches, it can optionally fall back to approximate matches. This is rarely necessary to provide.

Matches should be sorted alphabetically.

When one option is the prefix of another, put the shortest one first.

The matching should probably be case insensitive unless there are two options that differ only by case. In that case (pun intended), prefer the one that more closely matches the user’s input.

The action to make use of the selection (e.g. to search the term) must be a different key than the action to accept the first suggestion unless you have to do something first to start using autocomplete suggestions (e.g. hit the down arrow). The user should never have to take extra steps to not use autocomplete.

The tab key should always accept the current autocomplete option, if there is one (whether it is highlighted in a dropdown or suggested inline).

If an autocomplete selection is highlighted, pressing enter should always make use of that selection. It should never revert to a default selection, even if part of the page is loading. If something is still loading, it is better to ignore the enter press than to navigate to the wrong destination.

Autocomplete should almost never activate on keypresses when the field using autocomplete is not focused.

The results should come in <100ms in the common case.

It’s OK to pause autocompleting when the user is rapidly typing additional letters, but don’t show results from the middle of that burst of letters after the user has finished typing. It’s better to wait longer and change the results once than to show results that appear finished but aren’t. (I admit that this rule is quite subjective.)

If an option is highlighted, never change it, even if new data is loaded.

There are some optional features that make sense in certain kinds of autocompletion and not others. I’m sure there are more correct names for these features than what I listed.