User Experience Stack Exchange is a question and answer site for user experience researchers and experts. It only takes a minute to sign up.
Sign up to join this community
Was wondering is anyone had experience dealing with autocomplete widget vs using a select box when you got 100-200-300 items in the select box.
I think the general consensus is that the autocomplete widget is better but I find that I (personally) am faster with a select box because I don't want to start typing.
What you guys think?
Put aside the question of whether or not a select box with up to 300 items is in fact usable, and to me the most important and distinguishing factor between the two seems to be that with an autoselect the user is not given a list of choices.
If you have a select box of possible items that you want users to use, I think it is bad user experience design to assume that the user will miracally know to type the letters of the correct item into the autoselect. Sure they might start typing and get suggested a good match, but if a user does not know the options, they might select a bad match, just because it is the first/only one that the autocomplete suggested.
If you have categories to enforce, the select box seems the better choice, as it gives the user information about possible options.
Your real problem seems to be having a list with up to 300 choices. Using an autocomplete disguises the fact that you have so an abundant amount of options. Maybe the solution would be to figure out a better way to split up or organize the choices. There is a couple of questions dealing with that problem in particular:
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 the users preferred to use them, and found that that were able to do their work faster and with less errors. Also, sometimes the item counts were in the thousands.
I say sort of autocomplete because I developed or modified the input controls to make them search for the typed text anywhere in the list, as opposed to searching only at the start of each choice.
This behavior requires that the list of choices get shortened as the user enters characters, which differs from the normal behavior which is scrolling the list so that the first matched choice is visible.
The need to search the whole text comes from the fact that the user might not know how the choice he wants is written. For example he might want to select "March 9th" and in a control that searches only the first characters of each choice he might miss "Monday, March 9th" because it starts with "Monday" and not with "March".
On the other hand, if the list shortens as the user types, he will end up with all the "March 9th" choices no matter if they happened on Mondays or whatever.
I made very successful implementations of shortening lists, with item counts in the thousands.
Else if the UI is for occasional users then they will not be aware of the search or autocomplete capabilities whatsoever, so I wouldn't implement them.
For choosing items hierarchically from within a big number of choices, see this prototype I built:
https://dl.dropbox.com/u/2965258/foodSelector/foodHierarchy.html
It has a restriction: it requires that the choices be categorized and the categories have to be known by the users.
An autocomplete is basically a form of select box with a text field to speed up the selection. If you only have to select a single item from a list, then I would use autocomplete as it cleanly allows someone to use whichever method they prefer while also taking up minimal space.
If you have to select multiple items, I would go for a select box. As it that situation, it is usually faster and less frustrating (personal opinion). However I would still consider having an text field on the left side of the select box which acts like a filter.
