Search box: how to accept an autofill suggestion and run it

Question

I have a search box with autocompletion based on recent searches. Let's say it searches for names. As a user types "Rob", it autocompletes it to "*Rob*ert". I'm trying to figure out a way for the user to accept the autocompletion and run the search on it.

There is no predefined format and this is not a finite set of expressions, so the user's input may be anything he wants.

The question is how do I use the keyboard to distinguish between A) "run the term that I've typed so far and ignore the autocompletion" (e.g. Rob) and B) "accept the autocompletion and run that" (e.g. Robert).

I can't use Enter for A and Tab+Enter for B because I don't want to violate tabulation standards. Tab moves the focus to the search button and doesn't affect the search string.

I'd rather not display a separate suggestions box because this already takes place in a layover and I'd like to avoid piling popup components on top of each other. But it seems like that's what I'm left with. An alternative is "pretending" that I have a suggestions box - with up/down arrows navigating between possible autocompletion suggestions and enter accepting one.

Any other ideas?

Answer 1

Some thoughts:

• Giving suggestions in a text box is practically equal to providing a dropdown, IMO.
• Regarding unintended hiding of contents below the text box, Google handles this with white space and a limited number of suggestions, as illustrated in this answer.
• The behaviour of the text box being filled up by the best suggestion is called Text Completion (at least by Microsoft in the AutocompleteBox of Silverlight), as illustrated in this SO question. This means the value of the box consists of not only what the user has typed so far, but the entire suggestion string. This comes very handy for what you call "finit sets", where the user is encouraged to use one of the predefined strings, but the user can still avoid using the complement by pressing Delete, as the complement text always is selected.

Answer 2

May I suggest the convention from code hinting.

User distingues the auto-completed portion of the search via highlighting.

As user types:

Richard

Rochelle

Robert _{(user sees the desired outcome)}

At this point user may choose to search 'Rob' by either pressing < enter > or clicking < search >. Or accept the autocomplete by pressing < right arrow > or < tab >.

Robert _{(user pressed < right arrow > now highlighting has been removed indicating acceptance of the autocomplete)}

User may now seach 'Robert' by pressing < enter > or clicking < search >.

(sub suggestion) If user hangs on the search field for too long (5 seconds?), activate a tool tip describing the keyboard controls.

Alternatively:

1. Hit < Tab > or < right arrow > to accept autocomplete -> hit enter to search (user > autocomplete, assume user is correct) *my pref
2. Hit < enter > to accept autocomplete or Hit < space > or < tab > to reject -> hit enter (a second time) to search (user = autocomplete, assume neither)
3. Hit tab or space to reject auto complete -> Hit enter to accept and search, or just search (user < autocomplete, assume autocomplete is correct)

<1> has the advantage of assuming the user, so mistakenly using autocomplete is not an issue. Running the search without explicitly accepting auto complete will run the users key strokes only. The disadvantage is that some users will not understand how to use the autocomplete when they want to.

<2> has the advantage of agnotisim regarding user keystokes and autocomplete, user must specify with action regardless. Major disadvantage is that this method means using the search will ALWAYS have an extra click or keystroke, as there is no default.

<3> has the advantage of assuming the autocomplete, making autocomplete easy to use for all. But this is also a disadvantage, as users who do not wish to use autocomplete now have an extra keystroke to get around the feature.

IMHO: 2. is bad, simply because it persistently demands and additional action on the part of the user. And 3. is bad because it is overly aggressive with the autocomplete, meaning that it could get in the way of user intent rather than assisting it. So we are left with 1.

One final option to consider is the use of timers. If user hangs without a keystroke for a moment, that may also be a good place to trigger an acceptance of autocomplete.