About Face 2.0(c) The Essentials of Interaction Design

In the previous two chapters, we discussed two important kinds of direct manipulation: selection and drag-and-drop. In this chapter, we'll discuss the remaining kinds: control manipulation, object manipulation, and object connection.

Control Manipulation

We can categorize the types of direct manipulation on controls by examining which mouse actions they require: clicking or clicking and dragging.

Beyond simple one-click controls, most direct-manipulation idioms demand a click-and-drag operation. This is a fundamental building block of visual interaction using a mouse, and we will explore it in some detail.

Click-and-drag

A drag begins when the user clicks the mouse button and then moves it without releasing the button. The set of cursor screen coordinates when the user first clicks the mouse button is called the mouse-down point and that when the user releases the button is called the mouse-up point. The mouse-down point is a known quantity throughout any direct manipulation operation. The mouse-up point only becomes known at the end of the process.

After a drag begins, the entire interaction between the user and the computer enters a special state. In programmer lingo, we say that all interaction between the system and the user is captured, meaning that no other program can interact with the user until the drag is completed.

Any actions the user might take with the mouse or keyboard or any other input device go directly to the program — technically, the window — in which the mouse button was first clicked (the one that received the mouse-down event). This window that owns the mouse-down point is the source object. If this source object is contiguous data or a control, the drag will indicate a selection extension or a control state change. However, if the source object is a discrete object, it more likely indicates the beginning of a direct-manipulation operation like drag-and-drop, and capture will play an important part.

Technically, a state of capture exists the instant the user clicks the mouse button, and it doesn't end until that mouse button is released, regardless of the distance the mouse moves between the two button actions. To the human, a simple click-and-release without motion seems instantaneous, but to the program, hundreds of thousands of instructions can be executed in the time it takes to click and release the button. If the user inadvertently moves the mouse before releasing the button, capture protects him from wildly triggering adjacent controls. The source object will simply reject such spurious commands.

Escaping from capture

One of the most important-yet most frequently ignored—parts of a drag operation is a mechanism for getting out of it. The user not only needs a way to abort the drag; if he does, he needs to have solid assurance that he did so successfully.

If the communication to the user that the drag action was canceled is clear, bold, and unambiguous, he will be reassured and confident in using the cancel idiom, whatever it may be. Most applications, though, have no means of drag cancellation whatsoever. This is a grave lapse in user interface terms because any good interface provides consistent and reliable ways out of a user's illstarred action.

At a minimum, the Escape key on the keyboard should always be recognized as a general-purpose cancel mechanism for any mouse operation, either clicking or dragging. If the user presses the Escape key while holding down the mouse button, the system should abandon the state of capture and return the system to the state it was in before the mouse button was clicked. When the user subsequently releases the mouse button, the program must remember to discard that mouse-up input before it has any side effect.

Because the meta-keys are often the only keys that have any meaning during drags, we could actually use any non-meta-keystroke to cancel a mouse stroke, rather than offering up only the Escape. However, some programs allow the use of the arrow keys in conjunction with the mouse (we'll discuss this in the next chapter), so there are some exceptions to work around.

One less-known idiom is the chord-click, where the user clicks left and right mouse buttons together. In Windows, a chord-click cancels a drag operation in many instances. Typically, the user begins a drag with the left mouse button, and then discovers that he doesn't really want to finish what he has begun. He clicks the right mouse button, then safely releases both. The idiom is insensitive to the timing or sequence of the release and works equally well if the drag was begun with the right mouse button.

Microsoft used chord-clicking for drag cancel in its Word for DOS software, but unfortunately discarded the idiom when it went to Windows. Admittedly, the idiom is for experts, but why hobble an interface for mouse experts simply to pander to mouse novices? At least the current version of Word recognizes the Escape key as a drag cancel.

Windows Explorer (and even the desktop) in XP supports Escape and chord-clicking as drag cancel idioms, but if you actually try to use the chord-click, a problem arises. The Windows designers have chosen to launch the context (right-click) pop-up menu on a mouse-up event, rather than on mouse-down. This means when you lift your finger off the right mouse button, you are confronted with an unwanted menu that you have to actively navigate away from and dismiss (with another mouse click). Yuck! There's a reason why menus should launch on mouse-down events!

Because Microsoft was so tentative in committing to the presence of a second mouse button, it is only fitting that it has been tentative about committing the chord-click to a cancel idiom. But now that Microsoft seems to have admitted that all its users will have at least two mouse buttons, adopting the chord-click as a universal cancel idiom would only make good sense (assuming it was done right!). Write your congressperson today.

If your program is well designed and enables the user to cancel out of a drag operation with an Escape key or a chord-click, the problem still remains of assuring the user that he is now safe. The cursor may have been changed to indicate that a drag was in progress, or an outline of the dragged object may have been moving with the cursor. The cancellation makes these visual hints go away, but the user may still wonder if he is truly safe. A user may have pressed the Escape key, but is still holding the mouse button down, unsure whether it is entirely safe to let go of it (or perhaps he has just chord-clicked, and is holding down two mouse buttons). The user should now be informed that the operation has been effectively canceled and that releasing the mouse button (or buttons) is okay. It can't hurt — and can only help — to make sure that he gets a reassuring message.

Of course, the user will get visual feedback that whatever object he was dragging is no longer being dragged because it will vanish from underneath the cursor or snap back to where it came from. This snap-back could be enhanced with a brief animation indicating the snap-back, rather like the original Macintosh animation that accompanied windows opening and closing. (This was such wonderful visual hinting; Windows should learn a lesson in general from this.)

Alternately, or perhaps in addition to this, you could imagine a brief message, rather like a ToolTip, appearing for a second or two in the vicinity of the cursor. One could also imagine that a little "snip" sound to indicate premature termination of the drag operation would help reinforce the idiom.

Pliant response

Let's return to the drag operation itself: Once the drag begins, the meaning of the user's actions varies depending on the type of drag action. The drag action depends on the program, the context, and the master object.

In the simplest case, involving contiguous data, dragging means, "extend the selection." The text or other data is selected contiguously from the mouse-down point to the mouse-up point.

If the mouse is clicked while the cursor is inside a control, the control must visually show that it is poised to undergo a state change. This action is important and is often neglected by those who create their own controls. It is a form of active visual hinting: pliant response.

A push-button needs to change from a visually raised state to a visually indented state; a check box should highlight its box but not show a check just yet. Pliant response is an important feedback mechanism for any control that either invokes an action or changes its state, letting the user know that some action is forthcoming if she releases the mouse button. The pliant response is also an important part of the cancel mechanism. When the user clicks down on a button, that button responds by indenting. If the user moves the mouse away from that button while still holding the button down, the button should return to its quiescent, raised state. If the user then releases the mouse, the button will not be activated (consistent with the lack of pliant response).