Command Tabs: A Ribbon Interface in Java

Related link: http://weblogs.java.net/blog/kirillcool/archive/2005/09/who_does_not_wa.html

Microsoft's Office 12 pre-announcement last month introduces >Command Tab (previously known as
the Ribbon), their new approach to help connect their users with Office's functionality. (Apparantly the two have
been somewhat standoffish towards each other.) Some screenshots at
>MSDN and
>here.

Adobe's "patented" solution to this problem has been their floating toolbar pallatte gizmos: floating window containing tabs containing pallettes, some collapsable, which may have a little arrow in the corner to pull out choice pallettes. The pallettes are organized based on the object selected, typically.

Microsoft's Ribbon is a glorifed tab to select between different toolbars, hopefully grouped together by the kind of task you are doing. A top-of-window tab containing sections ("chunks", which may have all little arrow in the corner to open up dialog boxes) containing buttons or pallettes or menus all mixed together and sized according to rarity. The ribbon is organised in more task-oriented fashion. It looks very nice: ribbons can to a certain extent surplant menus, toolbars, pallettes, task panes and even wizards.

Extra sections appear by magic, depending on the objects selected. There is an XML file format, and developers will be able to add their own bits to the ribbon.

The general look in the previews so far is more like Apple's Aqua and brushed metal looks, however Microsoft's ribbons are, in a sense, as far as possible from Apple's classic Human Interface Guidelines as the old vi text editor is. The main menu is (almost) done away with for a start. And havind sections/chunks/tasks appearing and disappearing goes against Apple's Perceived Stability dictum.

The various Longhorn and Vista screenshots, not to mention Windows Media Player, have long shown a movement way from a top-position menu bar.

The Microsoft buzzword is now result-oriented user interfaces; not a happy expression to my ear, because one tends to think of unforgiving results-oriented "male brain" types as distinct from friendly people-oriented "female brain" types. Software with Asperger's syndrome? But I digress.

I had been thinking of putting a more task-based multi-toolbar interface into my company's Markup Editor product, and the Microsoft ribbon announcement spurred me into implementing a prototype. We are still evaluating this interface, and I expect we will release it.

I used and adapted Kirill Grouchnikov's JRibbon Java code, part of his Substance look and feel library, down-porting it to Java 1.4 and changing the look and feel to center components. JRibbon is not mature, and I suspect that it would be better to treat ribbons as a kind of JTabbedPane with toggle buttons and a layout manager for the tabs. The strip or task API is good though.

Here are a couple screenshots of my prototyped Command Tab:

To figure out the tasks I made a "Starting" task, a "Finishing" task, and then grouped all the main functionality of the editor in other tasks. I found using "-ing" words was a quite good way to make comprehensible groupings. Some tasks, such as the tagging commands, fit neatly into a stripe (see image next). But there were quite a few left over commands that didn't really fit together; I made a vague task "Text Entry" to house these, but it didn't seem to fit in with the ribbon ideology very well, where every control that is visible is somehow connected to the same task.

So that gives our editor product with tabs (for each document) containing the JRibbon, with various items organized by task. I decided to make each section contain a toolbar: users can pull out a section they like and don't need to continually switch between tasks in the command tab. In trialling the prototype, it seemed to me that there are some activities (notably the text Find function) that are called repeatedly no matter what the task: I am not sure what Office 12 does about that kind of case--repeat the button or just have it in one location?

This ended up looking rather Adobe-like, in the sense of making good use of a large screen, and certainly avoids the problem that Eclipse IDE (in common with may other IDEs) has in spades: the buttons you need are always somewhere else or are buried in with a zillion buttons you don't need. This screenshot shows the interface with floating toolbars: quite a good use of the extra space available on modern screens, I think.

We had previous feedback from users that menus for common functions were important because they provide a map of commonly used keystroke shortcuts. Again, I don't know what Office 12 does for this: in fact, I am not even sure where the documentation or help buttons are for the Command Tabs. (I suspect you get context-sensitive help by right-clicking on a control or object.)

So after implementing the prototype, but before getting user feedback, what are my impressions of the kind of ribbon interface that is easy to build with JRibbon and Toolbars? Very positive!

• I did not intend to go all the way and get rid of menus entirely, but certainly I was able to halve the number of menus. And the menu items remaining tended to be about global or generic commands, not window- or object-specific commands. The interface looks less cluttered even with a reduced main menu.
• It reduces the logic required for disabling menu items that are not required at a certain time.
• It allows a more task-based approach, and I am expecting it will make the help files easier to sue, because they may naturally become more tutorial.
• Because each chunk in each task has a heading, it makes it easier for each control (such as a button) to have a smaller text heading. In the very version version we released of the editor, our menus were sectioned with internal headers: I was never comfortable about giving this up in the name of uniformity and platform-look-and-feel fidelity, so that pleases me.
• By making it legitimate to have different sized buttons (of course, this is not taxing for Java Swing) and a mix of controls, it lets the interface guide the user more about what is important or common. I always found large hierarchical menus frustrating because the position of an item in a hierarchy tends to depend on how many other related actions there were rather than how important that item is in isolation.
• The combination of (something like) JRibbon, containing toolbars, with the contents of complex toolbars being specified in an XML user interface language (I use SwixML) is really neat and workable.
• The use of -ing words for the tasks worked well. Not the least because I found that using nouns or verbs confusing and unsatisfying. Certainly, after hanging around some older people recently, I am more aware that there is an accessibility issue, in that elderly people stereotypicaly require more explicit and non-ambiguous context to do things, compared to the young.
• I made up some design consistency rules along the way:
  I made little do/undo buttons available always,
  at the left (following some of the Office screenshots):
  probably there is some class of button or action that is
  comforting to always be manifest;
  I tried to order tasks left-to-right in the
  sequence they would be performed;
  and I tried to put buttons to invoke configuration
  boxes on the right side. I was not convinced by
  Microsoft's little plus button to invoke
  extended dialog boxes: it seemed to be a barrier
  to exploration because surely users would expect
  it to act like some kind of expand/contract
  button: I know I did.
• Moving to a Command Tab GUI also provided a nice
  chance to re-factor functionality into discrete
  steps: a couple of times when making a ribbon task
  I said "Oh, there is a natural spot here for
  a button to do X" or "Doh, between these two
  tasks, the user probably will want to do Y
  which we haven't provide yet". So good for
  functional review too!
  




• The difficulties that I found were the problem of where to put miscellaneous functionality and help, and
  also I struggled with whether moving to a more task-based
  grouping of interface functionality required us to make
  assumptions about our users more than we should. The
  side effect of having more floating toolbars overcame this
  resistance: the users can pull out the tools they like.
  


• And one thing that was not clear to me was the best
  way, in
  the absense of menu items, to handle shortcut keys.
  I also had a minor issue with whether Command Tabs
  were appropriate for people with 600x800 PC screens
  and people who, for eyesight reasons, need large
  type. There are good blogs at the Microsoft site addressing the issue of real-estate utilization and the ribbon
  interface, however I have not seen any mention of
  accessibility issues.

Of course, my ribbons and Office 12's ribbons are different: in particular because mine are inside the tabs for each file. However, it was interesting to see in a recent dummy screenshot of IE 7 that Microsoft also have may allow moving menues inside the tabs, presumably awaiting some kind of future ribboning. This may be accidental, but it makes sense to me for controls relating to objects located in a particular user interface panel to be grouped on or near that panel. It will be interesting to see how MicroSoft develop Command Tabs closer to the Ofice 12 release time, and how much influence they will have on Vista's look and feel.

I have been enjoying all the recent activity on the www.javadesktop.org site, especially Guy Romain's blog (I hope Sun keep him on if his internship finshes: he is a great programmer and a clear communicator with an experienced grasp of what developers of desktop applications require.) Especially with the release of Vista and Office 12's ribbon interface, Java really needs have some of these new interface components (breadbar chooser, command tabs, siding panels) added as standard parts in the near future in order to be a competitive choice for desktop application development. That activity on that site is really heartening, from this developers POV.

Do ribbons get your ribbon?