About Face 2.0(c) The Essentials of Interaction Design

When we are first exposed to the drag-and-drop idiom, it seems simple; but for frequent users and in some special conditions, it can exhibit problems and difficulties that are not so simple. As usual, the iterative refinement process of software design has exposed these shortcomings, and in the spirit of invention, clever designers have devised equally clever solutions.

Auto-scrolling

What interpretation should the program make when the selected object is dragged beyond the border of the enclosing application? The correct interpretation is, of course, that the object is being dragged to a new position. But is that new position inside or outside of the enclosing application?

Take Microsoft Word, for example. When a piece of selected text is dragged outside the visible text window, is the user saying "I want to put this piece of text into another program" or is he saying "I want to put this piece of text somewhere else in this same document, but that place is currently scrolled off the screen"? If the former, we proceed as already discussed. But if the user desires the latter, the application must automatically scroll (auto-scroll) in the direction of the drag to reposition the selection at a distant, not currently visible location in the same document.

Auto-scroll is a very important adjunct to drag-and-drop. Where you implement one, you will likely have to implement the other. Wherever the drop target can possibly be scrolled off-screen, the program needs to auto-scroll.

In early implementations, auto-scrolling worked if you dragged outside of the application's window. This had two fatal flaws. First, if the application filled the screen, how could you get the cursor outside of the app? Second, if you want to drag the object to another program, how can the app tell the difference between that and the desire to auto-scroll?

Microsoft developed an intelligent solution to this problem. Basically, it begins auto-scrolling just inside the application's border instead of just outside the border. As the drag cursor approaches the borders of the scrollable window—but is still inside it—a scroll in the direction of the drag is initiated. If the drag cursor comes within three or four millimeters of the bottom of the text area, Word begins to scroll the window's contents upward. If the drag cursor comes equally close to the top edge of the text area, Word scrolls down. Unfortunately, Word's implementation doesn't take into account the power of the microprocessor, and the action occurs too fast to be useful on the authors' computers (to be fair, some Microsoft products do implement auto-scrolling right). Besides compensating for processor speed, a better way to implement this same idiom would be to use a variable auto-scroll rate as shown in Figure 23-1, where the automatic scrolling increases in speed as the cursor gets closer to the window edge. For example, when the cursor is five millimeters from the upper edge, the text scrolls down at one line per second. At four millimeters, the text scrolls at two lines per second, and so on. This gives the user sufficient control over the auto-scroll to make it useful. The auto-scroll should always be constrained; computers are only getting faster.

Figure 23-1: Microsoft, unfortunately, auto-scrolls at whatever speed the computer is capable of, or at least far too fast for users to control. Not only should there be a maximum speed limit on auto-scroll, the movement should also be graduated and user-controllable. The auto-scroll should go faster the closer the user gets to the edge of the window. To its credit, Microsoft's idea of auto-scrolling as the cursor approaches the inside edges of the enclosing scrollbox, rather than the outside, is very clever indeed.

Another important detail required by auto-scrolling is a time delay. If auto-scrolling begins as soon as the cursor enters the sensitive zone around the edges, it is too easy for a slow-moving user to inadvertently auto-scroll. To cure this, auto-scrolling should only begin after the drag-cursor has been in the auto-scroll zone for some reasonable time cushion—about a half-second.

If the user drags the cursor completely outside of the Word's scrollable text window, no auto-scrolling occurs. Instead, the repositioning operation will terminate in a program other than Word. For example, if the drag cursor goes outside of Word and is positioned over PowerPoint, when the user releases the mouse button, the selection will be pasted into the PowerPoint slide at the position indicated by the mouse. Furthermore, if the drag cursor moves within three or four millimeters of any of the borders of the PowerPoint Edit window, PowerPoint begins auto-scrolling in the appropriate direction. This is a very convenient feature, as the confines of contemporary screens mean that we often find ourselves with a loaded drag cursor and no place to drop its contents.

Avoiding drag-and-drop twitchiness

When an object can be either selected or dragged, it is vital that the mouse be biased towards the selection operation. Because it is so difficult to click on something without inadvertently moving the cursor a pixel or two, the frequent act of selecting something must not accidentally cause the program to misinterpret the action as the beginning of a drag-and-drop operation. Users rarely want to drag an object only one or two pixels across the screen. The time it takes to perform a drag is usually much greater than the time it takes to perform a selection. Dragging is often accompanied by a redraw operation, causing objects on the screen to flicker (although this will cease as computers get faster). This unexpected visual paroxysm can be disturbing to users expecting a simple selection. In addition, the object is now displaced by a couple of pixels. The user probably had the object just where he wanted it, so having it displaced by even one pixel will not please him.

In the hardware world, controls like pushbuttons that have mechanical contacts can exhibit what engineers call bounce, which means that the tiny metal contacts of the switch literally bounce when someone presses them. For electrical circuits like doorbells, the milliseconds the bounce takes aren't meaningful, but in modern electronics, those extra clicks can be significant. The circuitry backing up such switches has special logic to ignore extra transitions if they occur within a few milliseconds of the first one. This keeps your stereo from turning back off a thousandth of a second after you've turned it on. This situation is analogous to the oversensitive mouse problem, and the solution is to copy switch makers and debounce the mouse.

To avoid this situation, programs should establish a drag threshold, in which all mouse-movement messages that arrive after the mouse-down event are ignored unless the movement exceeds a small threshold amount, such as three pixels. This provides some protection against initiating an inadvertent drag operation. If the user can keep the mouse button within three pixels of the mouse-down point, the entire click action is interpreted as a selection command, and all tiny, spurious moves are ignored. The object has been debounced. As soon as the mouse moves beyond the three-pixel threshold, the program can confidently change the operation to a drag. This is shown in Figure 23-2. Any time you have a situation where an object can be selected and dragged, the drag operation should be debounced.

Figure 23-2: Any object that can be both selected and dragged must be debounced. When the user clicks on the object, the action must be interpreted as a selection rather than a drag, even if the user accidentally moves the mouse a pixel or two between the click and the release. The program must ignore any mouse movement as long as it stays within the uncommitted zone, which extends three pixels in each direction. After the cursor moves more than three pixels away from the mouse-down coordinate, the action changes to a drag, and the object is considered "in play." This is called a drag threshold, and it is used to debounce the mouse.

The Program Manager in Windows 3.x had a one-pixel drag threshold, which was too small. It was far too easy to accidentally move an icon out of position when all you wanted to do was select it. Icons on the Windows XP desktop appear to have a three-pixel debounce threshold.

Some applications may require more-complex drag thresholds. 3D applications often require drag thresholds that enable movement in three projected axes on the screen. Another such example arose in the design of a report generator for one of our clients. The user could reposition columns on the report by dragging them horizontally; for example, he could put the Firstname column to the left of the Lastname column by dragging it into position from anywhere in the column. This was, by far, the most frequently used drag-and-drop idiom. There was, however, another, infrequently used drag operation. This one allowed the values in one column to be interspersed vertically with the values of another column—for example, an address field and a state field (see Figure 23-3).

Figure 23-3: This report-generator program offered an interesting feature that enabled the contents of one column to be interspersed with the contents of another by dragging and dropping it. This direct-manipulation action conflicted with the more-frequent drag-and-drop action of reordering the columns (like moving City to the left of Address). We used a special, two-axis drag threshold to accomplish this.

We wanted to follow the user's mental model and enable him to drag the values of one column on top of the values of another to perform this stacking operation, but this conflicted with the simple horizontal reordering of columns. We solved the problem by differentiating between horizontal drags and vertical drags. If the user dragged the column left or right, it meant that he was repositioning the column as a unit. If the user dragged the column up or down, it meant that he was interspersing the values of one column with the values of another.

Because the horizontal drag was the predominant user action and vertical drags were rare, we biased the drag threshold towards the horizontal axis. Instead of a square uncommitted zone, we created the spool-shaped zone shown in Figure 23-4. By setting the horizontal-motion threshold at four pixels, it didn't take a big movement to commit the user to the normal horizontal move, while still insulating the user from an inadvertent vertical move. To commit to the far less-frequent vertical move, the user had to move the cursor eight pixels on the vertical axis without deviating more than four pixels left or right. The motion is quite natural and easily learned.

Figure 23-4: This spool-shaped drag threshold allowed a bias toward horizontal dragging in a client's program. Horizontal dragging was, by far, the most frequently used type of drag in this application. This drag threshold made it difficult for the user to inadvertently begin a vertical drag. However, if the user really wanted to drag vertically, a bold move either up or down would cause the program to commit to the vertical mode with a minimum of excise. Before this method was instituted, a vertical move involved a semipermanent mode change by using a toolbar butcon.

This axially non-symmetric threshold can be used in other ways, too. Visio implements a similar idiom to differentiate between drawing a straight and a curved line.

Mouse vernier

The weakness of the mouse as a precision pointing tool is readily apparent, particularly when dragging objects around in drawing programs. It is darned hard to drag something to the exact desired spot, especially when the screen resolution is 100 or more pixels-per-inch and the mouse is running at a six-to-one ratio to the screen. To move the cursor one pixel, you must move the mouse precisely one six-hundredth of an inch. Not easy to do.

This is solved by adding a mouse vernier function, where the user can quickly shift into a mode that allows much finer-resolution for mouse-based manipulation of objects.

During a drag, if the user decides that he needs more precise maneuvering, he can change the ratio of the mouse's movement to the object's movement on the screen. Any program that might demand precise alignment must offer a vernier facility. This includes, at a minimum, all drawing and painting programs, presentation programs, and image-manipulation programs.

There are several acceptable variants of this idiom. A key can be pressed during the drag operation, like the Enter key, and the mouse shifts into vernier mode. In vernier mode, each ten pixels of mouse movement will be interpreted as a single pixel of object movement.

Another effective method is to make the arrow keys active during a drag operation. While holding down the mouse button, the user can manipulate the arrow keys to move the selection up, down, left, or right—one pixel at a time. The drag operation is still terminated by releasing the mouse button.

The problem with such a vernier is that the simple act of releasing the mouse button can often cause the user's hand to shift a pixel or two, causing the perfectly placed object to slip out of alignment just at the moment of acceptance. The solution to this is, upon receipt of the first vernier keystroke, to desensitize the mouse. This is accomplished by making the mouse ignore all subsequent movements under some reasonable threshold, say five pixels. This means that the user can make the initial gross movements with the mouse, then make a final, precise placement with the arrow keys, and release the mouse button without disturbing the placement. If the user wants to make additional gross movements after beginning the vernier, he simply moves the mouse beyond the threshold, and the system shifts back out of vernier mode.

If the arrow keys are not otherwise spoken for in the interface, as in a drawing program, they can be used to control vernier movement of the selected object. This means the user does not have to hold the mouse button down. Adobe Illustrator and Photoshop do this, as does PowerPoint. In PowerPoint, the arrow keys move the selected object one step on the grid—about two millimeters using the default grid settings. If you hold the Alt key down while using the arrow keys, the movement is one pixel per arrow keystroke. This is nicely done.