• Rules for Autocomplete
  • Originally written by Jeremy
  • The Nuggets translation Project
  • Permanent link to this article: github.com/xitu/gold-m…
  • Translator: fireairforce
  • Proofread by Fengziyin1234, Endone

Using known values to auto-complete text seems like an easy problem to solve, but many, many interface designs are wrong. I see these mistakes all the time, and instead of complaining about them one by one, I decided to write down some of the rules they often violate.

Maybe some of these rules aren’t the best, but there should be a good reason to break them (for example, if the values you fill in must come from a fixed set, you don’t have to follow some of the rules, such as the list of STATES in the United States). Follow these rules to at least have a good experience:

  • An exact match is always first. If the user accurately enters an option, the other options must always be lower than the one the user entered.

  • In addition to exact matching, the first consideration should be prefix matching. If I type “Fr”, I want “Fresno”, not “San Francisco”.

  • After the prefix match, the string match is performed. Matching from a substring is almost always wrong, because the user starts typing words at the beginning rather than somewhere in the middle.

  • If there is no substring match, you can choose to fall back to a subsequence match. This is only useful in certain situations.

  • If there is no subsequence/substring match, you can choose to fall back to approximate match. This is a rare occurrence.

  • Matches should be sorted in lexicographical order.

  • When one option is a prefix to another, place the shortest option first.

  • Matches should be case insensitive, unless there are two options that are only case sensitive. In this case, select the one that best matches the user’s input.

  • Using the selected action (such as searching for terms) must be different from accepting the first suggestion, unless you have to do something first to start using the autocomplete suggestion (for example, press the down arrow). Users always need to take extra steps to use autocomplete.

  • If there is a current autocomplete option, the TAB key should always accept that option (either highlighted in a drop-down menu or displayed in a line).

  • If the autocomplete option is highlighted, press Enter should always use that option. Even if a portion of the page is not fully loaded, it should never be restored to the default. If something is still loading, it is better to ignore the Enter key rather than select the wrong option.

  • Autocomplete is not activated by keystrokes when a field using autocomplete is not focused.

  • In general, the results should be available within 100 milliseconds.

  • You can pause autocompletion when the user is typing other letters quickly, but don’t display the result in the middle of the string after the user has completed. It’s better to wait longer and change the results once than to show results that look complete but aren’t (I admit this rule is quite subjective).

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

Some optional features make sense for certain types of autocomplete, but not for others. I’m sure there are more correct names for these functions than I’ve given.

  • When I focus on the input field but haven’t entered anything yet, displays the options I used earlier.

  • Auto complete to nearest fuzzy prefix. If I type “G” and match “Google” and “GoodReads,” this action will fill in two “O’s” and then allow me to type “G” or “D” to select the option I want.

  • Multipart matching. This is useful for auto-complete file paths, I can type “e/b/a” to auto-complete “env/bin/activate”. ZSH did a great job.

  • Recursive matching. Since autocomplete is sometimes dual-use as a way to quickly browse options, sometimes you want to start with a broad filter and then search through those results. For example, if I type “.pdf “to view all PDF files, I can press some key (perhaps a comma) to start searching through those results, even though what I type now actually appears in the file name I typed earlier.

  • Spelling correction. This is often useful in search engines.

  • Alias. When you try to auto-complete a user name, you can allow the user name to be auto-complete by the person’s first or last name. The same is true for acronyms for states with full status.

  • Additional information in the results. If you are auto-complete function names, users will be happy if they can see their argument lists.

  • Context-aware suggestions. This is useful when auto-completing a code or word (usually on a mobile phone), where the context can predict what the desired result might be.

  • After accepting the autocomplete suggestion, I can return what I entered. (An up arrow is a better way to do this).

If you find any mistakes in your translation or other areas that need to be improved, you are welcome to the Nuggets Translation Program to revise and PR your translation, and you can also get the corresponding reward points. The permanent link to this article at the beginning of this article is the MarkDown link to this article on GitHub.

The Nuggets Translation Project is a community that translates quality Internet technical articles from English sharing articles on nuggets. The content covers Android, iOS, front-end, back-end, blockchain, products, design, artificial intelligence and other fields. If you want to see more high-quality translation, please continue to pay attention to the Translation plan of Digging Gold, the official Weibo, Zhihu column.