Type to Add Value vs Purely Select to Add Value from a Drop-down

Question

For a B2B web app we are designing, we have a select box with a dropdown to select values from which are essentially tags. A user can select from an existing list of tags but they can not create a custom tag. Tags are added by a different user and are not too frequently updated. There is no upper limit on the total number of tags this dropdown can have but there is a lower limit of at least 1 tag to select from.

There are two design patterns which we are trying to explore, but we are not able to figure out which one to use/which one would be better for our users in both, short and long-term. We expect our users to interact with this UI component at least a few times a week.

Pattern 1) We show a drop-down with a placeholder text, ‘Select From Tags Below’ > On click of this field, we show the drop-down with all the available tags to choose from. We will add a Search provision inside the dropdown to allow the user search for a particular tag in the list:

Pattern 2) We show a searchable input field with a placeholder text ‘Type to Search or Select Tags’ > On click of this field, we show the drop-down with tags in alphabetical order > As user types the tags name, we show the tag in the dropdown list > User selects the value > Types the next tag value or scrolls through the dropdown to find and select the tags he would like to add.

This can be useful if the user knows the names of the tags he wants to add. But at the same time, is mostly used - in other apps we researched - where the user can add a value as per his/her will (custom tags/values), which we do not have.

Question: Which interaction pattern would be better in your opinion/experience and why?

Answer 1

As always with questions like this, the answer is a clear and definite "it depends"... ;)

Dependency 1: Which devices are your users going to be on mostly? Will they have access to a proper keyboard (and not to forget, are your users going to be versed well enough in typing quickly!), then that's a point for the "search and type" approach #2. Are they mainly going to be on touch-heavy devices (mobile, tablets) with only software-emulated keyboards (which are not proper keyboards!), then the more touch-friendly "scroll and select" approach #1 gets a point (the search bar in that case is a purely optional bonus, though, don't expect too heavy usage of that feature in that case).

Dependency 2: How many tags do you expect to end up with? You said tags are created somewhere else and not being updated too often, but are we talking about tens of tags (as your toy example suggests), hundreds, thousands, or millions? Or worded more precisely: Will the expected list of tags be easily browsable at a glance (or maybe two or three), that's a vote for the "pick one" approach #1 again. Do you expect a huge number of tags, a.k.a. several "pages" worth of your dropdown list, then the typing gets more important. And while both your approaches offer the search bar to counter that problem, then #2 has the advantage, as you're already typing, so why switch modes now. This question scales a little with screen sizes, as obviously you can display (and perceive at once) longer lists on larger displays than on smaller ones, so this dependency is still not completely device-independent.

Dependency 3 (maybe 2.5): How many tags do you expect to be selected at once? Is it likely that many tags are being selected, maybe even similar ones (like in your example, where you selected all tags starting with "Tag T", a.k.a. Two, Three, and Ten)? Then less typing and more selecting would give a bonus point for #1. Especially so if you expect a high ratio of your otherwise carefully limited tags to be expected (e.g. selecting half of all tags would not be uncommon).

Dependency 4: Can you infer any predictions on tags? Can you in any form guess, which tags are going to be more likely to be selected, e.g. based on the logged-in user, based on the date and time, based on other, previously collected data (like selected products or recognized keywords in other texts), or maybe just "recently used tags"? Then obviously route #3 would be ideal, sort your tags by likelihood and otherwise go with the generally faster #1.

---

If you're in the fortunate position of being able to still influence all these aspects, OR you're in the unfortunate position of working into a void of knowledge, and you can/must pick something right now, I would generally vote for #2 myself, too. Just then try to make sure that a proper keyboard will be available (again, I'm talking about hardware which you can blindly interact with, given some experience; software keyboards without this important haptic feedback can actually slow you down again).

Answer 2

if I were to decide between the two options, I would gravitate towards the second with few modifications.

1. Have a regular drop down without search (similar to the first pattern)
2. onclick -> dropdown the tags and transform the button to a searchable tags.(like second pattern)
3. if no tags are found -> display a message saying no tags are found and indicate somehow that the user cannot create tags, if possible suggest related tags.

Hope this helps :)