"The mission statement: Create a User Interface so that OpenOffice.org becomes the users' choice not only out of need, but also out of desire." With these words, the Renaissance project was launched last week with the goal of giving the popular free office suite a face lift.
It s about time. That is my first reaction, and one I suspect I share with many. My second: Which design philosophy will prevail?
So far, project members seem to have open minds, since they will spend the next three to six months in usability standards and competitive analyses before producing a first draft of the proposed changes. But, already, I am wondering -- and worrying, just a bit -- about whether it will eventually imitate Microsoft Office, and which level of user the interface changes will be aimed at. And considering how widely OpenOffice.org is used, perhaps other free and open source software users should be concerned as well.
Few people can deny the need for major interface revisions. As OpenOffice.org stands today, with version 3.0 just released a couple of months ago, the office application is an uneasy mixture of at least three interface standards.
The bottom strata has survived with few changes since the days that the code was locked in a proprietary program called StarOffice, and developed by a German company called StarDivision. Some of that code was stripped out when Sun Microsystems bought StarOffice and released the code, and some -- like the gunmetal gray background in the editing window and dialog -- has been softened or modified in subsequent releases.
The second layer has been added since the start of the OpenOffice.org project. Some of this layer, like the dialogue in Tools -> Options for setting the version of Java used, closely follows the first layer. But other parts, such as the current editing window for the presentation application are unashamedly borrowed from Microsoft Office. Similarly, various incarnations of the PDF export have been borrowed from Adobe Acrobat. If any best practices for interfaces has guided this second layer, they appear to have been followed inconsistently at best.
The final layer consists of extensions. Although not officially part of OpenOffice.org, extensions are popular and growing rapidly in number, and some seem likely to find their way into upcoming versions. This infrastructure includes countless small ingenuities, but -- as you might expect from dozens of developers working independently -- the user interfaces of OpenOffice.org extensions varies wildly.
Such a mixture of interfaces causes endless problems. To start with, the basic interface, as a friend remarked, remains "sooo 1995," and creates a credibility problem whenever someone presents OpenOffice.org as an alternative to MS Office. It doesn't help, either, that some parts have needed fixing for over a decade, such as the bibliographical database with its misleading (and useless) examples, and the table AutoFormats, that should have been regularized into proper styles several releases ago.
Just as importantly, where should a new feature go in the already crowded menus and toolbars? As the Renaissance wiki points out, many users overlook features in the crowd. Other features that are officially deprecated, like the old text art and mail merge tools, may be easier to use, but remain unknown unless you happen across them under Tools -> Customize.
Too often, the result of all these strata is completely arbitrary placement. It makes little sense for merge functions to be scattered between the Tools, Insert, and File menus -- yet they are. Similarly, why should an Outline Numbering tool exist in the Tools menu that is independent of heading paragraph styles in the Format menu? And why is AutoText in the Edit menu and AutoCorrect under Tools?
As for the dialog windows, don't get me started. Its enough to say that, the more you look, the more you conclude that the OpenOffice.org interface was not planned so much as just happened.
Part of the problem may be that free and open source software developers have only become aware of the need for interface design in the last few years. Another part is probably OpenOffice.org's source code, which has a reputation for being cryptic and hard to learn quickly. But, whatever the reason, since the start of OpenOffice.org, the project has tended to dodge interface issues. Even the new charting sub-system introduced last year did little except change the default colors.
The problem is so vast that, when IBM revamped the interface in Lotus Symphony, a version of the 1.x OpenOffice.org code, it focused on the top level menus and mostly ignored the sub-menus or dialog windows.
Renaissance, then, is approaching a task that is not only overdue, but immensely convoluted -- so much so that six months for the first draft interface seems unduly optimistic.
Some of Renaissance's possible directions are likely to be non-controversial. Nobody, for instance, is likely to be upset if its changes include theming, and allow people to use whatever colors, widgets, and order they choose. But others may be controversial if implemented.
One controversial direction would be to imitate the Microsoft Fluent interface, and replace menus and toolbars with ribbons. As the Renaissance FAQ suggests, this direction might be a patent violation, but I have to wonder whether a ribbon interface is innovative enough that the patent could be successfully defended.