A proposal for a LibreOffice UI overhaul

The Document Foundation split from the OpenOffice.org project just over one year ago, and has merged new features into LibreOffice, as well as cleaned up the code base and project infrastructure. The next milestone release, version 3.5.0, is in beta testing, and things appear to be running smoothly. To some contributors, then, now is the right time to revisit the office suite's user interface — an interface that can be complicated, given the scope of the components the suite includes.

Volunteer Miroslav Mazel has attracted significant attention with his series of UI mock-ups, which he calls "Citrus." Mazel was active during OpenOffice.org's Project Renaissance brainstorming effort in 2009 and 2010, submitting a detailed proposal, and is now part of the LibreOffice Design Team. Nevertheless, the Citrus designs are his personal work, not an official product of the Design Team. Consequently, they face a long road ahead before they would reach the actual LibreOffice repositories.

The Citrus work builds on many of the same ideas in Mazel's earlier OpenOffice.org proposal, most notably the removal of dialog boxes wherever possible, the use of contextual menus, an innovative way of color-coding buttons (and other UI elements) by their intended use, and moving key functionality to a sidebar that sits next to the open document. But while that proposal was primarily a text-driven description of concepts, Mazel has been creating mock-up images for Citrus, and blogging about them frequently.

Peeling back the layers

The Citrus idea has morphed over the months that Mazel has been working on it. At present, he breaks the ideas into five main categories: reorganizing the commands, adding "inline" controls, integrating the various navigational tools, adding support for open font repositories, and simplifying the Draw vector graphics application. In addition, all of the mock-ups sport a minimalist, light-gray widget theme that represents a distinct departure from the current LibreOffice look-and-feel.

The command reorganization is the most substantial set of proposed changes. It involves breaking all of the commands into groups based on what part of the document editing process they affect — e.g., application-wide functions, document-centric functions, and separate categories for altering document display, inserting content, or operating on a selected object. The menus then change content depending on the state of application: if the user selects an image, an "Image" menu appears; if they select several items, a "Group" menu appears. At no point are inactive menu commands visible. Mazel also suggests regrouping the toolbar buttons to match the menu layout, and making sure that all functions are accessible from a menu, a toolbar button, and a keyboard shortcut.

The inline controls changes center around a "floatbar" — a small, floating toolbar that appears just above a selected object. Like the menus and toolbar, it is context-dependent, so when text is selected, only font and style functions appear in the floatbar. He also proposes adding a "new page" button to the bottom of every document (where it would be closer to the cursor when the user is editing the last existing page), and using "handles" to select all objects — including full pages, which must be selected in order to change page-specific settings.

The "navigator" is a sidebar that integrates the Find/Replace search box, the built-in Help search tool, and an in-document browser that allows the user to jump between pages, slides, or document sections. This feature is akin to the slide thumbnail browser already used in the LibreOffice Impress presentation tool, but is also similar to document sections in Writer and analogous navigation aids in the other applications. It is also intended to hold some of the selection tools, so that there is one place to go to perform a "select all" on a particular content type (image, table, etc.).

The font integration proposes two changes: a reworked Font drop-down menu, and under-the-hood support for loading and using remote fonts from open font repositories like the Open Font Library or League of Movable Type. Mazel proposes that LibreOffice support transparent fetching of fonts from these remote sites, creating the notion of "supported" fonts that are accessible to all LibreOffice users even if they are not locally installed. He recommends showing only supported fonts in the font selector by default, as well as sorting the fonts into categories (serif, sans-serif, monospaced, handwriting, and "display" fonts).

Finally, the drawing changes include adding an "insertbar" (a vertical toolbar docked on the left-hand side of the window) that holds buttons for inserting various objects into the document, a layer-management tool for the sidebar, and a pop-up color picker.

Sprinkled throughout the mock-up images are an assortment of notes that point to other features, such as the monochrome, indicator-style button icons, and the color-coding of objects by their function. The image used to illustrate the layers tool, for instance, also describes the color-coding scheme. Red icons are used for animated and video content, orange for images, yellow for vector shapes, green for tables and data cells, blue for text, and purple for audio. Various shades of each color make subtle distinctions between related element types, such as selected words and selected paragraphs.

Response

Mazel's mock-ups have generated a lot of praise on Linux news-discussion blogs in recent weeks, although the positive feedback focuses largely on the look and feel of the widget set used, rather than the more functional proposals. Within the LibreOffice project, most of the debate around Citrus has come on the libreoffice-design list, where the Design Team and interested community members regularly discuss and refine user experience (UX) issues.

On the list, the attention from various blogs sparked several discussions in mid-to-late November. The mock-ups have attracted both ardent supporters and critics with detailed concerns. Stefan Knorr pointed out several issues related to the command reorganization. The strict-ordering of commands in the toolbar is problematic because LibreOffice users have long been able to customize their toolbars, he said. It also diverges from the decades-old menu structure other office applications use, in ways that may confuse users. Knorr went on to say that the menu reorganization "is throwing (useful) conventions out of the window: should we really move Cut, Copy and Paste into completely different menus?"

Knorr did not care for the insertbar concept, but Kévin Peignot liked it, as well as the floatbar. However, he too disagreed with the menu reorganization, saying that "the current menus, even if not perfect are great." He also observed that color-coding UI elements can have unintended consequences, such as the fact that red is generally used for alarms and other "attention needed" urgent messages. Knorr also pointed out that color-coding icons could put color-blind users at a disadvantage.

Commenting on a similar UX proposal from another user, Design Team lead Christoph Noack observed that context hierarchies are very tricky to get right for all use cases, and that LibreOffice must cope with additional challenges like cross-module functionality and extensions. Opinion on the design list is divided on many issues, particularly the menu restructuring and context-dependent functions, but on a lot of minor changes, too. Some individual elements fared particularly well, such as the "add page" button, but ultimately, no consensus was reached.

Peignot floated the idea of a user survey to gauge broader support for many of the individual changes, but Björn Balazs (a psychologist with experience in user surveys) cautioned against using such a survey to measure acceptance for a new UX:

Balazs also warned that the discussion around Citrus needed to be grounded in the fact that the mock-ups came from outside the official project, and "is not on the agenda of any LO-developer." That stance is borne out by comments on the developers' list, where Michael Meeks said:

He also expressed concern that mandating a Citrus-like interface risks alienating enterprise and power users.

From mock-up to code

Balazs' comments about the future of the proposed changes deflated some of the more enthusiastic supporters, but he added support for the continued development of the ideas, saying: "We will get to the point where this is constructive - but at the moment it is just the opposite of it. If anyone wants to do something really [helpful]: try to find and document the small improvements that are possible to make LO rock even more." One such supporter, Andrew Pullins, then asked how to proceed getting the proposals into the LibreOffice roadmap.

The Design Team's Charles H. Schulz suggested that, for starters, the mock-ups and blog posts be developed into more detailed, feature-by-feature specifications, noting that "the developers cannot implement a complete redesign all at once. Therefore you need to push changes one by one. Little by little." Michel Renon added that the proposed changes should use the Design Team's whiteboard section, which already hosts a long list of UI and UX proposals, and recommended that the mock-up images be re-done using wireframe graphics, so that the aesthetics of the theme do not distract from the UX discussion.

Renon emphasized that while he has nothing against the Citrus mock-ups or UX proposals, it is important for the project to make it clear to the public that Mazel's work does not represent an official or approved direction for the LibreOffice user interface. "I would propose to use a neutral form: "future UI". So let's make a lot of one-step proposals to reach one day the "future UI"!"

On December 5, Mazel began to draft more detailed specifications for his proposed changes in the whiteboard section of the wiki. They indeed focus on small changes, initially covering only the "add page" button, insertbar, a full-page-select button, and an "overflow" button to capture toolbar buttons that do not fit on screen. Incremental changes to the code may not be as exciting to look at as full-blown UI renovations, and the path to ultimate adoption by the project is still long, but the Citrus mock-ups are finally beginning to make their way into the project's workflow. As the public discussions over Citrus show, many users and project contributors seem to agree that LibreOffice is in need of a UI and UX refresh. What it will end up looking like, however, won't be known for some time to come.