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.
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.
Comments (17 posted)
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
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 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
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
<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
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
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:
I fear that regular expressions have this market cornered, and
there isn't anything possible that is so much better that it'll
drive them out.
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
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)
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
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)
Page editor: Jonathan Corbet
Inside this week's LWN.net Weekly Edition
- Security: Seunshare, /tmp directories, and the "sticky" bit; New vulnerabilities in acroread, clamav, firefox, logwatch,...
- Kernel: Waking systems from suspend; Capabilities for loading network modules; Who wrote 2.6.38
- Distributions: SCALE: Projects and distribution unfriendliness; Fedora ARM, FreeBSD, MeeGo, Debian ARM, ...
- Development: Choosing between portability and innovation; GNU Radio, Mercurial, SciPy, xorg-server, ...
- Announcements: Ada Initiative, Document Foundation, MeeBlip synthesizer, DoD and Open Source Software. ...