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
I am introducing searchable drop down lists to filter grid data. The number of items in a list could range from anything like ten to a ten thousand.
The larger the number of items, the more awkward the feel of the view (let alone the performance hit).
So, what is the maximum recommended number of items to put in a drop down list (searchable or otherwise)?
There is no recommended maximum number of items to put in a drop down list.
No-one can say the maximum is 7 or 12 or 200 or 10,000 and definitively say that for all scenarios, that is the maximum you should use.
There is a myth for drop down lists and menus that you should not use more than 7 +/- 2 because that's how your memory chunks things, but that's not true because of the way lists are inherently scannable - you don't have to remember all the items in a list.
The next factor is the number of items visible at any one time in the list - let's say 10 to 20 items. That seems reasonable but depends on whether the list is wide and/or covers the content underneath and how that affects the user's ability to be able to choose an item when other content is covered.
After that there's the introduction of a scrollbar and the difficulty of making a choice is increased because you only have a relatively small window view to the whole set of options. So the ratio of number of options to the number visible at any one time is the factor there.
At that point you also really start to care about how the items are sorted, so as to make the list scannable, and aid memory of where you saw an item earlier or later in the list. So a typical scenario is choosing a country when entering an address. We're all familiar wih 200 or so items in such a list and can deal with that reasonably well most of the time, but imagine if that list wasn't sorted - it would be a horrendous task.
Unfortunately that really happens in the wild - here's a preposterous example from Hyatt Hotels asking you to choose an airline from 180+ options. Note the rediculous position in the list of "Other Airlines (Not Listed)"
Even so - when sorted, all lists are not equal - some numbers are more easily scanned than some words, especially if the numbers are sequential, and the words are unevenly distributed across the alphabetical ordering.
Once you start getting over this 200 or so mark then things get unweildy. The numbers 1 to 1000 could work, but 1000 cities around the world would be undesirable if you can only see 10 at a time and have a tiny scrollbar to manage it with.
At that point you no longer want users to interact by scrolling - the searchable option comes into play much more dominantly. There is a step change in the way the user is expected to interact at that point - the drop down list no longer is a static list, but a dynamic list showing results of a search.
If you treat the drop down as a results list rather than a list of all possible items then the sky is your limits - your entire inventory is at your fingertips. However, you need to present it as a search box (not a static list), firstly because performance issues arise as you point out, and secondly because you will always get some users who decide to scroll up and down this immense list. Such a dynamic list should show as empty when no search term is entered rather than contain all the items.
To summarise - it depends. It depends on the visual relationship between the underlying screen content and the drop down content; it depends on the scanability of the list data; it depends on the sorted state of the items and the distribution within the sort key range; and you should question whether a static list content is even desirable in the first place.
Finally - because every situation is different (and because you just should) you should A/B test a few options with users in order to verify any such assumptions, so that you can make evidence based arguments to yourself and others that yes this was the best way to do it.
It can help to think about what you could do in an ideal world, then look back at the drop down list and see how unsuitable or archaic the drop down list feels. If it feels like that, then you have realised that the drop down is not the best way to do it. If you proceed to use the drop down anyway (eg due to time/cost/toolkit constraints), then you just made a decision based on some business rules rather than on providing a good UX, and you have to live with that.
Ultimately, the best UX does not come for free. It costs money - get over it.
I'm currently building a web-based application to replace some hideous behemoth written about 10 years ago and have encountered a similar issue, with some drop downs in the extant version having over 1000 entries.
Whilst not being able to offer any specific UX tips as above, I've managed to reduce the user's problem to some extent by allowing them to filter the contents of the select based on text input - have a look at the jQuery Chosen plugin (although I didn't use this in the end).
Using a multi-line select helps as well (I went for an arbitrary 10 in my case) as it allows the user to visually scan the contents without having to do so much typing - it also has a fixed height and doesn't obscure stuff below.
This may not however solve your problem if your users don't really now what to start looking for, but in my case (an intranet application), the users are already familiar with the data so it works for them very well. To back this up, we've had very positive feedback about how much of an improvement this is from the relevant user working group.
I considered a few other options to get my version to work well, including things like a Miller Column style output, but I didn't have a hierarchy to justify one and wasn't going to impose one for the sake of it. In the end a custom jQuery fn has done the filtering and performs really well in my version with around 1000 rows (my application is tested for IE8 and there is no noticeable lag with lots of data).
Generally if the dropdown requires the user to do extra work and scan a significant list (such as needing to scroll) hen a dropdown can present usability issues.
However!
The one thing that dropdowns have going for them is that everyone uses them... so users know how to use them. So while it may not provide the best experience users are likely to know what to do when they encounter it.
I generally think dropdowns are over used.
Most country dropdown lists will have 300+ entries in, selecting your birth year will probably have 100+ entries in it (you don't want to exclude those Centenarians). But those are for well known options. The problem comes when people don't know what they're looking for, e.g. even in country lists it can be a pain searching for the UK in country lists as some people list is as United Kingdom, some as Great Britain, some as Britain, some as England/Scotland/Wales, some put it near the top etc.
So the list has to be either numerically or alphabetically sorted but then certainly lists of 100 should be ok. Beyond that you can start using 'Typeahead' concepts:
For desktop (Keeping only user's convenience in mind)
If your list is a dynamic, then go with an auto-suggest.
If your list is static and small (upto 10 items), then go for a simple drop-down
If your list is static but large, then based on the size of the text
--- for smaller length (upto 20-25 characters), go with a scrollable dropdown
--- for bigger length (more than 25-30 chars), go with an auto-suggest
For Mobile
Go with something as lightweight as auto-suggest. As per my experience, drop-downs are bit too heavy to use on a mobile device.
If the list is as small as 3-4 items, go for radio buttons
<select>field will have better performance (= will be able to show more<option>fields), than using<div>elements; I did a demo of this here trying to render a list of 1m search results: github.com/radekstepan/coding-challenges/tree/master/apps/…