Designing the default UX

At the end of this research, my conclusion is the following:

Nobody knows what they’re doing, humanity is doomed and our only hope is the colonization of Mars.

Ok, it’s not that bad. But, we still have some serious problems:

• There is no consensus on the default validation handling
• Differences between the sites are huge, we can’t expect users to be familiar with any of the presented approaches
• A lot of solutions are bug ridden, which is a good indicator of how hard it is to implement a good inline validation

Let’s recap the questions stated before the research:

• When should the field be marked as dirty?
• When should the errors be shown?
• When should the field be validated?

If we can find the right answers to these questions, we can assure that the validation UX will be at least good. Validation UX is determined by the timeliness of the reaction, so let’s define the correct timing for each of those cases.

When should the field be marked as dirty?

In the research, you could see both approaches:

• mark field as dirty as soon as the user focuses the field
• mark field as dirty after the user entered some data in it

Facebook and JotForm mark the field as dirty immediately after you focus them. In my opinion that feels janky and aggressive. It felt much better when the field was marked as dirty after I had interacted with it. And I’m not counting focusing of the field as an interaction.

Also, when the user clicks the “Submit” button, all fields in the form should be considered dirty, and should be immediately validated.

When should the errors be shown?

This is another question where the research hasn’t given any clear answers. We’ve seen all of the possible combinations:

• errors that are always shown
• errors that are only shown when the user is interacting with the field
• errors that are not shown only when the user is interacting with the field

None of these feel like the best answer, but my vote goes to the errors that are always shown. They do add some visual noise, and might feel redundant, but at least we can avoid the confusion where errors are disappearing on (seemingly) random occasions.

When should the field be validated?

To reiterate, we can validate the field either during the data entry or after the data entry.

In my opinion both of these approaches have timing issues.

Forms that perform the validation during the data entry punish the users as soon as they start entering the data. It is most apparent with the email fields. On the other hand, forms that perform validation after the data entry are not informing the user that they fixed the error soon enough.

For the default behavior I propose a hybrid — reward early, punish late — approach:

• If the user is entering the data in the field that was in a valid state, perform the validation after the data entry
• If the user is entering the data in the field that was in an invalid state, perform the validation during the data entry

Combining these two approaches feels like a pretty good compromise. Remember, we are looking for the best default behavior possible, different forms will have different needs, so make sure to adjust the approach as needed.

Notice how this implementation is not suffering from the email confirmation bug present in the Facebook registration form.

The implementation

If you are using ClojureScript, you should try out the Keechma Forms library because it definitely has you covered. That’s what I used to build the example (check out the code).

I don’t know of any other validation libraries that support this kind of customization (if you do, please send me the link to include it here), so I’ll just write down how to implement it:

• The validation library must keep track of the dirty fields.
• If the field was in a valid state, perform the validation on the blur event
• If the field was in an invalid state, perform the validation when the field value is changed (using the combination of onchange, onblur and onkeypress events)
• When the field goes from the invalid to valid state, treat it like a valid field

You should also make sure that the validation functions can check the current data of the whole form. For instance, email confirmation validation should be able to check what’s the current value of both the email and email confirmation fields. This way you can avoid bugs like in the Facebook registration form.

In my opinion (and implementation) the validation should not be defined on the input components. Validations should be always performed on the data, never on the fields itself.

Conclusion

I thought that the live validation is a solved problem, but after doing this analysis, it seems that every team has a different approach. I’m also pretty sure that most of these sites (they are some of the biggest sites in the world, after all) are doing extensive A/B testing on their forms, which left me pretty confused about the best approach.

In the end I’m pretty satisfied with the defaults, and I hope you found this article useful. Please let me know if you have any feedback, I’m very interested in your thoughts about this topic.