2

We're optimizing a single-select dropdown menu. It has a dynamic number of items (that are grouped), typically exceeding 15. The current design displays only 8 items at a time, requiring scrolling. We're debating whether to implement a search functionality or not. I believe a search is necessary for lists with 15+ items, but some team members disagree. What are your thoughts on the best approach?

More context: When user decides to import data, a modal dialog presents a table with four columns. The final column contains a dropdown menu, where the user can optionally select a data type. These data types are pre-configured by a consultant, for specific user's (company's) needs, and remain consistent unless explicitly requested by the user.

Improve this question
3
  • This is very context dependend. Sometimes browsing is preferred, sometimes selecting filters, sometimes it's quicker to search when one knows what to search for. Please give as much context as you can for a more accurate answer. Commented Mar 18 at 15:15
  • More context. When user decides to import data, a modal dialog presents a table with four columns. The final column contains a dropdown menu, where the user can optionally select a data type. These data types are pre-configured by a consultant, for specific user's (company's) needs, and remain consistent unless explicitly modified by the user. Commented Mar 19 at 7:28
  • Personally I find the minimum before I like there to be search is like 3 items. Commented Mar 19 at 22:33

4 Answers 4

Reset to default
2

I find it difficult to name a hard threshold of the number of items in that menu that would warrant a search field. It's just that this depends a lot on context. for example:

  • How familiar are the users with the contents of that menu?
  • Are the items always in the same order (even if some items are missing)? - If so, can users easily tell what that order is (e.g., ascending alphanumeric, etc.)?
  • How does the grouping affect the order of menu items (that grouping sounds intriguing; can you expand on that a bit?)?

That said, offering search in a drop-down menu is a common design pattern, of course, especially in a table layout. (See just about any spreadsheet software for reference.)

I'd suggest you test with users if they find the search capability useful, and how its (non-)existence affects the time it takes them to fill out a few rows in that table.

If you do decide to add search, I'd display it at all times, even if there are few items in the menu. Otherwise, users might start wondering why it is sometimes there, and sometimes not.

Finally, especially again with this being a table, make sure to offer extensive keyboard support for interacting with that widget: let users select from the filtered list of menu items by using the arrow keys and Enter.

Would love to hear how you decide, and based on what test results and/or considerations! 👍

Improve this answer
2
  • +1 for keyboard support - it's the most annoying to type the search and have to reach for the mouse instead of just pressing enter Commented Apr 2 at 7:49
  • We decided no to use search, although I was advocating for it to be implemented. Reason, It would take to much time to develop the control. Commented Apr 4 at 6:48
1

Scrolling is cheaper than searching (the user has to recall from memory what they're searching AND type it). Obviously, for a small list (3-4 items) the user can see all items on screen, having a search form would be overkill.

However, you mention that in your case the items are dynamic and usually exceed the amount visible on the screen, so there doesn't seem to be a way for users to memorize an item's position on the list anyway. I believe in this case adding a search box is justifiable - and search-as-you-type would bring results faster.

search dropdown field

Improve this answer
0

Surely Search within the dropdown will help in making finding the option selection easier but it depends upon the context. Certain options you can try such as group the options within the dropdown to make easier in understanding groups (ex. Music genre in music apps etc.) or alphabetically sorting options (ex. Country dropdown in web forms etc.).

Improve this answer
1
  • More context. When user decides to import data, a modal dialog presents a table with four columns. The final column contains a dropdown menu, where the user can optionally select a data type. These data types are pre-configured by a consultant, for specific user's (company's) needs, and remain consistent unless explicitly modified by the user. Commented Mar 19 at 7:28
0

Having a search and select combo is necessary when:

  1. The loading time in the list is too long, above 2s. Then may be search will have faster results. Of course, we need to consider the time it takes to type in the keyword.
  2. When the final number of items in the list is not defined and chances are that the list will grow further in the future.
  3. Not necessary if the items in the list are well known like months of a year. Even though there are 12 items, everyone knows them as well as their order. Same goes for years. Me personally, I get cautious anytime above 10 items in the list.

The country list is a good example where you do not bother about how many you display. It is always faster to type in and start searching. So defining a number flat to invoke search in the dropdown will not always be applicable.

Improve this answer

Start asking to get answers

Find the answer to your question by asking.

Ask question

Explore related questions

See similar questions with these tags.