July 21, 2011

I’d like to highlight the awesome research project that intern Lilian Weng is leading around Firefox’s new tab page.

While our goal is to make users more efficient at their browsing tasks, what makes them more efficient is a question we keep returning to. Most other browsers display links on new tab pages based on frecency. Frecency is a portmanteau which combines frequency and recency. At Mozilla, we use it to refer to sites that users have been to often, recently, or both. It’s how we calculate what should be the first, second, third, etc site that appears when you type a letter into Firefox’s URL bar.

Using frecency to list links on a new tab page seems an obvious design direction, but we want to truly investigate whether another solution would be best for users. So, Lilian is spinning up a brave new study. Once her test is ready, users of Test Pilot, our platform for collecting structured feedback on Firefox, will be asked if they’d like to participate in a new study. If they say yes, they will be randomly assigned one of six new designs on their new, blank Firefox tabs. One of these six designs will be our control group: a blank white tab, just as Firefox users see currently. The other five will look almost identical to each other. They will display a simple 8×8 grid of favicons set on a button which is colored to highlight them based on a color-matching algorithm designed by Margaret Leibovic:

Minimal 8x8 Grid Layout of Site Links

The only variable that will be changing among the five designs is which sites are displayed in this grid. Here’s the five variations we’re testing:

Frecency. A combination of a user’s most frequently and most recently visited sites.

Most recently bookmarked sites. By displaying prominently what a user has recently starred, we effectively turn the new tab page into a read it later list.

Most recently closed sites. This could lead users to treat new tab page as an undo feature, or close tabs in order to temporarily store them in the new tab page as a short-term read it later list.

Sites based on content similarity. Intern Abhinav Sharma is trying out his project, called Predictive Newtabs, which displays sites based on where the user has opened a new tab from. For instance, if the user has been browsing a news site, a new tab would offer other news sites the user has been to.

Sites based on groups of sites frequently visited together. In another part of Abhinav’s Predictive Newtabs experiments, he has designed an algorithm to predict sites to show based on sites users visit in groups. For instance, if every time you get to work you first check the weather and then check stock prices, this new tab would offer you a stock page on a new tab after you checked the weather. If you want to try this experiment out yourself, you can download the Jetpack here.

The above study is still in preparation, and once it goes live I predict that we’ll learn tons of valuable information about how new tab suggestions can positively impact users. Lilian will be collecting data on many aspects of users’ responses to these designs, such as how they effect the breadth of sites users visit, how likely they are to click on each item in the grid, and how long they spend deciding where to navigate. I can’t wait to start pouring over the data that comes back: it’s very new research in an area that has a profound impact on how we use the web.

February 14, 2011

Updating software sucks. For most of your software, you’d probably prefer to never think about updating. Ideally, your applications would stay current and fast on their own without ever requiring your input.

That’s why one of the important changes in Firefox 4’s add-ons manager is keeping add-ons up-to-date automatically. This happens in the background without you even noticing.

Automatically updating add-ons does exactly what users have been telling us they’d like for a long time. However, some users will want to manually update their add-ons, as they did before Firefox 4. Other users will want to automatically update some add-ons but not others.

Hard as it is to cater to many use cases, we felt it was important to allow users to manually update add-ons if they prefer. Add-on updates are essentially new software, and users should always have the ability to opt out of them.

Below is the basic use case of managing add-on updates I’m proposing for Firefox 5 (which is only a few weeks after the release of Firefox 4 thanks to our new shorter release cycles). The user begins with completely automatic updates on by default. By switching to manual updates in the advanced menu, the user can go back to installing updates themselves. Each add-on shows, in its detailed pane, whether it receives updates automatically or manually.

However, there’s another kind of usage that needs to be supported. What if a user wants all but a few add-ons updated automatically? Or, all but a few add-ons updated manually? Allowing users to switch any particular add-on between manual and automatic updating allows users to make one-off exceptions.

If a user goes to the detailed pane of add-on, they can see how an add-on is currently updating and switch it to the other method. To change <i>all</i> add-ons to the other method, the user needs to select that option in the advanced panel. This way, we allow users to make both blanket rules and exceptions as they go. Here’s a more complete diagram showing updating preferences, with one-off exceptions included:

January 26, 2011

As we approach the release of Firefox 4, the last few polish and stylistic changes are happening in the add-ons manager. Some are simply graphic cleanup, while others are the result of beta testing the new manager for the past several months.

I wanted to highlight one change in particular that you’ll be seeing in the Firefox nightlies soon. The date an add-on was last updated, rather than being displayed in list view, will now only appear in the detailed view of an add-on. This also means that installed add-ons can no longer be sorted by last updated date.

For some users, this change is substantive and will feel disruptive. So, I wanted to give the rationale behind this design decision.

1. Providing a simplified overview

The intended purpose of the add-on manager’s list view is to give a brief overview of the users’ add-ons and to provide only the minimal, most used information and functionality. This minimal information is the name of an add-on, its icon, and a short description. The minimal functionality is the ability to disable and remove an add-on. Even the author name we’ve removed to provide the simplest, most visually scannable design. By removing the last updated date, we not only visually clean an add-on’s list entry, but also eliminate the need for a sorting bar at the top of list view. This gives back both whitespace and a cleaner appearance at the top of the list.

2. Updated date does not provide important functionality for most users

For most users, the last updated date does not give information meaningful enough to justify its placement in list view. It allows users to see which add-ons have been updated automatically most recently, but does not give any details about the updates nor provide tools to interpret the information.

Some advanced users use the last updated date as a diagnostic tool to identify which add-on updates may be causing a recent problem in Firefox. However, the date makes a very poor diagnostic tool. One reason is that the date does not give any information about the size nor scope of the update, and thus can only be used for diagnosis by disabling one add-on at a time to isolate a problem. In many cases, a problem in Firefox caused by an add-on are instantly identifiable as being caused by a particular add-on. Even in the rare case where a problem suddenly appears in Firefox, the chances of it being from an add-on update are not large. A problem could be caused by any number of online events, which is why Firefox provides tools such as the Error Console and about:crashes to help diagnose them. And, even if we were to give fuller information about updates in the add-ons manager and make it into a better diagnostic tool, why should this tool be so far removed from other diagnostic tools? How could a new user figure out that, to access diagnostic tools related to add-ons, they should go to the add-ons manager rather than a more comprehensive diagnostic tool? It would be wildly inefficient to apply this elsewhere in Firefox by placing diagnostic tools only on the interface elements they relate to.

What we should do is add diagnostic tools about add-ons to comprehensive tools such as about:support. Then, we could provide expert users the information they want in a better format while keeping one-off diagnosis away from list view in the add-ons manager.

3. The goal of removing updating entirely for most users

The intended purpose of automatic updates is to remove updating from the list of items the user has to care about and remember. By exposing the updated date in list view, Firefox insinuates both that the updated date is very important that this is a process the user should manage.

Actually, the actual reason sorting and the last updated date were initially proposed in the add-ons manager design was to give users the ability to sort their add-ons by performance, not updated date. Sorting by performance would allow users to find out how their add-ons effect Firefox on metrics such as startup time and memory. However, the ability to rank an add-on’s performance is going to be a part of FIrefox after the 4.0 release, making the remaining sorting categories (alphabetic and updated date) much less useful.

By the way, Firefox 4 beta 10 is out, so please try it out and tell us what you think!