Design your way

Inline validation informs users whether what they type is valid as they type.

The theory is that it’s easier to fix errors as soon as they occur instead of waiting until submission.

The thing is, inline validation causes several problems:

1. Interruption causes friction

For fields that require a certain number of characters, the first keystroke will cause an error. Meaning users will be interrupted early and often.

We could wait until the user has entered enough characters but this means the only way a user will get feedback is after completing the field successfully which is pointless.

2. Interruption on blur is too late

We could provide feedback when the user leaves the field (onblur) but this is too late. The user has already started to mentally prepare for, and to fill out the next field.

Many people switch windows or use password managers to assist in filling out forms. Leaving the field (which triggers the blur event) causes an error to show prematurely before the user finishes typing.

And tabbing to the next field causes an error in the first. Due to this error, the user leaves the second field to fix the error in the first. This causes an error in two fields. This sucks.

3. Visual glitches are disorientating

When a field switches between valid and invalid states, the error appears and disappears respectively. This causes the page to judder which is disorientating and can cause problems for mouse users.

Ideally error messages should be hidden as the user starts to fix the field — either onfocus or onkeypress. However, this exacerbates the problem.

4. Field groups are inconsistent

Groups of fields need to be considered holistically. Take a group of checkboxes, for example.

The user must choose at least two options. If the user clicks yellow and blurs is that an error?

Or the date field below. As the user leaves the day box, the field is instantly invalid. You could validate when the last box is blurred but what if, for example, someone leaves the first box empty, and then tabs onto month?

Designing something that relies on the user doing something in the right order is not ideal. We could validate these fields onsubmit but that gives users a false positive as they have grown to expect fields to validate inline.

5. Server side validation makes for an inconsistent experience

Some validation routines can only be performed on the server via submission. For example, checking someone’s login credentials. This inconsistency in behaviour is confusing.

6. False positives are untrustworthy

Some implementations use inline validation to show green ticks when the user fills out a field successfully. This may provide a sense of progression and stop people feeling like they need to check through their answers later on.

However, inline validation typically checks the format. This means that a correctly formatted field may still be erroneous once it’s submitted. This makes the experience untrustworthy and unpleasant.

7. Pre-populated fields are tricky

Pre-populated fields cause further issue. Should we display them in the success state, if there is one? If they appear to have been validated already, should we then hide the success message until they have left the field again?

8. Validation inconsistency

Some fields can be validated as the user types. For example, if typing a letter in a numerical field. But this causes inconsistency and is rarely applicable to the slew of fields requiring various different validation routines.

9. Users might not notice it

Many users look at the keyboard as opposed to their screen when typing. In this case users won’t see the error until later or at all.

10. It breaks the user’s flow

In Is Inline Validation Out?, Jessica Enders says users have to repeatedly switch between two quite different mental modes: form filling and error correcting. This slows the user down, increases cognitive effort, and generally reduces user satisfaction.

11. Marking success is confusing

Luke Wroblewski’s testing showed that users weren’t sure how to interpret a green tick. He says the participants knew we had no way to know their correct name, so they knew that the green check mark didn’t mean “correct.” But they weren’t sure and that was the problem.

12. Problems for screen reader users

When someone is using a screen reader they may want to go through the form fields to get a feel for what is coming before attempting to fill each field out. This could cause errors in all fields before the user even started their journey.

Summary

Inline validation causes many problems and forces users to switch between filling in forms and fixing them.

Designers like inline validation because it avoids users seeing lots of errors after filling a long form. Assuming this is a true we can:

• remove unnecessary fields
• ensure fields are well-understood with clear guidance
• ensure error messages are presented well
• use One Thing Per Page
• use Errors-only approach

In any case, designing the perfect inline validation experience is nigh on impossible. Any potential benefit is outweighed by the problems it introduces. Instead put the user in control by showing errors on submit.

This is something I cover in my upcoming book Form Design Patterns. If you enjoyed this sign up to my newsletter and I’ll let you know once it’s released.

The post Inline validation is problematic appeared first on Design your way.

Source: http://ift.tt/2faPWTs