- 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.
Unlearning is a great option. I have in Firefox a persistent autocompletion for a URL that I typo'd once, which still shows before the one I've been to a thousand times (because it's first alphabetically, I suppose?)
My biggest gripe with Firefox's history bar is that it's so slow to update that I'll go to click something, and then the whole list scrolls down or up and I now click something entirely different.
Even with search autocomplete disabled it takes forever just to search the history.
MacOS Mail has the worst autocomplete feature I've ever seen when it comes to the "To:" field. When I have to manually type a new e-mail address, it always selects some other e-mail address. I've just tried again: return validates the wrong address, tab does the same, clicking elsewhere does the same... A complete nightmare!
This irritates me as well and my brain now registered that to autocomplete on chrome I need to hit return/enter.
Issue is that on most forms where chrome suggests autocomplete based on what you fill other forms with, return/enter does not autocomplete and usually submits the form or goes to the next field..
Learning typos is terrible with Android autocorrect/swype on a Galaxy S8. Swype with autocorrect actually degraded over time, when I had an S1 it worked beautifully, and nowadays it frustrates me so much I end up typing words letter by letter.
Another annoyance that, while not the fault of autocomplete, still bothers me: I write in either Spanish or English, frequently changing between the two. It's hard to explain, but the UX of swiping right to change the keyboards generates too much friction on my brain when I'm tired (like when commuting back from work), so I end up using the Spanish default even when writing in English. Therefore, poor autocomplete is fast becoming bilingual. So when I want to write Spanish, it suggests me English words and viceversa.
I'm not blaming autocomplete here; it's clearly my usage pattern that's difficult. But at the same time, this is how I use my phone, so there's a problem to be solved here, and it doesn't involve me changing my habits :)
Every time I hit this problem I end up cursing and typing the word letter by letter, instead of changing the keyboard config. There's probably some valuable psychological insight there!
I'm exactly the same! It used to work first time, every time. Now I have to re-do every other word, so I just have to type it out. I know you can make it forget words, but it takes even longer.
This is one that drives me crazy. Esp in the context of trying to be politically correct. No, Apple, I've never wanted to say "Duck" instead of "Fuck."
This is google favoring people who dont really understand the shared search address bar, and want _enter_ to "do something useful" vs returning an invalid page.
however, if i type out the full tld AND a slash, like google.com/ and click enter, DO NOT take me to a subpage unless i started typing another character.
short term workaround is to add periods to the end. google.com. it will strip the trailing period (even though it is more technically correct) and the period entry will get added to autocomplete suggestions.
The first also happens with ivy in Emacs, and makes it harder for me to create a new file from within Emacs in a directory with a different file with a similar name. Very infuriating.
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?
>> 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?
I think the author means "never change it without user input". The problem is that Autocomplete is often slow, so developers load suggestions asynchronously, and may update suggestions shown to the user after better suggestions have been loaded.
If a suggestion was already highlighted at that point, the system should not change it, to avoid the case where the user tries to commit a suggestion, but the system changes it just before the user hits the key to commit the suggestion.
Oh yes, I can relate to that - iOS system search is always pulling the rug on me and making me click random apps / web search results. This can be solved by clearly indicating that new results are loading, or deactivating the current items.
speaking of slow autocomplete - there is one mac app (omnifocus) I use where autocomplete will become busy and beachball after a few characters and it does this every time.
Do not block autocomplete, especially when you're just starting to type. I would be good with having a delay before autocomplete kicks in rather than that.
>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.
I read the list as being ordered by priority. Each of the items above "should be sorted alphabetically" defines a group, and within each group items should be sorted alphabetically.
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.
I agree, Firefox's Awesome Bar is the single best implementation of combining local and web results I have ever used. You can even set local results to appear at the top so the order of items doesn't jump around once the Google results are loaded and populated in the dropdown.
The closest we have now is datalist[1], which acts as a data source that you can attach to a text input to give it autocomplete. Unfortunately, it isn't nearly as fully-featured as it could be, possibly because no one uses it so there's no incentive to make it better (although Chrome's implementation has gotten markedly better over the past two years or so, mostly by fixing blatant bugs).
There are two problems with adding widgets to browsers:
1: Once they are in, you have to support them forever. Or you will break the few websites that use them.
2: Almost nobody uses them. Try 10 popular websites and chances are you will not see a single native dropdown. You might not even see something as simple as a native radio button.
I think it's better to get the basics right instead of building more and more 'userland' type of functionality into the browser itself.
> 2) Almost nobody uses them. Try 10 popular websites and chances are you will not see a single native dropdown.
I'd argue that's because the native widgets haven't changed much since I've started using computers around 1994 (probably longer), and simply aren't up to the modern standards anymore.
If there was a native widget that worked better than any of the current javascript-enhanced widget and could be styled to fit the website around it, lots of people would use it. Maybe not the top 50 web pages in world, but lots of developers with lower budgets would.
that's because the native widgets haven't changed much
So why aren't they updated?
If browser makers can't maintain something as simple as a radio button, they will probably not be able to maintain more complex widgets.
Browser engines are already so complex that even a giant like Microsoft gave up on maintining one. And Firefox is spending over $200m in software development per year to keep up.
>If browser makers can't maintain something as simple as a radio button, they will probably not be able to maintain more complex widgets.
Who said they "can't maintain it"? They just wont, which is different. Besides, it is up to HTMLWG/W3C to expand on those widgets, and they have done nothing...
>Browser engines are already so complex that even a giant like Microsoft gave up on maintining one.
Not because of them having radio buttons and form controls. Those we had since Mosaic... Even Lynx supports those.
It's all the other craziness (from 3D, to MIDI, to sound APIs, to 2-3 layout engines, to crazy CSS features).
It’s not even that they won’t, it’s that the radio button doesn’t do the thing you want it to. The radio button works, perfectly, as much as it ever did. There are no issues, regressions, or any such thing.
It is perfectly maintained as the exact UI element it should be.
> If there was a native widget that worked better than any of the current javascript-enhanced widget and could be styled to fit the website around it, lots of people would use it. Maybe not the top 50 web pages in world, but lots of developers with lower budgets would.
Awareness and training matter a lot here. There is now a usable <details> and <summary> element, but a number of people I know simply use bootstrap's data-toggle or a custom onclick handler because they don't actually know about the existence of these tags nor the gotchas you need to account for. Safari will have <datalist> support in the next major version, but I expect it will be a year or so before libraries begin to use it and developers won't use it until it is well documented and supported by libraries. The HTML spec introduced native attributes for a bunch of form states including valid/invalid state, required state, min/max values and more, but most libraries don't take advantage of them because they built the functionality before it had browser support and so developers don't use them either. We'll see these things gain adoption, but it will take time.
>1: Once they are in, you have to support them forever. Or you will break the few websites that use them.
That's not a problem. We want them supported forever. And basic widgets/controls haven't changed in substance since Xerox park or Win 3.1 anyway, so it's not like we'll discover suddenly that a autocomplete widget is a thing of the past.
>2: Almost nobody uses them. Try 10 popular websites and chances are you will not see a single native dropdown. You might not even see something as simple as a native radio button.
That's because they have been neglected (unlike the rest of the stack), and don't support extensive styling in most browsers.
I agree they are great but isn't most of the work in fetching & sorting the data? I can't see how this would work as a general widget.
In terms of the UI - I made a react component for showing dynamic suggestions (essentially a wrapper for downshift).
And I've found the options out there for the sorting part quite good (e.g. match-sorter for sync or Elasticsearch completion suggester for async)
No mainstream browser sends arbitrary keystrokes back to their server.
If such an autocomplete widget becomes HTML standard it should be done through client-side information only. Knowing chrome though, they'd want to tie it to your "sync" identity which already autocompletes passwords/cc.
I don't understand. Currently the website I'm on and the browser get access to all my keystrokes. The suggestion is to allow an <input> tab to let the browser take over and do its thing for suggesting autocompletes (whatever that is) instead of the website suggesting them. What's the novel security concern?
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
You could type G, "oo" gets appended but selected so right arrow validates the suggestion, and continuing typing overwrites the suggestion and the second "o" is appended again if you type "o".
Then "gle" is appended because it is more frequent but if you type "d" "gle" is replaced by "dread", with " read selected"
I think I have seen this implemented before and when it inserts the extra 'oo' it automatically ignores extra 'o's that might be typed. It allows for users to actually type Google, but also allows users to type 'Ggle' and get the same response.
The article mentions this being on some activation like tab or similar like bash uses. Automatic completion could work with two levels of highlighting. Example with []/{} showing active/suggestive:
"[G]" <- Typed
"[G]{oo}" <- Displayed in input, with Google/GoodReads as options
"[Goo]" <- Tab Pressed
"[GoodReads"] <- R Pressed
"[Google"] <- g pressed
"[Gx]" <- Any other character x
Then things like Chrome's url bar will fill in the complete first suggestion with a way to clear it which gives UX like:
I think this type of Autocomplete only works on fixed lists. You're right, it would be completely annoying if it were a free text field with autocomplete suggestions...
I think this suggestion comes from what Unix shells do, albeit I'd say that auto-complete there works rather different from how it usually works in GUI applications, browsers, and web applications. It's a model that's useful for some (I personally can't stand it exactly because it amends the input in unpredictable ways, but others get annoyed when a shell doesn't provide it like they're used to), but unless talking on HN it's probably a minority of users that like and prefer it.
Mac Spotlight Search doesn't follow this rule and it's sooooo annoying. I have Firefox and Firefox Developer Edition both installed and the top search suggestion seems to randomly switch back and forth between the two depending on how many letters of "firefox" I type.
Trying to switch to 1Password is somehow even more irritating. Typing "1p" reasonably suggests 1Password. If I continue typing "1pa", however, I'm given the hilariously unrelated knowledge that 1 Pascal is equal to 0.0075 Torrs. Pressing return then takes me a Google search (in Safari, which isn't even my default browser) for "1pa" which gives me yet another pressure unit conversion, 1 Pa = 1e-5 bar.
The Windows 10 start menu does the same thing. As I type "Visual Studio", the selection changes seemingly at random between Visual Studio, VSCode and the Visual Studio Installer. Infuriatingly, it seems to prefer the installer, which is never the one I want and AFAIK it's not possible to remove an item from the search results without uninstalling the application completely.
Matches should monotonically disappear and not get reordered as you enter more letters.
This is trivial to do on exact contexts (like start menus - why none gets this?). It's ok to wait until the user enters some letters to start showing options, it's also ok to limit the number of results as long as you say there are more somewhere. What is not ok is to show a single match, and then after the user press another key show two matches, with the first one gone.
Distance based matching can't strictly follow this rule, but if you are optimizing one, it is a good goal to get approximately right.
You're right in that this example violates, "When one option is the prefix of another, put the shortest one first." But a personal peeve of mine is Apple Spotlight. When I type d-a-s it autocompletes to dash.app, as soon as I type d-a-s-h it autocompletes to dashboard.app. Since it's built-in I felt limited in what I could do about it. Thanks to this post I looked up how to suppress it from Spotlight since I dont use Dashboard.
I'll check it out again. I only use the most basic functionality of launching apps (I stretched out and started using the calculator a few months ago!). Years ago I looked at what was out there and used Quicksilver, but as soon as Spotlight started working for launching apps I stopped looking for anything else.
I can't imagine anything faster than Spotlight other than the few times where it's reindexing.
Even then its hard to even define the next letter. With sub-sequence matching something like "gsl" might be displayed as "[g]et[D]isplay[L]ist" with items in brackets highlighted. No real next letter in this case.
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.
> 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.
Spotlight in macOS is terrible when it comes to this sort of thing, and it's been that way forever. I can't count how many times I've tried to launch an app with Spotlight only to realize that macOS has conveniently replaced the highlighted top hit (that I wanted) with something else between the time my brain said "go" and my pinky hit "return".
Ctrl-, (or Ctrl-T) in Visual Studio (...not VS Code) drives me nuts in this regard. It takes about 2-4 seconds before you can safely select an option without fearing it will be taken away by sleight of hand.
I'm experiencing this daily with Google search results where they keep adding that box around a link you clicked last when you click back in the browser. You press back to return to search results to click the next link in the list and it jumps all the results down and you end up miss-clicking. Infuriating.
On Gboard every time I try to type the word "don't" I type d-o, see the suggestion in the middle, and start reaching for it while I press the "n"... only to have it type Don, the proper name of nobody in my contacts.
> 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.
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.
This should only happen for user requested auto-completion. For example typing "g" <tab> "g" <tab> would result in Google in the provided example.
This is very beneficial in code completion or navigating file directories. It is horrible when typing an email (though maybe when searching email contact). Definitely needs to be context aware.
"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.
> 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.
To be fair, the introduction says that these guidelines shoukd be changed on a case by case basis if common sense dictates that. The ruleset as described is generic - and also slightly opinionated.
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
sitemaps easily run into the gigabytes for larger sites. I just checked https://www.nytimes.com/sitemaps/www.nytimes.com/sitemap.xml... and it contains 2000 urls of individual weekly sitemaps of 1 or 2MB each. And that's just part of their sitemap structure.
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.
What's frustrating with San Francisco is when you're in the US, type it in, and see San Francisco, Agusan del Sur; San Francisco, Cebu; San Francisco, Quezon; etc. pop up before the one in California... like what are the chances that you're in the US and referring to those instead of the one that's actually in the US?
Matches should be sorted by a weighted score that takes both geographical distance, prioritizing San Jose over San Jose appropriately rather than blindly sorting them adjacent.
Exactly, some rules are meant to be broken. If the user is believed to be in northern California and types 'San ', then "San Francisco" should probably be higher up the list than "San Diego" despite that not being alphabetical order.
Determining whether or not the autocompletion should work like this is a matter of common sense applied by the developer, there is no hard and fast rule. In some hypothetical circumstances it may make more sense to sort by population size, rather than geographic proximity (let alone alphabetically.)
* 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.
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 conspiracytheorist in me thinks Chrome's address bar is intenionally crippled to make you do a Google search instead. It's so so different from how well it works in Firefox.
It also breaks the rule in the article about not selecting the suggestion for you. When I start typing in Chrome it fills my whole bar with a suggested url that matches. I end up pressing esc to remove the last highlighted/completed part, but that ends up clearing the whole field. I do this multiple times a day, drives me nuts.
I do use Firefox as my private browser, but at work I switch between multiple browsers and various test environments. So I have lots of almost identical urls where Chrome completes something I don't want to be completed, or pretends it doesn't understand what I'm looking for.
> 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.
> Now where are the details about how to get ElasticSearch to behave this way?
The rules posted in the article make a lot of sense, but they also require a ton of backend work. To do prefix matches quickly, you need to create a new index of your content. Then to handle the relevance rules described, you need to be able to query both indices and merge the results in a meaningful way. No obvious way to do this with ES.
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.
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:
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.
Disable the "Editor: Accept Suggestion on Enter" option. There's also a setting "on Commit Character" which would approve the suggestion on semicolon (javascript).
Took me a while to find them, but life is so much nicer without needing to manually correct stuff.
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).
Whoopsie. Caught cold turkey I admit. But for what it’s worth, for text editor and text message spelling autocorrect, auto detect would be nice, even if off-topic.
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.
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.
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.
- 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.
Even with search autocomplete disabled it takes forever just to search the history.
The second is very annoying and has even caused me to abandon the tool / software.
This irritates me as well and my brain now registered that to autocomplete on chrome I need to hit return/enter.
Issue is that on most forms where chrome suggests autocomplete based on what you fill other forms with, return/enter does not autocomplete and usually submits the form or goes to the next field..
They actually made the app worse. Progress?
Another annoyance that, while not the fault of autocomplete, still bothers me: I write in either Spanish or English, frequently changing between the two. It's hard to explain, but the UX of swiping right to change the keyboards generates too much friction on my brain when I'm tired (like when commuting back from work), so I end up using the Spanish default even when writing in English. Therefore, poor autocomplete is fast becoming bilingual. So when I want to write Spanish, it suggests me English words and viceversa.
I'm not blaming autocomplete here; it's clearly my usage pattern that's difficult. But at the same time, this is how I use my phone, so there's a problem to be solved here, and it doesn't involve me changing my habits :)
Every time I hit this problem I end up cursing and typing the word letter by letter, instead of changing the keyboard config. There's probably some valuable psychological insight there!
This is one that drives me crazy. Esp in the context of trying to be politically correct. No, Apple, I've never wanted to say "Duck" instead of "Fuck."
however, if i type out the full tld AND a slash, like google.com/ and click enter, DO NOT take me to a subpage unless i started typing another character.
short term workaround is to add periods to the end. google.com. it will strip the trailing period (even though it is more technically correct) and the period entry will get added to autocomplete suggestions.
> 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?
>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?
I think the author means "never change it without user input". The problem is that Autocomplete is often slow, so developers load suggestions asynchronously, and may update suggestions shown to the user after better suggestions have been loaded.
If a suggestion was already highlighted at that point, the system should not change it, to avoid the case where the user tries to commit a suggestion, but the system changes it just before the user hits the key to commit the suggestion.
Edit: and I have disabled both frequently visited pages and search there, but it still manages to reorder things after a couple seconds
Do not block autocomplete, especially when you're just starting to type. I would be good with having a delay before autocomplete kicks in rather than that.
I read the list as being ordered by priority. Each of the items above "should be sorted alphabetically" defines a group, and within each group items should be sorted alphabetically.
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.
[1] https://developer.mozilla.org/en-US/docs/Web/HTML/Element/da...
1: Once they are in, you have to support them forever. Or you will break the few websites that use them.
2: Almost nobody uses them. Try 10 popular websites and chances are you will not see a single native dropdown. You might not even see something as simple as a native radio button.
I think it's better to get the basics right instead of building more and more 'userland' type of functionality into the browser itself.
I'd argue that's because the native widgets haven't changed much since I've started using computers around 1994 (probably longer), and simply aren't up to the modern standards anymore.
If there was a native widget that worked better than any of the current javascript-enhanced widget and could be styled to fit the website around it, lots of people would use it. Maybe not the top 50 web pages in world, but lots of developers with lower budgets would.
If browser makers can't maintain something as simple as a radio button, they will probably not be able to maintain more complex widgets.
Browser engines are already so complex that even a giant like Microsoft gave up on maintining one. And Firefox is spending over $200m in software development per year to keep up.
Who said they "can't maintain it"? They just wont, which is different. Besides, it is up to HTMLWG/W3C to expand on those widgets, and they have done nothing...
>Browser engines are already so complex that even a giant like Microsoft gave up on maintining one.
Not because of them having radio buttons and form controls. Those we had since Mosaic... Even Lynx supports those.
It's all the other craziness (from 3D, to MIDI, to sound APIs, to 2-3 layout engines, to crazy CSS features).
It is perfectly maintained as the exact UI element it should be.
Awareness and training matter a lot here. There is now a usable <details> and <summary> element, but a number of people I know simply use bootstrap's data-toggle or a custom onclick handler because they don't actually know about the existence of these tags nor the gotchas you need to account for. Safari will have <datalist> support in the next major version, but I expect it will be a year or so before libraries begin to use it and developers won't use it until it is well documented and supported by libraries. The HTML spec introduced native attributes for a bunch of form states including valid/invalid state, required state, min/max values and more, but most libraries don't take advantage of them because they built the functionality before it had browser support and so developers don't use them either. We'll see these things gain adoption, but it will take time.
That's not a problem. We want them supported forever. And basic widgets/controls haven't changed in substance since Xerox park or Win 3.1 anyway, so it's not like we'll discover suddenly that a autocomplete widget is a thing of the past.
>2: Almost nobody uses them. Try 10 popular websites and chances are you will not see a single native dropdown. You might not even see something as simple as a native radio button.
That's because they have been neglected (unlike the rest of the stack), and don't support extensive styling in most browsers.
In terms of the UI - I made a react component for showing dynamic suggestions (essentially a wrapper for downshift). And I've found the options out there for the sorting part quite good (e.g. match-sorter for sync or Elasticsearch completion suggester for async)
https://dan-kwiat.github.io/filter-suggest/
If such an autocomplete widget becomes HTML standard it should be done through client-side information only. Knowing chrome though, they'd want to tie it to your "sync" identity which already autocompletes passwords/cc.
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
Firefox does that in the address bar.
> 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).
Trying to switch to 1Password is somehow even more irritating. Typing "1p" reasonably suggests 1Password. If I continue typing "1pa", however, I'm given the hilariously unrelated knowledge that 1 Pascal is equal to 0.0075 Torrs. Pressing return then takes me a Google search (in Safari, which isn't even my default browser) for "1pa" which gives me yet another pressure unit conversion, 1 Pa = 1e-5 bar.
So "de" might suggest "defaultdict" but if I add an "f" and auto complete it gives me a function template.
This is trivial to do on exact contexts (like start menus - why none gets this?). It's ok to wait until the user enters some letters to start showing options, it's also ok to limit the number of results as long as you say there are more somewhere. What is not ok is to show a single match, and then after the user press another key show two matches, with the first one gone.
Distance based matching can't strictly follow this rule, but if you are optimizing one, it is a good goal to get approximately right.
How would this not always be the case anyway given the other rules in place?
I can't imagine anything faster than Spotlight other than the few times where it's reindexing.
Even then its hard to even define the next letter. With sub-sequence matching something like "gsl" might be displayed as "[g]et[D]isplay[L]ist" with items in brackets highlighted. No real next letter in this case.
> 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...
It turns out that people in London, England have to type 2 more letters, a task that I am sure is not beyond them.
Together with all the other millions of people that write London around the world.
According to google trends London is searched about 20-30 times more often than Lon.
Sorting Lon before London (in absence of more information) seems a bad choice.
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.
Edit: my solution has been to rename apps, thereby fixing Spotlight. Every update breaks this though.
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.
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.
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.
This is very beneficial in code completion or navigating file directories. It is horrible when typing an email (though maybe when searching email contact). Definitely needs to be context aware.
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.
> 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.
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.
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
It is hard to learn predictive input when you cannot know if the predicted end result was actually what the user wanted.
I find "smart case" is a nice solution here. The filtering should only be case-sensitive if the input has an uppercase letter.
> 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 :(
Determining whether or not the autocompletion should work like this is a matter of common sense applied by the developer, there is no hard and fast rule. In some hypothetical circumstances it may make more sense to sort by population size, rather than geographic proximity (let alone alphabetically.)
* 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.
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.
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!
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.
It also breaks the rule in the article about not selecting the suggestion for you. When I start typing in Chrome it fills my whole bar with a suggested url that matches. I end up pressing esc to remove the last highlighted/completed part, but that ends up clearing the whole field. I do this multiple times a day, drives me nuts.
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?
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).
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.
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.
The rules posted in the article make a lot of sense, but they also require a ton of backend work. To do prefix matches quickly, you need to create a new index of your content. Then to handle the relevance rules described, you need to be able to query both indices and merge the results in a meaningful way. No obvious way to do this with ES.
The best autocompletion I've seen is on Wikipedia - no frills, and extremely accurate. If only all services were like this.
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.
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:
You will actually get some nonsense like this: Very frustrating.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.
> Matches should be sorted alphabetically.
But pay attention to other languages / alphabets. From 2009:
https://alistapart.com/article/accent-folding-for-auto-compl...
Took me a while to find them, but life is so much nicer without needing to manually correct stuff.
I’m not sure if they fixed this in newer versions but jeez is that bad UX
https://news.ycombinator.com/item?id=19432965
Consider using SaaS like Constructor.IO, algolia.com etc.