The Future Facelift of OpenOffice.org

Datamation content and product recommendations are editorially independent. We may make money when you click on links to our partners. Learn More.

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

Digging through the interface layers
Imitation is the sincerest form of desperation
The possibility of dumbing down
Conclusion
RELATED NEWS AND ANALYSIS

Digging through the interface layers

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. It’s 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.

Imitation is the sincerest form of desperation

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.

But, leaving the question of patents aside, a switch to ribbons would evoke mixed reactions. A few people seem to like ribbons, and you could argue that OpenOffice.org would be more likely to attract MS Office users if it had them. But, by my unscientific count, Fluent has three people who hate it for every one who likes it, and OpenOffice.org would run the risk of being dismissed as a clone if it were to use ribbons — a label that the project has understandably been at some pains to avoid. In fact, Fluent is so unwelcome that there is even a commercial software product designed to give MS Office users classic menus again.

Nor, as the Renaissance FAQ points out, is there any indication that ribbons have any advantage over standard menus and toolbars. My guess is that ribbons are not innovative enough to have any advantage, because all they do is combine menus and toolbars in a different way.

Just as important, ribbons will be undesirable if Renaissance sticks to its concern about making features accessible. One of the main results of ribbons is that some broken parts of MS Office such as master documents are hidden. Users also complain about having trouble locating features that are included in Fluent, although that may be due more to unfamiliarity than any design flaw.

The possibility of dumbing down

Another disturbing possibility is that Renaissance will follow the lead of network applications, and dumb down OpenOffice.org. Judging from Renaissance’s wiki, the possibility of removing features seems remote, but Renaissance could dumb down OpenOffice another way by reducing the emphasis on styles.

As you may know, styles are a way of setting format once, then applying it in a number of different locations with a few mouse-clicks. Although the first application of a format takes time with styles, in subsequent applications styles are much faster than manually applying formats in each individual instances — especially when combined with reusable templates.

Most office suites use character and paragraph styles. However, OpenOffice.org uses them far more extensively. In the Writer word processor, character and paragraph styles are joined by page, frame, and list styles. Other applications also use them more extensively than their equivalents in other office suites do — so much so that many tasks either can’t be done or take more time if you do not use styles. Styles are actually what makes OpenOffice.org not just a word processor, but also a surprisingly flexible desktop publishing program as well.

But, despite their convenience, styles are an intermediate or expert users’ feature. Unlike manual formatting, they take time to learn how to use, which is probably why most network applications either de-emphasize them or do not use them at all.

Undoubtedly, basic users would view the reduction of OpenOffice.org’s emphasis on styles as a much-needed simplification. More advanced users, though, would consider such a change a crippling reduction in functionality. Perhaps more could be done to make manual formatting easier in OpenOffice.org, but those of us who rely on styles can only hope that Renaissance’s usability testing involves different levels of users, and not just basic ones.

Conclusion

What directions Renaissance will take is still uncertain. Even if the initial timeline for the first draft interface proves realistic, the revamped interface is probably two or three years from completion.

All the same, it is not too early to start watching and supporting the project. You could start by answering Renaissance’s initial survey, and continue by providing input whenever the opportunity arises.

Despite the kludgy interface, OpenOffice.org remains the premier office application in free and open source software. That makes Renaissance an influential project, and well-worth the time to help ensure that it’s done properly. Otherwise, we run the risk of Renaissance being still born.