Hacker News Board Hacker News, browsed like a classic message board
Live data from Hacker News

Rules for Autocomplete

jeremymikkola.com

Post reply on HN
Print view View original

71–80 of 151 posts

Re: Rules for Autocomplete

#71

Post by alexcroox »

yoz-y wrote: 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.

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.

Re: Rules for Autocomplete

#72

Post by interfixus »

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.

Re: Rules for Autocomplete

#73

Post by k_ »

jakobegger wrote: post #67
ricardobeat wrote: post #64

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 comm…

>> 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 sug…

Yeah. I get that all the time with vivaldi address bar and it's driving me insane =/

Edit: and I have disabled both frequently visited pages and search there, but it still manages to reorder things after a couple seconds

Re: Rules for Autocomplete

#74

Post by TuringTest »

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

Re: Rules for Autocomplete

#75

Post by maaaats »

isatty wrote: post #56
maaaats wrote: post #29

Earlier quoted context omitted.

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…

Alright - use Firefox! It's a great browser and one that doesn't treat you as the product.

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.

Re: Rules for Autocomplete

#78

Post by thedufer »

perlgeek wrote: post #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…

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

[1] https://developer.mozilla.org/en-US/docs/Web/HTML/Element/da...

Re: Rules for Autocomplete

#80

Post by spectre256 »

It's important to note that this set of rules is for use with a small (> 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...

Post reply on HN