The ease of the common – "docking" toolbars

I had an interesting experience the other day with, of all things, a toolbar.

I was using Adobe Framemaker - a publishing application I use quite a lot during my normal working day. I kind of knocked my mouse and clicked at the same time, and suddenly my editing toolbar (copy, paste, yadda yadda) was floating around instead of comfortably glued to the menu.

So, obviously, I tried to dock it. Gripping the top of the palleted toolbar and dragging into the corners, over the other toolbar: slowly, quickly, in little circles . . . Then I tried docking it somewhere else: the bottom, the top, the right-hand side. Anywhere so long as it wasn't drifting around in the middle of the page. No joy.

After about five minutes of this, I even resorted to the help. "Docking", I searched for. Nada. "Dock". Zilch. So I asked my colleagues – all experienced Framemaker users. One of them had had this happen before, but didn't know how to fix it. He'd given up – his toolbar was now floating. He suggested looking in the help . . .

So, does Framemaker have a crazy feature where you can un-dock a toolbar and then never re-dock it? Nope. It has a perfectly sensible system, and it's right in front of your eyes.

It has a button.

(c) 2002 Adobe


A button on the toolbar (second one along, if you haven't spotted it yet) that un-docks the toolbar, and a button on the pallet toolbar that re-docks it. And they call it "Vertical/Horizontal QuickAccess Bar", not docking.

And what did this tell me? That our current knowledge and ideas about the world are crucial in how we can learn and recall an interaction design. Docking is neither more "intuitive" (see my rant on that word) nor less. Docking is certainly more versatile, in that it has the potential to support many more locations for a toolbar, and it reduces button clutter. But having a button on the toolbar is pretty obvious isn't it?

The fact that it took me the best part of ten minutes constant effort, a couple of stabs at a help file (where I was using the "wrong" word, because that's what I'm familiar with), and two colleagues' efforts, tells us that it's not pretty obvious - how users understand their world is fundamental to successful design.

If a button was the best solution by far, and if you didn't have any casual users, you should probably still go for the button. In all other circumstances, you've got to do what everyone else does.

Jakob Neilsen on following convention on websites
Jared Spool on taking into account users' current knowledge before you start (this is very relevant - Framemaker is not a particularly modern product: was the docking concept firmly entrenched when they made this decision?)