Validation should not start before input is complete
When the user starts entering a correct value, no errors should appear while typing. The input is considered to be complete when
the input focus is lost (navigating to another field) or
the form is submitted (e.g. autosubmit when pressing enter) or even
after not receiving input for some time (e.g. 3sec ...
Rather than continuously display a red validation message when the user has not met a field's requirements, a nice alternative is to (1) display a tip that tells the user what is expected, and (2) display a green "requirements met" message when the user has entered a valid value. You can go green as soon as the input is OK.
It depends on the type of Input Field.
For the Email Field:
You don't wanna be too jumpy. Let the user finish typing the email address.
If the input field turns red with an error-text at the moment the user starts typing, it will annoy the user.
The right approach would be to let the user finish typing and when the user shifts the focus away from that ...
I don't think you need to overthink it too much, most users understand the concept of passwords these days.
I would suggest something simple like this can work:
A valid password can only contain letters, numbers and special characters.
I would suggest making "special characters" a hyperlink (as illustrated by the bold style above). This can ...
You could just utilize a paired checkbox with the field. Checking the box indicates that the user acknowledged the field and intentionally wanted to leave it blank.
This way a user cannot submit the form unless they either input data or check the box. May need to include some helper text so that the user isn't confused.
It appears that the username and password fields are related to creating a new user account, perhaps something that a system admin would do when setting up a new user (as opposed to a user doing it for their own account).
With this is mind, I would suggest making that part of the form a more explicit action. Only show those fields when they are required to ...
I'm sorry if I don't answer easily, but that's my old habit of being a designer, I usually start with the 5 whys.
Why would you limit the user in using specific characters in the first place?
More special characters don't make your password more secure, the longer of the password is more important than the type of character. For instance, for ...
Real-time validation works if you properly handle incomplete responses.
The example given is bad UI because "reara" is a valid way to start an email address. An example where real-time validation can reject an incomplete response is "reara@@". In that case the real-time validation can reject it without waiting for completion.
In general, ...
The main issue for me is not whether or not the validation can be done automatically but that the user has explicit control over the action the interface is offering. Users should have explicit control over the interactions the application offers to them. If they don't have explicit control they may find themselves unsure of what the application did and what ...
"All keyboard symbols" could introduce additional confusion in some cases: not all keyboards are the same, some have characters which are not in your list, frequently used by speakers of other languages.
"special characters" with validation sounds like a good solution in most cases. The error message could also be improved to indicate ...
Common practice is to use conditional logic.
You can prevent the user being nagged about something they intended by adding a checkbox before the department filter field. The checkbox can say something like "Add a department filter?" and only show the filter if it's selected.
When you do this, you can make the department filter field mandatory, if ...
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 ...
If you really need the data to be entered - make the input as required.
As your users are 'internal employees who will become familiar with the UX' they could be instructed that if label has no data on it they should enter predetermined value, e.g. 'N/A'.
You will be able to validate value entered and implement some application logic, e.g. to notify user ...
Maybe this is a variation of another answers, just a kind of clarification of option 3.
You may introduce the concept of status (role, etc.) of user and clearly mention it in user interface. Say after registration with email verification user become Reader. And you promote in your interface that to write post user need to become Writer. So user constantly ...
Just offer the option. Let the user know that these steps will be required at some point, but let them choose whether to do them at the time of registration or at a later time. You'll find that those who are already "sold" on the service will likely complete the entire registration process at once.
On the other hand, those who just want to cheque ...
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 ...
I would recommend looking at how someone like gov.uk handle errors on their forms. Adam Silver has written a great book on form design.
Here is an example of a great form error pattern that is tried and tested by the team at gov.uk
I highly recommend this book: https://www.smashingmagazine.com/2018/10/...
No right answer here, depends on strength of cue and use case. Blur events and submit events may go very wrong if the page reloads in form submit, like it does on some tech stacks, causing user to never see the cue. Can you do it on every keystroke?
Username and password together are an entity that is optional. When the entity is wanted then the fields within it are required. What can we call this entity, "credentials"? Similar to musefans answer but with the emphasis on using a fieldset with legend and with the difference that you use buttons to explicitly add or remove the credentials. Name ...
I wrote an article about the problem with live validation:
In short: it either provides feedback too early and often before the user has had a chance to type their answer OR it provides it too late once the user is finished typing their answer and is focused on the next field answering the next question.
Instead focus on:
clear and concise label, hint text ...
So if the user provide value for Code field, before previous validation request is done, then its new value is not checked.
I think this is where your problem lies. It seems that on the front-end, you should just keep track of whether the values in the fields have been checked or not. Changing the "Code" field should trigger another validation ...
You could handle this in one of 2 ways:
Option 1: ask if they have that information first
Do you know the colour of a unicorn?
( ) Yes
( ) No
if yes ask them for that information
What's the colour of a unicorn?
Read more about this pattern in handling optional fields
Option 2: put ‘if applicable’ or ‘if you have ...
the current design looks great, Also in my opinion when dealing with promo codes its important to provide the user a sense of satisfaction. hence feedback should tell you that
The action has been successful
and how much money was saved
and both needs to be shown in a more presentable manner.
not sure if your system allows removal , if yes you can find the ...