Archive for January, 2010

Add-ons Manager Update

Big day, right? iPad, Prop 8 Trial’s Witness Testimony concludes, Obama’s first State of the Union, Ted Haggard was cured of being gay (again). But you found the time to stop by my blog anyway.  That warms my heart.  So have a seat, and let’s talk about the add-ons manager.

Oxygen or Bling?

First, humor me a second, because I want to back out a little. Lately I’ve noticed that we talk about add-ons in very different ways.  Add-ons developers and community sometimes talk about add-ons as something “everyone” should install. I’ve heard some say that there’s an add-on for everyone, or that everyone should install a few that help their browsing experience. This is the “add-ons are oxygen” view. And heck, it’s been said plenty that add-ons are one of the main things that make Firefox great, and they are certainly what differentiates Firefox from other browsers.

But hold on. Isn’t Firefox sexy and beautiful right out of the box? Don’t about half of Firefox users have no add-ons installed? And when users have problems with Firefox, aren’t “weird add-ons” the first thing we blame and disable? This is the “add-ons are bling” view.

So, should we encourage users who don’t use add-ons to install them? Are they oxygen or bling? Like about everything, they’re probably in between.

A Browser with a Bike Rack

The purpose of a car is to drive places. That’s why you’d buy one, and you’d expect it to do that perfectly as soon you buy it. There are some car nuts (I know quite a few) who care deeply about a car’s engine, performance, style, etc. They will make incredibly deliberate decisions about the car they buy, and even make modifications to get it to behave differently. Some of these modifications will be purely functional (e.g. tires with better traction), others are stylistic (e.g. racing stripes), and some help them perform other activities (e.g. a bike rack).

But the majority of car drivers won’t look for modifications and will be content as long as their car looks good, drives well, and get them from A to B safely. If they’re driving a good car, it’s probably because one of their car-head friends told them it was a good model (explains my Civic). Should these users be encouraged to modify their car? If so, how?

While the casual car drivers may not understand much about the workings of their car and may be bored at what car-heads find interesting, many could have a better car experience if some modifications were easy to understand and easy to install. If I could change the color of my car every day with a click, I would. Ditto if I could add a laser gun to the front. If putting a red stop-sign sticker on my windshield protected it from bird droppings, I’d stick it on.

So if you were a car manufacturer of free cars and free car modifications, and your goal was happy users, what would you do? First, for those car-heads, you’d want modifications to be easy to develop and share. For those casual drivers, you’d want the free modifications to be simple to find, install, remove, and understand. You’d want it to be clear how a modification would change the driving experience. And if one of those casual users wanted to become more of a car-head, you’d pave the path for them. These are roughly the goals of the add-ons manager redesign.

Add-ons as Preferences

There’s something else to keep in mind with the add-ons manager. Add-ons are essentially choices the user has made about how to tailor their browsing experience in a way that reflects their preferences. Uhoh, preferences? You bet – installing and configuring add-ons is a small part of a user’s browser preferences, and as such should probably not be separate from the Preferences menu. I constantly see users go to the Add-ons Manager when they want their Preferences, and vice versa. So in a future Firefox, it makes sense to combine these. But, because there are many separate challenges involved, for now we are focusing only on the add-on manager’s redesign, with the eventual goal of integrating it with Preferences. I’ve described in a previous post that it makes sense for the Add-ons Manager to display in the content area of Firefox: I think the same can be said for the Preferences menu.

The Preferences project is still in its infancy, but keeping in mind that the add-ons manager will probably exist within the context of the user’s Preferences is important both in design and implementation.

Design Direction

The design currently being considered for the add-ons manager is a two-panel basic hierarchy view within the content area of the browser. Add-on categories would display in the left panel, with an expanded on the right.  This gives the user an overall view of that the add-ons manager entails, as well as enough room to individually configure items.

One of the benefits of having this two-panel design is that it allows scanning the contents of a category.  The current add-on manager currently employs a sort of “digest-style” summary for each add-on, and with category view this sort of functionality can be improved with better information.

If a user selected a particular add-on from their manager, the right panel would show a detailed view of that add-on.  This is something the current add-ons manager lacks: enough space to find out more about an add-on and configure it.  Below an add-on’s information, the developer could add preferences for that add-on.  The current manager pops preferences out in a separate window, launched from a button.  This is essentially a pop-up window within a pop-up window.  A two-panel in-content layout allows all of this functionality to be integrated.

This post is getting long pretty fast, so I’ll close here for now. Next up – how some of the interactions for maintaining, configuring, and installing add-ons could work within such a design.

As usual, these designs are not final and feedback (especially from add-on developers) is absolutely welcomed..

Mechanical Turk Studies Show IE Users’ Discontent, a Growing Interest in Chrome

You’re probably familiar with the whole European Commission/Microsoft browser case. Long story, but basically the EC accused Microsoft of harming consumer choice by bundling Internet Explorer with Windows, Microsoft offered to present users with a browser ballot, I wrote about how a ballot wasn’t a great solution but should be designed well, yadda yadda.  Last month, Microsoft agreed to show the browser ballot choices in random order, rather than fixed. Definitely an improvement!

I still wondered what effect, if any, item order and other variables would have on what browser people would choose. Would certain design changes on the ballot have a big impact on users? And how could Firefox optimize its space on the ballot to be most effective?

Mechanical Turk: The Odds are Good, the Goods are Odd

My colleague Alex Faaborg suggested that I try using Amazon’s Mechanical Turk to get some answers to these questions. Mechanical Turk lets users create tasks that they need humans (called workers) rather than computers to perform. Workers select tasks that look interesting to them and are paid a small amount for each task completed. I was pretty skeptical about using any pay-for-answers service at first. My fear was that workers would be a strange grabbag of too-technically-competent-to-be-representative people who would go through tasks at lightening speed, barely reading them, to get the most profit out of their time. But I was curious about how well the system worked and tried it out with a series of tests.  Some of these presented workers with ballots, and others asked workers to compare different aspects of Mozilla’s branding within the ballot.

I was actually amazed at how well the Turk performed, and especially at the ludicrous speed at which workers responded. Within four hours I had the time of about four hundred workers, each spending an average of three minutes on a short seven-question survey that I thought would take 20 seconds. To my surprise, the vast majority of free-form answers were filled in with thoughtful detail. Numbers of people this large, for that kind of time, for so little money (each worker was paid ten cents USD) was pretty sweet. It’s frightening how the hive mind’s torrential force is so easily bribed.

The bad news is that as suspected, the Turk workers are a strange sample. They skewed heavily towards living in North America and being more technical than an average users. Of my workers, 49.35% were already using Firefox (compared with 31.34% worldwide), and only 18.44% were using Internet Explorer (compared with 55.53% worldwide).  However, those free-form answers were pretty effective at separating geeks from n00bs, and it’s n00bs I was interested in.

So what are the results already?

Ok, ok. For the majority of tests, I presented users with a browser ballot with some small variables changed – maybe a different Firefox logo, a different description, etc – and had users select a browser as though they were being given the ballot when starting Windows. Unsurprisingly, no change to Firefox’s logo nor description on the ballot made a statistically significant difference to what browser workers selected.  But people were in the mood for change: 29.09% of people wanted to switch browsers when presented with the ballot. Internet Explorer users were most likely to want a new browser – 38.03% of them changed teams. Opera users were most loyal, with 92% staying on Opera. 70.53% of Firefox’s users wanted to stay with Firefox.

Of those Firefox users who wanted to switch, 51.79% wanted to try Chrome. Of Chrome users who wanted to switch, 50% wanted to try Firefox. It’s not too surprising that there’s crossover – both Chrome and Firefox attracted the more tech-saavy users who followed browser innovation to some degree. What’s interesting is that the main reasons people gave for switching to Firefox and Chrome from any browser were related to brand recognition. Nearly everyone who wanted to switch to Firefox said they’d “heard good things” about it, or that an acquaintance had recommended it. Most switching to Chrome mentioned using and liking Google’s search engine and being curious to see what else Google could do. In Firefox’s case, recognition was based on recommendation. In Chrome’s case, recognition was all about the familiar logo associated with successful searching.

Of Internet Explorer users – the only ones who will actually see the ballot – 22.53% wanted to switch to Chrome, 8.45% to Firefox, and 7.04% to Opera.  I should note that I believe the high Chrome percentage is partially because this sample of people make part of their income through the browser and are thus more familiar with the Google brand than your average European Joe. However, it does show a huge momentum towards Chrome, fueled by that all-important brand recognition.

So what else made people switch browsers? Workers had many associations with browsers – even those they didn’t use. They described both Chrome and Firefox as fast, easy to use, and innovative.  Most users sticking with Internet Explorer described it as being familiar, or that they were content with their current browsing experience.  However, there was one association that workers only made with Firefox: security. Nearly every comment relating to security and privacy was in support of Firefox, and most of those who would consider switching to Firefox mentioned this as a personal priority.

Below is a graph of how the workers responded to the ballot. Unsurprisingly, most people voted for the browser they were using, shown by a strong top-left to bottom-right diagonal.

If these results were extrapolated, it would dramatically change the browserscape of Europe. Internet Explorer would lose 38.03% of its European market share, Chrome would gain 10.11% the European share, and Firefox would gain 3.79%. Again, these results are highly skewed towards Chrome because of the Mechanical Turk sample, but I do think that Chrome will probably emerge as a big winner of the ballot screen. The Google brand is well known and well established, and I believe it will cause users to recognize Google as a brand they already use thus try Chrome.

I’ll see your Pocahontas and raise you Speaker for the Dead

Speaker for the Dead vs. Avatar

Herdict and its Tasty, Anonymized, Aggregated Data

Nothing sucks on the web like not being able to go to the site you want. Page not found and 404 errors are an inconvenience that entirely halt your workflow. What’s worse than not being able to access a site is not being given relevant information to fix the problem. When users are presented with an error message, they tend to do whatever will make the error go away to get back to their task. Page not found errors can’t be dismissed, because they’re shown instead of the content wanted.

What creates an added level of frustration is not being given information on what the problem is. When users get a Page not found error, they likely have two questions in mind:

  1. Is this problem on my end, or not?
  2. If the problem is on my end, how can I fix it?

These are questions that have been hard for browsers to answer. Currently, Firefox’s network error pages aren’t incredibly useful. They’re certainly not as useful as Chrome’s, which use Google Link Doctor to find possible matches both for subdirectories and domains. That won’t necessarily tell the user if the problem is on their end or not, but it will help if the problem is a typo.

So how could a browser tell users if the problem is on their end or not, without infringing on their privacy? One project that currently takes a stab at this is Herdict, which Johnathan Zittrain’s been working on at Harvard University’s Berkman Center for Internet and Society. What Herdict does is let computer users tell the “herd” – via a Firefox extension – what sites are accessible. The aggregated data can tell if a site is down (because no one can access it), or blocked by a firewall (because only some people can access it), or likely on the user’s end (because everyone else can access it). Not only does that answer the question of “is this problem on my end,” but it may start to answer questions like “is this problem only experienced by my country, network provider, or device?”

Useful stuff! Does it have a place in the browser, and specifically in Firefox? I think that getting and submitting anonymized data should have an increased role in the browser, and especially where it promotes transparency and information to the user. Mitchell Baker has been writing about data, and how Mozilla could be treating aggregated, anonymized data as a public asset that should be freely available. Especially in situations where sites are being blocked and censored, giving users knowledge of the situation seems to align with Mozilla’s goals of transparency and viewing the web as global public resource that must remain open and accessible.

One way something like Herdict could be incorporated is through those Page not found errors. If there were an option on these to submit anonymized data, we could build a pretty accurate view of accessibility information for a website and share it. Allowing users to submit data when there’s a problem is something many programs do already – especially for crashes. This is good design; it makes users feel better by registering the annoyance they feel as a useful data point to developers. Here’s some sketches of what it could look like to incorporate Herdict’s aggregated accessibility data with these error messages:

1. No available information on a site:

2. Site is blocked due to local firewall:

3. Site is down for a country:

4. Site is down for everyone: