Error Messages - Page 3

If your system picks up a problem on validation, you need to send an error message back to the user and give them another chance to fill in the form correctly.

Two big no-no's here. Never return the form to the user without a full explanation of what's wrong, and, when it's returned, don't clear form entries that were perfectly valid. If everybody could abide by these two rules, the world would be a happier place. Unfortunately, they're often broken.

If you have extensive validation you will need to put a lot of thought into your error messages. You should finish up with dozens of them for different circumstances. If you have only a handful, it's a sign that you're not getting into enough detail. There's a fine opportunity here to score points with your customer by saving them time and explaining exactly why they're an idiot, rather than just telling them they're an idiot and letting them work out the reason themselves.

Which brings us to tone. Customers often complain that error messages are too curt, forceful, or downright insulting. The usual reason is that they've been cobbled together by a programmer, while the company's customer relations expert sits four doors away doing something else (maybe struggling with a piece of software). Ideally, the same person who writes the company's grovelling apologies for major foul-ups should be brought in to edit programmers' attempts at error messages, which will rarely hit the right tone.

Now let's take a look at usability and individual form elements.

Checkboxes

Can't go wrong with these, as long as the question you're asking can only have a yes/no answer — which is why you don't see them that often. Few questions are that simple.

Checkboxes can be grouped together under a single HTML control name. That's fine, but don't mix this kind of list with mutually-exclusive radio button lists or your visitor may become confused.

Radio buttons are a series of mutually-exclusive on/offs sharing the same control name, and checkboxes can be single, or can be a series of on/offs of a non-exclusive nature, sharing the same control name. ( http://www.w3.org/TR/REC-html40/interact/forms.html#h-17.2.1).

Radio Buttons

A series of checkboxes with alternative answers to one question. Again, this is straightforward as long as all possible answers are covered. If you can't be sure, include an "other" option and look at the stats to see if it gets ticked.

Radio buttons are suitable for presenting two or three options. They can stretch to four and possibly five. There's a suitability overlap with dropdown boxes, which are also great for presenting a small numbers of options. Your choice of which to use may depend on context. If you've got a sequence of regular checkboxes, a few radio buttons would fit well with them, but if you have a series of dropdown boxes, you might as well use another dropdown box for a choice between a couple of options rather than changing over to radio buttons for a single field.

Consistency helps usability, and it may be worth staying consistent even if that means choosing a form element that isn't the one you'd normally choose for that kind of field.

One thing to watch out for is radio buttons in an optional section, shown without pre-selection. The classic trap is that once the user has selected an option they can't reverse out to show no selection. Instead, design the field with "no selection" or "not applicable" as a button and make it the pre-selected option.

Optional and Required Fields - Page 2
Usability and HTML Forms
Dropdown Boxes - Page 4