Live data from Hacker News

Rules for Autocomplete

jeremymikkola.com

31–40 of 151 posts

Re: Rules for Autocomplete

#31
post #20

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

yeah both Windows search and iOS search swap things around as they load and it's super frustrating

Re: Rules for Autocomplete

#32
post #20

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

Re: Rules for Autocomplete

#33
post #4

I was pretty sure I'd see this: > If an option is highlighted, never change it, even if new data is loaded. They're quite deliberate in favoring showing new things in response to additional keystrokes over results that have already been displayed and not selected with fewer keystrokes. This annoys me, but I type faster than I read even when I'm searching. I don't think most people do so it makes sense to not keep sho…

[deleted]

Re: Rules for Autocomplete

#34
post #20

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

The thing is, it does never really stop: https://i.imgur.com/UVPpYYO.png

Re: Rules for Autocomplete

#36
post #9

One rule I always consider important: > If I type the next letter of the top match, it should remain the top match. I find these types of inductive rules might be a better way to express how autocomplete should work (given a limited universe of suggestions).

This is one of my pet peeves in Visual Studio Code. If you type a language keyword it put it on top of the suggestion list.

So "de" might suggest "defaultdict" but if I add an "f" and auto complete it gives me a function template.

Re: Rules for Autocomplete

#37
Mobile phones are barely mentioned here.

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

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

Re: Rules for Autocomplete

#38
post #10

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

Don't make me backspace twice when I want to type "Github" but it isn't in autocomplete yet.

Re: Rules for Autocomplete

#39
post #10

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

This needs to special case when the next character that would break the ambiguity can also be an o.

Re: Rules for Autocomplete

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

Post reply on HN