Drag-and-drop in Mac OS X: For a more universal ‘spring-loading’ mechanism
Posted by Pierre Igot in: MacintoshDecember 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.
December 8th, 2006 at Dec 08, 06 | 11:02 am
I think you’re touching a really interesting topic here. On the one hand I totally like the spring-loadedness of Finder windows as well (when it works at least, sometimes windows don’t seem to make it all the way to the front), on the other hand, I keep thinking that OS X’s window management can be a bit too relaxed and I often find applications bringing a window to the front when I’d rather not want them to do so. So I’d be a bit hesitant to join your suggestion, as this kind of behaviour requires really careful implementation.
An example for a third party application that does implement this in a good way, would be Transmit.
What I usually consider to be a good compromise is using Exposé’s F9 mode for cross application drag and drop operations. This mode is also drag and drop aware, so you can just start dragging, hit F9, find the window you want, rest above it for a moment and see Exposé select that window and bring it to the front where you can navigate the window more finely. In particular this has the advantage that it doesn’t require extra effort by the application programmers as everything is done by Exposé.
December 8th, 2006 at Dec 08, 06 | 11:23 am
Yes, things would have to be implemented careful, with a good delay before spring-loading, so that people don’t accidentally bring windows to the foreground by dragging over them. But, like you said, things are already a bit messy now, so it’s part of a more general problem with window management in Mac OS X.
I would use Exposé more often for this, but I find that too often I have far too many windows open for it to be really useful. (With too many windows, you spend too much time finding the one you want, which is now in a different and arbitrary location, and not visually where you know it is in the normal window layout.)
December 8th, 2006 at Dec 08, 06 | 11:38 am
It’s true that windows can be hard to spot in a big Exposé mess. But usually I find that bit of searching less frustrating than having to stop the drag, move things into place and restart everything.
Thinking about it, perhaps it would be a good compromise if Dock icons were springloaded and hovering over them would make the application come to the front. That’d give easily recognisable non-moving drag and drop targets. Of course that wouldn’t solve the problems where you have many windows open in an application, but it’d be a good first step. I’ll give this another thought and perhaps file an enhancement request if I don’t find reasons why that’d be a stupid thing to do.
December 8th, 2006 at Dec 08, 06 | 12:52 pm
Note this trick with Exposé: use it to display the windows of the the *current* application (not all windowq), then hit “tab”: this will display the windows of the next application. Thus you don’t have too many windows at a time. I think it’s a bit more comvenient than the command-tab approach.
December 8th, 2006 at Dec 08, 06 | 6:52 pm
ssp: I can think of several things that could be spring-loaded, actually: Dock icons, toolbar buttons (when they have submenus that could apply to objects being dragged to them), etc. It’s all a matter of implementing things properly.
mricart: Yes, I suppose this would work too, although it’s not much different from my approach. It just lets you see all windows of the destination application and choose the one you want to drop the object on.
Basically, there are various ways of doing things. I just think that other applications should be able to bring the window that the user is trying to reach to the foreground of the background the same way that the Finder already does. It would be… consistent.
December 9th, 2006 at Dec 09, 06 | 5:26 am
You might be glad to know that in Leopard folders in the dock are now spring-loaded. This is a feature that folk have wanted for as long as OS X has existed.
December 11th, 2006 at Dec 11, 06 | 9:41 am
Mike: Good news indeed, although the Dock really needs a major overhaul :).