Friday
Sep252009
Iteration 2 on Dock Mockup idea
Friday, September 25, 2009 at 3:04PM Based on your feedback, here is an iteration on my previous design post to better show what applications can accept certain files dragged to them in the Mac OS X Dock.
Reader Comments (11)
Nice work Keith - that's a definite improvement over the current Dock behaviour, and over the last mock-up.
I agree the extra glow might be a bit much here (and I'd be tempted to dim the 'inactive' apps a slightly less personally), but the concept is great.
Thanks Tony,
The problem with using a less severe change in the opacity is that is looks (on the default desktop) too similar to the 'selected' darkening of the icon- I thought initially I could be more subtle, but that doesn't really work. :-)
I've been following this with interest since the first video and think it's a really good idea; especially for those that are less accustomed to the Mac. This second iteration is a great improvement upon the first.
One question I have is; what is the behaviour when you hold the Cmd + Alt keys whilst dragging the file onto the Dock (since this action forces any application to attempt to open the file)?
Keep up the good work
Best
Sam
Thanks Sam.
If you held down the modifier keys, perhaps it would simply 'light up' all of the apps? I can't see any particular problem with that.
I liked the first iteration more; it makes more sense to me that only the relevant items get affected in an interaction. The second iteration would make more sense to me if the entire screen or the entire Dock (including the mirror) were faded, to use the metaphor of bringing the relevant items to the forefront rather than the irrelevant items to the backfront. (You know what I mean.) I think either of those would be silly, mind you. But apparently some people don't; Windows 7 does some everything-fading, and it works well.
Personally, I've always admired the Dock for succeeding in being extremely minimalist interfacetically while still a delight to use—everything is animated, but nothing is superfluous. So I see both ideas as being detrimental for me; typically, when I'm dragging an item to the Dock, I know exactly which app I'm aiming for, so seeing a few other apps pop up seems like it would be distracting. Less noticeable feedback, I think, would work better. Since there's already a glowing dot underneath running apps, hijacking those wouldn't add any clutter; the dots could temporarily reappear under the apps which can accept the file. I doubt your white glow on its own, though, without other apps fading, would be that bad either.
Another issue I just thought of is that there are more targets available to files than just the apps. There are stacks, of course, which can be treated like apps, but there are also spaces /between/ the stacks. Providing animation that tells you that something can be put somewhere (apps and stacks) but not providing animation that tells you that it can be put somewhere else (in its own slot) seems misleading—it might teach users that they can't add files to the right side Dock.
A note on current animations: a part of the advantage of app icons darkening is that, for me at least, it invokes the metaphor of holes. When you drag a file over an app, it looks like the app is saying, "yes, I am a hole, you can drop things in me". The apps which don't dim are covered by manholes, and the file you're dragging walks right over them. Part of the reason I prefer your first iteration, probably, is that it preserves the metaphor I'm used to.
As I noted three paragraphs ago (whoa, text flies when you're writing in a small box! I should have resized this thing sooner), I wouldn't make use of this since I use the Dock differently. So that we're clear, what's the use case for this kind of thing? You know you want to edit a file, but you don't know which app would be best for that, so you want the Dock to tell you what's available? Because that strikes me as at odds with the philosophy that you should use One App to do One Thing; most people don't have multiple image editors or multiple browsers.
Sorry for writing a huge thing! ^_^;
In this mockup, I see that you've kept name tags for every app in the Dock, including those that can't open the dragged file.
This behavior differs both from the standard Dock and from your previous mockup. For some reason, it feels strange to me: it provides a form of visual feedback yet is not actionable in any way.
Is there a rationale behind this choice?
@ Louis-Jean
My mistake for keeping in the name tags above every app, even those that cannot open the dragged file. No rationale.
@Kelsey, thanks for the in depth comment.
There is 'everything fading' when you right-click on an app in the Dock in SL. I actually find that a bit disconcerting, to see such sudden change is unexpected to me.
I like your metaphor of the darkening/selection of apps = a 'hole' to drag something into.
I'm not a fan of the 'one app per filetype' actually. But, most people don't drag documents to apps—and actually there is no indication of what app will launch when you double-click on it. So there's a great opportunity to clean it all up!
Keith, have you thought of the possibility of only highlighting the other apps when you move sideways over the dock?
If you could drag down into the dock and you knew which application you wanted to use, then no highlighting would appear. But once you start to hesitate and move sideways away from the entry point, then it would make sense to show alternatives. This way you would not be distracted by other dock icons wanting your attention when you are certain about your target.
Also, dragging down and then across could be quite hard if the icons are far apart. Did you consider a snapping behaviour where the pointer skips the unavailable icons and snaps to the next available one?
@Keith: Ah, I wasn't thinking about the fact that most people don't drag documents to apps! The whole idea makes a lot more sense now.
That's a really good idea Eric. I'll try to mock that up. Have you ever seen a similar approach in another UI?
I've seen some snapping behaviour of tool windows to make docking easier, but not snapping that would skip the mouse pointer. Maybe the closest I've ever seen would be a PC utility used to move the mouse pointer to above the default button when a dialog opens to improve accessibility.
It could potentially feel odd when the mouse pointer skips, so acceleration may be better.