2

How to design mutually exclusive textfields?

I'm redesigning a number of forms, each containing different contents. The structure is the same, a header at the top, some fields and a search button. Some of the forms allow the user to search in two ways, based on an ID or a Name. The images show the current implementation: using radio buttons the user can choose which way they want to do the search and the field is updated.

enter image description here enter image description here

In some forms this pattern occurs with more fields attached to the name such as date of birth and address to make it easier to identify the correct person. IDs are unique so no additional fields are necessary. In other forms it is just the one field as in the examples above.

The two textfields, 'Person Name' and 'Person ID' are mutually exclusive. In the current implementation 4 components (2 radios, 2 textfields) are used to handle the simple choice of using either the name or the ID to do a search. Are there other ways of solving this using less components? (and ideally not hiding anything)

Possible solutions (which I don't like / not possible)

  • Use the same textfield for both values (data is passed on to third parties, there is no way to distinguish between names and IDs locally)
  • Use tabs (Don't like it as in some cases it contains only one field)

Edit: To help clarify why we can't distinguish between IDs and Names, there are also forms where it's not about persons but about companies. Company names can have numbers and symbols which makes it nearly impossible. The queries are fired directly to third parties some of which take several minutes to return, hence no autocomplete can be done.

  • Are the ID's possibly detectable? My first choice would be to try to distinguish between names and IDs locally and use the same field. I've actually built a UI that does exactly this. We do a typeahead search that has a regex that determines if user is entering letters or numbers. – cloudworks Mar 23 '17 at 18:30
  • Another thought: is one or the other type more common? – cloudworks Mar 23 '17 at 18:32
  • Unfortunately the names and IDs can be very similar so we can't do that. Name is more common. – Martyn Mar 23 '17 at 19:06
4

Detect It

My first choice would be to detect whether the input is an ID or Name, then send it to the correct service for query. If IDs are numeric it would be straightforward, if they're similar to names, not so much. I understand you're not looking for that, but that would be the ideal in this case (and probably notable to future searchers).

enter image description here

Segmented Toggle

If you must ask the user to identify the type, a toggle that blends the label with the switch might be your best bet. At its simplest, this can be implemented as a styled checkbox, but that's up to you. As you've noted that Name is most common, I'd set that to the default.

enter image description here

  • +1 for detecting it. Assuming obvious patterns (eg, ID is a number) there is no reason the system shouldn't accept both and match the appropriate input. – Evil Closet Monkey Mar 24 '17 at 0:10
  • One reason I like typeahead search is that it eliminates the inefficiencies from forcing the user make an overly specific query. @Alvaro has a good illustration there. Depending on dataset, you may not need the user to identify type, then enter a query, then hit search only to yield 1 result. They may have gotten down to a single result with half as many keystrokes. – cloudworks Mar 24 '17 at 6:17
  • @EvilClosetMonkey As I mentioned in the question, it's not possible to detect. – Martyn Mar 24 '17 at 10:36
  • @cloudworks Unfortunately that's not going to work either as the data comes from third party databases, some of which take several minutes to return results. Also in some cases the user has to pay to get the results, (prices vary between free and £60 or something). – Martyn Mar 24 '17 at 10:36
0

There are two decisions to be made here:

  1. Which kind of content
  2. What is the content (search query)

In the scenario you explain the user knows both.

For the first point you can:

  • make the user explicitly indicate which kind of content. This can be accomplished with radio buttons, select box, toggle buttons (as @cloudworks suggests), or giving the user all the possible inputs and let him fill the one that he wants (the others should disable in some way).
  • don't make the user indicate which kind of content. This will skip one step for the user (at first).

In some forms this pattern occurs with more fields attached to the name such as date of birth and address to make it easier to identify the correct person.

For the second point you can:

  • use an input for each option (you can use two inputs but make them look like there is only one, in your images the only element changing is the label). This makes sense if you made the user select a kind of content previously.
  • use the same input for several options. In this case the input where the user enters the text will need to be able to contain each of the options and you will have to figure out which kind the user intended or let him decide after. This is possible for Name (text) and ID (text/numbers) but when you include more filters you might want to consider if this is feasible.

So in the case the user doesn't pre-indicate the kind of content you could give him an input where he types whatever he wants. You then give him clear results for a clear search (for example an ID might be easy to identify), or a list of possible searches and then let him choose which was the kind of content he was looking for:

enter image description here

  • Could you elaborate on: "This can be accomplished with radio buttons, select box, toggle buttons (as @cloudworks suggests), or giving the user all the possible inputs and let him fill the one that he wants (the others should disable in some way)." – Martyn Mar 24 '17 at 10:41

Your Answer

By clicking “Post Your Answer”, you agree to our terms of service, privacy policy and cookie policy

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