36

What is really the preferred behavior of form validation? When should the validation take place?

  • When the user clicks "save"
  • When the input field is out of focus
  • As the user types

Is the preferred way the same on long vs. short forms, wizards and so on? What do you think?

(The form will be on desktop platform only)

|improve this question
  • 2
    See this article alistapart.com/article/inline-validation-in-web-forms for information about validating as the user enters information. The article documents actual user testing. – bmb May 9 '17 at 16:09
  • 3
    ^ The ALAP article is an oldie, but it has some great insight into how to test and good principals for doing it right even 8 years later. – plainclothes May 9 '17 at 18:53
  • In addition, on multi-page forms, the user should be allowed to go on to the next page even if there are empty required fields on the current page. That way, the user can proceed and work on the rest of the form, then come back and fill out the other stuff later. Otherwise, I'll just put in dummy information, then maybe forget to replace it with real information before submitting. – Brian McCutchon May 11 '17 at 2:51
37

Generally,

The way in which validation should be implemented varies based on the unique needs of the form. However, in general, if the user’s input is incorrect, the system should inform the user by providing an identifiable and clear message that aids in correcting the error.

from https://www.nngroup.com/articles/indicators-validations-notifications/

More to the point,

The right time to inform about the success/failure of provided data is right after the user has submitted the information. Inline form validation that immediately informs users about the correctness of provided data results in an increase in the conversion rate.

from https://designmodo.com/ux-form-validation/

Working a lot with forms, I believe the least annoying way is to do it when the input field is out of focus until the user fixes the error.

  • When the user clicks "save" => It is a bit too late for validation
  • When the input field is out of focus => It is just the right time
  • As the user types => It is a bit too early for validation

Twitter has it quite right

twitter

|improve this answer
  • 29
    In addition to this answer: do not forget to validate both the client side and server side. There is always some user with javascript disabled or some weird browser addon that would allow him to pass client side validation. – Frantisek Kossuth May 9 '17 at 10:34
  • 5
    @FrantisekKossuth In that case, would it be correct to say to do Client-Side validation after focus is lost and server-side once the save button is pressed? – SGR May 9 '17 at 12:35
  • 2
    @SGR Yes, it is. – Frantisek Kossuth May 9 '17 at 12:59
  • 11
    I like validation on losing focus, but only if user actually entered anything. I find it annoying when I switch away from empty form and suddenly every field is marked as "invalid". – el.pescado May 9 '17 at 20:06
  • 2
    @Matthew - Although I agree that approach is ideal, I've found it to cause many bugs with coworkers who don't hook each asynchronous call into the form submission. This results in behavior like: "user enters zip code -> asynchronous validation call is made -> user clicks submit and moves to the next page because the zip code validation isn't finished". Hooking each async call into the submit isn't something I've seen frameworks tackle, so if you're on a team with less confident developers - I just wouldn't bother. – aaaaaa May 9 '17 at 23:54
4

Validation should be done per input field:

  • when the user has finished entering his answer: when the field is focused out or after a specific timeout that you consider the user finished typing (as suggested here)
  • while on focus, the entered information does not validate and extra characters won't make the validation proceed: for example, the user enters an invalid character that won't make the field pass validation
|improve this answer
4

Edit:

For critical forms such as Login, Online transactions, providing any type of information it is necessary to use server validations over https that will execute when users hit the Submit button.

For field level validations such as email, tel, number we can take advantage of client-side validations but with fallback for browsers that have disabled JavaScript;

Native client-side validations take place when the condition is met / as the user types.

Looking at the new values in type attribute <input type="email" />,

and the best implemented in almost all browsers Pattern attribute <input type="tel" pattern="^\d{4}-\d{3}-\d{4}$" >

We are experiencing form validations as the user types / conditions are met [ HTML5 client-side form validations ]. The program/code doesn't send a request to server to validate the information, browsers are taking care of it.

Examples:

enter image description here

enter image description here

enter image description here

|improve this answer
  • 6
    You should note that - for web contexts - using client-side validation is not sufficient from a security point of view. All content should be validated on the server side as well to make sure its not possible to forge requests (circumventing browser-side validation is trivial). This is sometimes overlooked when using client-side validation and can lead to major security flaws and data inconsistency. Especially the bolded part of your answer could be misinterpreted. – Polygnome May 9 '17 at 14:35
3

The user should be informed about an error as early as possible, in all types of forms (wizards, long forms, etc).

If it is possible to give error feedback while the user types, then do it. This will allow the user to fix his error more efficiently, because the cursor and his mind is located on the subject of the error.

I must stress the difference between informing the user about an error and stopping the user. The user may be informed about an error while he types, but he will not be stopped until the form is submitted or the field is out of focus. When to stop the user, depends from the severity of the error, the use case of the form, the type of the form and many other factors.

First of all though, you should try to prevent errors , i.e. by using list boxes.

|improve this answer
  • Wondering if it is a personal preference that I don't want to be given an error when still typing my data. – Dimitra Miha May 9 '17 at 10:01
  • @DimitraMiha, I agree that I do not like syntax and grammar errors in a word processor while I type, because they break your flow of thoughts, but free text writting in a word processor and form filling are completely different use cases. So imagine you have a "user name" validation that you must not use capitals. It will be annoying for the user to find this after he types the user name and leaves the field. – DesignerAnalyst May 9 '17 at 10:32
  • 9
    I'm with you, @DimitraMiha. I hate getting a "Bad Email Address" error while I'm still typing it. "Hold your horses! I haven't gotten to the @ yet!" – Ken Mohnkern May 9 '17 at 14:54
  • 4
    It seems to me that as a general rule, getting an error midway through would be helpful if the page can determine that what the user's typed so far cannot possibly lead to a result it can accept. So in @DesignerAnalyst's example, you should get an error straight away, since nothing else you type (other than backspace) will result in a valid username, but for an email address, you shouldn't get an alert for a missing @ until focus leaves the box. – rand337 May 9 '17 at 16:50
  • 3
    @rand337 That pretty much sums up my take on it perfectly. "Incompleteness" should be assessed only after the user has completed their input. "Incorrectness" should be assessed immediately. – heathenJesus May 9 '17 at 23:41
2

Provide feedback while you still have their focus

This is a delicate balance, as the answers here indicate. Informing the user after they've completed the whole form (as some apps/sites still do) interrupts the flow.

Avoid breaking their concentration

You'll create less frustration and reduce cognitive load if you follow a "just-in-time" principal of informing progressively throughout the form. This is usually referred to as in-line validation.

You want to inform them:

  • While the field is still in focus
  • After they think they have something meaningful entered
  • Before focus is shifted the next thing

Guess and test

The catch with just-in-time information is that you can't be entirely certain when the user is done typing/thinking.

Too early and you break their concentration on the field in question.
Too late and they're already onto the next one. Focus broken again.

Make an educated guess about the focus + typing + pause delay and then test it in action. Test with a prototype and continue watching your metrics (form abandonment, entry error) in production. Fine tune when you reach the happy middle ground.

|improve this answer
0

Ouch. At first, I was convinced of one option. But thinking more carefully the answer, in my opinion, is Depends, and all 3.

1. Depends on the input field

a. As user types

There are different types of inputs, and some inputs need different validation.

  • A password could be validated as the user types. If your site does not accept for example simple passwords like "123" that could be validated on the fly. You see this in "password straight" evaluators.

  • Choosing a username could be also validated on the fly as user types.

  • Typing a phone number with non-numeric characters, like letters, slashes or spaces could display a warning when detecting one.

b. When user leaves the field

This should mark some possible typing errors, for example, a not valid email, a name with only one letter or an invalid postal code.

c. Send or Next Step

Here is a bit obvious that a "Send or Next step" button should mark the empty required fields.

2. Aditional help

Some fields could have additional help like autocomplete when typing common things like places, county, probably States.

3. Validation warnings of different intensity

What I want to explore here is that some validations can be for example more subtle, for example, when typing an email the field could be a light gray color as the background, and when the email is valid (after having an @ and a final .something) change to white.

But when validating empty fields this same field can turn to a strong angry red.

4. Choose the right color scheme from start

I need to use a cell phone provider's page constantly to add some cash to my phone.

But the "modern cool sleek" color scheme they have makes a check box for an "I accept terms and conditions" almost totally invisible. I assure you, that I would mark it if I could see it from start.

|improve this answer

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.