18
Option B with a slight modification of the text:
12
There's a fair amount to unpack here.
A lot of this is dependant on context within the product, context within the page, and the core users.
If your users are in a hurry, almost always choose different options here, completing a long form, etc. then the better option may be to run with the most simple looking option - The single dropdown containing an option ...
8
Design (B) seems superior from an ergonomics standpoint.
With design (A), if I want to enable and configure the feature, I have to interact with two widgets instead of one. Using keyboard navigation, I have to press: Space to check the box, ↹ Tab to focus on the drop-down, Space to pull the drop-down, arrow keys to choose the item. With design (B), I only ...
7
Separate the User Lookup Task from the Add Task
In other words: Remove the "Did You Mean?" section.
In the provided example, it's easy for a user to get distracted and wander off from the key task of adding a new user. Example: "I need to see if Thomas Jones is already in the system. Oh, there are two people called Thomas Jones... I wonder if ...
6
Give the required name fields a little more separation from the either/or fields; that will help the user understand that one or the other is needed. Here's an example of a government petition signing pattern that does this well:
If it would benefit the user to enter both phone and date of birth later on, let them know the reason why in the text above that ...
5
I think it's a design problem.
You are putting an unnecessary graphic limit at the card bottom: the black button.
By changing the location of this button, the number of "new users" can be 5 or twenty without generating any UI problem.
In this example the button is at the top not as a final solution but to show the design versatility without that ...
4
There's an important functional difference between those two options: option A allows the software to remember the position even when the feature is disabled, and option B doesn't. Only you know enough about the software to decide whether that's desirable or undesirable.
Another thing to think about is what will most users do? If most users will disable the ...
3
I would like a third option, like the Microsoft Excel cell border widget:
The GUI has the field labeled "None" ordered in parallel to the various line styles: all of them are immediately accessible. That makes sense: Only one of them can be active at any given point in time. Logically though it could be seen as a two-step process, like in your ...
3
Summary
As others have stated, it can depend on a variety of factors, such as what this control is used for. However, my immediate response is very emphatically that option A is clearly superior. Option B is just too clunky.
Reasoning
With option A, I can set the location of all my widgets until I like the interface. Then, I can simply enable and disable any ...
3
Preface
I would actually suggest to think in reverse. Start by asking the question why it is important to tell or show the user that they are only required to fill in one of the two options. Especially when filling in both options is completely fine, too.
The average user has already filled in hundreds of forms just like this one during their life time, so ...
2
Options:
Validate When Form is Submitted
Validate When Input Loses Focus
Validate X Time after User Stops Typing
Validate After Every Keystroke
Traditionally, sites would use option 1. Option 2 became much more common with the widespread adoption of HTML5. Over the last decade, sites have begun moving to option 4. What I rarely see is option 3, which is a ...
2
TL;DR
"Did you mean?" is out of context and demeaning for your purposes.
I would name it "Existing Matches" if you're interested in keeping the current interface. The other answer does a good job of suggesting the relocation so I'm not going to beat that dead horse.
Presumably the next step in your interface is to enter the person's full ...
2
Ideally, you want to create one form that assists both user types. Multiple solutions could create cognitive load for users that aren't sure which path they should take. Ultimately, you should have the following goals for your solution:
A form that you can get through quickly for experienced users
A form that can provide support to users that aren't ...
1
100 % - > (A) design a checkbox for enabling/disabling the feature + a dropdown list to select additional options
Second option is just too messy the user would get lost
1
It sounds like "Contact info" is just a free-text field, as opposed to a lookup reference to another record. In this case, I would suggest you change your logic and allow the user to submit an empty field.
This then essentially becomes the method for "removing the contact info". The user edits the field (modal shows), they empty the data ...
1
The answer from @AndyMercer is a good one, but I'd suggest there is a slightly better approach that combines Option 2 and Option 4.
How I would approach this is using the following steps:
The first time the field is focussed, defer validation until the field loses focus/is blurred.
This avoids the angry error message before you've had a chance to at least ...
1
I know the question is old, but if you're worried about users entering the wrong domain, you can use something like mailcheck.
Only top voted, non community-wiki answers of a minimum length are eligible
