My wife strongly dislikes the new Firefox 3.6 tab behavior (where tabs opened from links appear immediately to the right of their parent tab, instead of at the extreme right of the tab bar).

I do like the new behavior, because by keeping related tabs closer together, it reduces the amount of time I have to spend interacting with the tab-bar scroll buttons (my least favorite UI element in all of Firefox).

She dislikes it for consistency reasons: when you open a new blank tab, it still appears at the far right. So now tabs can appear in two different places, depending on where you opened them. It violates the principle of consistency, which is generally considered one of the most important UI principles. This inconsistency hasn’t really bothered me personally. I’m not sure why; maybe it’s because opening a tab through a link, and opening a new blank tab, feel like different actions to me. There’s a difference in what I’m thinking about. But I can certainly understand how it feels like a consistency violation to other people.

My wife also doesn’t like that there’s no way to change Firefox back to the old behavior without going through about:config. (If you’re interested: type “about:config” in the location bar and hit enter, then do a search for a preference named browser.tabs.insertRelatedAfterCurrent and set it to True or False, as you like.)


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!

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 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.

A great post from Boriss on using Amazon’s “mechanical turk” process for user research.

Her conclusions (about the European browser ballot) are interesting too, but personally it’s the research method that interests me most. Is it possible to get an accurate picture of your target audience from a group of self-selected responders? The answer to this question is obviously very relevant to Test Pilot.

While you’re at it, you should read Boriss’ posts on improving the Firefox Add-Ons Manager here and here. In fact, if you’re at all interested in Mozilla usability stuff you should be reading her blog regularly.

On one of my previous posts, commenter Rasmussen wrote:

Umm, am just a dumb end user. Chrome is really tempting me now.. I stuck with FF while all my friends switched over to chrome solely because i’m addicted to addons and the Manifesto.

FF was the first software company that i discovered had an ideology, and it’s kinda exotic, because i always believed software companies were soulless.

I do hate the startup time and the crashes and as chrome has brought in the extensions, the case for me staying with FF is getting weaker.

However, Google is being evil sometimes, and the FF ideology charms me, and it could be the reason i’m typing this through FF, which is why i hope the bigwigs of FF are and will remain sincere about the ideology.

Hope you guys remain competitive, I do want you to win but just don’t become obsolete.

From my experience talking to and working with the “bigwigs of FF” as Rasmussen call them, I can personally vouch for their sincerity. They’re more serious about the Mozilla principles than most people I know are serious about anything. They’re dedicated to fighting for openness, freedom, and user choice on the Internet, and they know we can’t get complacent just because we’ve been gaining market share. They know that talking about our principles isn’t enough: we have to back them up with quality software that people want to use.

This isn’t the first time I’ve heard users complain about Firefox’s startup time and stability relative to Chrome. I could talk and talk about how seriously we’re taking those problems, how hard the Firefox team is working on performance and stability, and how killing crashes and reducing startup time are some of our highest priorities going in to Firefox 3.6 and 3.7. But maybe it will be more convincing to show you:

  • The Crashkill project is aiming to identify and fix the most common causes of crashes.
  • The Startup Time project is analyzing the reasons it takes Firefox as long as it does to start up, and finding ways to reduce that time.
  • The Electrolysis project is moving plugins like Flash to a separate process, and extensions to another separate process, so that a problem with a Flash movie or an extension (both common causes of crashes) can’t take down the whole browser.
  • Finally, see the Firefox Roadmap, which shows the top improvements planned for the next few releases.

Since Firefox is developed in the open, anyone can follow our progress. Firefox developers — who include not just Mozilla corporation employees, but also volunteers from all around the world — use the pages that I linked to above to track their own work on startup time and crashes. Since these pages are developer-oriented, they’re on the technical side. But whether you’re a developer or not, you’re welcome to use them to take a peek into what we’re doing.

Edited to add: Vlad has blogged a a good introduction to the problems involved in improving startup time. It’s still technical, but less so than the wiki page; check it out if you’re interested.

Alexander Limi has posted a video, from the Design Lunch three weeks ago, wherein the UX leads answered questions about their provisional redesign of the Firefox UI.

Alex wants to warn you that the contents of this video are very rough, very much a work-in-progress, and very much liable to change. You shouldn’t watch it thinking "this is how the next version of Firefox is definitely going to be". You should think of it as a behind-the-scenes look at "how the sausage gets made", in Alex’s words. He also warns:

There’s swearing, there’s mumbling, there’s ranting, there’s hand-waving, there’s political incorrectness.

I’m also in the video, playing MC in my overalls.

Today we recorded Part 2, which goes into detail about the notifications interface and the downloads manager; it should be posted fairly soon.