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.)
> 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.
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
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...
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 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.
> 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.
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.
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.
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.
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.
> 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.
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.
> 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.
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.
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.
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".
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.
* 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.
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.
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.
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.
* 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.
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.
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.
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).
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?
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)
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.
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.
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.
150 comments
[ 2.3 ms ] story [ 227 ms ] thread> 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.)
> 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.
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.
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.
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.
> 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.
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.
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.
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.
* 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.
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.
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)
https://dan-kwiat.github.io/filter-suggest/
I find "smart case" is a nice solution here. The filtering should only be case-sensitive if the input has an uppercase letter.
Consider using SaaS like Constructor.IO, algolia.com 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
The best autocompletion I've seen is on Wikipedia - no frills, and extremely accurate. If only all services were like this.