Designing the Form
Having captured some key information about the form, we’re ready to start designing it. We’ll approach the topics in this section in the order in which you might like to consider implementing them.
We’ll assume that you’re designing a single form (or set of forms), disregarding locale. For international sites, you may decide to design different forms for different locations. This may cater for different representations of information such as addresses, different languages for the users (and therefore potentially different character sets as well), different currencies if you’re dealing with money, and so on.
Before we start, however, we should make a quick note about something that crops up throughout the chapter: accessibility.
When designing your form , you need to take into account accessibility issues. Accessibility is important to understand when designing any web site, and forms are no exception. In this section, we’ll be noting some important things to remember about accessibility. If you’re not familiar with the topic, pick up a copy of Constructing Accessible Web Sites (Jim Thatcher et al, glasshaus, ISBN 1904151-00-0).
The aim of making a site accessible is that it should be available to the largest number of users possible. It’s not just a case of making sure that users with disabilities can use the site, as is often thought; it can include considering those with older software or hardware and those who don’t view images in their browser. Many of the issues we’ll look at, however, do concern building a site that can be accessed by visitors with disabilities.
There are various sets of guidelines relating to accessibility. These include:
- The Web Accessibility Initiative’s Web Content Accessibility Guidelines, Version 1.0, May 5, 1999,
- The Access Board – Electronic and Information Technology Accessibility Standards, 36 CFR Part 1194, Web- based Intranet and Internet Information and Applications (1194.22),
- The IBM Web Accessibility Guidelines, Version 3.0, August 20, 2001,
The second of these corresponds to Section 508 of the US Rehabilitation Act. In 2000, the United States government legislated that all federally purchased technology products had to meet these guidelines from 25 June 2001. Other countries are quickly following suit in enforcing similar legislation.
We’ll be addressing some of the concerns that you should be aware of when designing forms to ensure that they are accessible.
Selecting Types of Controls
We met the different types of form control that are available to form designers in Chapter 1. It’s important to pick the right control for the information you’re trying to collect. Having already determined the information that you need to collect with the form, you can select the type of control that you’ll use for each item. Once you’ve done this, you’ll have an idea of the length and size of the form you’re constructing.
If you want to allow the user to enter text:
- and it’s only a single line of text, use an <input> element whose type attribute has the value of text.
- and you want the user to enter multiple lines of text, use a <textarea> element.
If you want to limit the choices the user can make:
- so they can select one from several options, use radio buttons, a select box, a drop-down menu, or a button.
- so they can select multiple items from a set of options, use checkboxes or a multiple select box.
Remember to give your controls names that correspond to the information that you’re collecting from the user – for example, txtFirstName for an input box where the user enters their first name – as this will make development and maintenance of the site easier than using names such as input1, input2, and so on.
It’s helpful to use a prefix for the name of the control that indicates what kind of form control the data relates to, such as:
- txtControlName for textboxes and text areas
- radControlName for radio buttons
- chkControlName for checkboxes
- selControlName for select boxes and list-boxes
In creating your form, you should consider the way in which a user would normally expect to give data and try to take advantage of those expectations. A lot of this experience might come from printed forms and, to a lesser extent, other computer-based forms (perhaps if you are translating a software application to a web application).
If your form differs from the user’s experience, they are more likely to make a mistake that they’ll have to correct, or they may just fill out the form incorrectly. A common example that has been demonstrated by Jakob Nielsen ( ) is the use of address fields. When asking the user to enter their address, you should expect them to give the lines of an address as they would when writing a letter or filling in a printed form, perhaps using four or five input boxes. As Nielsen demonstrated, if you try to provide a drop-down menu for the type of road that the user lives in – say offering the options of road, close, street, avenue, and so on – then the user will often have to go back and delete this from the first address line, as they are so used to giving it there.
In fact, drop-down menus, checkboxes, and radio buttons are common choices for designers who want to limit the selections that users can make. However, you have to decide whether this is a natural way for the user to provide data. As we just saw in the previous example, if the form is not designed to match the way in which the user expects to see the data every day, it will take them longer to fill out the form and can potentially introduce errors. While it might increase the server-side validation and/or processing involved, you should present the menu in a way that the user will understand.
Radio Buttons and Checkboxes
As a general rule of thumb, radio buttons and checkboxes will work better than drop-downs when there are few options present – say up to three or four items. With few options, you need not be concerned about the amount of screen real estate they take up, and you have the advantage that all options can be viewed at once. However, consistency does help usability – if you already have a set of drop-downs, then another one might be a better choice than inserting one set of three radio buttons among several select boxes.
Multiple checkboxes are also a better choice than select boxes that allow users to choose multiple items. Users often find multiple select boxes difficult to operate, and most users have to learn how to add more than one item. Checkboxes, on the other hand, are simpler to use and more likely to match their experience.
Note that you should not change the default intention of radio buttons or checkboxes. Do not make checkboxes mutually exclusive, and do not allow radio buttons to be used to select multiple options.
Radio buttons also make it easier to explain further information about a choice, compared with drop-down menus. A radio button with a description next to it is better than a very wide drop-down menu. For example, here the options can’t fit on the screen when you use a drop-down menu; the radio buttons below it are much more user-friendly (ch02_eg1.htm):
Remember that once you’ve selected a radio button, you can’t deselect it. If your radio buttons represent an optional question , allow the user a way of offering no answer after they have selected one – don’t lock them into that option. Also bear in mind that it can be useful to provide an ‘other’ option if the user is presented with a selection to choose from (in Chapter 7, we’ll see an example of activating a textbox when the user selects an ‘other’ option, so that the user can specify an alternative that you haven’t listed).
Don’t mix checkboxes and radio buttons up too much as this will confuse users.
The advantages of checkboxes over multiple select lists are similar to those of radio buttons over drop-down menus. Checkboxes are also ideal for Boolean selections where you assume that if the user does not check/uncheck the box they agree with your option (such as agreeing that you can mail them with further details). However, radio buttons are better than checkboxes when you want the user to select either yes or no explicitly, as they’re given two mutually exclusive options and it’s easier for them to see that a choice is required.
Drop-down Menus and Select Boxes
Drop-down menus save space on the screen when there are more than a few options. However, you shouldn’t make the options too long (the optimum length will depend on the layout of your form, but preferably no longer than around 30 characters, unless it’s guaranteed to fit on the screen). If the text goes off the screen – as in the previous screenshot – it becomes hard to navigate.
It’s worth noting that many users are not aware that they can select items from a drop-down list with arrow keys or using the first character of the item if alphabetically sorted. Therefore, they use a pointing device to select an item from a menu – which can require them to switch from the keyboard if the option is among text inputs.
You should be careful to include options for all users. For example, if you have a list of US states, do you need to provide an option for those not in the US?
Ordering of items in a menu should reflect a user’s experience . For example, if you’re using days of the week or months of the year, put them in chronological order. If there isn’t a typical way of relating this information, then alphabetical lists are often the best approach. If there are a few options that are a lot more common than others, you should consider putting those at the top so that users don’t have to scroll through a huge list of items; for example, many US sites put the US at the top of a list of countries.
If you have to present a lot of options, consider using hyperlinks or radio buttons instead. For example, here’s a long list of countries. The list contains over 240 options, which makes for a very long and hard to navigate drop-down. The preferable option is to use links – here, countries are linked to and grouped by the letter that they begin with (ch02_eg2.htm):
While drop-down menus help you get the data in the way that you want to receive it, you should make sure that it’s clear how users are supposed to enter the data. Remember that many users will prefer to enter text rather than use drop-downs , and careful use of the text input controls can be more straightforward than drop-downs. For example, which of the following is a more natural way to enter your date of birth (ch02_eg3.htm)?
While the first option using select boxes may introduce fewer errors, the second method is more likely to be familiar to users. Dates notoriously introduce problems, as Americans are more used to using the format MM/DD/YYYY while European users are more familiar with DD/MM/YYYY. Indeed, both groups also have a tendency just to enter two digits for the year.
You should also be careful when using context-dependent drop-down menus, where options change based on a selection already made by the user. While they can be helpful, users won’t tend to notice that the options change based on other events, and this can introduce errors. We look at context-dependent menus in Chapter 7.
Textboxes are often a more natural way for users to provide information – unless there is a clear and limited choice of options for them to choose from. We just saw a demonstration of this with the date of birth example. Users tend to prefer textboxes as long as they make sense.
Users often take the size of a textbox to be an indication of the length of answer you want them to give.
Following on from that, generally speaking, text areas should be large enough for users to enter what they need to without having scroll bars appear. The only exception to this is when the user has to enter large amounts of data, such as e-mails or articles.
The use of textboxes might require extra processing on the server, although it’s often worthwhile. You may, however, choose to provide users with options when the answer is easily mistyped or when you need to get data in a specific format.
An Aside on Reset Buttons
You should be particularly careful about your use of reset buttons. If you use one, it should be clearly differentiated and preferably positioned away from the submit button. If the user wants to change a detail, they can often do so by going back and changing the relevant control. Generally, reset buttons are unnecessary unless a user is likely to want to start completely over again on a form.
For example, you could use reset buttons on forms where the same user will have to use the form several times and where the data will be different each time they use the form.
Selecting Types of Controls – Summary
- Where possible , your choice of form control should reflect the experience of users in dealing with that type of information.
- Textboxes are often the most natural way for users to supply information, although it might be preferable to supply specific choices if you need to control the format of the data.
- If you only have three or four choices for the user to select from, use radio buttons or checkboxes over select boxes.
- Multiple checkboxes are better than select lists that allow users to select multiple items.
- Checkboxes are good for Boolean selections where you assume one option, although radio buttons are better for giving mutually exclusive options.
- Do not make items in select boxes too long (over approximately 30 characters wide). Radio buttons are more user-friendly than wide drop-down menus, so they’re useful if, for example, you want to provide explanatory text.
- Do not include too many items in your select box, so that it scrolls off the screen: use hyperlinks or radio buttons instead.