Source-and-Target Interactions

A well-designed object will visually hint at its pliancy, either statically, in the way it is drawn or actively, by animating as the cursor passes over it.

The idea that an object can be dragged is easily learned idiomatically. It is difficult for a user to forget that an icon, selected text, or other distinct object can be directly manipulated after he has been shown that it can. He may forget the details of the action (so other feedback forms are very important after the user clicks on the object), but the fact of direct-manipulation pliancy itself is easy to remember. The first-timer or very infrequent user will probably require some additional help. This help will come either through additional training or by advice built right into the interface. In general, a program with a forgiving interaction encourages users to try direct manipulation on various objects in the program.

As soon as the user clicks the mouse button over an object, that object becomes the source object for the duration of the drag-and-drop. On the other hand, there is no corresponding target object because the mouse-up point hasn't yet been determined: It could be on another object or in the open space between objects. However, as the user moves the mouse around with the button held down, the cursor may pass over a variety of objects inside or outside the source object's program. If these objects are drag-and-drop compliant, they are possible targets, called drop candidates.

There can only be one source and one target in a drag, but there may be many drop candidates. Depending on the drag-and-drop protocol, the drop candidate may not know how to accept the particular dropped value; it just has to know how to accept the offered drop protocol. Other protocols may require that the drop candidate recognize immediately whether it can do anything useful with the offered source object. The latter method is slower but offers much better feedback to the user. If the protocol requires extensive conversing between the source object and each drop candidate, however, the interaction can become very sluggish, at which point it may not be worth the trouble.

Visual feedback while dragging

The only task of each drop candidate is to visually indicate that the hotspot of the captive cursor is over it, meaning that it will accept the drop—or at least comprehend it—if the user releases the mouse button. Such an indication is, by its nature, active visual hinting.

DESIGN TIP 

Drop candidates must visually indicate their receptivity.

The weakest way to offer the visual indication of receptivity to being dropped upon is by changing the cursor. It is the job of the cursor to represent what is being dragged. It is best to leave all indications of drop candidacy to the drop candidate itself.

DESIGN TIP 

The drag cursor must visually indicate the source object.

It is important that these two visual functions not be confused. Unfortunately, Microsoft seems to have done so in Windows. This decision was likely made more for the ease of coding than for any design considerations. It is much easier to change the cursor than it is to have drop candidates highlight to show their drop receptivity. The role of the cursor is to represent the master, the dragged object. It should not be used to represent the drop candidate.

As if that weren't bad enough, Microsoft performs cursor hinting using the detestable circle with a bar sinister, the universal icon for Not Permitted.

This symbol is an unpleasant idiom because it tells users what they can't do. It is negative feedback. A user can easily construe its meaning to be, "Don't let go of the mouse now, or you'll do some irreversible damage," instead of "Go ahead and let go now and nothing will happen." Adding the Not Permitted symbol to cursor hinting is an unfortunate combination of two weak idioms and should be avoided, regardless of what the Microsoft style guide says.

After the user finally releases the mouse button, the current drop candidate becomes the target. If the user releases the mouse button in the interstice between valid drop candidates, or over an invalid drop candidate, there is no target and the drag-and-drop operation ends with no action. Silence, or visual inactivity, is a good way to indicate this termination. It isn't a cancellation, exactly, so there is no need to show a cancel stamp.

INDICATING DRAG PLIANCY

Active cursor hinting to indicate drag pliancy is a problematic solution. In an increasingly object-oriented world, more things can be dragged than not. A cursor flicking and changing rapidly can be more visual distraction than help. One solution is to just assume that things can be dragged and let the user experiment. This method is reasonably successful in the Windows Explorer and Macintosh Finder windows. Without cursor hinting, drag pliancy can be a hard-to-discover idiom, so you might consider building some other indication into the interface, maybe a textual hint or a ToolTip-style pop-up.

After the source object is picked up and the drag operation begins, there must be some visual indication of this. The most visually rich method is to fully animate the drag operation, showing the entire source object moving in real-time. This method is hard to implement, can be annoyingly slow, and very probably isn't the proper solution. The problem is that a master-and-target operation requires a pretty precise pointer. For example, the source object may be six-centimeters square, but it must be dropped on a target that is one-centimeter square. The source object must not obscure the target and, because the source object is big enough to span multiple drop candidates, we need to use a cursor hotspot to precisely indicate which candidate it will be dropped on. What this means is that, in master-and-target, dragging a transparent outline of the object may be much better than actually dragging a fully animated, exact image of the source object. It also means that the dragged object can't obscure the normal arrow cursor. The tip of the arrow is needed to indicate the exact hotspot.

Dragging an outline also is appropriate for most repositioning, as the outline can be moved relative to the source object, still visible in its original position.

INDICATING DROP CANDIDACY

As the cursor traverses the screen, carrying with it an outline of the source object, it passes over one drop candidate after another. These drop candidates must visually indicate that they are aware of being considered as potential drop targets. By visually changing, the drop candidate alerts the user that it can do something constructive with the dropped object.

A point, so obvious that it is difficult to see, is that the only objects that can be drop candidates are ones that are currently visible. A running application doesn't have to worry about visually indicating its readiness to be a target if it isn't visible. Usually, the number of objects occupying screen real estate is very small—a couple of dozen at most. This means that the implementation burden should not be overwhelming.

Internally, the source object should be communicating with each drop candidate as it passes over it. A brief conversation should occur, where the source asks the target whether it can accept a drop. If it can, the target indicates it with visual hinting. The target also needs to know when the cursor leaves its airspace, so it can turn off the hinting.

Microsoft not only doesn't insist on drop candidate visual hinting, it suggests that changing the cursor is sufficient. This decision is unfortunate for users. It is difficult to understand what is being dragged, what the target is, and whether the target can make sense of the drop. At least on the desktop, Windows icons now correctly indicate their drop candidacy by visually highlighting. Is this a shallow imitation of the Macintosh Finder specific only to the Windows desktop, or a system-wide standard for how source-and-target drag-and-drop should work? We hope it is the latter.

Completing the drag-and-drop operation

When the source object is finally dropped on a drop candidate, the candidate becomes a bona-fide target. At this point, the source and target must engage in a more detailed conversation than the brief one that occurred between the source and all the other drop candidates. After all, the user has committed, and we now know the target. The target may know how to accept the drop, but that does not necessarily mean that it can swallow the particular source object dropped in this specific operation.

The implication of this more-detailed conversation is that the transfer may fail. That is okay. It is better to show drop receptivity and fail on the actual drop than it is not to indicate receptivity if there is any likelihood of it succeeding. (If minimum common format standards are adhered to, there will never be a physical failure.) If the drag-and-drop is negotiated, the format of the transfer remains to be resolved. If information is transferred, the source and target may wish to negotiate whether the transfer will be in some proprietary format known to both or whether the data will have to reduced in resolution to some weaker but more common format, like ASCII text.

Insertion targets

As the user drags a source object around the screen, each drop candidate visually changes as it is pointed to, which indicates its capability to accept the drop. In some programs, the source object can instead be dropped in the spaces between other objects. Dragging text in Word is such an operation, as are most reordering operations in lists or arrays.

The vital visual feedback of drag-and-drop is showing where the source object will fall if the user releases the mouse button. In source-and-target, the drop candidate becomes visually highlighted to indicate the potential drop, but in this kind of reordering drag-and-drop, the potential drop will be in some space where there is no object at all. The visual hinting is drawn on the background of the program or in its contiguous data: an insertion target.

Rearranging slides in PowerPoint's slide-sorter view is a good example of this type of (interior) drag-and-drop. The user can pick up a slide and drag it into a different presentation order. As you drag, the insertion target (a vertical black bar that looks like a big text edit caret) appears between slides. Word, too, shows an insertion target when you drag text. Not only is the loaded cursor apparent, but you also see a vertical gray bar showing the precise location, in between characters, where the dropped text will land.

Whenever something can be dragged-and-dropped on the space between other objects, the program must show an insertion target. Like a drop candidate in source-and-target drag-and-drop, the program must visually indicate where the dragged object can be dropped.

Visual feedback at completion

If the target and the source can agree, the appropriate operation then takes place. A vital step at this point is visual feedback that the operation has occurred. If the operation is a transfer, the source object must disappear from its source and reappear in the target. If the target represents a function rather than a container (such as a print icon), the icon must visually hint that it received the drop and is now printing. It can do this with animation or by otherwise changing its visual state.

A richly visual source-and-target drag-and-drop operation is one of the most powerful operations in the GUI designer's bag of tricks. If tool vendors better support this idiom, it will grow in popularity with application developers. Users will be the beneficiaries.