December 8th, 2006 • 10:52 am
For a long time now, the Mac OS has had this “spring-loading” mechanism that enhances the drag-and-drop process in the Finder: When you take a file in a Finder window (in the foreground) and drag it over a folder icon, if you keep the mouse button down and wait for a second or so, the Finder ends up “spring-loading” the destination folder by opening it in a new Finder window, so that you can continue to explore the contents of the folder (and choose a more specific destination inside that folder) while still holding the mouse button down.
As long as you don’t release the mouse button (i.e. as long as you don’t “drop” the file you are dragging), the Finder continues to let you browse through the hierarchy of folders inside that initial folder destination, but effectively opening these folders for you (either in a new Finder window or in a new column inside the current Finder window in column view) while you are still holding down your mouse button and dragging the file that you want to drop somewhere.
One other interesting aspect of this “spring-loading” mechanism is that it doesn’t just work for opening folder destinations. It also works for bringing already open Finder windows to the foreground.
If, like me, you often have many different windows open in the Finder, it can happen quite often that the file that you are dragging needs to be dropped inside a Finder window that is already open, but is currently almost hidden by all kinds of other windows that are in front of it. All you can see of it is a little corner of the window, but you know for sure that this is the window where you want to drop your file. Unfortunately, you cannot bring this window to the foreground without first releasing the mouse button and dropping the file you are currently dragging back in its original location.
In that case, the “spring-loading” mechanism works not by opening a new Finder window, but by bringing the background Finder window that is your intended destination to the foreground. All you have to do is keep the mouse button down (still dragging the file you want to drop) while you are hovering above the little corner of the window that is actually visible. After a second or so, the Finder kindly brings the window to the foreground so that it becomes visible in full, and then you can continue dragging to select a more specific destination inside that window.
This is quite useful. And it works not just within the Finder, but also when you are dragging something from a third-party application to a half-hidden Finder window in the background. The third-party application is in the foreground and the Finder window is in the background and half-hidden, but if you drag an object (a block of text, for example) from within the foreground third-party application onto the half-hidden window in the background, and then hold still for a second or so, the Finder kindly “spring-loads” the half-hidden window by bringing it in the foreground of the background, so that you can see its contents in full and choose a more specific destination for the object (which will then become a text clipping file when you finally drop the text block in the final destination in that Finder window).
Unfortunately, there is one aspect of the “spring-loading” mechanism where things could still be improved. It is what happens when the destination (not the source) of the drag-and-drop operation is a window that belongs to a third-party application.
For example, you might be in the Finder and have a file that you’d like to drag from the Finder and drop onto a window belonging to your favourite FTP application (in my case, Interarchy). But the Interarchy window happens to be almost completely hidden by other windows. You can just see a corner of it, and you know very well that it is the window that you want for the destination of your drag-and-drop operation from the Finder. But if you drag your file from the Finder and move your mouse pointer to that small portion of the Interarchy that is visible and hold still for a second, nothing happens. The Interarchy window stays in the background, and remains hidden by the other windows. The Finder is unable to “spring-load” it and make it a foreground window in the background, so that you can view its contents in full.
At best, you might see some kind of visual effect (such as a border in your default selection colour along the inside edges of the destination window) indicating that the half-hidden window is a valid destination for the drag-and-drop operation and that, if you release your mouse button now and drop the file, the file will indeed be dropped somewhere inside that window. But you have no control over where exactly inside the window it is going to be dropped.
And the problem extends to all kinds of other applications. For example, I frequently drag active links from within web pages in Safari to the main window of Speed Download 4, which I have running in the background and which I use as a download manager. (It lets me queue downloads so that I don’t have multiple concurrent downloads; it lets me limit bandwidth usage; etc.) But my Speed Download 4 window is often half-hidden and I would like to be able to determine exactly where in the Speed Download 4 window I am going to drop the link from Safari (so that I can determine the exact rank of the download in the queue).
Unfortunately, in such a situation, there is no “spring-loading.” The Speed Download 4 window stays in the background, half-hidden, and I have to drop my link in a semi-blind fashion.
Fortunately, there is one way to work around this: You can actually use the application switcher (Mac OS X’s built-in command-Tab mechanism) during the drag-and-drop process, i.e. while you are holding the mouse button down and trying to choose the exact destination of the drag-and-drop operation.
So if you are dragging an object that you want to drop on a third-party application window that is mostly hidden from view, you can actually use your other hand to command-Tab to the desired application. This will bring the target application window to the foreground of the background (like the “spring-loading” does with Finder window), and then you can drop the object exactly where you want.
I still would like it even better if third-party applications supported the same “spring-loading” mechanism as the Finder, i.e. their windows would come to the foreground of the background if you drag your object to the portion of the window that is visible and hold still for a second or so.
But it is quite possible that this would require third-party application developers to modify their applications. So maybe what we actually need is some kind of “API” for this that Apple would provide in Mac OS X and that third-party developers could use to add support for this “spring-loading” mechanism in their own applications.
On the other hand, that would probably mean that it would take at least ten years for developers like Adobe and Microsoft to actually embrace the mechanism in their own applications. So unless Apple has a way, in Mac OS X, to implement such a mechanism in all applications unilaterally (which I doubt very much), I don’t see any major changes in that area in the near future—which is a shame, because, after all, we are talking about pretty fundamental interplay between applications here.
There was a time, not so long ago, when Apple was actually exploring ways to move from an application-centric approach to a document-centric approach, in which presumably drag-and-drop operations would have played an even bigger role. But this philosophical change was put on the back-burner, and we still live very much in an application-centric computing world today. Some days, I would like to see signs that Apple is still thinking about those fundamental issues and exploring ways to design tomorrow’s user interface, rather than just continue to fine-tune today’s standards.