Rules for Autocomplete
jeremymikkola.com
Rules for Autocomplete
1–10 of 151 posts
Re: Rules for Autocomplete
#2Agree with some of them, but not all:
> Matches should be sorted alphabetically.
Not always. Sorting is usually a good idea, though.
> When one option is the prefix of another, put the shortest one first.
Except this means that uncommon, short prefixes will always show up first. I guess "San Francisco" isn't going to have a great time :(
Re: Rules for Autocomplete
#3Agree with some of them, but not all: > Matches should be sorted alphabetically. Not always. Sorting is usually a good idea, though. > When one option is the prefix of another, put the shortest one first. Except this means that uncommon, short prefixes will always show up first. I guess "San Francisco" isn't going to have a great time :(
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?
Re: Rules for Autocomplete
#4I was pretty sure I'd see this:
> If an option is highlighted, never change it, even if new data is loaded.
They're quite deliberate in favoring showing new things in response to additional keystrokes over results that have already been displayed and not selected with fewer keystrokes.
This annoys me, but I type faster than I read even when I'm searching. I don't think most people do so it makes sense to not keep showing the same result after more keystrokes.
Plus I think it just looks smarter, and surfaces more results. So if you're using the autocomplete of Spotify, you see more songs than you would if it kept showing the same result.
I think they're trading function and usability for showing the user more stuff, and making the app look more intelligent.
For an example of what I'm talking about, if I type "ha" into spotify, "Happy Now" is the third result. If I type "p" so it's "hap", it becomes the sixth result. Sometimes it pushes it all the way to past the end of the screen.
Re: Rules for Autocomplete
#5Great 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
Re: Rules for Autocomplete
#6This is pretty interesting and useful. Now where are the details about how to get ElasticSearch to behave this way? :)
Re: Rules for Autocomplete
#7here'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.
Re: Rules for Autocomplete
#8Agree with some of them, but not all: > Matches should be sorted alphabetically. Not always. Sorting is usually a good idea, though. > When one option is the prefix of another, put the shortest one first. Except this means that uncommon, short prefixes will always show up first. I guess "San Francisco" isn't going to have a great time :(
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.
Re: Rules for Autocomplete
#9One rule I always consider important:
> If I type the next letter of the top match, it should remain the top match.
I find these types of inductive rules might be a better way to express how autocomplete should work (given a limited universe of suggestions).
Re: Rules for Autocomplete
#10Great 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 o…
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.