Rules for Autocomplete • Hacker News Board

Re: Rules for Autocomplete

#111

Post by jwr » Wed, Mar 20, 2019, 4:42 PM UTC

> 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

This is terrible, unless I misunderstood. It would mean that if I typed "Google" without looking at autocompletions, I would end up with "Goooogle".

I keep fighting the in-browser auto-completion boxes which try to be too smart and annoy me to no end. Whatever auto-completion you provide, your first priority should be "do no harm": if the user typed something that should be considered as Holy Scripture.

Re: Rules for Autocomplete

#112

Post by the_af » Wed, Mar 20, 2019, 4:49 PM UTC

gwbas1c wrote: post #97

Here's two autocomplete mistakes that really irritate me: - Autocomplete on enter: Chrome does this, if I type in https://example.com (enter), it makes the mistake of autocompleting to https://example.com/some_page_I_visited_yesterday - Arguing: Some applications that I use have autocomplete spell checkers that continue to aggressively try to "correct" technical terms, uncommon names, or company jargon that's not kno…

Learning typos is terrible with Android autocorrect/swype on a Galaxy S8. Swype with autocorrect actually degraded over time, when I had an S1 it worked beautifully, and nowadays it frustrates me so much I end up typing words letter by letter.

They actually made the app worse. Progress?

Re: Rules for Autocomplete

#113

Post by jessaustin » Wed, Mar 20, 2019, 4:51 PM UTC

tgb wrote: post #94

alexandercrohde wrote: post #93

Earlier quoted context omitted.

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

Perhaps parent has turned off javascript?

Re: Rules for Autocomplete

#114

Post by marcosdumay » Wed, Mar 20, 2019, 4:59 PM UTC

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

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.

Re: Rules for Autocomplete

#115

Post by cimmanom » Wed, Mar 20, 2019, 5:01 PM UTC

My pet peeve - the Safari URL bar that will start autocompleting based on page title, but won't let you edit the URL it completes to without visiting said URL. (It only lets you edit the title it's matching)

Re: Rules for Autocomplete

#116

Post by Larrikin » Wed, Mar 20, 2019, 5:05 PM UTC

the_af wrote: post #112

gwbas1c wrote: post #97

Here's two autocomplete mistakes that really irritate me: - Autocomplete on enter: Chrome does this, if I type in https://example.com (enter), it makes the mistake of autocompleting to https://example.com/some_page_I_visited_yesterday - Arguing: Some applications that I use have autocomplete spell checkers that continue to aggressively try to "correct" technical terms, uncommon names, or company jargon that's not kno…

Learning typos is terrible with Android autocorrect/swype on a Galaxy S8. Swype with autocorrect actually degraded over time, when I had an S1 it worked beautifully, and nowadays it frustrates me so much I end up typing words letter by letter. They actually made the app worse . Progress?

Holding down on the word in the auto compete will allow you to delete it from your dictionary.

Re: Rules for Autocomplete

#117

Post by theobon » Wed, Mar 20, 2019, 5:05 PM UTC

jwr wrote: post #111

> 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 This is terrible, unless I misunderstood. It would mean that if I typed "Google" without looking at autocompletions, I would end up with "Goooogle". I keep fighting the in-browser auto-completio…

This should only happen for user requested auto-completion. For example typing "g" "g" would result in Google in the provided example.

This is very beneficial in code completion or navigating file directories. It is horrible when typing an email (though maybe when searching email contact). Definitely needs to be context aware.

Re: Rules for Autocomplete

#118

Post by bluetidepro » Wed, Mar 20, 2019, 5:08 PM UTC

gwbas1c wrote: post #97

Here's two autocomplete mistakes that really irritate me: - Autocomplete on enter: Chrome does this, if I type in https://example.com (enter), it makes the mistake of autocompleting to https://example.com/some_page_I_visited_yesterday - Arguing: Some applications that I use have autocomplete spell checkers that continue to aggressively try to "correct" technical terms, uncommon names, or company jargon that's not kno…

> - Learning typos, or incorrect learning:

This is one that drives me crazy. Esp in the context of trying to be politically correct. No, Apple, I've never wanted to say "Duck" instead of "Fuck."

Re: Rules for Autocomplete

#119

Post by perlgeek » Wed, Mar 20, 2019, 5:24 PM UTC

kgwxd wrote: post #85

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…

Yes, fill the web with keyloggers. It's best for the users.

Not more or less than a JS based autocomplete box does now. Possibly less, if more state is held locally.

Re: Rules for Autocomplete

#120

Post by basch » Wed, Mar 20, 2019, 5:25 PM UTC

efa wrote: post #104

gwbas1c wrote: post #97

Here's two autocomplete mistakes that really irritate me: - Autocomplete on enter: Chrome does this, if I type in https://example.com (enter), it makes the mistake of autocompleting to https://example.com/some_page_I_visited_yesterday - Arguing: Some applications that I use have autocomplete spell checkers that continue to aggressively try to "correct" technical terms, uncommon names, or company jargon that's not kno…

That first one annoys the hell out of me.

This is google favoring people who dont really understand the shared search address bar, and want _enter_ to "do something useful" vs returning an invalid page.

however, if i type out the full tld AND a slash, like google.com/ and click enter, DO NOT take me to a subpage unless i started typing another character.

short term workaround is to add periods to the end. google.com. it will strip the trailing period (even though it is more technically correct) and the period entry will get added to autocomplete suggestions.