Have there been any usability tests (or even just a logical argument) that show the OS X-style dock to be a good UI mechanism?
Seems to me that turning off magnification and flushing it to a corner (so that everytime it grows it doesn't move around the existing icons) would have been a better default solution.
Apple usually thinks these things through though so maybe I'm missing something?
The hit space for the icons is static, and matches the area of the un-zoomed icon. It achieves this by growing and shrinking (and sliding) the zoomed icon as you mouse across it, so you come to the end of the icon at the same place you would have if the icon didn't zoom in at all. This allows it to look neat while still having good usability, because your spatial memory is left intact (the only thing that changes that is adding/removing icons).
You're talking about horizontal space? Or does it apply to vertical space as well.
Because I had a lot of trouble acquiring the resizing corner of a window when it was near the dock. I would miss that tiny target and mouse-over a dock icon and then have to drag the mouse a lot further up to make the icon go back down.
I have since switched to having the dock on the left side of the screen instead of the bottom and that seems to be noticeably easier to use.
I was talking strictly about the horizontal space. If you don't like the icons moving up to cover more vertical space, maybe you should just turn off zooming?
I hide and never use my dock. I don't miss it at all. It is one of the most disappointing UI features Apple has ever done. It's much more about sizzle than being useful. I feel even the Windows task bar (both before and after Win7) is better than the dock.
Considering that it is merely a refinement of the NeXT dock that was conceived in the late 80s I'd say it hasn't aged too badly. I suspect it will gradually die as the iOS-like springboard app launcher that appeared in Lion matures.
If it ever does die completely, it won't be because of iOS.
Right now, the dock basically serves two UI purposes: "here's a list of apps you want to be able to access quickly, viewable at the edge of your screen", and "here's a list of apps you're currently running, also at the edge of your screen".
On OS X, these are currently combined into the same UI widget.
On iOS, they both exist, but as two separate entities: the docked app icons at the bottom of each springboard page serve the first purpose, and the list of recently-used apps in the double-tap multitask bar the latter. The interface has changed slightly due to the fundamental difference in the multitasking paradigms between the two OSes, but I don't think it's a stretch to say that the iOS UI has something that is clearly related to the OS X dock, both in form and in function.
I wish there was an easy way to fit this into some of my projects. I don't mean the browser incompatibilities others have pointed out, either!
I feel like the idea of using this in a practical application is stunted by the "Ikea effect" of something looking awesome in the showroom but crappy in your actual house. Unless you take great pains to make sure that everything in a room matches thematically, it will look like a careless hodge-podge of well-intentioned designs that don't work well with each other.
The reason it looks great inside OS X is that Apple have put years of thought into how the Dock fits in with the rest of the user experience. You can't drop a dock into an application without putting real thought into whether it's the right navigation tool.
It's usually not the right navigation tool, but it sure is pretty.
It works on the latest Google Chrome and Firefox on the latest Ubuntu and looks nice. On my several years old computer both cores used around 20% to 30% while moving between the icons at a normal pace. Not critical and good performance, comparable to a few flash sites I checked for comparison.
One of those flash sites seemed to mess up the browser and the subsequent flash dock sites failed to load correctly. I don't see this with HTML 5 and CSS sites which achieve the same level of feature usability.
Does not work properly in two of three browsers I have. I don't see a reason why not use javascript in cases like this. I get it as a showcase of power of css but please, don't use this on your websites (yet). Here's[1] an similair example from 2007, works just fine in all three browsers I tested.
Opera, Chrome, and Konqueror. In Chrome it seems to work fine, in Opera the reflection is missing and in the Konqueror there is no reflection and it is not animated.
Maybe you really should reconsider you browser preferences? I mean, it also doesn't work in the browser that the kid from next door built as his school side project.
I don't use Konqueror, I just have it. My point was that even with this browser the javascript version works. Chrome is quite popular in desktop market and Opera is too (in some regions at least). Besides that, the same rendering engine is used in mobile and internet-enabled devices (such as a TV) -- so it's still relevant.
A combination of CSS transforms, opacity, gradients, and -moz-element (https://developer.mozilla.org/en/CSS/-moz-element) allows you to do this in Firefox. I prefer Mozilla's method over WebKit's since it gives you more control: -moz-element is basically a way to replicate any element (even cross-domain iframes!) and apply any transform you want.
The idea behind vendor specific items is that people can play around with things after vendors introduce them in an attempt to get traction for wider adoption...
IE6 in my experience was less hated for this than for implementing the box model differently.
I don't have to use vendor specific extensions unless I want to play around on the cutting edge. I have no easy way to work around the different box model in older IEs.
The vendor specific thing allows vendors to do widespread bug testing. People who coded border-radius expect it to work, and (I'm not 100% sure of the current state of that) people who wanted it before they were sure it worked had to do -webkit-, and -moz-, etc. They should understand that the vendors aren't 100% sure they coded it right. This way, if someone finds a bug with -webkit-, they don't have to worry about breaking websites by changing it.
What will happen to all those -webkit and -moz declarations in the wild once a feature gets added to the standard? Will all browsers be expected to observe -webkit-feature-foo or -moz-feature-foo as though the author intedended to use feature-foo with no vendor tag? It seems unlikely that all authors will go back and update their code once standardized.
It's the website developer's responsibility to switch it over.
Using them in the first place is saying, "I want to use cutting edge features that may change and break at any time." Being removed and replaced with the standard version is just a special case.
But it doesn't hurt to use multiple versions, so most people just specify it for each browser and the standard. The browser will ignore the ones it doesn't understand. For example, this works:
div {
-webkit-border-radius: ...;
-moz-border-radius: ...;
border-radius: ...;
}
That's because it is non-standard, and it's supposed to be. The author gives a short description of the compatibility, starting with Chrome at full support (webkit), to Firefox (some supported features), to Opera (no extra support, but basic functioning remains). The good thing is that even without webkit, it won't just stop working altogether, but you really won't have it optimized.
It looks nice on Safari, but I do echo other people's comments: the code looks like it uses non-standard mechanisms for achieving it's goals and had to be tailored for specific browser families. To me, that's a "code smell".
Yes, and I remember some early GNOME docks had this same issue, so you couldn't appreciate fluid motion when you moved the cursor horizontally across the dock. But it's very well done otherwise.
Seems to me that turning off magnification and flushing it to a corner (so that everytime it grows it doesn't move around the existing icons) would have been a better default solution.
Apple usually thinks these things through though so maybe I'm missing something?