How did you get started in Open Source?

I had to build a UNIX shell and UNIX-like kernel for a university course on operating system design. After running into incompatibilities between system calls on Mac OS X and the Linux-powered lab computers, I installed Ubuntu on my Mac to align my development environment with that of the lab computers. At the end of the project, I remember thinking “this Ubuntu thing has everything I need, maybe I should stick with it.”

The following summer I worked at Google with Sean Egan, who was the maintainer of Pidgin at the time. Sean described what it was like to run an open source project, and I thought the responsibilities involved sounded really exciting.

The one application that was preventing me from making the switch from Mac OS X to Ubuntu was Quicksilver, a keyboard launcher application by Nicholas Jitkoff. For my senior thesis in Computer Science, I decided to form an open source software project to explore desktop search with the goal of ultimately producing an equivalent application for Linux, and the result was GNOME Do.

How did you join Canonical?

I met Mark Shuttleworth in Boston at GNOME Summit 2008, where I spoke with him about my ideas about user experience and free software. He suggested that I stop by Canonical’s London office for an interview and to see if I’d be interested in moving to London to join Canonical’s nascent design team, and by coincidence I had plans to visit London the very next week, so that’s what I did. I decided not to join Canonical initially, but eight months later Mark asked me to attend a design sprint in Capetown and I was too excited to say no!

Where do you fit into the design team and design vision of Ubuntu?

My role on the design team is “Desktop Interaction Architect.” I write narratives and create wireframes to describe wonderful experiences for people using Ubuntu. Other members of the design team turn these descriptions into interactive prototypes and visual renderings that can be tested with users and eventually implemented.

When I’m not “architecting desktop interaction,” I’m trying to engender interest in user experience throughout the free software community. To this end, I’ve led the One Hundred Paper Cuts project and the recently announced UX Advocate project while at Canonical.

I’m not sure how I fit into the “design vision” of Ubuntu, but I’ll answer this question by saying that I try to encourage technical stakeholders in Ubuntu to see software not only as an opportunity to write beautiful source code, but also as an opportunity to create beautiful experiences for people.

What is Unity?

Unity is a lightweight interface for your Ubuntu netbook. Considered more generally, it’s a shell tailored for devices with small screens.

Unity comprises: a launcher that makes opening and switching between applications delightful; a panel where indicators behave uniformly; a view of your installed applications, with Ubuntu Software Center integration; a view of your files, with quick access to favorite folders, recent files, downloads, and simple browsing; and a search interface, enabling pervasive use of find-as-you-type search so you can find applications, files, and settings with a few keystrokes.

What is the vision for Unity? What do you seek to achieve with it?

Canonical recently announced Ubuntu Light, a version of Ubuntu whose interface was honed to create a fast, simple, and secure web experience. Mark Shuttleworth describes Ubuntu Light adeptly in an announcement on his blog,

…Ubuntu Netbook Light, or Ubuntu Desktop Light, will give OEM’s the ability to differentiate themselves with fast-booting Linux offerings that are familiar to Ubuntu users and easy to use for new users, safe for web browsing in unprotected environments like airports and hotels, focused on doing that job very well, but upgradeable with a huge list of applications, on demand. The Light versions will also benefit from the huge amount of work done on every Ubuntu release to keep it maintained – instant-on environments need just as much protection as everyday desktops, and Ubuntu has a deep commitment to getting that right.

The Ubuntu Light range is available to OEM’s today. Each image will be hand-crafted to boot fastest on that specific hardware, the application load reduced to the minimum, and it comes with tools for Windows which assist in the management of the dual-boot experience. Initially, the focus is on the Netbook Light version based on Unity, but in future we expect to do a Light version of the desktop, too.

There’s a lot of overlap between Ubuntu Light and Ubuntu Netbook Edition, mostly because they’re both optimized for small screens and web browsing. Unity serves as the foundation of both products so that they can share common elements like indicators and the Launcher. My short term goal for Unity is to build a fantastic experience for Ubuntu Netbook Edition 10.10 by extending Ubuntu Light to support basic application and file management use cases that are appropriate for general purpose devices like netbooks.

I’d also like to explore search further, and begin to incorporate touch. I’m very interested in using search to tame complex user journeys (but I don’t treat search as a panacea), and everyone is interested in touch devices these days.

When will Unity hit the netbook edition?

Hopefully Unity will be released in Ubuntu Netbook Edition 10.10! We have a lot of work to do before October, but with Neil Patel as the Unity engineering lead, I am at ease.

Can people participate in Unity, and if so, how?

Unity is available immediately from a PPA:

ppa:canonical-dx-team/une

After adding this PPA to your Ubuntu system (you need to be running Lucid for now), install the “unity” package, then change your session from GNOME to Unity at the login screen.

Once you have Unity installed, please play with it and report bugs. You can find me in the IRC channel #ayatana on irc.freenode.net, where my nickname is “djsiegel.” Please come talk to me about Unity–I am eager to hear your feedback and suggestions!

How do you feel Unity improves on the current crop of netbook interfaces?

I’ve already described Unity’s Launcher as “delightful,” and I really meant it. The first version of the Launcher simply scrolled off screen when full. The second version of the Launcher, due to land in time for Ubuntu 10.10, behaves completely differently. Words cannot describe it–it’s breathtaking. If someone sees you using Unity, they will ask, “hey, what is that?”. It’s not only an improvement over the current crop of netbook interfaces, it’s an improvement over personal computer interfaces in general.

The Applications Place–Unity’s view of your installed applications–is unprecedented. It lets you browse your installed applications in a gorgeous manner, and provides find-as-you-type search of both your installed applications and applications available in the Ubuntu Software Center. It’s slick.

The Files Place–Unity’s view of the files on your netbook–eschews traditional, hierarchical filesystem navigation and instead promotes search and time-based browsing. This will make Ubuntu Netbook Edition the first netbook interface with a file browsing experience powered by Zeitgeist. There is still much to be designed, but it’s already a bold and exciting experiment that challenges many longstanding assumptions about how people think about their files.

How is this going to affect GNOME Shell?

Mark Shuttleworth already addressed this question during his keynote at Ubuntu Developer Summit, so I defer to him.

Some people have accused Ubuntu of mimicking Mac OS X, what is your take?

I don’t take a position on every silly little thing that people say, but if forced to take a position on the matter, I would say “haters gonna hate.”

What do you see as the ultimate goal and opportunity for Ubuntu on the desktop?

The ultimate opportunity for Ubuntu is to make people happy, and its goal is to do so ethically by not treating its users as means to an end; Ubuntu users will be made happy by great user experience, and they will be treated as ends in themselves by not requiring them to sacrifice freedom in order to use software.

We simply cannot go on like this! We need to be able to address user experience issues at least as effectively as we address technical issues, and this starts with being able to communicate about these issues at least as effectively. If I discover a user experience issue in F-Spot, there should be exactly one person I can discuss it with, who will take responsibility for keeping an eye on it, and who will discuss and prioritize it with F-Spot’s development team. This person would be F-Spot’s User Experience Advocate, and everyone working on F-Spot would have this person on speed dial.

The User Experience Advocate is responsible for representing the interests of users within an open source project, and has the following specific duties:

• Review usability and user research documents.
• Communicate user experience research to the project team.
• Review use cases if they are available or produce them if they don’t exist.
• Review software against user experience guidelines, usability heuristics and brand.
• Work closely with the maintainer and advise on solutions that are most aligned with users needs and findings.
• Conduct usability testing or other research to support the project team’s decision making.
• Write and follow usability bug reports throughout the lifecycle of the project.
• Work closely with UX Advocates on related projects.
• Participate in the greater user experience community.

Where do we find people with these skills, you ask? We already have them! To be a UX Advocate, you don’t need to be able to create pixel-perfect mockups in Inkscape or have an HCI degree. All you need is love–you have to love an open source project and the people who use it, and you need to be patient, persistent, and persuasive. Of course, if you have some background in user experience, that would be tremendously helpful, but it’s unnecessary; it’s far better for an open source project to have a novice UX Advocate than none at all.

Many open source projects already have people serving in this capacity; sometimes it’s the project maintainer, or sometimes there’s a de facto usability expert. My goal is to ensure that all major software projects shipping in Ubuntu can name their UX Advocate by this coming October. I would be delighted if the same happens for Kubuntu, or for any arbitrary open source software project for that matter. In my opinion, if an open source project has a Maintainer, it should also have a UX Advocate.

In his keynote address at O’Reilly Open Source Convention on July 22nd, 2008, Mark Shuttleworth challenged the open source community to not only to catch up to Apple in terms of user experience, but to surpass the user experience of Mac OS X within two years. That two year period will expire in 45 days, so how are we doing?

(Before people start complaining about this comparison, let me make it clear that I understand that many Ubuntu users are not interested in Apple or any of their products, and that many members of the open source community do not share the goal of making Ubuntu’s user experience surpass that of Mac OS X. That’s fine, I understand. I am writing this because it is my duty to make the experience of using Ubuntu better than the experience of using any similar product, and because Ubuntu and Mac OS X, as desktop operating systems, are similar products, it is my duty to make the experience of using Ubuntu better than the experience of using Mac OS X. I cannot accomplish this effectively without comparing the two, but I digress.)

It is an incredibly daunting task to compare the total user experience of Ubuntu to the total user experience of Mac OS X, so instead I will attempt a cursory comparison the rate of change of user experience over the course of the last two years. Any objective critic will readily admit that the Ubuntu of two years ago, Ubuntu 8.04, did not offer the same or better user experience as the Mac OS X of two years ago, Mac OS X 10.5. To trump the user experience of Mac OS X, Ubuntu’s user experience will necessarily have had to improve more in two years than Mac OS X did.

Ubuntu, two years ago.

Here’s how the user experience of Ubuntu has improved in two years:

• The Ubuntu Software Center made it a snap to discover and install software.
• The Humanity icon theme gave us much improved, scalable icons.
• The Radiance and Ambiance themes made Ubuntu more beautiful.
• The Me Menu lets you Tweet, Dent, and change status from anywhere.
• The Messaging Menu consolidated new message notifcations.
• The Session Menu made fast user switching and other session states more accessible.
• PiTiVi Video Editor enabled video editing out of the box.
• Brasero made burning CDs much simpler.
• Empathy enabled video and audio chat on supported hardware.
• Gwibber Social Client brought Facebook, Twitter, and other social services to the desktop.
• Monochromatic panel icons reduced visual noise and made the panel feel cleaner.
• Improved window animations and effects made Ubuntu feel snappier and smoother.
• Simple Scan made scanning a no-brainer.
• The Ubuntu One Music Store puts a huge library of DRM-free music at your fingertips.
• Rhythmbox added fantastic iPod and iPhone support.
• We fixed 178 Paper Cuts.
• When you start or shut down, there is less flickering.
• Ubuntu boots very very quickly.
• Encrypted Home Folders keep your files extremely secure.
• Ubuntu One keeps your files synchronized across multiple computers and the web.
• Bluetooth Setup greatly simplifies working with Bluetooth devices.
• The Installer slideshow gives a slick overview of the Ubuntu experience.
• USB Startup Disk Creator saves time, hassle, and CDs!
• Notify OSD presents uniform, unobstrusive notifications.
• Sudoku!
• Firefox 3 brought private browsing, improved UI, better security, more speed, improved audio, video, and web fonts.
• Transmission BitTorrent Client makes downloading large files very pleasant.
• Easier configuration of multiple displays.
• Much refined installer, including a nicer time zone selector.
• Ability to enable auto-login.
• Tomboy Notes sync puts your notes on all of your computers and the web.
• OpenOffice.org v3 brought many new features and improvements.
• PulseAudio gives us better sound control for multiple devices.
• Improved out-of-the-box experience for users of Nvidia drivers.
• Mobile Broadband support lets you easily connect to the Internet via your mobile phone.
• BBC and YouTube support in Movie Player.
• Guest Account makes it easier to share your computer.
• Fast User Switching.
• Improved user account management.
• Evolution with Exchange MAPI support (not just OWA).
• Plug-and-Play printing enabled by automatic printer driver installation.
• Notification of USB device removal (i.e. “you can unplug now”).
• PDF comment support.
• F-Spot duplicate photo detection.
• Improved WINE integration.
• Autorun for media containing software.
• Tabs in Nautilus.
• Desktop background slideshows.
• And of course, improved hardware support so more things Just Work.

Now I’d like you take a look at the improvements Apple made to Mac OS X in a two year period. Please visit that link and read at least the bold text, if not the entire page.

At the very least, can we not say that these improvements are comparable? I think they are. Of course there have been some regressions, but if someone would have shown me the list of improvements made to Ubuntu two years ago, and told me that all of these changes would be made in time for Ubuntu 10.04, I would have been very skeptical.

What will Ubuntu be like two years from now if every project assigns a UX Advocate to take ultimate responsibility for the user experience of that project? It will be amazing!

Then,

Edit: Weak Mono/JVM comparison removed.

Update: wks asked me to try calculating some larger Fibonaccis to normalize runtime startup cost when comparing Mono to JVM performance:

Mono: 0.42s total
JVM (IcedTea6 1.8): 84.45s total

Go, Mono, go!

You’ll need hs-twitter, and you can run this as a script like ./jonometer.hs

Now I need to bone up on CouchDB and write version 2!

Unity running on a very small screen

Unity comprises:

• A launcher that makes opening and switching between applications delightful.
• A panel where indicators behave uniformly.
• A view of your installed applications, with Ubuntu Software Center integration.
• A view of your files, with quick access to favorite folders, recent files, downloads, and simple browsing.
• A search field, enabling pervasive use of find-as-you-type search so you can find applications, files, and settings with a few keystrokes. (This is not the search field pictured above.)

Some pieces of Unity will be defined further this week at the Ubuntu Developer Summit. Other pieces are available now for testing. Neil Patel, the engineering lead for Unity, has written a nice summary of the features we’ve started to implement, or plan to implement (or plan to plan to implement this week at UDS) for Ubuntu Netbook Edition 10.10, along with instructions for how to test Unity on your computer. You might also be interested in Mark Shuttleworth’s account of why Unity was created and what it will be used for.

I will discuss each piece of Unity separately and in great detail; this is only the opening remark in a long and exciting conversation!

Happy Ada Lovelace Day!

• Super↓E↓↑↑ triggers Expo as usual.
• Super↓W↓↑↑ scales all windows on your current workspace (hint: try typing in scale mode!).
• Super↓A↓↑↑ scales all windows on all workspaces.
• Super↓D↓↑↑ replaces Control↓Alt↓D↓↑↑↑ for Show Desktop.

Other Compiz changes have landed this week, including snappier window animations and other paper cut-sized fixes. Enjoy!

Despite being good at these things, the barrier to entry for fixing a bug in any given application (paper cuts are a very good example of the kind of bug I’d like to fix) is still very high for me. I am lousy at chasing down dependencies, maintaining clean build environments, generating patches, and dealing with unfamiliar version control systems. I know next to nothing about packaging or publishing PPAs. Some of you may read this and think, “well, that’s your fault–stop complaining and learn these things,” but I contend that there are very many talented, opportunistic programmers just waiting to contribute by doing what they do best–writing code. These eager programmers are similarly hindered by this barrier to entry, and we would benefit more by accommodating them than by insisting that they accommodate us. Furthermore, we have the ability to completely automate the stuff that isn’t software development and hide its complexity from developers–in fact, we’re already mostly there. To illustrate my point, I present my ideal user story for fixing a paper cut.

I want to fix bug #511767, “‘Hash for Duplicates’” is tech-speak.” F-Spot has a great feature for finding duplicate images in your photo library and getting rid of unwanted copies; however, this useful feature is exposed to the user under the label “Hash for Duplicates.” The user likely doesn’t know what hashing is. Besides, the user wants to find duplicates, not hash them–hashing is just an implementation detail. To fix this bug, I click “Quickly fix this bug,” right on the bug report in Launchpad:

Automagically, an application on my machine opens to handle the URL behind the Quickly fix link (e.g. lp://fix/?bug=511767). This application performs the following steps on my behalf:

1. Runs apt-get build-dep f-spot to prepare my machine to build the package affected by the bug.
2. Runs apt-get source f-spot to download a source package that can be built on my machine.
3. Opens the f-spot source in Eclipse*, where the source package is built for me.
4. …and presumably cleans up the mess after I’m done.

* Why Eclipse and not [insert your favorite IDE/editor here]? Because Eclipse is extensible, popular, cross-platform, and supports many different languages, but most of all, I picked Eclipse hoping we could just skip the endless debate where everyone argues that we should use the IDE they wrote “Hello, World” in once.

With the exception of typing my password if needed, the next thing I should see after clicking “Quickly fix this bug” is the F-Spot source package open and built in Eclipse, where I can “quickly fix” the bug:

With one click, Eclipse builds and runs the project to let me test my changes:

Looks good to me! Time to submit my changes to the Launchpad bug report. With one additional click, Eclipse can push my changes to a PPA, publish a Bazaar branch and generate a merge proposal, or simply attach the patch to the Launchpad bug report. I choose “Attach Patch to Bug Report,” so Eclipse creates a patch, opens my browser to the patch submission form on the Launchpad bug report, attaches the patch, and leaves it to me to add a comment and submit:

To summarize, this user story consists of the following steps to create, test, and submit a patch for a small bug:

1. Click “Quickly fix this bug” on the Launchpad bug report.
2. Edit the source of the corresponding package in Eclipse.
3. Build the project and test the changes.
4. Submit the patch and comment back to Launchpad.

Which version control software does upstream use for this package? How do I get the code? Which build environment or IDE do they recommend? What dependencies does the package have? How do I use debuild? I shouldn’t have to know the answers to any of these questions to fix the bug in question. Can we make this quantum leap forward in our bug workflow? Even if we were to enable “Quickly fix this bug” for only a handful of important packages, this would be a tremendous force in improving the quality of software in Ubuntu.

]]> http://davidsiegel.org/improving-bug-workflow-for-opportunistic-programmers/feed/ 27 http://davidsiegel.org/100papercuts-karmic-lucid/ http://davidsiegel.org/100papercuts-karmic-lucid/#comments Tue, 24 Nov 2009 15:34:55 +0000 David http://davidsiegel.org/?p=585 Karmic Retrospective

Long story short: we fixed 76 paper cuts for Karmic. Hooray! Congratulations! For more details, see the Ubuntu wiki page.

(I believe we actually reached 100, but many paper cuts were fixed without being reported or carefully tracked, and some individual paper cuts addressed multiple instances of a general of problem.)

What about Lucid?

At the Ubuntu Developer Summit last week in Dallas, the Canonical Design team; members of the papercutters team; and representatives from the Ubuntu community agreed to tackle one hundred paper cuts for Lucid. As an LTS (Long Term Support) release, Lucid is a fantastic opportunity for us to use the One Hundred Paper Cuts project to enrich the experience of LTS users by delivering a polished release that will stand the test of time. Bear in mind that paper cuts that go unfixed in Lucid will affect LTS users for years to come, so each opportunity to fix a paper cut is momentous. Luckily, very few disruptive changes are being introduced in Lucid, so we will be able to spend less time adjusting to major changes, and more time nailing the details.

Here are descriptions of the ten milestones structuring our effort to fix one hundred paper cuts for Lucid (see the Lucid series on Launchpad):

Round 1 “Kibosh on Karmic” (2009-12-03)

In Round 1, our goal is to fix ten of the fifteen paper cuts from the Karmic cycle that had patches attached but were not merged. After some discussion with Rick “Quickly” Spencer–the Ubuntu Desktop Team lead–we’ve established a more comprehensive workflow for landing paper cut fixes in Ubuntu: in the Lucid cycle, paper cuts with patches attached should be assigned to “canonical-desktop-team,” and “ubuntu-main-sponsors” should be subscribed to the bug report to prevent patches from languishing.

Round 2 “Kibosh on Karmic” (2009-12-10)

In Round 2, our goal is to fix the remaining paper cuts from the Karmic cycle with patches attached. Additional unfixed paper cuts from the Karmic cycle will be moved to this milestone to make an even ten.

Round 3 “Kibosh on Karmic” (2009-12-17)

In Round 3, we will finish fixing the leftover paper cuts from the Karmic cycle.

Round 4 “Paper Jam: Empathy” (2010-01-07)

Round 4 will be our first “Paper Jam.” A Paper Jam is a milestone where a majority of the paper cuts are taken from a particular domain of user experience. Our first Paper Jam will focus on Empathy; this milestone should contain paper cuts affecting Empathy’s user experience.

Round 5 “Paper Jam: Gwibber” (2010-01-14)

Gwibber is shipping by default in Lucid. Let’s help it make a great first impression.

Round 6 “Paper Jam: Sound & Video” (2010-01-21)

Movie Player, Rhythmbox, and maybe PiTiVi. These are very solid applications, so this milestone will be challenging!

Round 7 “Paper Jam: F-Spot” (2010-01-28)

With the removal of the GIMP from the default install, more weight is being placed on F-Spot’s shoulders — especially viewer mode.

Round 8 “Paper Jam: Notifications” (2010-02-04)

Fixing notification priorities and any other vagaries that pop up (ha!).

Round 9 “Paper Jam: Compiz Settings” (2010-02-11)

Clean up animations, make appearance consistent with Ubuntu’s look and feel, improve discoverability of Scale and other useful features, etc.

Round 10 “Fin” (2010-02-18)

Odds and ends.

As you can see, the One Hundred Paper Cuts effort for Lucid will look very much like the One Hundred Paper Cuts effort for Karmic, except that most of the milestones are organized around threads of user experience.

Documenting Design Decisions

In the Karmic cycle, it was often difficult to find the relevant design decisions buried in bug activity and comments. One important change to observe for the Lucid cycle is that paper cut design decisions should be documented separately on the Ubuntu wiki. When a paper cut needs an explicit design specification, append the following line to the bug description:

Design Spec: http://wiki.ubuntu.com/OneHundredPaperCuts/Spec/<bug id>

And document the design decisions there. Here’s an example spec for the unfinished Karmic paper cut, “Home Folder” has 3 different names. If you’d like to propose a solution, do not merely post a comment on the bug report; rather, please use the following template to record a solution in the design spec:


== Solution: <solution name> ==

=== Description ===
# Succinctly describe the solution.

=== Advantages ===
# List advantages of the solution.

=== Disadvantages ===
# Give at least one disadvantage of the solution.

=== Behavior Changes ===
# Specify behavior changes.

=== String Changes ===
# Specify string (text) changes.

=== Visual Changes ===
# Specify visual changes (e.g. icons).


If you agree or disagree with a proposed solution, feel free to add a bullet point to the appropriate Advantages or Disadvantages section. If you strongly disagree with a proposed solution and find it beyond remedy, please propose an alternate solution.

Sound good? Great, let’s do this!

]]> http://davidsiegel.org/100papercuts-karmic-lucid/feed/ 31 http://davidsiegel.org/haskell-unwrap/ http://davidsiegel.org/haskell-unwrap/#comments Thu, 05 Nov 2009 04:30:14 +0000 David http://davidsiegel.org/?p=566 While processing some email, I needed a script to unwrap indented lines in email headers. I wrote a Haskell program that turned out to be a short and sweet demonstration of simple but interesting Haskell features (pattern matching, guards, type inference, function composition, and the humble cons) so I thought I’d share it.

If you’re new to Haskell,

• [] is the empty list
• [a] is a list with a single element a
• x : y creates a new list by placing element x at the front of list y
• ++ is concatenate
• interact is a function taking a single argument, a function that takes a string and returns a string, and returns a bit of IO that runs the string transformation function on the contents of STDIN and prints the result
• . (period) is a binary operator that composes functions
• foldr is right-fold, and behaves like this: foldr f d [a, b, c] == f a (f b (f c d))
• Lines of the form | a = b are guards, which evaluate to b if a evaluates to True

Example usage:

[/tmp]% cat > header
This is a normal line.
This is a slightly longer line that
  wraps with two spaces.
A short line.
Another example of a long line that
    wraps with tabs (not just once,
    but twice.
Final line.
[/tmp]% cat header | runhaskell Unwrap.hs
This is a normal line.
This is a slightly longer line that wraps with two spaces.
A short line.
Another example of a long line that wraps with tabs (not just once, but twice.
Final line.


Care to share the same program implemented in your language of choice?

]]> http://davidsiegel.org/haskell-unwrap/feed/ 16