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
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.
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.
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:
We will not get anywhere concerning the issue of this thread by conducting
a survey. Normal users will not understand what we want from them. They
cannot experience the UI. So they have to imagine what this UI would mean
to them - and this will lead to a major variance in data - and the results
will be worthless.
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:
much depends what people want really. If they want a hyper-simple UI to
do simple stuff, that's fine, if code shows up that is maintainable &
works, we'll include it of course.
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.
to post comments)