Generally, we don't like filling in forms - we associate bad things with them, such as paying taxes! The design of a form might determine whether it's used or not. If a form is difficult to understand and use, or if it's overcomplicated, some users will simply avoid it. Printed forms can be daunting at the best of times, but electronic forms can be even more daunting. As you will see in this chapter, it pays to spend a little time thinking about the form before you start creating it, and when you do start coding it, there are lots of good practices you can employ to make it more usable.

In this chapter, we'll look at design issues about the forms you create. The topics covered range from how to make a form easy to use, to how to make a form accessible to users with disabilities. We'll approach the topic in a chronological order through design, creation, and testing to see how we can make our forms easy to understand and accessible to as many people as possible .

To illustrate some of our examples, we will be looking at some of the pages from our ongoing-running example, Pizza This, which you will find discussed in far more detail in Chapters 4 and 5.

Before You Design the Form

Before you start designing a form, you should be clear in your mind what the aim of the form is and what you need to find out from the user. There are some useful questions you can ask yourself to help clarify the issues. Having answered these questions, you'll save yourself time in the actual design of the form.

What Is the Form's Purpose?

Here you should be thinking of the general task that you want to perform. For example, is it a search form to allow users to search for something on your site? Is it an order form, allowing users to purchase something online? Is it a test, where users will be marked on their answers? Is it an application for some service? And so on... In our case, it's an online order form for delivery or collection of pizzas.

As we'll see, you may actually end up with more than one form in the finished product, but understanding the aim of the form(s) that you're designing gives focus to the other questions that we'll meet in this section.

What Information Do You Need To Collect?

Exactly what information do you need from the user? This should be a complete list of the information that the user will be required to offer. You might start with a general list that includes things like addresses. Then, for each item from that list, you would go into the detail of what information makes up these requirements, such as house number, street name, suburb, and postcode in the case of addresses. For example, we need to know the following:

• Which pizzas a user wants.
• Whether they want the order delivered or ready to collect.
• What their name is.
• What their address and phone number are..
• If they want side orders.

We can split this down further, to give the exact information we need:

• Pizza: type, size, quantity, extra toppings.
• Whether they will collect the pizza or want it delivered.
• When they want the pizza.
• Name: first name, last name.
• Address: street, suburb, postcode, additional information for delivery.
• Phone number: area code, phone number.
• What side orders they want, in what quantities.

It's worth remembering that there are often two aspects to information collecting.

First there is the information that you want from a user to get the job done. You can be quite strict on this; for example, do you really need a home phone number, a work phone number, and a mobile phone number? Are you ever going to use that fax number if you ask for it?

Then comes the question of what information you want to capture from your user for the purposes of research and marketing. (As we'll see later in the chapter, you also have to be aware of data protection issues, as most countries have laws governing the collection, storage, and use of customers' data.) When it comes to the second question, it's often tempting to get as much information about the user as possible.

However, the longer a form is, the less likely the user is to complete it, and indeed there are some answers that users don't like to divulge (such as income or details of possessions). Unless there's a reason for the user giving the data, you should not assume that they'll be happy to give it out. And unless you're sure that you're going to use some data in your research, you should not collect it. If you present a user with a form that requests non-essential data, then the user may be tempted to get the service or product you offer from an alternative source, where it takes less time to fill out the form.

Asking questions that don't relate to the task that the user is trying to accomplish by filling out the form will frustrate users.

If you really must collect data that's non-essential to the task in hand, though, consider offering users an incentive to give it, such as entering them in a prize draw or providing them with privileged information. Or, for example, our pizza company could offer free toppings or a second pizza free in return for answering extra questions. The questions that are non-essential should be at the end of the form and clearly marked as optional (you should be very clear about which data is optional and which is mandatory when you come to designing the form).

Does Some of This Information Fall into Logical Groups?

If there are groups of like information, put them together. In our case, we might group information like so:

• Delivery/collection + when they want the pizza
• Name + address + phone number
• Pizza details + side order details

Grouping information will help the user to understand which section of the form they are completing.

Is There a 'Real-Life' Equivalent of the Form That Users Will Have Previous Experience of?

If you're creating an online application form, are there printed versions that the user will have used? If you're creating a web application, is there a software equivalent that the user may have used? Is there a standard way of representing the information that you're collecting that the user will have had experience with?

If the answer to any of these questions is yes, then you should make the form relate to their previous experience. This will help the user to understand the new technology quicker.

For example, you could be creating an online purchasing application, which could relate to the purchase order form that the user previously had to fill in on paper. If you're creating a web-based e-mail application, its design and use could reflect the package that the user is familiar with. If you're collecting address information, ask for it in the same way in which a user would write out the address.

What Information Will You Be Storing in a Database?

Certain information you will only require your users to divulge once. For example, you might only require that they provide their delivery details once. You should decide which items of information you're going to require each time a user visits the site and which you'll be able to retrieve from a database - given some kind of user authentication.

If you are considering storing credit card details then you should check with local legislation, as many countries impose restrictions on how long you can store such information for. You may also need to be aware of data protection laws regarding divulging information about customers.

If you are going to store information about users, then it's a good idea to have a page that explains what you do with data and how it's stored in layman's terms, in order to address customer concerns. The link to this need not be prominent – you can put a link to it by the first form control that indicates that user data is stored, then it may just appear in the footer of remaining pages.

If your forms are being processed manually, as opposed to by a script that populates a database, you can be a lot more forgiving about how a user enters the data in the form.

Is There Any Other Information That You Have To Provide On the Form?

You should also consider what other information should appear on the form. This could include legal notices, summary details of a shopping cart, or timers for a test. What you might have to add depends on the topic of the form.

Before You Design the Form - Summary

• Make sure you know what information you need from a user, and group it together.
• Only ask for data that you really need.
• Be clear which information is required and which is optional.
• Look for real-world equivalents of the form that the user will be familiar with.
• Make sure you comply with local legislation for storage of data if you intend to keep it in a database.