Tuesday
Sep222009
Suggested Improvement to the Mac Dock
Tuesday, September 22, 2009 at 6:20PM Here's a mockup I made for a slight improvement on the way Apps in the Mac OS X Dock indicate that they can accept files dragged to them. Do you think it would be helpful?
Reader Comments (19)
I really love the idea of changing the way the dock handles this. But I would prefer to see all the dock icons grey out of the apps which won't accept the file when dragging over the dock.
Nice idea and mockup of this new behavior...
Although, I don't get it : when you drag a file in the Dock, I'm sure you already know which application you'll open it with.
Most of the time I'm dragging images to photoshop/Picturesque to edit them, I don't need every other image-opening-able apps to stand up, I don't see the point in that.
wherefore?
I know that I want to drop file to the photoshop and it doesn't matter what else can open that file.
That's quite cute. I think it would especially help when you have a bunch of apps open, and minimised windows. Even if you do know the application you're interested in - having it "stand to attention" would make it quicker to spot.
Thanks all for the nice words.
@ChriB — the problem is that greying out the icons is a bit too similar imo to the current darkened 'selected' look.
@ Moitah, good point. There's some other functionality I think missing where the dock could show you any app from your Applications folder that could open the file. With the loss of Creator Codes in 10.6 I think we'd need to rely on this type of funtionality more
@relooc @Justin Yes, even if you knew you wanted to drag the document to a singular app, having it 'stand up' might make that task a little easier? Maybe not, not sure.
Is there anyplace in OS X where something lights up upon a drag, without being explicitly dragged over? It's kind of a shame that this doesn't happen.
I think it's for a technical reason. In the general case, a view element gets a message when something is dragged over it. It gets to light up, adjust the mouse pointer, etc. as a result of examining the thing being dragged. This is some amount of computation that's trivial for one moment in the drag, but might not be if many targets were considered. I *expect* this is why things light up only one at a time.
But on the Dock, these computations are simple; they're just a question of app configuration and there is no custom behavior. Furthermore, you might have 100 things on your Dock but that's kind of a known worst case. So, you could implement this to work in a predictable manner with no slowdowns.
I just wonder if it's not done on the Dock because it's not common elsewhere.
Really nice idea, although I think on reflection I prefer ChriB's suggestion. This is mainly because, for those of us who regularly drop files onto applications (such as image editors) it could get annoying for the applications to be "standing up" and down all the time.
Irrespective of how it currently works, having only the applications which are able to accept the file light up seems the most logical to me.
I've not seen anything which 'lights up' — the closest I can think of is the spotlight effect in the System Preferences when you begin to type in a search term which a number of items match.
To clarify, by 'light up' I personally meant that apps that can't open the type of file dragged to the Dock should dim, where as the rest could remain in their normal state (appearing lit up compared to the dimmed applications).
Apologies, my previous comment could have been worded better. :)
(And I would never have used a smiley if I'd known it would be converted into an emoticon!)
I think I agree with Tony's more subtle indication.
Keith, how did you make this mockup? It looks pretty complete especially with the interaction animation unless it is just timed.
Also, in regards to Creator Codes, you should check out http://www.appleinsider.com/articles/09/09/22/inside_snow_leopards_uti_apple_fixes_the_creator_code.html
Thanks all for your comments: I've put up iteration 2 of the idea here:
http://www.uiandus.com/2009/09/25/video/iteration-2-on-dock-mockup-idea/
(Hopefully this mockup fixes those problems you mentioned tony)
@Anderson I've put this together using Quartz Composer. It's purely a mockup in a separate window, not a prototype. That is, it doesn't actually do anything. The mockup has mechanics for each App icon to react on mouseover.
@ Kevin,
I just re-read your post, thanks.
I don't *believe* it's a technically difficult, although possibly problematic if mousing over multiple views. Depends how complex the hot area is (square? circle?) I *guess* and how much flexibility the OS has. Any coders want to comment?
Having distant objects light up when dragging could cause distraction, but at the same time can be very useful in showing what potentially could be a target for the drag. I totally agree with you that this should be explored more.
I didn't mean that it's difficult to detect what the pointer is over. I was talking more about the CPU implications of notifying one UI element at a time, versus many all at once, that something is being dragged.
My point was that notifying everything on the screen could make the start of the drag jerky, because you don't know how fast those apps will decide to outline in blue, darken, lighten, change the mouse pointer, or do nothing. I think this is why generally, you only notify the UI element under the mouse pointer -- it's far less work, so the drag is smooth.
But on the Dock, the CPU use is known, so it really could act like you describe, and I think it should!
Ah, thanks for the clarification Kevin.
@Kevin I would imagine that it would send notifications on a different thread than the desktop UI to avoid any disruption or jerkiness in the drag. Also whether it be implemented as a delegate or observer pattern, it would be a very quick response such as a typical rollover/click rather than a complicated calculation. Even with 50 or so icons on the dock, I don't think the CPU would have many problems with this split-second conversation of, "Do you like the file being dragged?" and a focus ring (lighting up in this case) immediate response.
Currently, the protocol only sends the drag notification to the view it is currently entering/over. As I understand it, an exception to the current protocol would need to be made specific to the Application Dock Tile (NSDockTile) to send a one-time notification to all registered Apps as soon as the drag begins.
An example of 'lighting up all possible targets' I stumbled across today was the runways in the Flight Control app for iPhone. When you touch a helicopter, all the helicopter landing pads (the targets) get a soft glow.
@Anderson, perhaps the new blocks mechanism in Snow Leopard makes this even less of a technical issue, negating most of the thread handling.
@Anderson They probably would happen on separate threads, yeah. So I suppose it wouldn't be jerky in any case. If anything, the individual views might slowly react after the drag began.
And I agree that on the Dock it's not going to be a problem, especially because the Dock can be controlled by its author (unless NSDockTile is implemented in your app, which as a concept impresses me). I only meant that it isn't done in the most general case, and the likely reason is because it's an unpredictable amount of work for every view of every visible window.
WOW! i really love your work, and the video, that is a good started to publish the work in the world.
Wonderful!! Kepp up:)
Kay