Blog

Is inline validation out?

The following is an excerpt from our brand new book, Designing UX: Forms.

Buy the book wherever great content is sold online, including Book Depository, Booktopia, Amazon and O’Reilly.

You can also receive the book as part of a SitePoint Premium membership.

What is inline validation

Forms should always be checked for errors every time a screen of questions is submitted (“server-side validation” in technical speak). In the last few years, however, some forms have included “inline validation”: answers are checked as soon as they’re provided (a particular kind of “client-side validation”, in which validation tasks are handled by the browser).

Figure 1: The user is halfway through this form, which has inline validation. The first answer has passed validation, but the second has failed.

Inline validation gives immediate feedback when there’s an issue, and often also when there’s not. For very short forms with few questions — such as the sign-up form in Figure 1 above — this is a good thing.

Inline validation issues

Being performed too soon

However, there are many implementation issues involved with inline validation, the most common being that the validation is performed too soon.

Figure 2: This user was still typing the email address when the inline validation error message came up

If you look closely at most web forms using inline validation, you’ll see they have this problem. Even Facebook wasn’t immune: the company removed inline validation from its sign-up form after initially including it.

Hard to validate everything inline

Another major problem is that it quickly gets very difficult to perform all validation inline. For instance, some answers may need to be checked against a large database stored on the server.

If you can’t validate all answers inline, you’ll have to include both inline and server-side validation in the one form. But this in turn leads to a most unpleasant experience, where a user passes the inline validation, and thinks all error checking has been done, only to receive yet more errors on submission. This might happen, for example, on a login form, where the username is judged by inline validation to contain acceptable characters, but then fails server-side validation because there’s no matching account.

May not be seen

A third issue is that many users are watching their keyboard when they type, not their screen, so inline validation might not be seen.

Breaks flow

As if all this weren’t enough, inline validation on longer forms interrupts the form-filling process and makes for a much worse user experience. This is because, with inline validation, 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.

Avoid inline validation in many cases

Given all these issues, we recommend against using inline validation. It certainly should only be considered if:

  • the form has a small number of questions (e.g. fewer than 10)
  • the vast majority of validation rules can be checked inline.

For instance, you may want to use inline validation on a very short account registration form (see figure below). In this situation, inline validation is a much faster way for users to go through the steps of:

  • picking a username and checking to see if it’s available
  • choosing a password and checking to see if it meets the site’s requirements.

Figure 3: Inline validation can work well on very short registration forms

If you do use inline validation:

Never rely solely on client-side validation

As you likely already know, you should never rely solely on client-side validation for anything important, like something that might break your database if submitted in the wrong format, or that might open the site up to malicious attacks via injected code. Client-side validation is very easy to defeat if someone has nefarious aims. Server-side validation should always be present to prevent the entry of any problematic data or code.