Is there a UX pattern for "drop-down preferred but free text allowed"?

Question

Trying to design a user interface screen for a part of the system where users will be able to select companies from a drop-down. The drop-down list is potentially very long. However, if the company is not there, they are allowed to add it in free text.

The important thing about this screen is that if the company is in the drop down list, it's critical that the user finds it and selects it. If they add it again, it could cause serious problems with the workflow.

What we've considered:

1. A searchable (i.e. type in the box to get autocomplete suggestions) drop-down, with an "add new" option at the bottom of the list which they can't get by typing. That way users have to scroll all the way down to add something.

2. A check-box toggle between a drop-down and a free-text entry, with a possible warning popup when they hit the checkbox.

Are there any other smoother, cleverer or more secure ways to try and ensure a user tries to find and select something already on the list before adding?

Answer 1

Worked on a project with this exact problem. We needed a way for the admin staff to add attribute to products. Because attributes are used for search purposes, we need to ensure if that attribute type already exists, it should be selected instead of creating a brand new one.

We ended up using something akin to your first idea.

^{download bmml source – Wireframes created with Balsamiq Mockups}

The "Create New" option does not show up until the user has initiated a search. This ensure the user sees all likely matches before attempting to create a new item.

Note: This solution assumes you have sensible users who understands why it's a bad idea to create duplicates. It provides increase flexibility to your search to still find potential matches, without preventing the user from creating another item if that action is really necessary. e.g. Apple Inc. & Apple Inc. Canada

Update: Because of the way the autosuggestion box works, it will only show the top X (we used 5) matches for the search string. This system is optimized for speed and depends on the user being diligent in typing in the full item name when creating the new item. For tools that gets infrequent usage, consider JeromeR's solution. Context matters! Test your design!

Answer 2

The first idea failed field testing and variants failed usability testing

It sounds like we had the same idea as your option 1, and we implemented it. We were looking for a way to force users to search first without users realizing that we were forcing the search to occur. A variant of our first design actually tested OK with a small sample in usability-test sessions.

Post-release, it was bad news.

Let me first tell you the details of our earlier design, and then tell you why it failed and what we're planning to do to make it more usable.

Our first attempt

As users type in the box, matching names appear in a drop-down list. The drop-down list scrolls if there are more than four matching. Clicking an item in the list adds a lozenge to the box. To multi-select, users can click in the box again, beside the lozenge, type some more, and select another match from the drop-down list.

The more characters the user types in the box, the more exact the matches become in the drop-down list. As you can imagine, this shortens the list of items. The very last item in the list is always an icon with its Add new command link. But if there are still more than four items in the list, users can't see this command link unless they scroll down.

In this detail the design failed. Users didn't scroll. They didn't discover that the Add new command was at the bottom of the list. It increased support calls. The majority of users of this system are occasional users, so not daily users. They are data-entry clerks. Some of them are unwilling users who enter garbage data so they can "finish" their task and get on with other work. The garbage data must later be cleaned. The users quickly learned—and remember—that they can enter a few character in the box, and see a list of matches. They stop typing as soon as the list of matches appears, so the list is never short enough to reveal the Add new command link. #FAIL

We also considered putting the Add new command at the top, but this path was too easy and caused over-use in usability testing. The desired user behaviour is to select an existing item whenever possible. The Add-new function needs to be the user's last resort, in this context.

Another thing we considered was a non-scrolling block below the scrolling drop-down list, for the Add new command. Our developer couldn't manage it in the available time.

[Edit] One comment asks why we didn't pursue this for the subsequent modifications. The circle-plus icon was present in the legacy version, to the right of the box. We moved it to the bottom of the list for the first release, but there was pressure from various interested parties to put it back. So the solution described next includes a political compromise. (This is UI-design and usability in the real world, folks.)

Our second attempt

We relocated the command. It's no longer at the bottom of the drop-down list. It's now to the right of the box, but with a few differences.

• The command is now a button with only the icon. The command link's text has moved into the tool tip, which appears on hover. The icon is a circle with a + inside, common on the Windows platform. This icon is appropriate for these users.
• The command never appears unless the box has focus and the user has typed at least one character.
• The command doesn't appear in one abrupt snap. It fades in, so it won't trigger an involuntary looming-stimulus response. This is because we don't want the user's brain to flush its short-term memory or to release stress-inducing adrenaline.
• The command fades out when the box loses focus.

We're about to start testing this Saturday.

We really want the user to click in the box and start typing, so we can look for existing matches before they create a new entry.

Answer 3

My answer shows simularities with others posted here but I want to emphasize how important the right communication is.

For example:

1. Reconsider the used language to make the intentions clear. For example use create company to add some weight to the action or use the word new to emphasize the difference.

^{download bmml source – Wireframes created with Balsamiq Mockups}

2. Directly show the create button as it makes users aware of the possibility to add a new company.

3. Showing the suggestions without delay allows to experiment with the input to find out if a company is possibly in the list (maybe with a slighlty different notation)

4. When clicking create/add show all possible duplicates first (eg. in a modal). A small informative text can make clear why this action is needed.

^{download bmml source}

Answer 4

Not commenting on the usability of this design pattern.

The New Relic sign-up form uses this pattern.

Example: Country drop-down/search field.

Answer 5

The problem with scrolling is that scrolling to the bottom of the list box can be inconvenient, and takes the user's attention from the text box where the item to add is located. Basically, the content to add is above the list, but the command to add is below the list.

To resolve this, use the first method you described, but have the "Add" button beside the search box. To protect from errant additions, disable it, and only enable it if the search returns no results.

Here's a mockup:

^{download bmml source – Wireframes created with Balsamiq Mockups}

You can also put a link to add the content in the results box itself when nothing is found. I'm a bit leery of this approach since the list box does double duty, which may confuse the user. Still here's an example:

^{download bmml source}

Answer 6

Hmm... This is just an idea and I don't have any actual examples of other sites that do this but what if there was a field where the user would type the full name or part of the company name and then clicks "search". Their entry would generate a list of clickable matches which would appear below the search box, perhaps using a "tag" style. If there's a 100% match, only show that one for the customer to choose from. If there's more than one, include an option for "It's not listed" or something to that effect and clicking on that would allow the user to enter in a custom value.

The great thing about doing a search first and then allowing the user to pick from the results is that it ensures that the full company name is entered first, not just the first few letters, which would provide a high-percentage match of search results. Dev would need to be involved but it may be worth it not expose the user to a myriad of options in a drop-down menu. This would be a much cleaner, more elegant approach.

An example of this could be if the user types in "P&G", they would see "Proctor & Gamble" appear in the list of matches.

Answer 7

What about a drop-down with a "other" option at the bottom, which, when selected, displayed a text box?

Answer 8

Or you could simply just authenticate user submissions.

Note: I'm not a developer with this technology but being a developer using other languages, I think front-end editing power to users is generally a bad idea since there's all sorts of people out there.

I would simply just do manual authentication.

Answer 9

Among the posted solutions I think Julia's one might be the best, but I want to point out an important aspect: with selections so complex as that for a company, of which there are likely many with very similar if not identical names, the thing that could help the most in avoiding both duplicates and erroneous entries is giving the users extended information about the selected (already existing) company: give the users information about the company location, its logo, its field of activity, but actually even just their website, that could be more than enough: it's very easy for a user to click a link and check that that's what he meant (and there are very few companies without a website these days).

Actually you could likely allow and demand the users to enter the information themselves if they want to add a company: this is both increased effort that stimulates searching for an existing match and a quite trivial of an effort if the user really wants to enter the correct information: it's very likely that he already knows the company's website.

To be sure not to frustrate too much the users you could allow them to skip the website information entry, but you should do that rather hard to do; you might activate the option after a minute, maybe still showing it, disabled, but saying to those who click it something along "Please try for a little longer to find the company website. If you can't find it in a minute you'll be allowed to go on without that".

Actually in the end it would likely make sense to allow the entry of either the company name or its website's url, and the entry (paste) of the url will likely be easier for most users.

You should consider only the second-level domain name of the url by default, and maybe tell that to the user for confirmation and allow to instead enter a longer part of it they say it's not correct to cut it (some company might have a site without their own domain name).

Many little companies have just a social network page, you should handle the major ones (facebook...) automatically, recognizing them and probably storing only the relevant part of the url for them.

---

You could think about e-mails as another option, but that would likely help little and add confusion, as most companies will have more than one, and while you might want to consider only the domain part, those who don't have a website will likely neither have e-mails with their own domain.

---

You could, and maybe should, go further with this by making yourself internally a web search with what the user enters, displaying the first urls found (of course as clickable links) and making the user select the correct one.

---

You should sort the informations returned by number of past selections and, if you do the web search, by relevance from the search engine.

===

Consider also if it really makes sense to allow the users themselves to add new companies, if they are not very frequent it might be better to make a less automatized process, with a request for adding a new company or in any case with a second check on your part that the entered company is new and its information is correct.

===

As an aside, if this makes you think of using the url as a database key, not the worst idea but not ideal either, urls change owners and probably not every single company in the world has a website.

===

Edit: Well actually I'm not sure Julia's solution (requiring the entry of the full name) is the best one, if you implement the checks I wrote here you should probably allow partial entries of the name, and of course searching results as the user types