The Plenitude of Arboreal Beauty

GNOME Do 0.8.2 was just released! Peng has a great post describing what’s new. Get the application source here and the plugins source here.

Recently, the noisy debate over whether Mono poses a real threat to Linux has gotten even noisier. I’m not a lawyer so I’m not going to comment on matters I don’t fully understand, but I want to offer a constructive suggestion. No number of blog posts or vitriolic Reddit comments can by themselves generate a viable alternative to Mono. The Mono opposition needs to get serious, get organized, and channel their passion for Free software in a useful manner. Here’s how:

1. Create a mailing list where people interested in replacing Mono and/or Mono-based applications can subscribe. A quick perusal of Google Blogsearch, Reddit, Digg, and Slashdot will turn up many vociferous individuals who appear to be willing to contribute. These people need to start working together instead of participating in the same fruitless arguments over and over again.
2. Interview stakeholders. Figure out why developers like me are using Mono; I love Mono and would be happy to tell you why.
3. Conduct a competitive analysis, evaluating Mono and technologies like it. Look at C with GObject, Qt, Etoile, GNUStep, Squeak and others. Document the strengths and weaknesses of these tools for creating Linux applications. How complete are they? Are they actively developed? Why do developers pick them? Why are they popular or unpopular?
4. Using this competitive analysis data, decide on the best existing alternative to Mono.
5. Using the data about why developers choose Mono, begin to address the deficiencies in the chosen alternative. The mailing list subscribers from step 1 should be eager to help — get them involved writing documentation, reference applications, libraries, and new language features.

This will result in a compelling alternative to Mono. If it pleases developers, great new Linux applications will be made using it.

The first One Hundred Paper Cuts milestone was completed on time! Ten Ubuntu paper cuts and one Kubuntu paper cut were fixed:

1. Width of notifications seem arbitrarily small

Mirco Müller, Mat Tomaszewski, Matthew Paul Thomas and I worked tirelessly to change this to this. Mirco documents the painstaking attention to detail that went into fixing this paper cut.

2. “Archive Manager” doesn’t mean anything if you don’t know what an “archive” is

Ivanka Majic conducted a fair amount of user testing to determine the appropriate solution for this bug. Sebastian Bacher wrote a patch, but the upstream bug status is still UNCONFIRMED.

3. “Write in this folder” is confusing terminology

Reported by Marc Carson, and quickly patched by Chow Loong Jin.

4. Drag and drop of images is dangerous in evince and too easy to perform

Reported by Vincenzo Ciancia, this paper cut appears to be fixed upstream already!

5. ‘Open With’ Nautilus list is unsorted

Reported by Gavin Hamill, and fixed by A. Walton upstream.

6. Set “open” animation to glide 2, not glide 1

David Prieto reported this subtle annoyance, Dries Harnie wrote a patch, and Robert Ancell merged the patch into Karmic.

7. Search button does not toggle search field

Reported by Jan Klopper, patched and sent upstream by Jean-Louis Dupond. The upstream status is still UNCONFIRMED.

8. Spellcheck in [Pidgin], Evolution, gedit etc doesn’t recognize “Ubuntu”

Filed in 2005 by Chris Zubak-Skees, and fixed at long last by Bryce Harrington.

9. volume is set to zero when changed in fullscreen mode

Reported a couple years ago by Sebastian Barthelemy, this bug with six duplicates was finally fixed upstream.

10. “Clean up by name” -> “Arrange items by name”

Vlad Anuchin noticed this paper cut, and Bryce Harrington fixed it. The upstream status is still UNCONFIRMED.

11. PowerDevil plasma applet is too skinny, clipping off the sides of the applet

This Kubuntu paper cut was reported by Michael Marley, and fixed upstream already!

In addition to all of the contributors already mentioned, I would like to thank Lightbreeze, mac_v, Sean Goff and Ilya B for their incredibly diligent bug triage work; they have done an amazing job sifting through the deluge of new paper cuts reported daily. Now it’s time to get working on next week’s milestone, or any of the other paper cuts targeted for Karmic. One thing we desperately need is more people writing patches. If you are able to patch applications like Nautilus, please grab a paper cut and have at it. Many of the fixes are one-liners, so they’re an easy way to score some karma

Here is a tentative list of 100 paper cuts for Karmic, divided into 10 weekly milestones of 10 paper cuts each (some milestones contain an additional Kubuntu paper cut):

• https://edge.launchpad.net/hundredpapercuts/karmic

Many of these paper cuts call for trivial patches, requiring little design consideration or user testing. Some of the paper cuts would benefit from the involvement of the Canonical User Experience and Design team, so the milestones outline a schedule for Design team participation.

Guide to paper cut statuses:

• Confirmed: the bug has been reported as a paper cut and was checked at least once against paper cut criteria.
• Triaged: the bug has design feedback on it, and is ready to be worked on.
• Invalid: the bug is not a paper cut, and should be replaced within its milestone. Please mark incomplete and discuss instead of marking invalid.
• Incomplete, in progress, fix committed, etc. mean what they usually mean.

If you feel like fixing a paper cut, please assign it to yourself. If you can conduct user testing or other research, that would really help make progress on the trickier paper cuts. Some people have been blogging about paper cuts, and have even been conducting user testing with their readers, or informal surveys in the comments. Others are busy writing patches.

We are trying to fix these for Friday and we’re making great progress. Please blog, tweet (#100papercuts), and dent about paper cut progress until all one hundred are fixed!

One Hundred Paper Cuts is off to a great start. After my last post, many people began adding existing bugs to the project, and filing new bugs as paper cuts. Now we have hundreds of bugs filed, and we will probably have hundreds more by the end of the week, but many of the bugs are not paper cuts. Some people are confused because, although every paper cut is a usability bug, not all usability bugs are paper cuts; also, although we have committed to fixing one hundred paper cuts, when your bug does not qualify as a paper cut, that does not mean we do not think it’s a great bug that should be fixed.

As a reminder, a paper cut is:

• Very easy to fix.
• A bug that, if fixed, makes Ubuntu more usable for a significant percentage of users.
• A bug that affects a default install of Ubuntu 9.10. A good rule of thumb: if the bug affects an application that is not in the applications menu by default, it is probably not a paper cut. We are looking for “ambient paper cuts,” little glitches a user might encounter many times during the day.

A paper cut is not:

• A new feature. If it requires writing more than a few lines of code, or adds any new visual elements to an interface, it’s probably not a paper cut.

Now that everyone is posting their pet usability bugs as paper cuts, we need to start filtering out the noise to find the hundred paper cuts to fix for Karmic. Here are all of the new paper cuts. Please take a moment to go through one or two of them, and mark them invalid if they fail to meet any of the positive criteria above, or if they meet any of the negative criteria listed.

• If you find a bug that only affects a small number of specialized users (like this one), mark the bug invalid in hundredpapercuts with the comment “This is not a paper cut because it is not a general usability issue, but rather a bug affecting a relatively small user population.“
• If you find a bug that is not trivial to fix (like this one), mark the bug invalid in hundredpapercuts with the comment like “this bug is not trivially fixable, so it is not a paper cut.” If you are not sure whether a bug is trivial to fix or not, just leave it alone.
• If the bug is a vague rant about someone’s problems with Ubuntu (like this one), patiently ask the poster to identify the particular issue they believe to be a paper cut. If they cannot identify one, kindly mark the bug as invalid in hundredpapercuts.
• Only take any of these recommended actions if you are very confident that your decision to mark the bug invalid is correct. There is absolutely no harm in leaving the bug for someone else to adjudicate; however, there is harm if you mark a good paper cut invalid by mistake.

When reporting a new paper cut, please make an effort to identify the other projects affected by the bug. If you can go so far as to search upstream bug trackers first, and file paper cuts there, that would be incredibly helpful. Many people are reporting new bugs in hundredpapercuts without bothering to report the bug against the software project that is actually affected. If you can identify the actual project affected (for example, gnome-panel or network-manager), please mark the bug as affecting that project.

Finally, let me reiterate–when a bug is marked invalid in hundredpapercuts, that doesn’t imply that it’s not a good bug, that it doesn’t affect user experience, or that it won’t be fixed in Karmic. Thanks!

Edit: If you believe very strongly that a bug is a paper cut, mark the bug confirmed. Please don’t try to elevate the status of your non-papercut bug by marking it confirmed, because others will catch it and just mark it invalid! Everyone believes their bug is a paper cut, so avoid marking your own bugs confirmed–let a third party confirm it.

In a recent post, I introduced the concept of a paper cut as “a bug that will improve user experience if fixed, is small enough for users to become habituated to it, and is trivial to fix.” Canonical’s nascent User Experience and Design team is determined to identify one hundred paper cuts to be fixed before Ubuntu 9.10 “Karmic Koala” is released in October. We have dubbed this exciting endeavor “One Hundred Papercuts.” From the project page on Launchpad:

[One Hundred Paper Cuts is] a project led by Canonical’s Design and User Experience team to improve user experience in Ubuntu by identifying 100 small points of pain for users, or “paper cuts”, and healing them!

You can see the paper cuts we’ve found to get a better idea of what a paper cut is, or to start fixing one of them today. Here are some of my favorites so far:

Suggested output when printing a file to PDF is technical and generic “~/output.pdf”

When you try to print using your PDF printer, the PDF created is named “output.pdf” by default and saved in your home folder. Even worse, sometimes it’s named “.ps” — good luck finding that file! Let’s give the file a sensible name and consider saving it to your desktop by default.

Workspace switching via touchpad works badly

Have you ever accidentally scrolled your mouse while your cursor was over your desktop, with desktop effects enabled? If not, make sure you’re sitting down when you try it. Let’s not make our beloved users nauseous.

Width of notifications seem arbitrarily small

notify-osd bubbles can display about three words before line wrapping occurs. Making these bubbles slightly wider will decrease strain on your eyes when reading them, and will allow you to read short messages more quickly.

“Unmount” in volume right-click menu, is tech-speak and undiscoverable

What’s the difference between “unmount” and “eject”? Why do I have to choose between them when all I want to do is get my CD out of the computer?

We need your help! Help find paper cuts on Launchpad by searching through existing bugs. If you find a bug that you believe to be a paper cut, here’s how you add it to the project. First, click the “Also affects project” link on the existing bug report:

Then add the project “hundredpapercuts” to the report:

You can report a new bug if your paper cut hasn’t already been reported, but please do your best to provide enough information for others to understand why the bug is a paper cut, what needs to be changed, and how it should be fixed.

If some small usability detail has been bothering you release after release, now is your chance to step up and get it the attention it deserves. If you’ve never contributed to Ubuntu, or even Free software, this is a great opportunity to get involved and make a big difference — take ownership of a paper cut by discovering and documenting a great solution, or roll up your sleeves, check out some code, and try to fix a paper cut on your own. If we can find and heal one hundred paper cuts, Ubuntu 9.10 will surely be the most usable release of Ubuntu yet. Let’s get to work!

Edit: Feature requests are not paper cuts. Also, please think twice about reporting a paper cut if it only affects a very small number of users; we’ve only allocated resources for 100 paper cuts this cycle, so we want to choose them carefully to maximize user benefit.

Edit #2: For this first cycle of 100 paper cuts, fixing a paper cut should improve the usability of the default Ubuntu experience. In other words, a bug that does not affect a default installation of Karmic does not qualify as a paper cut at this point in time.

For Ubuntu 9.10, the Ayatana Project together with the Canonical Design Team will focus on fixing some of the “paper cuts” affecting user experience within Ubuntu. Here I offer an example of a paper cut and a preliminary definition of the term.

Let me introduce you to Launchpad bug #302231, the perfect example of a paper cut. In the screenshot below, you can see GNOME Do’s preferences window, opened to the Plugin configuration tab with the plugin search field highlighted in green. When a user opens Do’s preferences window, most of the time that user is going to enable, disable, or configure a plugin. For this reason we worked very hard to make the Plugin configuration tab easy to understand, and not only simple to use but fun to use as well. We also select the Plugin tab by default whenever you open the preferences window.

Here’s where the paper cut fits in–the search field lost default focus at some point during development, and two releases were made in which users had to click on the search field to focus it nearly every time they configured plugins. This is a very small detail, and it was extremely simple to remedy, but it slipped through the cracks for two successive releases before I sat down to fix it. Part of the reason I put off fixing it is because it seemed inconsequential, as the amount of programming required to fix it was so small compared to other bugs in the application. Also, as with many other paper cuts, users (myself included) became habituated to this annoyance, learning to ignore and work around it.

Even though this was a small bug with a trivial fix, fixing it improved the usability of the application dramatically. Once fixed, the experience of configuring the application became significantly less painful, and this bolstered an aura of usability surrounding the entire application.

From this experience, I would say that a paper cut is a bug that will improve user experience if fixed, is small enough for users to become habituated to it, and is trivial to fix.

It’s been a couple months since I left Los Angeles and Idealab to move to London and join Canonical’s new Design and User Experience team, which Mark blogged about in September:

We are hiring designers, user experience champions and interaction design visionaries and challenging them to lead not only Canonical’s distinctive projects but also to participate in GNOME, KDE and other upstream efforts to improve FLOSS usability.

The team is shaping up very nicely. We just got back from two fantastic weeks in Barcelona — one week spent meeting our new colleagues at AllHands, and one week spent establishing new design processes with the community and planning Karmic at UDS.

I will follow up with more detail about what we’re working on for Karmic once my jetlag subsides and I can write more freely. Before I finish I want to give kudos to Mark Shuttleworth and Ivanka Majic for putting together such an amazing team of artists and user experience fanatics. Free software has a beautiful future.

In my senior year of high school, I took an amazing course called “Men’s Studies.” Some of the questions we tried to answer in this course included: what male stereotypes do we find on television and are they harmful? What is ‘machismo’? What does it mean to be masculine? Who in the class is least masculine? Most masculine? What does the emotional life of a man look like? What can you tell about a man from the way he hugs other men?

Years of studying philosophy have brought me closer to understanding what it means to be a good person, but this high school course has been my singular exploration of what it means to be a good, healthy, happy man in particular. The course made me acutely aware of nearly invisible cultural cues that I now understand to be tremendously damaging to men and women alike.

One cue that I see time and time again is found whenever people ask me how my parents feel about my independent, adult life. Before graduating, I lived with my mother and father continuously from the time I was born for about eighteen and a half years. See if you can spot the cue:

“David, I bet your mom was pretty sad to see you move away for college!”

“David, do you call your mom from college? I know she misses you!”

“Your mom must be so excited for you to come home on your college break!”

“David, how does your mom feel about your move to Los Angeles — you’ll be so far away!”

“Did you tell your mom you’re moving to London?! How does she feel about it?”

Did you spot it? I invariably retort “what about my dad?” when asked these questions.

Here’s one more cue. A good friend of mine was told by his father for the first time that he had made his father proud. My friend was very happy and a little choked up to hear this, but when he told me the good news, he said it was “a little gay” for his father to say this to him.

Something really stinks here. Frankly, I think that an unconscious homophobia undermines father-son relationships, and that this may be the primary cause of the emotional bastardization of men. Anyway, I haven’t thought it through too carefully, and I’m pretty sure Freud has something to say about all of this, but for some reason this was on my mind today.

We’ve just released GNOME Do 0.8, and it’s ridiculous. Please check out the release notes, and Digg it!

Read what Jason has to say about docky.

So there was a tiny ah-ha moment, and it became clear that GNOME Do already knows what applications you use most. Not only does it know what applications you use most, but it knows what music you listen to, what people you talk to, what bookmarks you use the most. Why not let GNOME Do add some of these to the Dock? Obviously we wont remove the ability to manually add and remove things from the dock (you can even manually remove these automatically found items from the dock in the same way), we just augement that with the ability to have a Dock that is more adaptive to who you are.

Alex is always entertaining. Check out Peng’s thoughts. Kalle has something to add. Mike joins the party. Cimi likes it too.
Read the rest of this entry »