Do Your Web Forms Show Good Form?, Part 3

Now that you know how to optimize your Web forms when things go right, let’s discuss handling errors when things go wrong.

I asked our CTO, John Quarto-vonTivadar, who’s the author of several techie books, to explain things in plain English for us marketers. I asked him to provide insight in such a way you could print this out for developers and tell them this is what you want.

Error handling involves not just the visitor but also the Web site’s response to the visitor’s input. Developers are often tasked with writing code to handle errors. Many times, their instructions are little more than “go write some code” to process such errors. They’re not given guidelines as to precisely what should happen. Without that information, the result is often error-handling done the techie way: concise, accurate, minimal, and thoroughly unintelligible to the average visitor.

You’ve seen this before: You submit a form and get an ugly, unrelated screen that says you’ve made an error. No additional information is provided. Perhaps you actually made two errors. Once you correct the first one, the error message comes back. The Web site wasn’t capable of providing information on all errors at once. It wants to handle them one by one, and gosh darn if it isn’t going to force you to handle them one by one, too.

What Error Handling Is Required?

Error handling falls into two categories: error handling for requirements and error handling for type or format validation.

The first category deals with required information, whatever the company determined must be completed on a form, such as the address field in a pamphlet request form. You can’t send a pamphlet if the customer doesn’t provide a mailing address, right?

The second category deals with ensuring information provided is of the right type. The mailing address field has an address in it, not a phone number.

When designing Web forms, you must determine not only the required information, but also the format of all collected information, required or not. Perhaps a visitor’s phone number is optional. But if she does provide one, your site should be able to determine it is, in fact, a phone number.

Google handles this issue well. Complete only a few required form fields to register to buy AdWords, click “Submit” at the form’s bottom, and watch how the form returns to you. It indicates which fields you must complete and retains already-entered information so you don’t have to type it again.

Developers tend to bring their binary experience with technology to their handling of Web form errors. They fall into two camps: One favors client-side form error handling; the other likes server-side form error handling. In other words, should the Web form itself contain code that checks required fields and data format before it’s submitted or after?

This may seem like six of one, a half dozen of the other to you, but techies passionately argue over which approach is “better.” Client-side validation is perceived as faster (a euphemism for “the Web acts more like a familiar desktop GUI application”), but it’s typically implemented in JavaScript. JavaScript is highly dependent on the visitor’s browser, browser version, and computer platform.

Server-side validation allows great control over the algorithms that operate on the data and bypasses the browser-compatibility issue. But it does require a round trip to the Web server and holds off on error messages until after the user hits “submit.”

Developers often miss the point: What’s right is whatever satisfies the visitor’s needs and creates the tiniest possible speed bump to successful form submission with accurate, intentional data. Developers should use both techniques to better serve business needs, even at the expense of increased complication for themselves when maintaining code.

First, provide a base level of client-side error handling. It’s a very effective way to deal with required fields and validation routines. Use one of many cross-platform compatible standard libraries for JavaScript form validation, such as qForms, and provide redundant error handling on the server side. This way, no matter what version of what browser a visitor has, you can help provide the information.

Presenting Error Messages

Web sites should strive to present error messages to visitors in a way that makes absolutely clear what must be corrected. A good example is Banana Republic. Follow the “Access Your Info” link on the bottom of the page, and submit an improperly formatted email address. The form returns with red text to tell you what the error is and how to fix it.

It’s helpful to have error page copy written to imply the error is in no way the visitor’s fault (even when it is!). Go ahead and blame the Web server: “We’re sorry, our server wasn’t able to understand your Zip Code.” Believe me, you won’t hurt the server’s feelings.

When performing format validation, don’t make users jump through hoops to use a format you prefer but they may not, especially if you can extract the desired format from the provided data. The telephone validation field is one example, such as on Nordstrom.com. The form requires you to enter a phone number with no spaces, dashes, periods, or parentheses.

Why? I am the human. The computer running the site is here to serve my needs. It should accept my phone number is any of the several common formats. A skilled developer can certainly write code to handle such situations and still determine if the data provided is a telephone number or my pet’s name. Other sites manage this with ease, such as AOL. Follow the “try AOL today” link on the right. As you enter a phone number on the signup form, it’s automatically formatted for you.

Finally, bear in mind this strange but true irony: Customers who do experience problems that are handled well by a company often rank their experience with that company higher than customers who don’t encounter any problems at all!

Make the necessary changes. They’ll maximize your return on investment (ROI) and conversion.