Not The User's Fault

See that? That is the Thunderbird dock icon on Mac OS X. It shows the number of unread emails you have.

What looks like “1487!” is actually “14875” with part of the “5” cut off. I have discovered the dock icon can’t display 5-digit numbers correctly! A bug!

Hm. Perhaps this is the rare case where it is, in fact, the user’s fault for having 14875 unread emails. What should Thunderbird do when you get to five digits? At this point the exact number is not particularly informative. Maybe when you get to 5 digits, it should just show an infinity symbol. Or a sign that says “You’re screwed”. Or a link to inboxzero.

Congratulations to Mozilla Messaging for finally finishing Thunderbird 3! In honor of last week’s Thunderbird 3.0 release, I’d like to do a series of blog posts on my experience migrating from GMail to Thunderbird over the past couple months.

Don’t get me wrong, I love a lot of things about GMail. Treating the conversation, instead of the individual message, as the basic object was a big step forward in e-mail interfaces. Good, fast search plus vast disk space changed the way I think about my email archives.

However, this October I ran into some problems with GMail. I had set myself up both to receive email sent to my mozilla.com address in my GMail inbox and also to be able to send from my mozilla.com address through the GMail interface. Although it had the minor drawback of mixing my work and private lives together in a single extremely busy inbox, that seemed like a fair price for the increased convenience.

In October, though, I realized that some of my coworkers hadn’t been getting emails from me. It took me a while to notice: I thought everyone was just too busy to respond to what I had written. But by asking a few people to search their inboxes for mail from me, I confirmed a hunch – most of the mail I had sent from my mozilla.com address through the GMail interface over a period of a couple of weeks had not been delivered. It hadn’t gone to their spam folders, either – it had just silently disappeared.

Everything had been working fine up until October, so what happened? I’m still not exactly sure. One theory is that my Mozilla mail was being sent through gmail.com, but the “from” address said “mozilla.com”. A “from” address that doesn’t match the sending server is a common sign of spam, so maybe a change in spam-filtering policy made our relay servers start throwing out my messages. On the other hand, maybe it had to do with me changing my Mozilla LDAP password, and not remembering it to update the password stored in my GMail settings for the external account.

Either way, it was the worst kind of software failure: the silent kind! Because GMail’s interface reported that the messages had been sent, I never stopped to think that maybe they hadn’t. It’s easy to forget that email was never designed to be a highly reliable protocol. Sometimes you get bounce messages back when something goes wrong, but it’s never guaranteed.

So I don’t particularly blame GMail for what happened. It would have been nice to get more notification, but the problem was really outside of their knowledge or control; I was expecting too much from a web application. It is in the nature of a web application that the user gives up a certain amount of control in exchange for convenience. Often a good trade. But for something as personal and essential as my email? My experience with the lost messages drove home the price of not having that control.

Besides, it was about time I started eating Mozilla’s own dogfood for my email.

I’ve been keeping a notes file on my transition to Thunderbird. In my next few posts I want to share with you some of its pros and cons, tips for using it effectively, things that are cool about its interface and things that could use improvement.

How often do you recycle passwords? That is, use the same password for multiple sites? Even though you’ve probably been told this is a security no-no, it’s just too much strain on most people’s memory to come up with unique passwords every time.

Theoretically, the password manager feature of Firefox can help. Come up with a random string of characters and let Firefox remember you for it. This works great… as long as you have Weave, or if you never need to log into the site from a different computer.

And the problem’s getting worse, because these days almost every new site you come across thinks it’s important enough to ask you to create a password. Meanwhile, phishing attempts are getting more sophisticated. These are some of the reasons Mozilla is starting to explore identity management in the browser.

It would help if we knew how much password recycling is actually going on. How many different passwords does the average user use? How many times do they recycle each password? Do they have a throwaway password that they use on lots of unimportant sites, while making unique secure password for their bank?

That’s where Test Pilot comes in.

The above pie chart, generated by Test Pilot, shows a breakdown of the passwords that I have saved in the Firefox password manager. I was running it on a throwaway profile, so it only has five sites with stored passwords. (If it was my real profile, it would have dozens.)

We should be rolling this study out sometime this week. Of course, the study will not be collecting the actual passwords themselves! Instead, it compares passwords on the client side, so they never leave your machine, and only the count of duplicate passwords gets sent across the network to the Test Pilot server.

I’ll post again when we have some findings to share from this study.

Since Firefox is at something like 25% worldwide market share, and that already includes a lot of the world’s most tech-savvy people, our future growth is going to have to come more and more from the ranks of computer novices and first-time Internet users.

In a recent post I talked about the problems of teaching total beginners the basic concepts they’ll need in order to become capable users of the Web.

This reminded me of something from an old video game… (Nearly everything reminds me of something from an old video game.)

This is the first screen of the classic Nintendo game Metroid. At the time, most video games were either single-screen affairs, or they were long tedious marches in a single direction (usually to the right, as in Super Mario Bros.). One of Metroid’s many innovations was that it allowed the player to explore in every possible direction (and completing the game required an obsessive dedication to exploring every nook and cranny). This innovation worked so well that it is now taken for granted as a basic principle of almost every game.

Developing Metroid must have been like developing any software based around a brilliant new idea. You, the developer, know this feature is hot stuff and can potentially change the way people interact with software. But the problem is that your users don’t know this feature exists, and if they did know, they wouldn’t know why it’s something they would want, or how to make best use of it. What do you do?

The first-time player of Metroid will most likely begin by doing what most video games have taught them to do: force their way rightward by any means they can. After going through a few doors, they will come to the screen above.

The tiny tunnel on this screen is too small to enter, but it obviously goes somewhere. It is a conundrum. It taunts you.

The only solution is to go back to the start and this time, walk to the left. If you do so, you are immediately rewarded with the discovery of this glowing ball (for trivia buffs: it was called the “Morph Ball” in later games, but here it was called the “Maru Mari”.)

When you pick it up, you can then have Samus (your character) curl into a pillbug-like ball and roll along the floor, which lets you get through tiny tunnels like the one that stopped you before. You can now proceed with the next phase of the game.

This whole side-trip is a sort of in-game tutorial. It’s quite ingenious, actually. Without using any words at all, the game designers have taught you several of the key skills you’ll need to play effectively, and they’ve ensured that you understand these skills before you proceed on to the main part of the game. There are several subtle things that they did exactly right.

First, they made the side-trip very easy. All you have to do is go left: there’s no traps or enemies in the way. Asking people to break their always-walk-right habits is quite enough without adding extra frustration on top of that.

Next, notice that the screen where you get the Maru Mari is ingeniously designed so that you can get in by jumping, but you can only get out by rolling into a ball. In other words, the game designers aren’t letting you go anywhere until you’ve proven you understand the meaning of the item you just found. It’s like asking a student a question to make sure they understood what you just told them.

By going left to get the Maru Mari, the player has actually learned four things. They learn that this is a game where they can move any direction. They’ve learned that they will be rewarded for exploring unexpected places. They’ve learned that items found scattered around the cave give their character new abilities. And they’ve learned that these abilities open up access to new areas. The player has been equipped with a lot more than just a gadget that lets them roll up: they’ve been equipped with the mindset that they’ll need to face the challenges ahead.

The game designers could have put a line in the instruction booklet that said “By the way, you’ll need to explore in every direction, not just march to the right”. In fact, maybe they did put this in. I wouldn’t know. Who reads instruction booklets? Even if they did read it, seeing the text wouldn’t have had one tenth of the impact of figuring out the principles for yourself. People learn best by doing.

Nintendo seems to love this technique, and uses it in game after game. For instance, a few years and two games later, in Super Metroid, there’s a bit where you fall down a very deep shaft. At first, there seems to be no way out; you’re stuck. But if you pay attention, you’ll see some tiny alien creatures climbing up the shaft by bouncing back and forth between the walls:

“I wish I could do that”, says the player. And if they’re smart, they give it a try… and discover, to their surprise, that they can. Wall jumping is essentially an undocumented feature. It’s an ability that Samus has always had, since the beginning of the game, but the player doesn’t know about it because they’ve never had cause to try it before. It most likely takes a few tries before the reach the top of the shaft and escape. But when they do, they get the thrill of achievement, and they’ve mastered the Wall Jump technique, which will serve them well in the rest of the game. The aliens are there to teach you by example.

So, to bring this back to the original topic: Samus is like your web browser. She can do a lot of cool tricks, some of which you don’t even know about, and she can find upgrades (add-ons?) that let her do a lot more. The caves of planet Zebes are like the Internet: a vast interconnected labyrinth full of wonders and dangers where you can get lost for days. Samus’ abilities, or the features of your web browser, are the tools you use to navigate this labyrinth.

So the question is: What’s the web browser equivalent of the Maru Mari side quest, or the wall-jumping aliens? Could there be something like a tutorial level for the Internet? A site where we trap you, and don’t let you leave until you’ve mastered the use of the History menu? Have cute fox creatures running around on the page to teach you by example?

Careful – cute foxes teaching you by example sounds dangerously close to the universally despised “Clippy” from Microsoft Word. We must be careful: naive attempts to implement tutorials can turn out really, really awful. But maybe the key is that Clippy sucks because it tries to tell you what to do, while the Metroid examples work because they make you learn by doing it yourself. Is there something analogous we could do in Firefox?

I have a Motorola Razr. It’s a lousy, generic cell phone that I hate.

I call it my “phone”. Like, if I’m looking for the recharger, I say “Darn it, where did I put the charger for my phone?”. I do not say “Darn it, where did I put the charger for my Razr?”. In fact it would sound really weird if I said “where did I put the charger for my Razr?”. It would sound like I was in a commercial or something.

I would guess that most people call their phone a “phone”.

Except for Apple iPhone users. They always call it an “iPhone”. Even if they’re in a hurry. “Darn it, where did I put the charger for my iPhone?”. They never just call it a “phone”.

You see what Apple did there? They somehow convinced us all on a subconscious level that their phone is so different from all other phones that it’s in a category all by itself. Whatever they did, it worked so well that we always refer to their product by its full brand name and not by the short generic term.

Nobody calls an iPod anything but an “iPod”, either. Apple’s been doing this ever since they convinced us that a Mac was somehow in a category of its own, and not just an overpriced high-end PC with a better operating system that was incompatible with everything else (…, he typed on his MacBook Pro.)

Sometimes this kind of thing works too well, and backfires. Like, Sony got everybody to call their Walkman a “Walkman”; but to Sony’s chagrin, we started calling every other portable tape player a “Walkman” too. It became a generic term. But that doesn’t seem to happen with Apple’s stuff. Apple has somehow imprinted their brand identification into our very language. That’s a pretty scary level of marketing savvy, bordering on hypnosis. How do they do that?

This week, the support.mozilla.com team (known as SUMO for short) ran a contest. They set up four computers in the hallway, each open to a feed of support questions, assigned everyone to one of four teams by last name, and offered prizes to whichever team could answer the most support questions by Wednesday afternoon. I stopped by several times and did a few rounds of tech support for the “S-Z” team.

It reminded me of my old days of working at Humanized, where I would often spend the first few hours of each day catching up on emails from users: tech-support questions, bug reports, and complaints — before digging into code. It’s repetitive work, but it gave me the great benefit of seeing our software as our users saw it. A stint doing tech-support for one’s own product is something I strongly recommend for anyone in software development. It teaches you what you need to improve vs. what you merely would like to improve.

(more…)

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.

Here is the video of our Design Lunch session from last week, in which we discussed ideas for identity management in the browser.

The video is almost an hour long, so I don’t know if you have the patience to watch the whole thing… but it does open with me wearing a funny hat and narrating an imaginary legal drama. Then it proceeds to the showing off of screen mockups, followed by vigorous discussion of what the right thing is for Firefox to do in various tricky situations.

This is the first time I tried recording a design lunch using fancy cinematography techniques such as “pointing the camera at the person who’s talking”. I hope it makes it easier to follow.

You may also want to check out Aza’s blog post, which shows the mockups of potential interface designs. They should be easier to read there than they are in the video. You can also find out more at the Mozilla wiki page on the Identity project.

Google has just launched Extensions for the Chrome browser. It will be interesting to watch whether their approach to add-ons differs from ours, and in what ways.

The vibrant community of Firefox add-on developers has long been one of our greatest strengths, so Google’s addition of this feature is something of a challenge. I for one welcome the increased competition. It’s going to make us at Mozilla work harder to stay ahead, but the end result can only be good for users — more choices and higher quality software.

The Chrome extensions apparently don’t work on Mac yet, which is too bad; the Google Translate extension looks pretty useful.

We’re trying something new with the “Week in the Life” Test Pilot study. Instead of running just once per user, it will automatically recur about once every two months (60 days, to be precise) and run for one week each time. The idea is to let it recur over the course of a year, and see whether we can detect any long-term trends in the data that would indicate user habits changing over time. For instance, a lot of us who work in web browsers have a hunch that our users are using bookmarks less, and tabs more, compared to a few years ago. But does the data actually support this?

Because the “Week in the Life” study recurs, and because we never submit any data without the user’s explicit permission, we’ve got a potential user experience problem: Test Pilot is going to ask you whether you want to submit the data from the study every time it recurs. Do you want to submit the data? Do you want to submit the data? How about now? How about now, huh? How about that data, do you want to submit it?

Isn’t it annoying being asked the same question over and over again?

To mitigate this problem, I’ve added a new UI widget to the Test Pilot status page:

The principle of “Don’t pester the user” is important, but so is the principle of “Make sure you have the user’s permission before doing anything with their data”. These principles are natural enemies. Finding a compromise between them is not easy! I know that my little drop-down menu is not a perfect solution. What do you think? Is it self-explanatory enough? Too wordy? Is there a better approach to this problem?