Who, who does not want to wear a ribbon?
This week Microsoft unveiled the new UI approach in its upcoming Office 12 suite. The best starting point would be reading this blog and downloading the interview with the UI design lead of Office here. It's 618 MB (41 minutes long) and worth every minute of it.
I'm not going to go into the details (see the above two links), but the impact on the corporate-oriented applications in the next few years is going to be immense. An average corporation (not in IT field) does not use Macintosh, Solaris or Linux. Your average Luisa and Tom continue clicking on Office documents, unaware of open-source alternatives. And why should they, it's not like they are paying. Luisa and Tom notice that every two-three years the UI colors change a little, a bunch of new menu items and tool bars are added, and continue using the same set of 10-20 buttons and menus. For them, editing an Excel chart inside Word document is a regular thing. They are completely unaware of the complexity of the underlying code.
However, once every two months they need to do something special to their document. After a quick scan of hundreds of menu items and tens of toolbars and taskbars (in Word 2003 there were 1500+ options), they go to that "wiz kid" down the hall. The kid does the magic, Luisa and Tom go on, satisfied that Word can do it, and slightly worried that there may be other great stuff around that can make that document look better.
And now a switch to our Java world. The last two years have seen an unprecedented competition between Java IDEs. I can only speak for Eclipse and IDEA, as i use them at work and at home, but from brief occasions when i run NetBeans (majorly to show off my LAF lately), the trend is the same there. Hundreds of features added with each release, waiting in some obscure menu for that "wiz kid". Sure, we may know way more shortcuts than average Word user, but can you really say that you know and use every last feature of your IDE? Unless you develop / design / test that IDE (and most probably not even then), you are like me, happily settled with 30-40% (i really hope so).
Here i must take a short time-out and say that i have never used Mac / Solaris / Linux neither at work nor at home. All of the below (and above) is relevant for Windows.
Now, the task-oriented approach of Office 12 is certainly not new. About three years ago when we started using Eclipse at work, i was very unhappy with the Perspective concept. Up until then, i was a happy (?) user of JBuilder and MS Visual Studio 6, where everything is there for you to see. You need a stack trace window - open it. You don't need it when you write new class - close it. It took me about a week to realise the truly revolutionary approach of Eclipse perspectives (i really hope that Eclipse was the first to use it, but if not, it was the first for me). Laying out windows specific for a certain type of task, and switching between perspectives in a single mouse-click is still one of the biggest advantages of Eclipse over IDEA (don't you just hate those tabs that pop automatically?)
This same approach will be now mainstream (rest assured, Windows is still 90%+ of the IT market, despite what slashdot crowd would like to believe). Luisa and Tom will have no choice but using it. It's not them making the decisions - you come to work one day and there's an e-mail in your box from the head of IT department. It says "We are happy to announce that effective today our corporation starts working with Office 12". And it's not like Luisa and Tom have an option of uninstalling Office 12 and going back to Office 2003. Neither do I. Where i work (about 15.000 employees), all external and internal communications is in Office. Once the decision is made, it is for everybody. Once new documents are written in Word 12, i wouldn't be able to review / print / correct them in Word 2003.
From what i saw in the above video, the experience of Office 12 will be much nicer. Little by little I will come to expect that from my Java IDE (be it Eclipse, NetBeans or IDEA). The whole idea of ribbon with "Write / Debug / Refactor / Package / Document / ..." tasks just makes me click on that "Become NetBeans / Eclipse contributor" link. The Eclipse perspective is not enough. Sure, the windows and the toolbars change, but they are on top of each particular inner window and the menus stay the same. It was a giant step forward, but Office 12 takes an enormous leap. I think that the first IDE to embrace this approach will obliterate all others.
However, this approach works only for very big applications with hundreds of available actions (such as office applications or IDEs). Now that I think of it (and i'm too lazy to edit what i've already written), the SwingSet demo application has employed the same approach, grouping component demos with toggle buttons. But i digress. An application written by less than 50 people over less than 5 years (unless it's very user-interaction oriented) will have hard time trying to classify its UI scenarios under tasks. So, the end of menubar/toolbar applications is not near.
And now to the eye-candy. Here is how pre-release pre-beta Word 12 ribbon looks (sorry, you would have to scroll):
Having read this entry, a comment caught my eye: Menu oriented and the slick presentation of the widgets difficult to achive for all but L&F developers (and/or Romain ;). Well, i'm not French, but i am an L&F developer, so the latest Flamingo drop provides the ribbon component with customizable UI.
The source files are right here. The following sketch outlines the ribbon terminology (as it currently stands in MS / blogs / my own head):
The whole ribbon is (predictably) ribbon, toggle button along with its corresponding controls is task (logical entity), and a group of task controls is band. The corresponding classes are JRibbon (which is a JComponent), RibbonTask and JRibbonBand (which is also a JComponent). The JRibbon and JRibbonBand have their own UI delegates (i'll write Metal and Ocean inheritors to make sure that they allow easy plugging. Currently there is only Substance inheritor). These delegates provide basic drawing and layout capabilities (such as proportional layout of task bands on application resize).
The JRibbonBand is composed of two areas, title pane (UI provides a protected function for pluggable LAF override) and control panel. The control panel contains all band controls, and is responsible for the layout. Note that the layout must be supplied by the application itself, as only application knows what to do when too little space is available (remove icon labels, make smaller icons, hide some icons grouping them in popups or combos).
The JRibbon's upper portion is for regular controls (QAT in the video) and for task toggle buttons. The bottom portion is for the bands of the currently selected task.
In addition, i have added a JButtonStrip component (with pluggable UI delegate) that allows visual grouping of buttons (not only toggle buttons).
And now, after making sure that most of you are asleep by now, here is how it looks in the demo application:
Note that the icons are created programatically, so they are slightly different (and sometimes horribly looking) from the Word 12 screenshot. However, the approach is the same - you have QAT panel on the top left, task toggle buttons on top and task bands on the bottom. You are welcome to run WebStart demo and play around. Note that the second task is composed of screenshots, but the first one has real toggle buttons, buttons and combos. In addition, elements with down-pointing triangle have associated popups on mouse click. Here is a screenshot of the entire test application (click to enlarge):
This work has started yesterday evening and took about 15 hours to complete (half of which was spent on a 1100-line long class that draws icons). This only goes to show that either that it's terrible, or that Swing allows you to do anything in a reasonable amount of time.