Live data from Hacker News

Rules for Autocomplete

jeremymikkola.com

91–100 of 151 posts

Re: Rules for Autocomplete

#91
Autocomplete is really frustrating on my phone.

Spelling. It should use key distance. Typing "hrapg" should suggest "graph."

Grammar. The tense of the verb is never suggested correctly. Just previous, as I typed suggested, it gave me suggest until I got passed the whole word.

Responsiveness. If I type "early," I start with "ea" and I notice "early" as a suggestion. I type "r" as I reach up with my other thumb to select "early," but before I can even stop myself, "ear" now suggests "" (the ear emoji) and I inadvertently click it.

Editing. If I deleted a word at the beginning of a sentence, the new word is needing to be capitalized. I click the word, and that suggestion doesn't appear.

Re: Rules for Autocomplete

#92

Autocomplete is really frustrating on my phone. Spelling. It should use key distance. Typing "hrapg" should suggest "graph." Grammar. The tense of the verb is never suggested correctly. Just previous, as I typed suggested, it gave me suggest until I got passed the whole word. Responsiveness. If I type "early," I start with "ea" and I notice "early" as a suggestion. I type "r" as I reach up with my other thumb to sele…

I think your referring to auto-correct, rather than "autocomplete".

Re: Rules for Autocomplete

#93
post #88
post #85

Earlier quoted context omitted.

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

It'd be your browser providing this. They already get all your keystrokes.

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.

Re: Rules for Autocomplete

#94
post #88

Earlier quoted context omitted.

It'd be your browser providing this. They already get all your keystrokes.

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?

Re: Rules for Autocomplete

#95
One thing that is also annoying is that some autocomplete list implmenetations will select an option on mouseover even if mouse didn't move.

So if you place a cursor somewhere below the input, when you type, the list will open with non-first item selected, which breaks the muscle memory in a very annoying way (i know that after typing a few letter what the first item will be, so I confirm selection by habbit immediately).

Re: Rules for Autocomplete

#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 known. (For example, I'll cancel an autocomplete, then go back and add some punctuation, and it'll just "fix" the word again.)

- Autocomplete when the text field looses focus is a form of arguing.

- Learning typos, or incorrect learning: Libre Office started doing this. It learned some names, then it somehow learned a missed space after a common word and started continually trying to autocomplete "Electricvehicle" every time I put a space after the word "electric."

One thing that will help, in certain contexts, is the ability to unlearn or disable suggestions that frequently are canceled.

Re: Rules for Autocomplete

#98
"The user should never have to take extra steps to not use autocomplete"

Failure to follow this rule is possibly the most egregious of sins one may commit, and is unfortunately very common. You have to wonder if people doing this ever even test it themselves.

Re: Rules for Autocomplete

#99
post #70

Earlier quoted context omitted.

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.

Don't worry, Firefox is sure to fix that in an update any time now.

Re: Rules for Autocomplete

#100

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…

Oh yes, I can relate to that - iOS system search is always pulling the rug on me and making me click random apps / web search results. This can be solved by clearly indicating that new results are loading, or deactivating the current items.
Post reply on HN