The Source-and-Target Paradigm

When the user clicks on a discrete object and drags it to another discrete object in order to perform a function, what goes on behind the scenes embodies the source-and-target paradigm.

The object within which the dragging originates controls the entire process: It is the source object, which will be a window. If you are dragging an icon, that icon is its own window. If you are dragging a paragraph of text, the enclosing editor is the window. When the user ultimately releases the mouse button, whatever was dragged is dropped on some target object.

The main purpose of the term source-and-target is to differentiate this operation from the kind of drag-and-drop operations we find in drawing and painting programs, where tools and graphical objects are dragged around on an open canvas. Source-and-target is an idiom in which manipulating logical objects represents some behind-the-scenes processing. The most familiar form of source-and-target drag-and-drop is moving icons from folder to folder in the Program Manager or in the Macintosh Finder.

Dragging data objects to target functions

Instead of dragging a file or folder to another folder, you can drag it to a control that represents a function. This idiom is arguably the most famous expression of direct manipulation because of the Macintosh's familiar trashcan. Windows copies this familiar idiom with its Recycle Bin. As we build software with better object-orientation, we'll be able to drag-and-drop objects onto icons or controls representing functions other than just Delete. Apple has already extended this idea to printers, and the authors have also seen file decompression programs implemented in this manner. There is a lot of room for innovation in exploring this idiom!

Notice that all the idioms in the previous paragraph involve exterior drag-and-drop, because the target objects are separate programs. Within a single program, the code knows what objects can be dragged—usually one type—and any control that it gets dropped on will easily handle it. In exterior drag-and-drop, the source object can come from any program, and the target control may not have any direct knowledge of the originating program or the dropped object. The target must be able to handle the unknown object in some reasonable way without necessarily understanding what it is or what is in it. A file folder, for example, can do this because it knows that it will be handed only files. What would it do if it were handed a paragraph of dragged text from a word processor, for example? If it can't handle the text, it isn't truly exterior capable. To Microsoft's credit, the Recycle Bin in Windows can actually accept paragraphs of text dragged from Word or cells dragged from Excel.

To be truly exterior capable, an object must be able to accept a drop of anything from any other object, regardless of the originating program. At first, this sounds like a dauntingly complex implementation problem, but it doesn't have to be. Mostly, it's a matter of defining interface standards. When data is dragged to an object, all the target object has to say is, "Yes, I can accept the drop" to the source object. The two objects then must negotiate over formats, because it is unreasonable to expect every object to accept data in every other program's proprietary formats. If the source object is Excel, say, it may initially offer the data in its internal format. Another Microsoft program may know how to decipher this format, but a Brand X product might not. So the Brand X target object politely demurs—not to the drop, but to the format of the drop's contents. Excel, the source, must then re-offer the data in successively more generic formats: SYLK, CSV, ASCII. The target object can turn up its nose at SYLK or CSV, but by convention, it must accept ASCII; ASCII is the lowest common denominator format on all platforms. Every exterior capable object must minimally accept ASCII, simple bitmaps, pointers to files, and as we'll see, functions. Objects that hope to become successful in the open market will accept many more formats than these, but these four guarantee compatibility with everything. Even an audio file, for example, can ultimately be passed as a simple pointer to a disk file. Exterior drag-and-drop protocols that support this type of haggling over formats are negotiated drag-and-drop protocols. Protocols that don't negotiate formats can only accept known formats and are thus called known-format drag-and-drop protocols.

Dragging function objects to target data

A proper, negotiated, exterior drag-and-drop capability includes dragging and dropping functions onto data as well as dragging and dropping data onto functions. Defining the scope of such actions could be problematic when working in contiguous data, and there again arises the issue of verb-object ordering and termination, but in the authors' opinion, it is an idiom worthy of more research.

For now, there is no standard exterior drag-and-drop protocol, although OLE and ActiveX purport to offer one. Certainly, there is no negotiated drag-and-drop protocol.