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!

November 4, 2010

I’d like to give a few updates on the continued implementation of Firefox 4’s new add-ons manager. As development work continues, some parts of the manager’s functionality have been adjusted and updated since I last posted mockups. Here are a few highlights of what’s been going on.

Add-on Specific Notifications

Each add-on in the manager could have one of several notifications that only pertain to itself. How can it be made clear when an add-on needs attention or action? Stephen Horlander first experimented with adding subtle coloring and diagonal stripes to each add-on. In the latest nightlies, this method is expanded to give the full range of add-on notifications. Red and yellow signify different levels of potential problems, while grey and green signify when an add-on requires attention or action.

Here’s a mockup of what these notifications would look like in the manager:

In Detail View, where only one add-on is visible, notifications appear at the top of the pane.

Global Add-on Notifications

Notifications that relate to all add-ons now display in the scope bar (bug 566194). The color of global notifications follows the same scheme as notifications for individual add-ons.

Hiding Browser Navigation Widgets

The design of the add-ons manager is enhanced by displaying only relevant parts of the browser chrome and hiding those that don’t relate to the page (such as the URL bar and reload button). Some benefits of doing this include:

Presenting a minimal, clean UI

Creating a distinctive in-content page that no other site can mimic – vital because of the far-reaching changes which can be made within in-content pages

The user only sees actions that they can take. Reload, for instance, is needless on a page that’s locally hosted

Space in the navigation bar normally used for browsing buttons can be repurposed for widgets useful for in-page content. For instance, the URL bar space can be used in future Firefox versions to present breadcrumb navigation for in-page content.

Progress towards removing browser navigation widgets is being tracked in bug 571970. Unfortunately, this will only work when Firefox is in its default tabs-on-top mode. Removing elements for tabs-on-bottom configurations involves changing the entire theme of Firefox substantially. In order for fast tab switching to remain possible, tabs would need to remained aligned in tabs-on-bottom mode while still preserving the minimal style of in-content pages. This will be the goal for a future version of Firefox.

Downloading Add-ons within the Manager

If you run Firefox nightlies, you may have noticed that if you install an add-on from within the add-ons manager, the installation process happens fully within the manager. By turning the download button into a progress bar, the user’s focus need not move; the relevant information for the download is where the user was looking in order to prompt the download. After the add-on is downloaded, a notification will display on its entry alerting the user that either the installation is complete or that a restart is needed.

A notification will appear over themes and backgrounds when they are fully implemented in the manager. These and other changes that only effect the style of themes and backgrounds will be implemented in future versions of Firefox after 4.

Add-on Installation Process

We’ve also streamlined the process of installing an add-on from a website for Firefox 4. The new design uses Firefox 4’s new arrow notification panels to minimize the number of steps required. When the user begins an add-on installation, the download now begins automatically. For most users, this should only take a second or two. The user then sees the name, author, and source of the add-on, and has the option of allowing the installation of the downloaded add-on. Firefox only obtains this information about add-ons once they have partially downloaded, which is why the full information is presented after the download completes. Though the add-on file has already downloaded at this point, the file is not accessed unless the user allows it to be.

If the add-on does not require Firefox to be restarted, that’s it: the add-on is activated as soon as the user clicks “Allow”. If it requires a restart, the user is notified that a restart is needed and the add-on is activated after the next restart.

If you’d like to try out the new add-ons manager, try running the latest Firefox nightlies. Some of the smaller style changes have not yet landed, but the behavior described here is ready for testing (and bug reports where needed!)