Generally typeahead/autocomplete is instant, and to avoid confusion I'd recommend sticking with the standard of autocompleting instantly after a single character.
For no reason other than convention I'd suggest keeping an instant, one character autocomplete; every search bar I have within reach acts this way, including Google.com, Google Chrome, iTunes, ...
Perhaps a hybrid approach would make sense. What I'm thinking would be to link the delay to the number of characters already entered, with a longer delay for fewer characters.
If a user has only typed 'K', they're probably going to type a lot more, so an instant suggestion would return more results (less likely to have their target at the top), risk more ...
Yes! It is counter-intuitive; which is why any website that allows user names with single character should begin the check from first letter a user types.
It's similar to what Twitter does:
Don't change the functional behavior for short letters and long letter. In this case always use prefix ...
Firstly, don't auto-highlight the first option like shown in the screen cap. Then dim down the auto-suggest area when the user is just typing. If they hit the down arrow or hover over the auto-correct area, it will brighten back up to its current state. Some text could be added to give the users some instructions, but I don't think they'd be needed.
Yes, this is excellent practice. It can even improve the responsiveness of your application, because doing the actual search on every key press can cause delays in itself.
I have build a component (that we're using all over the place for this and similar purposes) that basically sets two times: a minimum time to wait for more input, and a maximum time from ...
Don't complete on enter, this will make people crazy if they want to search for shorter strings!
What you could do is showing them if their string will produce any results on-the-fly
Many websites check your chosen username for availability while you type it.
Edit: You can supply some selection and then allow to select it with enter, but never auto-select ...
Both of the methods you've described work well, so include both and let the user pick the one which suits them.
Exploratory vs Known-Item seeking
Rosenfeld et al describe two main types of seeking:
Exploratory seeking and Known-item seeking
The A-Z list method suits exploratory seeking, where the user isn't certain about the course they are ...
The problem isn't with your autocomplete control, it's with your form.
Check out how Trello does this.
1. Before you begin, the input field explains what you can enter
Note that the form is titled "Add Members" and allows you to input multiple email addresses and select multiple people in the list.
2. When you begin typing, "searching..." appears to ...
I don't have any studies for auto-complete in particular, but perceptible latency for a user interface is thought to be at 100 milliseconds. At that point, the user feels that they are in control and the interface is responsive.
With that in mind, there are a few factors you should consider.
How quickly will your query return on slow internet connections/...
Autocomplete and suggestion features serve different, though similar, purposes.
Autocomplete is there to make it faster for you to complete your search. If you for example want to search for "wikipedia puppies", and start typing, you will get an intermediate stage of:
You can see that the autocomplete has provided me the option of completing ...
Google actually removes autosuggestions for specific searches.
In which cases?
Were things being removed?
Yes, and for these specific reasons, Google says:
Hate or violence related suggestions
Personally identifiable information in suggestions
Porn & adult-content related suggestions
Legally mandated ...
Search from first letter.
If, for some reason, you can't load all results, you can just show your user that there are more. Something like this:
download bmml source – Wireframes created with Balsamiq Mockups
That way you would load only a few lines, and thus get a reasonable loading times. At the same time, your users will see that typing further ...
I think the answer depends on how your widget and search works:
In case you can search for partial results, you shouldn't automatically autocomplete the field, as the user might just wanted to search for the substring he entered (in the above case he wanted everything starting with AB). For this you probably have a combobox style widget, where you can enter ...
Completing the city/postal code first would allow your UI to propose a narrower selection but, in your context, this would go against the user's mental model of how an address works.
Even in a world where letter-writing is a dying art, people in the Americas and Europe learn that addresses start by smallest unit to largest. Generally something like this:
Typing on the phone is much more difficult than on the keyboard, so people make more mistakes and the phone autocorrect has to work much harder.
Keyboard mistakes come from actual grammar mistakes and from typos, which are usually caused by typing an adjacent key by mistake - in most cases the wrong key is the one immediately to the right or to the left of ...
If you are providing an autocomplete field, you are helping your users find information in a long list quickly. Pagination of results obviously doesn't improve the UX because flipping through pages isn't much different from scrolling a regular drop-down list. Therefore, simply don't display any results until there are no more than 10 left (the number may be ...
Do not change the functionality for different types of inputs if the person who inputs the data is the same. This will confuse the user.
The difference is that for Google search you show only top n
recommended/popular suggestions, while for users you expect to see a
complete list of matching users
You can do exactly what Google does and you can sort ...
There is a different between Auto-Complete and Auto-Suggest.
Auto-Complete happens within the input box where you type and you can press either enter or "right-arrow-key" to accept it.
Auto-Suggest list appears as a multiple suggestion list in the form of drop-down. To make use of auto-suggest items, you have to click "down-arrow-key" or mouse click to ...
Frankly, this is contextual. For a single word, generally 2-4 letters are kept as minimum to initiate the auto complete feature. There are at least two reasons for this.
One being the performance as you pointed out. There is no need to fire up a filtering call when you know that the resultant dataset will be huge.
Second being, the number of results you ...
Because you have a bunch of fields in rows, each doing the same thing (from what I can see from your screen grabs), you will want to handle this with an introductory message. Something along the lines of:
All fields below are optional. You may skip this step by taking the [add your action here]
Another takeaway for you, it wouldn’t be clear to me that the ...
Is there evidence that it's worth enabling keyboard functionality?
Yes. It's called Web Content Accessibility Guidelines (WCAG) 2.1.
WCAG 2.1 Success Criteria 2.1.1 states:
2.1.1 Keyboard: All functionality of the content is operable through a keyboard interface without requiring specific timings for individual keystrokes, except where the underlying ...
This possibly sounds like a good use case for categorised autocomplete - http://jqueryui.com/autocomplete/#categories
A single search box that splits the result into logical grouping when presented back to the user.
download bmml source – Wireframes created with Balsamiq Mockups
Hope this helps.
Apparently a research study done on the effectiveness of autocomplete and auto suggestions in a library website shows that people do use it. To quote the research article
The study’s findings were consistent across both rounds of usability
testing. Notable themes include using autocomplete to correct spelling
on known-item searches (specific titles, ...
I think your idea won't work well. Primarily because if I first end up in an interface where I expect to fill in forms and see a search bar, my first thought will be that I'm in the wrong place, I expect form fields where I can input my data. Users won't know how to submit their data using your approach. They will need to be instructed or guided, which is a ...
I'd rather stick with the well know format since users tend to go to "auto-pilot" in this mode, so making them think isn't recommended.
It has also happened to me before that I'm typing / choosing faster then the values are auto-update, creating confusion and sometimes input of double values.
Moreover, you've mentioned it's an international site, so that ...
First of all, user should know what is the state of a system. She used the feature, entered the data and now she expects to know the results. In such context, there is a value in showing the '0 results' information.
Next thing is to know what would user like to do when she gets no search results? Did she misspelled the name? Can she take another route of ...
If you automatically change some text input, the user may not notice that it has been changed. That will lead to a mismatch between what they expect and what happens.
I can see two possible solutions to this:
Only allow the value to be changed with the slider, and make the input field a read only field. This is the simplest to do, and I believe the ...
I've found a UI widget like this one (JS) to be helpful:
Some of the features that you would probably use:
Looks and behaves like a select box, but with search functionality.
Allows search, with a custom matcher if you need it (so you could check by ID or by name, address etc)
Allows loading of remote data sources, and ...
I am not sure I understand the logic behind delaying the display of the keystroke. Remember your key stroke is the primary action which the user performs (the resultant search results are secondary) and the user would expect an immediate response to the primary action he has performed. A delay in the response would just confuse him.
However with regards to ...