Object Connection

A direct-manipulation idiom that can be very powerful in some applications is connection, in which the user clicks and drags from one object to another, but instead of dragging the first object onto the second, a connecting line or arrow is drawn from the first object to the second one.

If you use project management or organization chart programs, you are undoubtedly familiar with this idiom. For example, to connect one task box in a project manager's network diagram (often called a PERT chart) with another, you click and drag an arrow between them. In this case the direction of the connection is significant: The task where the mouse button went down is the from task and the task where the mouse button is released is the to task.

As a connection is dragged between objects, it provides visual feedback in the form of rubber-banding: The arrow forms a line that extends from the exact mouse-down point to the current cursor position. The line is animated, following the movement of the cursor with one end, while remaining anchored at the mouse-down point with its other end.

After the user releases the mouse button, the mouse-up point is known and the program can decide whether it was within a valid target location. If so, the program draws a more permanent line or arrow between the two objects. In some applications, it also links the objects logically.

As the user drags the end of the arrow around the screen, input is captured and the rules of dragging for discrete data apply.

The left button can't normally trigger the connection function because it would collide with selection and repositioning. In some programs, the right button triggers it, but Windows makes that problematic with its usurpation of the right click for the context menu. A better solution might be to provide either a dedicated connection area or handle from which to drag the connection, or to use a modal or cursor-charged tool from a palette, or a meta-key mapping (is Alt still unused?).

Connections can also be full-fledged objects themselves, with reshape handles and editable properties. This sort of implementation would mean connections could be independently selected, moved, and deleted as well. For programs where connections between objects need to contain information (such as in a project-planning application), it makes sense for connections to be first-class citizens.

Connection doesn't require as much cursor hinting as other idioms because the rubber-banding effect is so clearly visible. However, it would be a big help in programs where objects are connected logically, to show which currently pointed-to objects are valid targets for the arrow. In other words, if the user drags an arrow until it points to some icon or widget on the screen, how can he tell if that icon or widget can legally be connected to? The answer is to have the potential target object engage in some active visual hinting. This hinting for potential targets can be quite subtle, or even eschewed completely when all objects in the program are equally valid targets for any connection. Target objects should always highlight, however, when a connection is actually dragged over them, to indicate willingness to accept the connection.

Also indisputably vital is a convenient means of canceling the action. Chord-clicking and Escape still work for this idiom.