Rules for Autocomplete
jeremymikkola.com
jeremymikkola.com
- 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.
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.
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."
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..
The second is very annoying and has even caused me to abandon the tool / software.
> 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: 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.
that's because the native widgets haven't changed much
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.
[1] https://developer.mozilla.org/en-US/docs/Web/HTML/Element/da...
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.
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)
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
"[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
"[G]" <- Typed
"[G]{oogle}" <- Displayed
"[G]" <- Backspace pressedFirefox 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).
How would this not always be the case anyway given the other rules in place?
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.
I can't imagine anything faster than Spotlight other than the few times where it's reindexing.
So "de" might suggest "defaultdict" but if I add an "f" and auto complete it gives me a function template.
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.
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.
> 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:
// This is a comment.[press enter]
// This is a comment.operator+=()
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
"When one option is the prefix of another, put the shortest one first."Consider using SaaS like Constructor.IO, algolia.com etc.