Drag and Drop to the Dock

My idea of triggering the single application Expose view by hovering a dragged item over the Dock works great (theoretically!) if an application already has a window or document (or two) open. What if you attempted to drag and drop an object onto an application that had no open windows? What about applications which are not open at all? The obvious solution is to create a new document containing the dragged object, assuming the application can indeed handle it, regardless of activation state.

  • For pictures dragged to an image viewer, a copy of the image would be opened in a new window. For iPhoto, this would add it to the library.
  • Text snippets would create new documents in text editors.
  • Any type would open a new mail message containing the dragged object in e-mail apps. For links to movies and images, the link itself would be placed in the body of the message, not the movie or image.
  • Spring objects could create a new canvas to be used as a holding spot.
  • Web links would open a new browser window or tab depending on existing user preference.
  • FTP links would open a new connection. AFP links dropped on the Finder would do likewise.
  • Files dropped on chat clients are tricky. Prompting for a buddy to send the file to seems like the only real choice if no conversations are in progress.

This would really work best in concert with my spring-loaded Dock combined with Expose idea. This portion handles situations in which no document or window is open, eliminating the need to choose one such item as a destination. The single app Expose would handle situations in which an application already presents one or more valid destinations for a dragged object.

For single-window applications whose sole window has been minimized, it would obviously be necessary for it to unminimize to provide an object destination.

Some problems to further ponder:

  • It is probably necessary for the cursor itself to actually hit the Dock icon to initiate the drop. It may even be necessary for the dragged object(s) to stop just outside of the Dock so that the cursor is clearly visible for selecting an application.
  • Would Dock icon-drop created documents come to the foreground or not?
  • Where would items dropped on the Finder’s icon go? The Desktop folder or the frontmost Finder window?

I’m sure there are many other potential problems that I cannot currently imagine.


I’ve been playing with the Flash zooming interface demo that is a part of Jef Raskin’s Humane Interface concept. As noted in the demo itself, it is limited and does not reflect the full capabilities of today’s rendering engines. With that said, it is still easy to see the potential of such a design.

The space is easily navigable and items can be grouped in certain locations. This is a more truly “spatial” UI than that advocated by John Siracusa. A “spatial” metaphor doesn’t really make sense when items can disappear. Sure, a window or desktop can have items arranged spatially, but the value of that spatial representation is greatly decreased as soon as the window is closed or the desktop covered.

My questions about the implementation of the zooming interface:

How is a given object’s zoom level determined?

Does the user have control over an object’s zoom level? Can it be set relative to nearby objects or a global scale?

How would things such as playing media be handled in such a UI? How would I create a playlist of audio files?

I know – just buy the book. Not seeing anything more detailed on the website, I imagine the book delves into specifics.