[feat] pfe-autocomplete UX guidance

[mwcz]

I saw this list of rules for good autocomplete behavior on the TLDR newsletter and I think we should review them. They're pretty thorough.

Rules for Autocomplete

For each rule, decide if we agree with it, and if so, check if pfe-autocomplete follows it. If it does, great! If not, fix.

[castastrophe]

• [ ] 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.

Optional features:

• [ ] Spelling correction. This tends to be useful in search engines.
• [ ] Context-aware suggestions. This is useful when autocompleting code or a word (usually on a mobile phone) where the context is very predictive of what the desired result is likely to be.
• [ ] Make it possible to go back to what I’ve typed after accepting an autocomplete suggestion. (The up arrow key tends to be a nice way to allow this.)

[bennypowers]

Can we loop design in on this one @coreyvickery ?

[coreyvickery]

@markcaron Something we should prioritize?