Validation and Usability – Don’t tell me what to type!

I had in interesting and rather involved conversation with a colleague yesterday who is involved in the development of a complex web application. In particular we disagreed about one of the input fields. This field contains a code which can contain both alpha and numeric characters. The rub? All the alpha characters have to be uppercase. The system as it stands currently updates each character as it is typed using JavaScript…

This is the whole reason I got involved, the JavaScript wasn’t working according to plan. So I immediately got to thinking; why does this for of transform have to be applied after every single character is entered? Why not simply run the transform on the whole field once the cursor has moved on? A simple onLoseFocus event handler will do the trick…

But thinking even further into it; why bother transforming at all? Sure, as my colleague pointed out, the code entered has to be only uppercase and by transforming it in front of the user you will eventually coerce them into entering the code correctly… which is a crock of shite.

The application is going to be used for data entry and, as anyone who’s ever had to do this for a living will know*, the key to a good data entry app is speed. If you are forcing the user to enter a code in uppercase the you are forcing them to use the shift key – not speedy. This got me thinking, how many other websites / apps have validation and correction scripts that are utterly unnecessary? In this case the transform could be applied server-side and the user would be free to enter the code in upper / lower or mixed case. Since the case of the code only matters to the processing agent – the server – why involve the user in this process at all?

Since then I have been noticing loads of instances where validation actually fails to help the user. I have even been responsible for a few myself. For example I recently wrote a validation script for a simple contact form. In his instance it would only allow numbers to be entered in the phone number field… which isn’t necessarily helpful as many number have hyphens, parentheses or other visual aids included. So why was I bothering to test for the presence of these characters? Well because the system couldn’t handle them… so why ask the user to remove them for me? I mean I’ the guy with string manipulation tools at my finger tips. The server (or even the client) could probably remove these chars in a fraction of the time it would take the user to read the validation message and change the numbers.

So I have a new mini campaign – I will ensure that every site I design involves the user in the validation process only as a last resort. Sure it may mean more work on my part but the benefits should be well worth it. After all, as any system designer will tell you, it’s the little things that matter!


*and yes I have – one whole summer of my life working for BT moving account details from one database to another! Joy…

4 thoughts on “Validation and Usability – Don’t tell me what to type!

  1. I had to go the other way at my last job. I did a VB front end for an Access DB for the plant floor to enter data that needed to be tracked and periodically entered into our MAI BASIC4 (don’t laugh) system. The BASIC system wanted only caps so I converted case to all caps as the records were written. This confused people to an incredible degree. They entered a record in proper case or lower case and it came back ALL CAPS. I got two or three calls a day from the plant floor asking what was wrong with the system. I ended up validating each field “on lost focus” and converting to all caps right there. Since the users could see it happening they weren’t afraid of it any more.

  2. That’s a good point and one that I hadn’t intially considered. I suppose user paranoia has to be taken into account but thi could easily be assuaged by a decent training program or maybe even a context sensitive help box?

    One of the projects I’ve been working on is actually adding a training mode to a very complex web application. Normal users can turn it off but new users can enable it to recive all sorts of usefull info about the various components of the screen they are viewing. I would certainly think that this kind of system is infinitely more helpful than the old fashioned help file.

  3. Context sensitive help is the bomb. The old fashioned help file is gone the way of the dodo, may it rest in infernal peace. Though we actually still use them here. Ouch.

    Our product goes on mixed systems of PCs and dummy terminals. If you use the GUI interface you get context sentsitive help. If you use the CUI interface you get the big file of “helpful” info.

  4. Like the beer commercial says… Brilliant!

Leave a Reply

Fill in your details below or click an icon to log in:

WordPress.com Logo

You are commenting using your WordPress.com account. Log Out / Change )

Twitter picture

You are commenting using your Twitter account. Log Out / Change )

Facebook photo

You are commenting using your Facebook account. Log Out / Change )

Connecting to %s