Take the 2-minute tour ×
User Experience Stack Exchange is a question and answer site for user experience researchers and experts. It's 100% free, no registration required.

I have a field which needs to be populated from a large list of items (many thousands). These items have unique numbers as identifiers, and there can be many thousands of them. (Similar to the way that bug tracking software will label 1000 items from #1 -> #1000). The field must be populated with a valid value.

A dropdown is obviously not a suitable control here. I've thought of five possible solutions:

  1. Free text input, with some kind of validation on input blur.
  2. As (1) but with a manual 'check' button which manually validates input instead of doing it automatically.
  3. As (1), but with a 'search' button which overlays a form allowing user to search on various item properties (ie. item title), and then select from a list of valid options?
  4. An inline sortable/filterable/pageable grid showing all items and some properties (such as identifier, Title, Date Created).
  5. As (4), but the grid is hidden by default. A 'search' button opens the grid in an overlay.

The first two options require the user to already know the ID of the item they are selecting or navigate away from the page and search for it. The inline grid might take up quite a lot of space for what is supposed to be a fairly simple selection. The overlays again seem quite complex for a simple control.

Are any of the options I've detailed appropriate? Is there a better way?

share|improve this question
1  
I think the answer will depend upon what your users know/ how they're likely to want to make their selection. Are they likely to know the ID? is there a human readable proxy for the id (in a bug tracking app this might be a title) which can then be dis-ambiguated by a secondary piece of information eg, a date or a username of the person who created the item etc. –  Tom P Sep 6 '13 at 12:03
add comment

3 Answers

The key thing is to ensure that there is no road-block for users who know the exact ID, but there is a good fallback for unprepared users.

One familiar example similar to what you describe is airport selection on travel sites. There are hundreds; the unique identifier is a three-letter IATA code (e.g. LAX); a user may know the code, but is more likely to select by city name (e.g. Los Angeles), which is usually but not always unique.

The common, and excellent, solution in this case is an autocomplete text field, selecting by the unique ID combined with some more recognisable description, so that a user who knows the identifier can get straight to it, while others can find what they want with minimal difficulty:

Example from kayak.com

If in your case there isn’t anything analogous to the city name — no human-readable “common name” in addition to the ID number — then I would suggest an autocomplete field for the ID (or, if for some reason autocompletion is unavailable/inappropriate, your option (1), free text with auto-validation) together with a side option of either a “search by attributes” (your (3)) or a drill-down menu (5) for users who don’t know the ID they want.

Which of (3) or (5) is more appropriate will depend on the data at hand. If there are some attributes for which the user will be able to choose an exact value (e.g. State/City/ZIP code with free text, or Garment type from the option list shirt/trousers/outerwear/underwear), then a hierarchical drill-down selection can work very well. If users are likely to have only partial information about attributes (e.g. date of a previously-submitted item), then an “advanced search” type form with multiple fields may be necessary.

Re your (2): I can’t think of any use-case where manual validation has any advantage than automatic. If a user is conscientious and always checks it, then (compared to automatic checking) they lose time when it’s valid, and gain nothing when it’s invalid. If they’re hasty and don’t check, then they gain nothing when it’s valid, and get tripped up when it’s invalid. The only conceivable reason I can see is if database queries are for some reason very expensive indeed, which seems unlikely.

Re your (4): if the fallback option is complex, then having it hidden by default (though of course still clearly accessible) keeps the form uncluttered, to optimise the workflow for users who know the ID.

share|improve this answer
add comment

Why dont you make a dropdown with sorted by categories and user can search with a search bar. Instead of a dropdown, make it a full page overlay. The sorted nav bar can be done in your situation, make a nav with link of Title, date, etc...

share|improve this answer
add comment

One thought is to question the premise which requires a user to search for an item among thousands? Is there for example a way to push to the user the item they should be interested in - for example via email, via a notification alert in-app, by tagging as a "favorite" or listing items that the user has worked with in the past ("related" to them).

Are there any relevant taxonomies which naturally support user workflow? (for example searching an airport - continent > country > city, searching for a bug - division > product > feature, etc).

In general if you can support "free text" search, in 2013 there is not much reason to do #3 (attribute/value pairs)

share|improve this answer
add comment

Your Answer

 
discard

By posting your answer, you agree to the privacy policy and terms of service.

Not the answer you're looking for? Browse other questions tagged or ask your own question.