Finder: Cursor has to be on folder icon or name in order to be able to drop item

Posted by Pierre Igot in: Macintosh
May 5th, 2005 • 6:26 am

This is something that I consider a flaw in Mac OS X’s interface. When you use the Finder’s colour labels to colour files or folders on your hard drive and when you view files or folders with such labels in a Finder window in View as List or View as Columns mode, the colour highlighting spans the entire width of the column. In other words, unless the file/folder’s name is very long, the colour highlighting with its round corners and subtle 3D effect that makes it almost look like a button is actually larger that the space used by the file/folder’s icon and name.

And this colour labelling makes it look as if the file/folder itself as a list item spans the entire width of the column.

Yet when you take an item from elsewhere and try to drag it and drop it on this file/folder with colour highlighting, the colour highlighting counts for nothing. In order to be able to drop the dragged item onto the file/folder, you still have to make sure that the mouse pointer is actually somewhere in the space covered by the file/folder’s name or icon.

For example, in the screen shot below, I am trying to drag a PDF file onto the folder called “Work“, which has an orange colour label:

Trying to drop an item onto a colour-labelled folder

As you can see, however, with the mouse pointer somewhere in the middle of the column, the “Work” folder is not recognized by Mac OS X as the intended destination, even though the mouse pointer is clearly on the colour labelling that is part of the item.

In my opinion, this behaviour is wrong. The colour labelling scheme used by Mac OS X spans the entire width of the column and makes it clearly look like the file/folder in question itself spans the entire width of the column — but this visual scheme doesn’t apply to drag-and-drop operations.

In fact, it could probably be argued that, even with files/folders that don’t have a colour label, the entire width of the column in View as List or View as Columns mode should still act as an appropriate destination for drag-and-drop operations. Why should the user be required to drag the item precisely over the icon or name? There can be nothing else between the right edge of the name of the file and the edge of the column. So why can’t the entire row act an appropriate destination for drag-and-drop operations? There is no reason why a drag-and-drop operation should be more difficult to achieve with files/folders whose name is shorter — yet that’s exactly what happens in Mac OS X. The shorter the name of the file/folder destination is, the harder it is to aim on the destination in a drag-and-drop operation. I don’t think that’s right.

(Indeed, the fact that the entire width of the column works as a destination for single and double clicks proves my point. It simply doesn’t make sense that what works for single and double clicks doesn’t work for drag-and-drop operations.)


2 Responses to “Finder: Cursor has to be on folder icon or name in order to be able to drop item”

  1. Pierre Igot says:

    Good point. It looks as if we are faced with a situation where we have to choose between consistency (item spans entire width in all situations) and usability (ability to drag a file to a window without putting it in a subfolder). It’s unfortunate that such a choice has to be made.

    Maybe the problem is with the fact that it’s so easy to accidentally put a file in a subfolder when you didn’t mean to.

    So maybe the real issue is with the very ability to drag a file onto a folder window without dragging it onto any of its subfolders. It’s easy to achieve this when the list of items in the folder is shorter than the height of the folder window. In that case you have enough empty space at the bottom of the window to drag the file onto the window without accidentally dragging it on one of its subfolders.

    But if the list of items is longer than the height of the window, then there is no such space. And in such a situation, if each list item spanned the entire width of the column, there is no space at all to drag a file onto the window without dragging it onto one of its items.

    And that’s the core of the problem, really. The inconsistency adopted by Apple is just a “work-around” of sorts. It doesn’t solve the basic issue, with has to do with using a window itself as the destination of a drag-and-drop operation instead of one of the items it contains.

    I am not sure what the solution would be here. Maybe a modifier key that would “force” the drag-and-drop operation to ignore the contents of the Finder window and just use the window itself (i.e. the folder that it represents) as the destination. (In the case of View as Columns windows, read “column” instead of “window”, of course.)

    The Option key is already taken for something else (changing from Move to Copy). Maybe the Command key?

    I think I’d much prefer this solution to a solution where the colour label background colour only extends as far as the file/folder name :).

  2. Olivier says:

    Well, if files could be dragged anywhere on the row to put them in a folder, it would be a pain to drag a file in a window without putting it in a subfolder. I rather like it the way it is. Label colour, on the other hand, would be better as just a circle on the left of the name, like when the window is in the background.

Leave a Reply

Comments are closed.