QA Hates You

As some of you know, I am quite the proponent of client-side validation for Web applications and Web sites. The main reasons are speed and load.

A Web application that expects a pile of use could better be served if its pages are smart enough to capture common problems without sending a server request and making your poor, creaking Web server figure out what’s wrong. Basic stuff that client-side logic, generally through JavaScript, can determine includes making sure the user enters required data, enters information in accepted patterns for the expected data (zip codes, e-mail addresses, and so on) and date validation. That way, when your Web server is hammered by a blog linking to your site, you can rest assured your confusing interface will not necessarily bring down your site.

On the other hand, there’s the speed issue. When users click Submit and send off that form data to your Web site, they’ll have to wait again for your wizbang media-rich page to load again or worse, wait for two pages to load if you use separates page for the error message and the form. So what, your cool Web designers and infrastructure people say. Well, friends, I personally have used dial-up AOL in the not too distant past, and I know how slow normal pages are to load. Even if you’re not dealing with customers on dial-up AOL at 33k, according to these numbers, 17% of users don’t have broadband. Granted, your tech team and designers are perfectly willing to sacrifice the impatient amongst those slowpokes, but your clients or business users probably wouldn’t like to hear that 10,000 of your 100,000 visitors are abandoning forms because they’re slow and frustrating.

So there are two compelling reasons to use the client-side validation, and they’re small potatoes compared to the developers’ counter-arguments (”It’s too hard” or “It’s too expensive” or “If the user has JavaScript disabled, it won’t work!”). Good reasons versus poor practices, and you’ll be lucky if you win using logic.

Now, as a best practice, your organization should actually use both client-side and server-side data validation for the optimal data protection. This will handle any flaws or browser incompatibility in your client-side data validation.

What would a QAHatesYou.com post be without pointing out how a Web form has not handled it very well? Ask, and ye shall receive!

Newegg.com ran a Guitar Hero III sweepstakes that didn’t follow these best practices.

For example, client side validation is in place for the Birthday field:

Click for full size We’ll ignore the extraneous space in the validation message because…. Well, no, we won’t ignore it. Shame, shame!The application confirms the presence of values in the birthday, but not the validity. Notice we’ve moved on to checking that the user has entered a phone number:

Click for full size The application is perfectly happy to let the bad birthday, February 30, into the database. Even the server-side validation doesn’t catch it.However, these two fields are the only ones with client-side validation on them; other things are caught in the server-side validation:

Click for full size Not only does this lead to a page separate from the form to display the missing fields, but it also capitalizes the I in verify/verification. Development IDE quirk, no doubt. But do you see the other problem here?That’s right; the application is validating on the default instructional text (Enter Email Address, Enter City, and so on). The application should validate to make sure that the user has entered something other than what the designers populated in the edit boxes by default. However, it’s unsophisticated and a touch shoddy.

So to make a short story long and to give you a set of bullet points you can cut and paste into your best practices document:

• Always include client side validation on Web forms/applications to make them faster for users and to remove common data problems from the server load.
• Use client-side validation to ensure that user has entered information in all required fields.
• Use client-side validation to ensure that user-entered data matches known patterns for valid data, including Zip codes, dates, and other structured bits of data.
• Check to make sure user has changed any default instructional text prepopulated in controls.
• Make sure that validation messages are grammatically correct and spelled correctly.
• Make sure validation works consistently among browsers.

The Web will be a better place for it.

This entry was posted on Monday, November 12th, 2007 at 3:07 pm by The Director and is filed under Philosophy, Failed Web sites. You can follow any responses to this entry through the RSS 2.0 feed. You can leave a response, or trackback from your own site.