7.1. THE BASICS OF FORM DESIGN First, a few principles to remember when doing input and form design:
Make sure the user understands what's asked for, and why. -
This is entirely context-dependent, and any generalizations here risk sounding vapid, but let's try anyway. You should write labels with words that your target users understandplain language for novice or occasional users, and carefully chosen argon or specialized vocabulary for domain experts. If you design a long or tedious form, take some space to explain why you need all the information you're asking for. If you're putting a control on a toolbar (or somewhere else equally space-constrained), and its use isn't immediately obvious, use a descriptive tooltip or other type of context-sensitive help to tell the user what it does.
If you can, avoid asking the question at all. -
Asking the user to answer a question, especially if it comes in the middle of some other task, is a bit of an imposition. You might ask him to break his train of thought and deal with something he hadn't expected to think about. Even in the best of cases, typing into text fields isn't most people's idea of a fun time. Can you "prefill" an input control with already-known or guessable information, as the Autocompletion pattern recommends? Can you offer a reasonable default value that removes the burdens of choice from 80 percent of your users? Can you avoid asking for it altogether? There's one glaring exception to this principle: security. Sometimes we use input controls in a challenge/response context, such as asking for passwords or credit card numbers. You obviously don't want to circumvent these security mechanisms by casually prefilling sensitive information.
Knowledge "in the world" often is more accurate than knowledge "in the head." -
You can't expect human beings to recall lists of things perfectly. If you ask users to make a choice from a prescribed set of items, try to make that list available to them so they can read over it. (A common exception might be "state or province," often needed for shipping addresses. Obviously, most people can remember the ones they need.) Dropdowns, combo boxes, lists, and other such controls put all the choices out there for the user to review. And when these items have visual renderings, such as images, layouts, and colors, you can use the Illustrated Choices pattern to show them. Similarly, if you ask for input that needs to be formatted in a specific way, like dates or credit card numbers, you might want to offer the user clues about how to format it. Even if the user has used your UI before, he may not remember what's requireda gentle reminder may be welcome. Good Defaults, Structured Format, and Input Hints all serve this purpose. Autocompletion goes a step further by telling the user what input is valid, or by reminding the user what he entered some previous time.
Beware of a literal translation from the underlying programming model. -
Many forms are built to edit database records, or to edit objects in an object-oriented programming language. Given a data structure like these to fill out, it's really easy to design a form to do it. Each structure element gets (1) a label and (2) a control (or a bundle of controls acting together). Put them in some rational order, lay them out top-to-bottom, and you're done. Right? Not entirely. This kind of implementation-driven form design does work, but it can give you a utilitarian and dull interfaceor a difficult one. What if the structure elements don't match up with the input the user expects to give, for instance? And what if the structure is, say, 30 elements long? For some contexts, like property sheets in a programming environment, it's appropriate to show everything the way it's implementedthat's part of the point. But for everything else, a more elegant and user-centered presentation is better. So here's the challenge: Can you exploit dependencies among the structure elements, familiar graphic constructs (like address labels), unstated assumptions, or knowledge of the user gained from previous interactions to make the form less onerous? Can you turn the problem into one handled by direct manipulation, like drag-and-dropping things around? Be creative!
Usability-test it. -
For some reason, when input forms are involved, it's particularly easy for designers and users to make radically different assumptions about terminology, possible answers, intrusiveness, and other context-of-use issues. This book has said it before, and will say it again: use usability testing, even if you're sure your design is good. This will give you empirical evidence of what works and what doesn't for your particular situation.
Your choice of controls will affect the user's expectation of what is asked for, so choose wisely. -
A radio box suggests a one-of-many choice, while a one-line text field suggests a short open-ended answer. Consciously or not, people will use the physical form of a controlits type, its size, etc.to figure out what's being asked for, and they'll set their expectations accordingly. If you use a text field to ask for a number, users may believe that any number is okay; if they enter "12" and you then surprise them with an error dialog box saying, "That number's got to be between 1 and 10," you've yanked the rug out from under them. A slider or spin box would have been better. The following section gives you a table of possible controls for different input types. You or the engineers you work with will need to decide the semantics of each question. Is it binary? A date or time? One-of-many? Many-of-many? Open-ended but requiring validation? Look it up here, then choose a control based on your particular design constraints.
|
