Toolbars in the Dock: Are Dockable UIs All They're Cracked Up to Be?

By Matt Stephens
August 10, 2003

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

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.

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

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 it.
2. Resize main window so that all MDI windows and toolbars are visible.
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 Login button.
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 Design

<< Back to Software Reality