Optional and Required Fields - Page 2
December 10, 2001
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:
- The user isn't presented with a single, intimidatingly long form.
- The pages can be individually validated, which helps error handling.
- 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
|
eBook library