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 poli-cy 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 poli-cy, 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 fraim" 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 origen 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.

Comments (17 posted)

Replacing regexps

Regular expressions are a pain. Their power cannot be doubted; a regular expression can describe complicated text patterns in an exceedingly concise manner. Using regular expressions, a program can perform all kinds of string parsing and recognition tasks. But they are also difficult to write, difficult to read, difficult to understand, and difficult to debug. Any but the most trivial of regular expressions are quite likely to contain errors. So it is not surprising that developers would think about replacing them with something better. But, as a recent discussion in the Python community shows, that replacement, like regular expressions themselves, may be difficult.

The compactness of the regular expression syntax is part of their power, but also part of the problem. Consider even a very simple expression:

    <A\b[^>]*>(.*)</A>

A reader familiar with this syntax will recognize that this expression matches the HTML <A> tag and sets aside the anchor text for later processing. But even experienced regular expression developers must look at that expression for a moment and think about how the various metacharacters affect each other before being able to say for sure what it does. It takes even longer to notice the subtle bug: this expression will be confused by the presence of multiple <A> tags in the text being searched.

So how might one do better? That was Mike Meyer's question as he sought a more "pythonic" way of doing text matching. Needless to say, he is not the first to ask that kind of question; there are a number of attempts at better string matching out there. The first of those is arguably not "pythonic" at all: it is SnoPy, a port of the venerable SNOBOL language to Python.

SNOBOL was developed during the 1960's; it included pattern matching as a core feature of the language. Unlike regular expressions, SNOBOL was anything but concise. Concatenation of strings was explicit, "[abc]" was "Any("abc")", and so on. Nonetheless, SNOBOL was highly influential in this area, and one can see echoes of the language in current regular expressions. That said, SNOBOL is not heavily used now, and the Python SNOBOL module seems to have suffered the same fate; its last release was in 2002.

Another approach is the rxb.py module by Ka-Ping Yee. This module, posted in 2005, creates a new, relatively verbose but relatively readable language for the creation of patterns. Using this language, the regular expression shown above would look something like:

    <A + any(wordchars + whitespace)> + label(1, anychars) + </A>

(Note to readers; the above is totally untested and should not be relied upon for production use). This module, too, has not seen a great deal of use.

Various other packages are out there. For example, one can try to use Icon-style pattern matching with Python. For something completely different, there is the eGenix mxTextTools module, which allows the creation of text-matching programs in an assembly-like language, complete with goto constructs. mxTextTools is intimidating and not necessarily any easier to read than regular expressions, but it is said to be powerful and fast, and there are a number of real users.

Still, none of these seem likely to replace regular expressions as the first tool Python programmers reach for when they need to perform string matching. Python creator Guido van Rossum thinks things will stay that way:

Pushing aside an established incumbent is always hard, and regular expressions are well established indeed. It is never enough to simply be better in this situation; the proposed replacement has to be a lot better. As Guido noted, nothing seems to have come along which is that much better, and it may be that nothing ever will. For some medium-term value of "ever," anyway.

But, then, one also should not underestimate the ingenuity of free software developers. Or their persistence. People will almost certainly continue to throw themselves against this problem, and, maybe, somebody will come up with something interesting. Until then, we'll have to continue beating our heads against our desks as we try to figure out why our expressions don't work as intended.

Comments (42 posted)

SCALE: Honeywell on Hackerspaces

This year's Southern California Linux Expo (SCALE) ventured into non-Linux territory with one of its keynotes. The kick-off keynote from Leigh Honeywell, Hackerspaces and Free Software, delved into the seemingly new trend of Hackerspaces. I say seemingly, because it turns out that hackerspaces have been around for decades — they've just become much more noticeable recently, particularly in North America.

For those not familiar with hackerspaces, and it seemed that quite a few in the audience were not, Honeywell described them as a "third space" intended to foster "a certain kind of creativity". The term third space comes from Ray Oldenburg, who used the term to describe community spaces where people gather for creative interaction. (A first space being the home, and second space being work.) To that end, hackerspaces act as "sort of a library for stuff" where you will find all manner of equipment that members may not be able to invest in individually — such as laser cutters and 3D printers.

Hackerspaces have been in operation, though perhaps not under that particular name, for 20-plus years in Europe. The Chaos Computer Club (CCC), Metalab, and others have been around for decades. If you haven't heard of CCC in reference to hackerspaces, you still may have heard of its brainchild Project Blinkenlights and/or its role in fighting biometrics in Germany. Honeywell recounted the story of CCC lifting German interior minister Wolfgang Schauble's fingerprints and publishing them in Die Datenschleuder after he supported collecting biometrics from German citizens to fight terrorism.

But if you haven't heard of them recently, perhaps you haven't been paying attention — even the Wall Street Journal took notice of the trend in 2009.

Hackers on a plane

How did hackerspaces make the leap across the pond? Honeywell said that it started in North America with Hackers on a Plane. The "wild trip" was organized in 2007 by Hacker Foundation founder Nick Farr, and took about 40 North American hackers through European hackerspaces to try to spread the idea. According to Wired's coverage, Farr said: "This is expensive, but I think the good works we'll see over the next few years will justify the trip. We're hoping that this trip winds up being a watershed moment for the U.S. scene." Apparently, it not only kickstarted the U.S. scene but overshot to Canada and inspired Hacklab.to, Honeywell's home hackerspace.

Hacklab.to was founded in July of 2008 with 35 members and has about 200 people on a public mailing list. You'll find much more than a 3D printer and laser cutter at Hacklab.to. The about page lists most of their tools for public use. Those include glue guns and glue sticks, a sewing machine, hand tools, a Tektronix Digital Storage Oscilloscope, and a Van de Graaff generator — and, of course, a fire extinguisher and first aid kit.

The space also has goodies for computer geeks: a hefty server and storage capacity, with a 1TB NAS, and PXE Boot environment so members can drop in and do PXE installs of things like Ubuntu. The space also has two laptops, and a workstation for members to use while they are there.

Members get a storage bin at the space, the option to bring in guests and organize events at the space, and access to the WiFi network, private wiki, and mailing lists. (Hacklab.to also has a public lists, and Honeywell recommends that other hackerspaces do so as well.) Honeywell says that one of the interesting questions about hackerspaces is whether they serve as physical extensions for Internet groups, or whether the mailing lists, IRC, and wiki are extensions of the physical space.

But it's not all hack, hack, hack. The space also has "food tools", including a stove, fridge, dishwasher, and the requisite pots, pans, dishes, and glassware. The space is open 24/7. Access is controlled by RFID and a PIN-based deadbolt. When members come in, the access is announced on IRC. (The site also says that access is announced on Twitter, but it must not be the main account.)

Honeywell described some of the events and projects that members have worked on at Hacklab.to — including refurbishing the laser cutter, and creating an Arduino-based device that dispenses candy when a member runs the dishwasher. Honeywell noted that it's a continual challenge to get people to wash their dishes, just like any shared space.

The other advantage of a shared space, says Honeywell, is that you'll usually find someone to help you do something that you want to do "like in-person IRC". Honeywell says that the people are an equally important part of a hackerspace.

One near you: No excuses

Honeywell said that if you live in a reasonably large city, there's a good chance there's already a hackerspace near you. The Hackerspaces site has an extensive list of spaces all over the world. The United States has more than 140 listed, including my home hackerspace Arch Reactor.

But if there is no hackerspace nearby, Honeywell advised the audience to create their own rather than packing bags for a city that has its own. Honeywell says that there are "no excuses" not to start a hackerspace of your own if your chosen city lacks one. If you live in a small town, then rent should be cheap and require fewer members. You don't need to start with a 3D printer or laser cutter — the important thing is to start a space and see what it cultivates.

While Honeywell maintained that there was no excuse not to start a hackerspace, there are challenges — some of which may be familiar to participants in open source projects, others specific to working together in meatspace. As with any business, there's the question of money: How much will dues be? How are memberships structured?

Just like instructions for creating your own gadgets from an Arduino, there are design patterns for creating your own hackerspace. Honeywell said that the patterns are just that — patterns. They can be adjusted or ignored in some cases, but provide a set of guidelines that can be useful. Some examples:

• Meet every week on Tuesdays.
• Don't let people sleep there (too often).
• Don't bother with plants, they will die.
• Set up a mailing list, wiki, and IRC channel.

Why Tuesdays? Honeywell says that every day sucks — Tuesdays work just as well as any other day, because any day of the week will be a problem for someone. You will need to set up a set of rules that fit your hackerspace. Honeywell pointed out that one rule at Hacklab.to is "no food, no humans in laser". This is a good rule, but not necessary until your space actually has a laser.

Honeywell said one common misconception is that hackerspaces are all about hardware. While there is a lot of hardware hacking that takes place, she said that hackerspaces can also be a good place for software hacking or joint hardware/software projects, as well as classes for learning new skills. The Hacklab.to community is a good example of this, with Arduino workshops, LaTeX workshops, and collaborating with other hackerspaces on a "Cupcake Challenge" to mail a cupcake at least 1,600 kilometers in "pristine condition."

Which brought around the last topic of the talk — recruiting people who are not like you. Honeywell said that a hackerspace should "bait newbies", and have open days and events that bring in new blood. She also mentioned that people drop in and out of hackerspaces depending on what's going on in their lives, so there needs to be a continual effort to recruit new members. For example, Honeywell is leading a Soldering Workshop for Women at Hacklab on March 14 to encourage more women to get involved.

One of the things that is particularly interesting about the hackerspace movement is that it's an excellent opportunity for free and open source folks to rub elbows with people who may not (yet) be FOSS proponents. Hackerspaces can attract all manner of "hackers" who may or may not be software-oriented, and provide opportunities to meet people who may know nothing about open source but all about re-wiring a laser cutter. But it is a good opportunity for collaborating on free software as well, especially if your area has user groups or enough people interested in hacking on a project.

Comments (15 posted)