Drag and drop is the desktop’s cross-application data channel

What it is

Dragging an object from one window into another—a file from a folder into mail, a table into a slide, a swatch into a drawing—is a cross-application data channel, not an in-app reorder gesture. Drag and drop makes “this data, from this app, into that app” a visible spatial act. The clipboard does the same job without occupying space and without pointing at a destination.

This entry is only desktop treating drag and drop as a pipe between applications. How pickup, move, and drop are distinguished is a matter for the input primitive.

Why it happens

Desktop windows can be visible at once, source and target side by side. Spatial pointing replaces “copy, switch, paste”: the object follows the pointer, the destination is named at release. Hutchins, Hollan, and Norman take “an object moved through space” as a canonical case of direct manipulation. The cross-app case exists because the OS offers a shared drag pasteboard: the source puts one or several representations on it, the target decides whether to accept when the pointer enters. The channel is the system’s, not a private protocol of one app.

Without the channel, the advantage of side-by-side windows is only visual; data still detours through the clipboard or an exported file. People feel the two apps “don’t connect”—the windows touch, the object cannot cross. Mobile has no stable side-by-side windows, so cross-app drag, even when present, is not a primary channel. Desktop made it one, so an app that refuses to join (internal drag only, nothing out or in) is refusing the form factor.

Studying it

Cross-app drag studies set a task of “get this object into that application” and compare drag-and-drop, copy-paste, and export-then-open on time, errors, and judged directness. Field observation records when people choose drag and when they fall back to the clipboard (windows not side by side, target too small, crossing a display seam).

Independent variables: whether source and target are co-visible, data type, whether the drag crosses displays, channel (drag / clipboard / file). Dependent variables: completion time, drop-location errors, times the person switches channel mid-way, a judgment of “did the data go through.”

Pre-arranging both windows in the lab inflates the choice of drag; on a real desk the target is often covered, and people start with the clipboard.

Where it stops holding

Sandboxed browsers and store-distributed apps may be forbidden from receiving some drops; the channel is cut by permission, not by a forgotten implementation. Remote desktop and virtual machines cross two drag bridges, so failure is more common. A fullscreen-only app has no second visible window to point at. A touch-notebook in tablet posture often cannot place windows side by side, and the channel goes away for a while.

Applying it

• Join the system drag channel: objects that can be dragged publish onto the system pasteboard after the drag starts; regions that can receive react when the pointer enters.
• Do not call in-app reordering “supporting drag and drop.” Cover at least round-trips with folders, the browser, and mail—the system-level targets.
• Verify by dragging a file from a system folder into the app, then an object from the app into a folder or a mail draft. Both directions must go through. Cover the target window and try again: copy-paste should still finish the task. Drag is a primary channel, not the only one.

Related

• Within the group: K2.05.2 Drop targets must declare which data types they accept · K2.05.3 A failed drop must explain why
• Adjacent: K2.10 Clipboard and System Services · C1.08 Drag and Drop · J3.07 Drag Alternatives
• Search terms: inter-application drag and drop · desktop data transfer · drag pasteboard