Here's two autocomplete mistakes that really irritate me:

- Autocomplete on enter: Chrome does this, if I type in https://example.com (enter), it makes the mistake of autocompleting to https://example.com/some_page_I_visited_yesterday

- Arguing: Some applications that I use have autocomplete spell checkers that continue to aggressively try to "correct" technical terms, uncommon names, or company jargon that's not known. (For example, I'll cancel an autocomplete, then go back and add some punctuation, and it'll just "fix" the word again.)

- Autocomplete when the text field looses focus is a form of arguing.

- Learning typos, or incorrect learning: Libre Office started doing this. It learned some names, then it somehow learned a missed space after a common word and started continually trying to autocomplete "Electricvehicle" every time I put a space after the word "electric."

One thing that will help, in certain contexts, is the ability to unlearn or disable suggestions that frequently are canceled.

A few good guidelines, but the author states this as generic autocomplete 'rules', and I feel a lot of bias and assumptions coming from programming and terminal contexts.

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

Supporting proximity matches is critical for anything dealing with city names, landmarks, events, person or commercial names, etc, where typos and mixed language input are a normal occurrence. This applies to almost every e-commerce site out there.

> Matches should be sorted alphabetically

This is countered by a few other of his own rules, such as 'prefix matches come first', 'exact matches come first'. Again, in some applications the best behaviour might be sorting by distance, recent use, relevance, popularity, ratings. Sorting is entirely domain-specific.

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

I don't get this one. If I have the second item selected, and search for a completely new term, should the item remain wedged in the new results at the same position?

So, here is the thing. Modern browsers (at least Firefox and Chromium, haven't tried the others in a while) have AWESOME autocomplete widgets for their URL bars.

They incorporate multiple data sources (URLs and page titles from history, bookmarks, the search engine's keyword autocompletion, probably more), build statistical models (when I start typing "y" I want to go to Youtube 95% of the time, so suggest that first), don't clobber my paste buffer even though they pre-select some text, and so on. Awesome all around.

Could we PLEASE get this exact same widget with pluggable data sources available as a HTML <input> element or similar?

Every time I build a web app, I feel that the user experience could be so much better if I had such an awesome autocomplete widget available. None of the javascript implementations come even close.

Great list. Easy to follow. I will be using this next time i write an auto complete

My only objection would be

> Autocompletion to the nearest ambiguous prefix. If I type “g” and that matches both “Google” and “GoodReads”, this operation would fill in the two “o”s, allowing me to then type either “g” or “d” to select the option I want.

Dont change the input as i am typing otherwise you qill get 4 o's. Show it as an option and allow me to choose the help with right arrow or something

One rule I always consider important:

> If I type the next letter of the top match, it should remain the top match.

I find these types of inductive rules might be a better way to express how autocomplete should work (given a limited universe of suggestions).

It's important to note that this set of rules is for use with a small (<10000), known, possibly hand crafted set of results.

> Exact matches always come first.

One place this very first rule doesn't work is autocomplete for geocoding.

If you are typing "London":

- There is a village called Lon, Pakistan [1]

- There is also a village called Lond, Pakistan [2]

- There are numerous places called Londo all over the world [3]

So its necessary to determine that some places are more likely to be typed than others (population is a commonly available number that can help, but doesn't always work), or autocomplete becomes useless.

[1]https://spelunker.whosonfirst.org/id/1209616309/

[2]http://www.geonames.org/1370290/lond.html

[3]http://www.geonames.org/advanced-search.html?q=londo&country...

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

I'd change this to "never change the positions of already visible elements when the person is not typing". Typing something, then trying to click/tap on a result that disappears and gets replaced by something else is infuriating.

> Besides exact matches, prefix matches come first.

Google Maps used to do this, and when I entered "9831 Main St, Funky Town" once and a day later I would not remember the street number. Entering "Main" would not give me what I wanted.

Google Maps does what I want now AFAICT and entering "Main" will return "9831 Main St, Funky Town" first.

> Matches should be sorted alphabetically

This should only be done in lieu of information about frequencies. If I type "repub" into Google, "republic of korea" appears before "republic of ireland" because it's more popular with users in my demographic (and we know that they are not simply doing reverse alphabetization because "republic of gamers" appears after both).

Sorting should happen in this order:

- whether it's a prefix

- empirical frequency

- the number of tokens in suggestion

- alphabetization

With that said, achieving all of this at the same time is pretty difficult - especially within the prescribed sub-100ms response time.

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

I completely disagree with this. Fuzzy matching is extremely powerful. People routinely get things wrong, particularly on mobile devices, and you don't want the suggestions to disappear the second I make a mistake.

> Autocompletion to the nearest ambiguous prefix. If I type “g” and that matches both “Google” and “GoodReads”, this operation would fill in the two “o”s, allowing me to then type either “g” or “d” to select the option I want

This is terrible, unless I misunderstood. It would mean that if I typed "Google" without looking at autocompletions, I would end up with "Goooogle".

I keep fighting the in-browser auto-completion boxes which try to be too smart and annoy me to no end. Whatever auto-completion you provide, your first priority should be "do no harm": if the user typed something that should be considered as Holy Scripture.

"The user should never have to take extra steps to not use autocomplete"

Failure to follow this rule is possibly the most egregious of sins one may commit, and is unfortunately very common. You have to wonder if people doing this ever even test it themselves.

I was pretty sure I'd see this:

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

They're quite deliberate in favoring showing new things in response to additional keystrokes over results that have already been displayed and not selected with fewer keystrokes.

This annoys me, but I type faster than I read even when I'm searching. I don't think most people do so it makes sense to not keep showing the same result after more keystrokes.

Plus I think it just looks smarter, and surfaces more results. So if you're using the autocomplete of Spotify, you see more songs than you would if it kept showing the same result.

I think they're trading function and usability for showing the user more stuff, and making the app look more intelligent.

For an example of what I'm talking about, if I type "ha" into spotify, "Happy Now" is the third result. If I type "p" so it's "hap", it becomes the sixth result. Sometimes it pushes it all the way to past the end of the screen.

Agree with a lot of these, particularly the ones that prevent misclicks (changing the data "underneath you" when you have something else selected, or "enter" doing something unexpected).

However, strongly disagree with the sorting and preference guidelines. In general the autocomplete should match the intention of what the user is trying to accomplish which is going to vary widely depending on context. Sometimes that's the shortest lexical thing, sometimes geo matters, sometimes recency of usage matters, etc.

I would love autocomplete in URLs I haven’t visited before. Eg my browser should be able to query foo.com for all its available urls and let me search / filter through them via autocomplete.

So I could type

foo.com/sig

And I see/tab through the route for foo.com/sign-in or signup or whatever the server has available.

We’d need an agreed endpoint for browsers to query (.well-known/routes?) and some implementations to automatically / easily generate the routes, but it doesn’t seem unfeasible

An anecdote on MacOS Spotlight and learning algorithms: I never started Chrome browser with it, because it was already running and never shut down. Then I (once!) started the chess game with Spotlight. Fast forward half a year, and Firefox had became my preferred browser. Chrome was no longer running always. However, Every Single Time I now try to start Chrome using Spotlight this happens: Type 'C', press enter and Chess starts up. Shut down Chess, carefully type 'Ch' and wait for Chrome to appear on the list.

It is hard to learn predictive input when you cannot know if the predicted end result was actually what the user wanted.

* If the user types a word that is both a common dictionary word and part of the name listed in a contact, do not auto-capitalize it. You are not helping when you auto-capitalize this.

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.

I find "smart case" is a nice solution here. The filtering should only be case-sensitive if the input has an uppercase letter.

Particularly twitter is a huge sinner in regards to autocomplete. When searching, autocomplete for profiles comes much faster than the autocomplete for search terms. Often bad timing makes me hover a profile and then right when I click the search terms autocomplete finishes and changes the data underneath me.

Agree with some of them, but not all:

> Matches should be sorted alphabetically.

Not always. Sorting is usually a good idea, though.

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

Except this means that uncommon, short prefixes will always show up first. I guess "San Francisco" isn't going to have a great time :(

Great list. I would add:

* Don’t automatically add the suggestion as selected text in the search box. Because pressing delete will delete (only) the auto-completed text, not the last character you typed (which is what you’d expect if you’re typing fast). The Chrome URL bar is an offender here.

Mobile phones are barely mentioned here.

On a physical keyboard you can be confident that key presses were intended, that assumption doesn't really hold on a phone.

If I type 'thr', 'the' is a possibly legitimate word that should be getting suggested at some point.

When the results change, they ability to use things that took over a position should be disabled for 100ms.

The biggest autocomplete annoyance I find in some implementations is that they spring into action the moment you type a single character, and then do so much processing (in apparently the same thread) that they horribly slow down the entry of subsequent characters! You make mistakes due to the lag, and the whole experience is just shit. The run prompt in Microsoft Windows is like this.

Like, hold your horses for three or four seconds so I can type more, then you have less to search for. Prioritize my typing response time over the background search, damn it!

(Really, explicit auto-complete is best, like in command lines ("Tab completion")).

The second biggest gripe is autocomplete choices that dispatch the command. Sometimes you see an autocomplete item that is close to what you want, except for a small edit or addition. Nope, you can't just have that completion in your edit buffer for further refinement: that item is actually just an item in a dynamically constructed pop-up menu, bound to do the dispatch action.

Third gripe: caching invalid entries, such as misspellings, and offering them in future auto-completions! Browsers do this: you misspelled a domain name three weeks ago, so the resulting URL couldn't possibly load, but now it's still coming up as a completion item!

here's my pet peeve: its the omnibox in google chrome. it only chooses prefix-lengthening matches

if I am on guardian.co.uk/au I can find sub-spaces under this.

I also visit guardian.co.uk/uk but I cannot be told about it by google omnibox rules. But, URL forms are syntactically bound, the /... is well understood to identify a base-URL and sister URLs. The stringmatch logic should show me at least some of my sisters alongside the longer-prefixes under the au... sequence.

> The tab key should always accept the current autocomplete option

I was with them right until here. Tab is a well-known button that has one function: going to the next selectable element. Not do something funky with your autocomplete list. If I want to tab to the "go" button that is after the autocomplete list, then I expect tab to take me there. How else would I do it? I'm not visually impaired, but I hate having to move over to the mouse to leave your input field (feels like Flash Player all over again).

Of course, if I selected an item and then press tab, then the value of the suggestion should be used together with sending my focus on its way.

An earlier item should solve this, so you don't need to use tab to use the suggestion:

> The action to make use of [your input] must be a different key than the action to [make use of the autocomplete]

(If I understood that correctly in the first place, the sentence is a little convoluted.) But to hijack a perfectly useful button? That's a no-go. I'm not even sure what other keys you could use: space should usually be a space, enter would go using your input (unless you selected a suggestion with the down arrow maybe), so what's left that does not have an alternate function, caps lock? Sysrq? Or something like shift+enter?

One thing that is also annoying is that some autocomplete list implmenetations will select an option on mouseover even if mouse didn't move.

So if you place a cursor somewhere below the input, when you type, the list will open with non-first item selected, which breaks the muscle memory in a very annoying way (i know that after typing a few letter what the first item will be, so I confirm selection by habbit immediately).

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

Someone please let Slack know. I type "@dustin" and see one of five Dustins, the one I want is highlighted, so I press tab and it selects the next Dustin and usually I press "tab enter" to then submit my comment and now I've pinged the wrong person.

> The user should never have to take extra steps to not use autocomplete

This! I hate it when I type a word, hit enter, and the widget search for a totally different search term that happens to begin with that word as its prefix. Firefox and Chrome, I'm looking at you.

And no, "press Backspace to search for what you actually typed" is not a good solution.

This is pretty interesting and useful. Now where are the details about how to get ElasticSearch to behave this way? :)

Goodreads is the most flagrant violator of most, if not all, of these rules. Searching for a book, author or a user is a PITA, and has been that way for a long, long time.

The best autocompletion I've seen is on Wikipedia - no frills, and extremely accurate. If only all services were like this.

In case you're looking for some JS autocomplete libraries you can inspect the kind of results they give on https://fiatjaf.github.io/search-comparison/

Autocomplete is really frustrating on my phone.

Spelling. It should use key distance. Typing "hrapg" should suggest "graph."

Grammar. The tense of the verb is never suggested correctly. Just previous, as I typed suggested, it gave me suggest until I got passed the whole word.

Responsiveness. If I type "early," I start with "ea" and I notice "early" as a suggestion. I type "r" as I reach up with my other thumb to select "early," but before I can even stop myself, "ear" now suggests "" (the ear emoji) and I inadvertently click it.

Editing. If I deleted a word at the beginning of a sentence, the new word is needing to be capitalized. I click the word, and that suggestion doesn't appear.

My pet peeve - the Safari URL bar that will start autocompleting based on page title, but won't let you edit the URL it completes to without visiting said URL. (It only lets you edit the title it's matching)

> The user should never have to take extra steps to not use autocomplete.

This is so annoying in VSCode. Often it has a really dumb autocompleter (if the language is hard to autocomplete for - Rust or Python for example), so there are always autocomplete options no matter what you type.

Also, pressing enter is the way you pick an option. Which means if you are typing something quickly followed by a newline like this:

  // This is a comment.[press enter]

  // This is a comment.operator+=()

I have written several autocompleters, both for desktop- and web-apps. Put in a good amount of thought and coding, and I do believe they worked reasonably well, and would have scored alright on this list.

One thing, though: Context. Expectations will vary, depending on who is using the particular input field and for what. Searching a customer base? Match first on names, then further down on addresses, emails and whatnot. Or whatever.

> 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.

But pay attention to other languages / alphabets. From 2009:

https://alistapart.com/article/accent-folding-for-auto-compl...

I just want VSCode to stop "fixing" "import numpy as np" to "import numpy as numpy" when I press enter.

Kibana 5 has (had?) one of the more annoying autocompletes I’ve seen, where when you press enter it searches for the first autocomplete result instead of what you actually typed in. Makes it so I always need to use the mouse to press the seach button.

I’m not sure if they fixed this in newer versions but jeez is that bad UX

Please add to the list: Auto detect language! It’s super frustrating when you try to write to your German friend and autocorrect just keeps mutilating perfectly good German words into gibberish (e.g. it’s trying to autocorrect to English etc. default language).

Interestingly enough, some of us were debating this elsethread

https://news.ycombinator.com/item?id=19432965

Do databases like MySQL/PostgreSQL support searching the reverse index? I was looking for a solution but haven't really found one to show autocomplete results.

undefined

One thing I didn't see here that's a big pet peeve of mine, if you're typing and the first option changes despite the first matching prefix not changing.

undefined

Desktop Safari breaks a number of these, most notably and annoyingly:

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

For most of businesses it's too pricy to write a good one. Also it's too pricy to have a bad one.

Consider using SaaS like Constructor.IO, algolia.com etc.

I've always thought that Markov chains would work well for autocomplete, or is that how most autocomplete engines are implemented already?

undefined

Twitter has some really bad autocomplete UI where invariably I am tapping something and a new result gets tapped instead.

undefined

Any good JS libraries that conform to suggestions noted?

These are almost completely wrong. The goal of AC is to get to “what I meant to type” and good AC systems are designed with priors (eg frequency), common spelling mistakes, etc in mind.

what if I want to search for something with a comma in it?