The Three Models of Web Form Validation

By Robert Gravelle

http://www.htmlgoodies.com/tutorials/forms/the-three-models-of-web-form-validation.html (Back to article)

Have you ever tried to fill out a form that just wouldn't let you through? You might ask yourself what it is that you're doing wrong, but the problem isn't you, it's the form's designer. A badly designed form can really turn off users. What's worse, on commercial sites, annoying your customers can make them stop using your site altogether.

Making a good form is mainly a combination of two things: the user interface and the validation process. The former can encompass everything from flow, to colors, clear labeling, positioning, hints & tips, and much more. Some of these factors contribute to usability and accessibility, while others contribute directly to validation, by lessening the chances of your users making validation errors.

Hence, validation plays a dual role of not only protecting your data and site from bad data, whether by malicious or accidental entry, but also as a guide to your users' goal of submitting the form in as painless and quick a manner as possible.

Today's article will outline the different ways of validating form data and relaying validation error messages to the user. In doing so, we're going to see why it's time to consider preferable alternatives to the ole' one field at a time style of error handling such as displaying all the form errors at once and inline validation.

Why Validating One Field at a Time is Rarely the Optimal Choice

When you think about it for a moment, the idea of telling someone that one field is wrong every time they hit the Submit button has the makings of a pretty good punk'd style prank. Imagine the frustration building as error after error comes back. It's enough to make you wonder where the heck did this idea come from. The answer is quite simple really; the truth is that it's a whole lot simpler to code it that way! If you have to run all of the fields through a set of validation rules, then you have to store them in a array and find a way to present them in a helpful format. There was a time, not so long ago, when dynamic content wasn't suitable for all browsers. As such, the alert box was the best way to show errors, and that's not a great way to display numerous error messages. In fact, there are a few really good reasons to avoid the use of alerts for displaying validation messages. Beyond the lack of formatting control, the user has to click the OK button and close the dialog to make any changes. They also make it impossible to link the message with the control that caused the error. Thus, alert dialog boxes tend to create a barrier to form completion. So from now on, remember:

Don't Use Alert Dialog Boxes for Validation Responses

While we're on the subject of what not to do,

Don't Use Error Pages for Validation Responses

Another outdated form validation practice is the use of error pages. This is where the form sends the information to a separate page to validate, and any errors that do exist get output to this page without the original form. This means the user must navigate back to the form where they may lose the information they previously entered, including the errors they need to correct! There is no need to do this anymore, so don't.

The New Tools of the Trade

Modern day tools such as Ajax, Dynamic HTML, CSS3, and HTML5 have ushered in a new era in Web forms. Not only do modern forms looks better than ever, but they offer several ways to validate user input. Input validation techniques fall into three categories:

• Server-side Validation
  With server-side validation, all form information entered by the user is sent to the server to be validated upon form submittal. In the event of a validation error, the original page is reloaded along with the error information. When combined with a one field at a time approach, this is the least user-friendly form of validation there is because the user must wait for the data to make a round trip to the server an back on each form submittal. On the positive side, it does bolster security, as server-side validation cannot be bypassed like client-side validation can. There is also the added benefit that the exact validation used is harder for a would-be-hacker to get at. So to sum up:

  Server-side Validation = Slow Response but Strong Security

• Client-side Validation
  Although HTML5 has begun to take over some of the common client-side validation duties, JavaScript is still the language of choice for client-side validation today. Unfortunately, as long as users can disable JavaScript in their browser, you cannot rely solely on JavaScript as a method of validation. Rather, client-side validation should be though of more as an extra layer on top of server-side validation. That means you've now got duplicate validation code.

  Client-side Validation = Fast Validation but Code Duplication

• Real-time Validation
  For one recent system that I worked on at Canada Border Services, we used real-time validation, where Ajax communicated field values to the server validation via the fields' onblur() events so that an error could be presented to the user right away or stored until the onsubmit(). One advantage to providing an instant response to a user action is that it saves them from having to fill out the entire form and pressing submit; the user gets an instant response as they are typing so that they can make immediate corrections if necessary. This also gets rid of the duplication issue.

  We used real-time validation with great success to create a password strength indicator where each key stroke triggered the validation to indicate to the user how strong their chosen password compared to our rather strict ruleset. That saved countless round trips to the server.

  Real-time Validation = Greatest Flexibility but Speed is somewhat Dependent on the Network

Conclusion

The take away from today's article is that not every approach works across the board. The size of the form, what kind of network the web page will reside on, who are your end-users, what are their most important requirements, sensitivity of data and validation routines must all be taken under consideration. In an upcoming article, we will learn ways to make your validation messages more helpful to your users as well as how to implement generic and hence reusable real-time validation.