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 ...
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 ...
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 ...
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:
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 ...
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 ...
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, authors,...
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 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 ...
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 ...
As frequently happens, it depends.
In this case it depends on the application type.
If it's a UI that the users will use frequently, as at work, then typing a few characters is both faster and safer that choosing with the mouse.
For this kind of applications I've set (sort of) autocomplete inputs, combined with drop-down, that were very successful in that ...
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 ...
You can implement it like the tags work in stackexchange sites. Start to type in the tags field and do a search on every character. In this example, I typed fin.
I see a list of tags (companies in your case) which I can select. Or i continue to type and create a new tag (company) if there are no matches made.
Google doesn't just do stuff for the sake of doing it
Highlighting what I typed over and over again doesn't really add any value while highlighting the differences helps a user quickly find what they are looking for...
If I had to pick just one then I would go with Option 2 (Google way) since they do a lot of usability testing based on successful ...
Option B Empowers the User, Option A makes work for them
Summing up the positives and negatives:
Option A offers either the positive experience of seeing a correctly auto-filled form, or the negative experience of seeing something that is incorrect and having to undo it to redo it correctly.
Option B offers either the neutral experience of simply filling out ...
Unlike B2C shopping sites where you can display a list of popular items or new promotions, there is nothing useful that you can display when it comes to finding employees, so a simple search field would suffice. You might also want to consider including a department filter if it help the user to narrow down the search criteria (assuming your data model ...
The last option, using a single field for type and street is likely the best. That said, let's go through the three options and see where the strengths/weaknesses of each are:
The "street" field starts focused; if the user selects something in
the drop down then the "street number" is focused ("type" is
autofilled); if he tries to move to the next ...
Are users supposed to know client IDs and names?
If it is so I would suggest to use an autocomplete (Google like) displaying results at the bottom of the search box.
You could also provide a checkbox to select "search by name" or "search by ID".