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

61–70 of 151 posts

Re: Rules for Autocomplete

#61

Post by ygra »

NationOfJoe wrote: post #5

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

Re: Rules for Autocomplete

#62

Post by no_gravity »

perlgeek wrote: post #57
no_gravity wrote: post #55

Earlier quoted context omitted.

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

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

    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.

Re: Rules for Autocomplete

#63

Post by ykampittaja »

An anecdote on MacOS Spotlight and learning algorithms: I never started Chrome browser with it, because it was already running and never shut down. Then I (once!) started the chess game with Spotlight. Fast forward half a year, and Firefox had became my preferred browser. Chrome was no longer running always. However, Every Single Time I now try to start Chrome using Spotlight this happens: Type 'C', press enter and Chess starts up. Shut down Chess, carefully type 'Ch' and wait for Chrome to appear on the list.

It is hard to learn predictive input when you cannot know if the predicted end result was actually what the user wanted.

Re: Rules for Autocomplete

#64

Post by ricardobeat »

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

Re: Rules for Autocomplete

#65

Post by pfranz »

cstrat wrote: post #13
ghayes wrote: 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).

> If I type the next letter of the top match, it should remain the top match. How would this not always be the case anyway given the other rules in place?

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.

Re: Rules for Autocomplete

#66

Post by vipulved »

These are almost completely wrong. The goal of AC is to get to “what I meant to type” and good AC systems are designed with priors (eg frequency), common spelling mistakes, etc in mind.

Re: Rules for Autocomplete

#67

Post by jakobegger »

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

Re: Rules for Autocomplete

#68

Post by coldtea »

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

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

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

Re: Rules for Autocomplete

#69

Post by coldtea »

no_gravity wrote: post #62
perlgeek wrote: post #57

Earlier quoted context omitted.

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

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

Re: Rules for Autocomplete

#70

Post by sprt »

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

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.

Yup. 10 years later, Chrome doesn't even come close to Firefox's implementation.
Post reply on HN