Optional and Required Fields - Page 2

It's common practice to mark required fields with an asterisk, and add a key at the top of the page, "* Required Field." This is good usability.

If you have a field that is required, but the reason won't be obvious to the user, then it's worth adding an explanation. For example, many users don't know why they need to give an e-mail address in order to complete a shopping transaction. You could say, "in case we need to contact you about this order," or "required as a credit card security measure."

If you have too many fields that are required for unknown reasons, you may lose your customer's trust. Do you really need their fax number? Are you ever going to use it?

Don't Collect Useless Information

Fax numbers are a prime example. If you're not sure if the information you're collecting is useful, one approach is to run a use-of-information audit perhaps six months after your form goes live on the Web. Find out if anybody in your company has used the information that's been collected. If they haven't, stop collecting it. Excess information has a cost, especially in terms of user perceptions.

Splitting Forms

Most e-commerce forms run to several pages, each dedicated to a particular task. One for product ordering, one for personal details, one for shipping and one for credit card details.

The advantages are:

1. The user isn't presented with a single, intimidatingly long form.
2. The pages can be individually validated, which helps error handling.
3. Details can be automatically pasted from early pages into later ones.

The main disadvantage is that the user may forget something they entered in an early page and use the Back button to refer to it, so ruining the sequence and causing all kinds of complications.

If there is a chance that the user will need information filled in on a previous page, add it to the current page. We've already mentioned addresses. A user with multiple addresses might easily forget which one they originally used. Shipping charges are another danger area. If you say, "50% reduction for five items or more," and the customer can't remember whether they ordered four items or five, they'll go back and you've instantly got a usability failure. If shipping charges vary according to the products ordered, you need to repeat the order information on the shipping page.

Validation

This is the automated process of checking that fields have been filled in correctly. For example, if you ask for an e-mail address and the answer doesn't contain the @ symbol, you know it's wrong.

Your system can spot this for you when it reads the data returned by the form. Some sites use JavaScript for validation at the client (browser) end. This may be OK for simple stuff but it's generally inferior to checking at the server end, where you can perform more complicated tasks and compare entries with database information.

Over-zealous validation is a common problem, especially among companies that try to sell internationally but don't have an international perspective. If you have a field for zip/postcode, and set the validation for a typical US five digit entry, you'll lose any UK or Canadian customer with a seven digit code. They won't be able to enter the code that matches their credit card details.

The issue of 'State' can also cause difficulty with non-US addresses. Millions of Internet shoppers in London, UK, have learned to enter

City: London
State: London

in US e-commerce forms, because London doesn't have a state and is effectively its own county. But it's confusing and poor usability. Dropdown boxes can cause even greater problems, which we'll come to in a moment.

Phone numbers are another validation area with plenty of pitfalls. They're probably best left unvalidated, unless you're keen to exclude international users who have helpfully used the international format +44 (0) 207… and so fail your numbers- only validation test, or even more helpfully write into the field, "No phone. I'm deaf." Ooops!

Usability and HTML Forms
Error Messages - Page 3