
An experiment mimicking the Dock of OS X using only CSS - js4all
http://michaelhue.com/cssdock/
======
statictype
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?

~~~
eridius
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).

~~~
statictype
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.

~~~
eridius
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?

------
peteforde
I am seriously impressed. Thanks for sharing!

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.

------
jebblue
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.

------
rplnt
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.

[1] [http://www.ndesign-studio.com/demo/css-dock-menu/css-
dock.ht...](http://www.ndesign-studio.com/demo/css-dock-menu/css-dock.html)

~~~
dylangs1030
Which browsers?

~~~
rplnt
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.

~~~
nazar
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.

~~~
rplnt
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.

------
ecaron
Wasn't Google's homage to the OS X dock, done in 2005, also using pure CSS?
<http://www.macworld.com/article/43631/2005/03/googlex.html>

------
jarek-foksa
Is something like -webkit-box-reflect available on other browsers? It seems to
be totally non-standard (none of the CSS specs mentions it).

~~~
ComputerGuru
Things that start with -webkit are only (at least originally) available on
WebKit browsers (Chrome and Safari, mainly).

~~~
spydum
Isn't this sort of thing is why everyone hated IE6?

I can't help but think we're going to have a bunch of bloat due to formatting
between the webkit-/moz- options, just like we had to for IE.

~~~
sdkmvx
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.

~~~
rhplus
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.

~~~
jlarocco
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: ...;
        }

------
pazimzadeh
Works great in Safari. In Chrome, there is a flicker when you click an icon.
Sometimes the entire window flickers white.

------
alpb
I think the growth rate should be adjustable easily. What's your approach to
this problem?

~~~
michaelhue
The growth rate can be changed quite easily in line 190 and 199 of dock.css.

------
king_magic
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".

~~~
city41
It's an experiment using cutting edge browser technology. It's acceptable to
only work in certain browsers.

~~~
king_magic
And one cannot critique an experiment?

~~~
ja2ke
Saying "This experiment uses experimental features" presented as a negative is
odd, that's all.

------
city41
The link to the old version leads to a 404.

~~~
michaelhue
Fixed, sorry about that.

------
CamperBob
Don't shake the platform when the user moves the mouse across the icons; the
effect is rather nauseating. (FF 9.0 on Win7)

~~~
emehrkay
the problem is that the icons don't overlap. The space between them isn't a
hit target

They are like [ ] [ ] [ ]

When it should be

[ ][ ][ ]

and just center the image inside

This is really cool though

~~~
dylangs1030
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.

