SCALE: Understanding Unity

Canonical's Ted Gould presented a session about the Ubuntu project's Unity interface on February 27 at SCALE 9x. It would be a tad inaccurate to refer to the session as a "talk," though — Gould spent a few minutes touring Unity via slideshow and describing the goals of the project, but he reserved close to 45 minutes of the allotted hour for audience questions. That turned out to be a wise move: the audience filled the available Q&A time with a steady stream of questions about Unity's design, features, place in the desktop stack, distinction from GNOME Shell, and deployment in Ubuntu. For a high-visibility project nearly two release cycles old, it seems there is a noticeable user-confusion issue still to be solved. Partly that may just be the lot of all interface redesigns — after all, GNOME Shell certainly shares the challenge, as did KDE 4.

Unity basics unmasked

Gould's session was entitled "Unity: Why Does It Matter?," and it started with an account of the goals of the project. First, he said, Unity began as an attempt to integrate design with "soft skills" like psychology, sociology, and art, more directly into the software development process. This is the user-centric design paradigm, which is not historically the way open source software is shaped. Most often, open source fills the values important to enthusiasts (technical superiority, ability to tinker, power, and freedom), but lags on other values important to the "everybody else" crowd, such as predictability, discoverability, and look-and-feel enjoyability.

The headline changes in Unity's design stem from regular usability tests performed every six weeks at Canonical's offices in London. The process involves selecting volunteers and asking them to perform real-world tasks that they regularly undertake on their own computers, then observing and interviewing them on the results. Gould gave an example of someone who responded that they spent a lot of time uploading personal photos to Facebook, and would be asked to bring in a camera or flash drive with their photos and do the same thing on the test machine. He added that it is important that the developers and designers be present at the test sessions to talk to and get feedback from the volunteers, rather than just watch video or read quantitative results.

The biggest change in Unity is the redefining of the way the top panel functions. Users expressed trepidation about clicking on icons and menus in the panel because over the years, Windows and Linux systems have devolved the space into a catch-all for unrelated functions: menus that reveal selections when clicked, buttons that perform actions, useless eye-candy, and so on. Unity implements a strict menu-functionality-only policy referred to as application indicators. Any application can place an indicator in the menu, but clicking on it cannot itself perform an action; it can only reveal a drop-down menu.

The second piece of the system is the left-hand side launcher panel, which like many dock interfaces, holds large launcher buttons for favorite applications as well as icons for running applications, and shortcut buttons for the file browser, application browser, trash, and workspace switcher. Here, too, Unity implements a strict display policy, grouping all windows from the same application into one icon, allowing drag-and-drop reordering only within the application launcher segment, and presenting an API developers can use to add right-click functions.

Unity also presents a searchable "quicklist" application browser rather than a text-driven menu. The visual presentation is almost identical to GNOME Shell's (including categories), but it uses Zeitgeist on the back-end to search through recently-used applications, and the full descriptions in application .desktop files, not just the short name. Also like GNOME Shell, Unity places a number of common functions (including IM or presence options) in a "user menu," although unlike GNOME Shell, Unity uses a separate "system menu" for maintenance tasks and shutdown/reboot functions. Finally, Unity preserves the multiple workspaces/virtual desktop feature that has become a desktop mainstay, but implements it with a non-optional zoom-out/zoom-in effect that Gould said was found in testing to reduce confusion for first-time users.

Unity itself is a plug-in for the Compiz window manager, and relies on Compiz's existing functionality (or other plug-ins) for window stacking, focus, and transition effects. Although he described making it "beautiful" as one of the design goals, Gould said Ubuntu regards Unity as a "picture frame" designed to put emphasis on applications, not the desktop environment itself. Canonical's program of integrating testing and design in the development process, he said, is intended to inspire other projects to adopt a similar approach, and hopefully to take advantage of the new indicator and launcher APIs.

Questions and concerns

When the tour was complete, the questions started coming in from audience members. They fell into two major categories: first, questions about Unity's technical implementation, and second, questions about the changes it brings to user workflow when compared to the GNOME 2.x panel.

In the first category, it was clear that many users thought that Unity either implemented a new window manager, replaced core parts of the GNOME desktop stack other than the panel, or simply lived outside the rest of the desktop environment. For example, one audience member thought that Unity removed the ability to save files or application shortcuts onto the desktop; Gould explained that the desktop was untouched by Unity, and handled by Nautilus as it is today.

Several audience members asked about customization features, including whether the menu bar and launcher could be themed, resized, or moved. Gould explained that the background color, icons, and font used were inherited from the user's GTK+ theme, and would follow any custom theme choices made by the user, including accessibility settings like high-contrast colors or larger font sizes. Application indicators are single-color "symbolic" icons, but the menu bar tries to pick up whether the background color is "light" or "dark" and choose the appropriate icon color for visibility. The size of the menu bar and launcher cannot be changed in the current version, he said, but there is a patch in development. Similarly, a patch is in development to move the launcher to the right-hand side of the screen, which is a feature asked about by right-to-left language users.

Others asked about customizing window management features like focus behavior and window stacking or tiling. Here, Gould explained several times that Unity is a plug-in for Compiz, and relies on Compiz's existing features for that sort of function. As he put it, if you have a plugin that animates closing windows by burning them down with OpenGL-rendered flames, then they will burn down with OpenGL-rendered flames in Unity. By default, however, Ubuntu's version of Compiz will only ship with a basic set of Compiz plug-ins, and it is possible for users to install others that interfere with how Unity works. Similarly, Unity does not have its own "Expose"-like function to show thumbnails of all the open windows, because Compiz has its own function to do so.

There were multiple questions about accessing applications not permanently docked in the launcher. Gould's slide tour showcased the Zeitgeist-backed search function, which several seemed to interpret as meaning that there was no "browse" function (which there is), and that searching for an application by name was the only way to find it. That confusion might have been averted by highlighting the "Applications" button on the launcher during the tour.

Several thought that searching for an application by name was slower than using GNOME 2's application menu — particularly when you know where the application is. One person said that "docks" like the Unity launcher are historically used only for favorites, and asked whether there was any positive benefit to removing the application menu. Gould replied that the GNOME 2.x application menu suffered from overly broad categories (such as "Internet") and that in testing, users tended to know the name of the application that they wanted to use, but not where to find it among the categories. Thus, hitting the search button and typing the application name was faster than browsing through a menu or grid of application launchers. Also, he added, the search feature returns results based not only on the application name, but the long description in its .desktop file, which makes it possible to narrow down a search query further than an application category alone can.

The user workflow questions tended to be more personal. One audience member expressed concern over the lack of GNOME 2.x-style panel applets because she preferred to use them for rapid-access tasks like taking screenshots. Gould replied by saying that she could add the same screenshot application to the Unity launcher, and for convenience, move it to the bottom of the button list, away from the "favorites" launchers and nearer to the Workspace and Applications buttons.

Another audience member, who installs Linux for new converts, asked about assigning alternate names to applications (such as "Word" for Abiword or OpenOffice Writer), and another asked about custom application categories. Gould answered that there was not a built-in facility to do either, but because the search feature indexes .desktop files, adding alternate names or additional categories to the .desktop file would implement the same behavior.

Finally, there were several people under the impression that the 11.04 Ubuntu release that includes Unity would force them to use it. Gould replied that it was a login session option, and users who wanted to use the 2.x-style panels could choose to do so.

Change

After the talk, I asked Gould briefly about how he thought the Q&A session went. He expressed surprise at some of the questions, most of all the concern about using search to launch applications, instead of a menu, saying that he thought Google had conditioned everyone to search for things as the default way to access content. He also speculated that UI changes are always met with concern because of their potential to disrupt comfortable working patterns.

That is almost certainly true when you look at the "workflow" set of questions. Most of them trace back to audience members being concerned that the new interface will slow down common, repetitive tasks. GNOME Shell, which adopts many of the same features implemented in Unity, has met with a strikingly similar set of concerns. But in both cases, it is very rare that the new interface actually removes any functionality — it just rearranges where its features are located. Communicating those changes looks like an area where both projects could use some improvement.

For example, the features of the GNOME 2.x panel has been split into two separate pieces in Unity. Some applets that behave more like menus already (e.g., Tomboy), can easily use the application indicator API to present the same functionality. Others that behave more like buttons (e.g., the screenshot applet), can offer the same functionality in the launcher. Although Gould did not explicitly say so, the hit-search-and-type-the-application-name sounds like the same basic paradigm as GNOME Do. When he answered the audience questions, the questioners generally seemed relieved. Perhaps that sort of point-by-point comparison ought to be a standard part of Unity and GNOME Shell's introductory documents.

On the other hand, it seems like Canonical has not gotten the message out about what pieces of the GNOME desktop experience Unity does and does not change, and there is no obvious solution to that problem. People were confused about its affect on the desktop, its window management behavior, its inheritance from GTK+, and other core functions. Perhaps part of that is due to the choice of wording — such as referring to Unity as an "environment," rather than as a panel and launcher. But it may also stem from its origin in the Ubuntu netbook edition, which carries with it the suggestion of a "stripped down" environment. Consider the current Wikipedia article on Unity, which highlights Unity's "more efficient use of space" in the first paragraph, and contrasts it with the "full" GNOME environment below. I would never suggest that anyone take Wikipedia as authoritative, but it is good for assessing the current general-consensus-viewpoint.

Because open source software is almost always developed by remote teams (in Canonical's case, often working from home), maybe it will always struggle to consistently introduce major new features. Most of what Gould explained in his answers is documented somewhere on the web, either on a wiki page or in blog posts syndicated on Planet Ubuntu, and yet even those users dedicated enough to spend their weekend at SCALE had misconceptions and questions. GNOME recently held an IRC "user day" where core developers and designers met to answer questions about GNOME 3.0 and GNOME Shell, and had a similar experience: even those users experienced enough to be comfortable with IRC had an endless barrage of questions.

It is always enlightening to see developers interact face-to-face with end users, and that is one of the best services offered by community shows like SCALE. In my estimation, the take-away message for the Unity team is the disconnect between the lay-person's understanding of Unity and what it actually is and can do. How to improve on that, though, is not so obvious. Come up with the answer to that one, and I guarantee you will draw a packed house at SCALE or any other open source software event.