Not The User's Fault

For Firefox 4, we’re thinking of replacing the home button with a home tab. It would be a mini-tab, not taking up any more space than the current home button; it would still be “click to go home”, but “home” would be a special page that is always open in a tab.

If the contents of that special page are useful, this could be a great feature. Because the home tab is part of the browser, like an extension, it would be able to do things that a normal web page can’t, like use statistics about your browsing habits to show you useful things. On the other hand, if the contents of the home tab aren’t useful, then it’s a pointless feature.

Given that… what would you put on the home tab?

That’s the question asked by the latest Mozilla Labs Design Challenge, which is open right now. If you have some ideas, go check it out!

We’re not having a Design Lunch this week, because no topics were submitted.

If you want to see more Design Lunches, then submit a topic! Just let me know what you want to talk about, and add yourself to the Design Lunch schedule wiki page. Simple as that. Remember, design lunch is a service that we run; the purpose is to get more eyeballs and more feedback for your design problem. It can’t exist without design problems to talk about!

Meanwhile, if you’re looking for something to do this Thursday during lunchtime, I encourage you to go to Murali’s brown bag talk on risk analysis of the code changes in Firefox in 2009.

Blake (who generated all the cool graphs I’ve been using to present Test Pilot results) has used the session data from the Week-in-the-Life study to form an interesting hypothesis: That Firefox crashes per user follow a power-law distribution. If true, the power-law distribution means that “mean crashes” and “typical experience” are two very different things.

I should emphasize that the Week-in-the-Life study was not really designed to look at crashes, so I’d rather do a follow-up study specifically targeting this hypothesis before I support it with any confidence. But, as Blake says:

If our crash data follows a similar distribution, the average crash per user metric tells us little about the experience of a typical Firefox user.

Anecdotal evidence supports this hypothesis. While we all know people who swear by Firefox’s stability, we also know people who complain of frequent failures.

…

With this in mind, I suggest we use Test Pilot to run a longitudinal study of true Firefox crashes.

Agreed! And it’s great to see more hypotheses coming out of the Test Pilot data!

We’re having a Labs Night tomorrow evening, starting at 6pm PST, at the Mozilla Mountain View office. It’s the first one in a while.

Jinghua, Blake, and I will be presenting some Test Pilot results there. It should be pretty fun. There’s free food, too, as long as you sign up in advance.

See you there!

Lost Garden is a blog worth following if you’re into usability topics. It’s primarily about video game design, but it’s game design from a psychology perspective and its insights are highly applicable to other kinds of software design as well. I first heard of Danc, the author of Lost Garden, through his presentation called Princess-Rescuing Applications, which is about how video games are actually highly targeted teaching tools in disguise, about how the sensation of “fun” comes from self-directed learning in a safe environment, and how we can apply that lesson to make productivity software easy and even fun to learn.

Now it seems like someone at Microsoft -specifically Microsoft Office Labs – has taken that lesson to heart and created a game meant to teach Office skills. It’s called Ribbon Hero. Lost Garden has an in-depth post about it here.

Even if “Ribbon Hero” doesn’t sound very exciting to you, I think this is an idea with a lot of potential and an exciting approach to improving usability of large, complex apps. I’ll be keeping a close eye on its development.

Edited to add: After watching the Office Labs video, I think one thing they’re missing in the current prototype is that the way the tasks are described to the player uses a lot of Office jargon, e.g. “change the orientation from portrait to landscape”. This jargon is in itself one of the barriers to learning complex productivity apps, so I think Ribbon Hero would be better if it described challenges without jargon, and made learning the terminology part of the game process too.

Mozilla has a Design Lunch every Thursday at lunchtime. The idea is that one or more people bring design questions that they’re working on – whatever is currently puzzling them. They present their design questions and the audience provides feedback and suggestions. I’ve been the MC of these lunches since we started them last year.

From now on I’m going to be announcing all the design lunches on this blog so that they’ll show up on Planet Mozilla. (This seems like such an obvious thing that I don’t know why I haven’t been doing it until now.)

So! Today’s Design Lunch will be on the Support.mozilla.org forums and how to improve them. It will be broadcast on air.mozilla.com starting at 12:30 PST today.

We’re broadcasting a launch event right now on Air Mozilla. So far it’s a lot of people at a table typing on laptops, so a little like watching C-Span, but later (9PM PST) I’ll be doing some live interviews with various folks who contributed to making 3.6.

Today also happens to be my 30th birthday. It’s a good day all around!

Edited to add: you can watch the progress of 3.6 downloads on an animated world map.

Here are my thoughts on things we did well in Ubiquity, and things we should have done differently, and areas for further exploration that we can get into when we start working on the project again. It’s all a bit long and rambly, and the parts aren’t in any particular order, but I want to put it out there to get discussion started.

What did we learn from a solid year of working on Ubiquity? Here goes.

(more…)

If you’ve been following Ubiquity, you know we haven’t made a new release of the extension since last summer. What’s going on?

Last October, Mozilla Labs got together and had a meeting about all the things we want to get done in 2010. It became clear that there were too many things on our plate, and we had to make some hard decisions. Ubiquity was one of the things that was put onto the back burner in order to focus better on Weave, Jetpack, Bespin, and other core projects.

Everybody I’ve talked to at Mozilla loves Ubiquity and would love to see it developed further — but all have agreed that the other projects are higher priority. Ubiquity remains an exciting experiment and I personally look forward to the time when I can work on it again. But for now I’m focused full time on Test Pilot.

Does this mean Ubiquity is dead? Not at all! It’s an open source project with a fairly large installed user base, and if you look at the Mercurial repository and the mailing list you can see that the community is still active fixing bugs and answering user’s questions. It’s clear that the Ubiquity community has taken on a life of its own and is capable of further development with or without direct involvement from Mozilla Corporation employees.

We’ll probably be releasing a new version of Ubiquity sometime soon, just for the sake of maintenance. The last released version isn’t compatible with Firefox 3.6, and the lack of compatibility is harming the many people who still use Ubiquity on a daily basis. Making it compatible should not be very difficult, since the “trunk” (the latest development code) is compatible with 3.6 to the best of my knowledge. So we just need to roll up a new release and get it out to people. We should be able to get that out this week or next week.

We’re also working on analyzing the first round of Ubiquity experimentation, so that we can figure out what to approach differently when we begin the second round. Yes, I’m pretty sure there will be a second round.) I’ve been writing up my thoughts on what we learned during the first round. It’s turned into quite a long essay. Not exactly a “post-mortem”, as that would imply the project is dead; call it a “retrospective”. Look for it within the next couple of days.

“An undefined problem has an infinite number of solutions” – Robert A Humphrey

I found that quote on the underside of a tea bottlecap. I think it’s germane to what we’re doing with Test Pilot.

In the months since we started the Test Pilot program, we’ve run three studies, which have collected massive piles of data.

But as the bottlecap warns, those massive piles won’t get us anywhere unless we know what problem we’re trying to solve with them.

There’s a temptation, when looking at a pile of data, to leap to design conclusions.

For example: Suppose studies show that almost nobody is using the profile manager. Great, that means we can get rid of the profile manager! Right?

Or, to use a non-hypothetical example:

(Thanks to Blake Cutler for generating all the graphs used in this post).

The most common Firefox session is one with three tabs open? Well hot dog, we should optimize Firefox for the three-tab use case! Right?

Careful, there. This kind of assumption is dangerous. Maybe lots of people would start using the profile manager if they knew it existed. Maybe people would love to have sessions with more tabs open, if the interface was better for managing lots of tabs.

(more…)