Toolbars in the Dock: Are Dockable UIs All They're Cracked Up to Be?
August 10, 2003
is a big step forward. But . . ."
The recently released JIDE framework has been
heralded as a sign that Java Swing user interfaces (UIs) are finally
maturing. In a recent JavaLobby
newsletter, Rick Ross rightly describes JIDE as a big step forward
for Swing UIs - showing that whatever SWT can do,
Swing can do pretty much just as well, and in 100% pure Java at
JIDE provides an application platform for building applications
with "modern" user interface features such as dockable
toolbars, dockable windows and pretty much anything else that could
feasibly be made dockable.
I program in Swing every day, so I welcome the arrival of any toolkit
which is going to make my life, and the life of my users, easier.
(Check out this new
book, which includes a brief case study of my current "agile"
code generated Swing/NetBeans project).
A downloadable demo of JIDE is available here
(needs Java 1.4). First, hats off to the JIDE team for producing
a UI demo that is genuinely responsive, and really does feel like
a modern, native GUI application. JIDE deserves the attention it’s
getting, because it is well-conceived and obviously well written.
However, there are also some problems: and the problems are more
deeply rooted than how well implemented (or not) JIDE may be.
It's worth stressing that any concerns I raise here are not to
do with JIDE itself, but with the many ways that JIDE could potentially
be abused - the downloadable demo being a perfect example.
how dynamic a Swing user interface can be made to be"
The demo, though technically impressive, has obviously been written
to show just how "dynamic" a Swing user interface
can be made to be. Everything in the JIDE demo can be dislodged,
moved around, connected to other things, lodged back into toolbar
areas, and so on. When you're trying to redock a window, there are
so many different areas of the screen that the window can connect
to that the window jumps around the screen, finding edges, resizing
to fit new areas, clinging onto other windows as you move it across
the screen. I found the experience quite off-putting.
From an interaction design perspective, this is far from being
the bee's knees. The end-result, which should feel nice and modern,
just feels brittle. The experience is rather like driving a car
with a steering wheel made of lego. The driver is afraid to turn
the wheel too sharply because chunks of lego keep crumbling off
the wheel. If the JIDE demo was a real application, I would be nervous
about clicking anywhere on the main window, for fear of accidentally
dislodging something, or accidentally making a floating toolbar
disappear without any immediately obvious way of getting it back
again. More time would be spent correcting accidental mouse-nudges
that have dislodged another part of the screen, than doing actual
part of the UI is dislodgable - it's customisability
It might be considered unfair to criticise the demo - it's obviously
been deliberately written to show everything that JIDE is capable
of. So everything and the kitchen sink has been thrown in, and every
possible part of the application UI has been made "dislodgable".
However, it's worth discussing because the demo is a "lego
steering wheel" application in every way - brittle and difficult
to use: customisability gone mad. In short, if it was a real application,
it would be unusable.
You might be surprised to hear dockable UIs described in this way.
Aren't they supposed to make users' lives easier? Surely, being
able to customise the user interface is a useful thing? The problem
is that, for most users, the software is simply there to get their
job done. They don't want to spend all day tinkering with the user
interface, tweaking the layout, nudging toolbar #101 a few pixels
to the left so that they can get to window #37 behind it.
This is something that Alan Cooper, in his book About Face
2.0, describes as "excise" - the unnecessary
extra tax that the user must pay in order to reach their goal.
For example, say if the user wants to login and make some amendments
to their user account. That's their goal. Two steps. In a modern
GUI application, the use case might be broken down as follows:
1. Double-click application icon to launch
2. Resize main window so that all MDI windows and toolbars are
3. Pause briefly to decide whether to click the Login toolbar
button, or bring down the drop-down menu.
4. Dock the Login dialog against the Actions palette. Watch with
dismay as the Login dialog resizes, obscuring its own Login button.
5. Drag the edge of the Login dialog to resize it. Move the combined
Login-Actions dialog-palette to the centre of the screen. Click
the Username text field. Type user name and password. Click the
6. Baulk as the windows and toolbars magically morph and reposition
themselves to fit the user's downloaded user profile.
7. Look around for the Actions palette. Realize it must have disappeared
at some point.
8. Click View.. Toolbars.. Actions, to make the palette visible.
9. Undock the Actions palette from the top of the screen, move
it around aimlessly for a few seconds, then dock it to the left,
out of harm's way.
10. Readjust the three other toolbars that have shuffled around
randomly to make room for the Actions palette.
11. Click the User Account toolbar button.
12. Adjust the size of the User Account window that pops up.
And so on...
Ideally, the application layout should be "just right"
in the first place. The user shouldn’t have to adjust the
windows and toolbars at all to get them right. The design
team should have done the thinking already, and designed the UI
to be just right. No adjustments necessary.
This is an ideal, of course: applications do need to be configurable,
because different users have different tastes and preferences. Not
to mention, different users have different goals: therefore the
optimal window & toolbar layout for one user might not be particularly
useable for a different user. As you'd expect, there is a balance
to be achieved. Certain parts of the UI need to be configurable,
but not the whole damn thing! A good rule of thumb is that the most
common tasks should require the least amount of configuration -
ideally no configuration at all. The most usable application is
the one that requires the least mouse clicks and gestures to operate.
So, back to the JIDE demo. It's rather worrying that the demo for
Java's latest best hope for the desktop is also a primary exercise
in how not to design a user interface.
Until now, Java programmers who have wanted to create modern dockable
user interfaces have been left lingering in the desert with clunky
Swing "metal" toolbars, with their odd-looking titlebars
that are bigger than the toolbar itself. My worry is that well-meaning
Java developers might now go mad with the new-found freedom and
power that JIDE offers, creating "lego steering wheel"
user interfaces that the poor users will be terrified to go near,
let alone use every day.
To sum up, dockable user interfaces do have their place (and JIDE
in particular is well worth a look), but they should be applied
very carefully, and only in places where they really do make your
application easier to use.
<< Back to Software