Form Design Issues

only for RuBoard - do not distribute or recompile

The material in this chapter showed how to create the elements that make up a form. When you re designing a form-based application, you need to apply this knowledge in the context of the task you re trying to accomplish to determine how to present and process your form. Here are some general issues to consider when you re writing such an application:

What kind of information do you want to collect? What s the easiest way for the user to provide it? In theory, you could construct practically any form using nothing but text fields, because almost any kind of information can be gathered that way. If a field is allowed to have only a fixed number of legal values, however, it might be preferable to use a more highly structured multiple-choice element such as a pop-up menu. This makes it easier for users to select a value without typing it explicitly, and with no possibility of entering an incorrect value.

What are the default values? Do you want to display the form with default values filled in? If you do, you risk having users be lazy by assuming those values are good enough. Or do you want to display empty fields, possibly supplying default values for those fields that users leave empty?

What kind of input validation is necessary? Do some fields require a value? Do values have to be supplied in a particular format (such as a number, a two-character state abbreviation, or an email address)? Are you prepared to handle bad input? This can take the form of missing or mistaken values (in free text fields, for example), or deliberately malicious and malformed information designed as an attempt to hack your site. If the input turns out to be unsuitable, can you redisplay the form showing the values that were submitted, along with feedback indicating clearly what must be added or modified to make the form acceptable? (It s better not to say click the Back button if possible, because some browsers may not present the form properly under some circumstances. For example, a browser might erase a form entirely when you go back to it.)

How much display space is available? Some elements are functionally equivalent, but have different properties that make them suitable for different situations. Consider, for example, the tradeoff between convenience and amount of window real estate required for radio buttons, pop-up menus, and single-pick scrolling lists. Each of these presents a list of alternatives from which you select one item. If you have the space, radio buttons can be better because each option is visible in the browser window at all times. With a pop-up menu, you must click the menu to see the options. However, the amount of space a set of radio buttons takes is proportional to the number of items, so it s not a good choice when there are many items. In this case, a pop-up menu can be superior because it s more compact and takes a fixed amount of layout space regardless of the number of items. But even here, a pop-up menu may not be suitable if the number of options is so large that the menu can t fit on the screen. You run into the problem that the user must scroll the menu to see all the items. If scrolling will be necessary, it s better to use a navigational item designed for that purpose a scrolling list. The user can move up and down in the list easily without having it disappear when the pointer is moved out of the list or if the button is released. A list uses a little more space than a pop up, but you get to decide how much.

What kind of confirmation or feedback do you provide for successful submissions? Do you just thank the user? Reformat the form contents for display as a confirmation page? Send an email message as confirmation? Some combination of methods?

In Chapter 5 we ll develop several applications for which these issues come into play. We ll keep them in mind and explore various options. For example, we ll use a number of form-validation techniques and provide several kinds of form submission confirmation.

only for RuBoard - do not distribute or recompile