Filling The Blanks

Helps make the interface self-explanatory. After all, we all know how to finish a sentence. (A verb phrase or noun phrase will do the trick, too.) Seeing the input, or "blanks," in the context of a verbal description helps the user understand what's going on and what he's being asked to do.

Arrange one or more fields in the form of a prose sentence or phrase, with the fields as "blanks" to be filled in by the user.

You need to ask the user for input, usually one-line text, a number, or a choice from a dropdown list. You tried to write it out as a set of label/control pairs, but the labels' typical declarative style (such as "Name:" and "Address:") isn't clear enough for users to understand what's going on. You can, however, verbally describe the action to be taken once everything's filled out, in an active-voice sentence or phrase. Write the sentence or phrase using all your word crafting skills. Use controls in place of words.

If you're going to embed the controls in the middle of the phrase, instead of at the end, this pattern works best with text fields, dropdown lists, and combo boxes -- in other words, controls with the same form factor (width and height) as words in the sentence. Also, make sure the baseline of the sentence text lines up with the text baselines in the controls, or it'll look sloppy. Size the controls so that they are just long enough to contain the user's choices, and maintain word spacing between them and the surrounding words.

This is particularly useful for defining conditions, as one might do when searching for items or filtering them out of a display. The Excel example below (and the Photoshop example in the book) illustrates the point. Robert Reimann and Alan Cooper describe this pattern as an ideal way to handle queries; their term for it is "natural language output."

There's a big "gotch" in this pattern, however: it becomes very hard to properly localize the UI, since comprehension now depends upon word order in a natural language. For some international products or web sites, that's a non-starter. You may have to rearrange the UI to make it work in a different language; at the very least, work with a competent translator to make sure the UI can be localized.

General suggestions for writing test items or tasks

1.    Use table of specifications
2.    Write more items than needed
3.    Write items well in advance of testing date
4.    Write items so that they call for the performance described in the behavioral objectives
5.    Task to be performed is clearly specified
6.    Write item at appropriate reading/writing level (in sub-tests not measuring, reading, such as math, science, and social studies, test makers generally write items two years below grade placement to avoid testing reading ability)
7.    Item provides no clue to answer
8.    Answer is agreed upon by experts
9.    Recheck items when revised for relevance