Imperative Controls

In the interaction between humans and computers, there is a language of nouns (sometimes called objects), verbs, adjectives, and adverbs. When we issue a command, we are specifying the verb — the action of the statement. When we describe what the action will affect, we are specifying the noun of the sentence. Sometimes we choose a noun from an existing list, and sometimes we enter a new one. We can modify both the noun and the verb with adjectives and adverbs, respectively.

The control type that corresponds to a verb is called the imperative control because it commands immediate action. Imperative controls take action, and they take it immediately. Menu items, which we will discuss in Chapters 27 and 28, are also imperative idioms. In the world of controls, the quintessential imperative idiom is the push-button; in fact, it is the only one, although it comes in numerous guises. Click the button and the associated action — the verb — executes immediately.

Push-buttons

Push-buttons are most often identified by their simulated-3D raised aspect. If the control is rectangular (or sometimes oval) and appears raised (due to its shadow on the right and bottom and highlight on the top and left), it has the visual affordance of an imperative. It will execute as soon as the user clicks and releases it with the mouse cursor. In dialogs, a default button is often highlighted to indicate the most reasonable typical action for a user to take.

The push-button is arguably the most visually compelling control in the designer's toolkit. It isn't surprising that it has evolved with such diversity across the user interface. The manipulation affordances of contemporary faux three-dimensional push-buttons have prompted their widespread use. It's a good thing — so why not use it a lot? Designers of hyperlinks on the Web have even borrowed the look of the push-button, though often at the cost of pliant feedback.

Part of the affordance of a push-button is its visual pliancy, which indicates its "pressability." When the user points to it and clicks the mouse button, the push-button on screen visually changes from raised to indented, indicating that it is activated. This is an example of dynamic visual hinting, as discussed in Part V. Poorly-designed programs and many Web sites contain buttons that are painted on the screen but don't actually move when clicked. This is cheap and easy for the developer to do (especially on the Web), but it is very disconcerting for the user, because it generates a mental question: "Did that actually do something?" The user expects to see the button move — the pliant response — and you must satisfy his expectations.

This is important in Web pages and multimedia applications, many of which, for reasons both artistic and technological, eschew the desktop rules of pliancy but still set aside portions of their display that are sensitive to clicking.

Cursor hinting isn't enough in these cases, although it's a desirable supplement. Even if the entire screen is consumed by a collage of, say, baseball collectibles, when the user clicks on a Louisville Slugger to perform some function, that bat should move to visually confirm to the user that it is an imperative push-button — or, in this case, a push-bat!

Butcons

Concurrent with the release of Windows 3.0 came the introduction of the toolbar (which we discuss at length in Chapter 29), an idiom that has grown into a de facto standard as familiar as the menu bar. To populate the toolbar, the push-button was adapted from its traditional home on the dialog box. On its way, it expanded significantly in function, role, and visual aspect.

On dialog boxes, the push-button is rectangular (with rounded edges on the Mac) and exclusively labeled with text. When it moved to the toolbar, it became square, lost its text, and acquired a pictograph, an iconic legend. Thus was born the butcon: half button, half icon. In Windows 98, the butcon, or toolbar button, continued to develop, losing its raised affordance except when used — a move to reduce visual clutter in response to the overcrowding of toolbars. Unfortunately, this makes it more difficult for newcomers to understand the idiom; the toolbar butcon in Windows 2000 now reveals its button affordance only when pointed at. Windows XP has continued the evolution of the butcon away from its "button-ness." Office XP application butcons have a rather confusing visual hint in which the icon lifts from the surface of the toolbar on a little square platform. The authors wonder why Microsoft couldn't leave well enough alone and continue to visually associate butcons strongly with their function as buttons.

Butcons are, in theory, easy to use: They are always visible and don't demand as much time or dexterity as a drop-down menu does. Because they are constantly visible, they are easy to memorize, particularly in sovereign applications. The advantages of the butcon are hard to separate from the advantages of the toolbar — the two are inextricably linked. The consistently annoying problem with the butcon derives not from its button part, but from its icon part. We instantly decipher the visual affordance — it screams, "click me!" (or did, in any case, before Windows 98). The problem is that the image on the face of the butcon is seldom that clear.

Icons, in general, are hard to decipher with certainty, and icons of verbs are much harder to decipher than icons of nouns. Because butcons are imperative controls, their icons represent verbs, and thus remain problematic. It isn't really a matter of coming up with better visual metaphors or finding a better graphic artist. The problem is that actions and relationships are difficult, if not impossible, to portray in the limited visual resolution of an icon. If you can find an appropriate icon, it may have good mnemonic qualities, but will usually be inadequate to teach newcomers its purpose.

The dilemma arises because images do have such good mnemonic qualities. These qualities are good enough that the visual image is more than enough to remind the daily user of the command represented by the butcon. The visual butcon is very space-efficient compared to the older, text-legend button. As long as there is a way to learn it initially, and it is part of the user's working set of commands, he will remember the image as an idiom and have no problem with the lack of innate learnability. Thus, to be successful, the butcon's image must be visually distinct from other butcons and memorable as an idiom.

Without any mechanism for explaining their purpose, however, butcons and toolbars would be significantly less useful than they are. The rapid spread of butcons on toolbars initially caused widespread grumbling about incomprehensible icons for just this reason. In response, some companies enlarged their butcons until they were big enough to hold text legends in addition to icons. Yet others required users to choose which commands would be displayed as butcons, adding another annoying layer of excise to the interface. But Microsoft's ToolTips neatly solved the inscrutable butcon problem once and for all. ToolTips provide initial learning without getting in the way of the frequent user. The grumbling over inscrutable butcons has since subsided to inaudibility due to ToolTips, a testament to the efficacy of the idiom.

We'll speak more about butcons, toolbars, and ToolTips in Chapter 29.