All posts in Features

Removing Firefox’s Status Bar and Rehousing Add-on Icons (Part 1 of 2)

One of the major goals in redesigning Firefox is presenting a simpler, cleaner, and smaller user interface. Firefox currently has more chrome (space taken up with user interface) than any of the major browsers, and all that chrome reduces screen space given to page content. We’d like to be more efficient with space in Firefox, maximizing the usefulness of the interface and the amount of content shown.

The process of reducing Firefox’s chrome has meant looking critically at each part of the interface and how it’s being used. The goal is to find places where chrome can be minimized, both through efficient redesign and pure removal where functionality just isn’t providing enough benefit. This process led us to an obvious candidate for chrome reduction: the status bar. In addition to taking up page content, the status bar is the only part of Firefox’s permanent UI located on the bottom of the browser. This placement leads to the status bar being easily obscured, and sometimes requires resizing the window to view. For an entire toolbar of UI, it seems this slacker may not be pulling its weight in usefulness.

The status bar is home to a few pieces of functionality. However, with the new Firefox design, much of this functionality is already being relocated to the top of the browser. Other parts are not extremely useful.

  1. Add-ons icons
  2. Link URL preview (answers “where does this link go?”)
  3. Resize window control
  4. Current loading task
  5. Progress bar for page loading
  6. Notification that the page has finished loading
  7. Link to Download Manager with download summary

Already we can start crossing items off this list. #3, the window resize control, does not require a toolbar. #4, the currently loading task, is not widely useful; most messages display unintelligible processes which are flickered too fast to be read. #5, the progress bar, we’re already planning to move to the top of the browser, attached to the tab that is loading. #6, the “Done” announcement, should be handled in the negative: if the progress bar is gone, the page is done. #7, the download manager link, we’re also planning to move to the top of the browser.

So, two pieces of functionality remain: add-ons icons, and link URL preview. Let’s look at add-ons first.

Add-ons are tricky to plan for because developers can do whatever they want with them, and put them anywhere in the UI. Also, add-on icons in the UI can do anything, from affect page content to launch a menu. Unlike the other parts of Firefox’s chrome, we have no control over the function and placement of add-ons. The best we can do is provide a space for add-ons, recommend add-on developers take advantage of it, and give them tools to do so.

An idea that’s been bounced around is saving the area to the right of the URL bar for add-ons. This is similar to what Chrome does.

The benefit of this placement is that it doesn’t add any additional UI to Firefox. The problem is that while this works for one or two add-ons, the more icons the user installs, the smaller the space for the URL and search becomes. Heavy add-on users would eventually have to choose between not having all the add-ons they want or having less space to browse and search. A better solution would be useful both to users who have only a few add-ons and users that have many.

One way we could handle this is by considering add-on icons to be modifiable, movable objects that the user can control. Since we can’t know what these icons will do nor launch, we can’t make decisions about their placement based on functionality. Why not gives users the ability to modify their placement, just as users can modify the bookmarks on their toolbar and the buttons on their UI? It seems inconsistent that we’ve been giving users easy control of so many objects in the Firefox UI, but not the placement of add-on icons.

By treating add-ons as movable objects, we can modify the appearance of add-on icons based on where they’re placed in the UI. For instance, let’s assume an add-on icon by default displays in the bookmarks bar. It would then display as a regular 16 x 16 icon. However, if the user moves that add-on icon to the upper toolbar of the window, we could draw a border for it so that it has a consistent look with the other buttons in the toolbar. Moving it elsewhere, such as to the top of the window, would produce a different look. The user would then have the ability to modify their interface depending on how they use their add-ons.

Next, incorporating add-ons that display more than an icon in the interface.

Themes and Personas in the Add-ons Manager

Personas and Themes are a bit of a strange beast in the add-ons kingdom. Themes completely change the look of Firefox, from its color and menus to the shape of buttons. Currently, Firefox needs to restart to switch Themes. Personas, or “Backgrounds” as I’ll refer to them here, are a kind of light-weight skinning which puts an image behind Firefox’s user interface, but makes no other changes. These can be applied without a restart.

This gets slightly complicated when a Theme and a Background are used at the same time. For instance, if someone wants to use a Theme with circular buttons, but also a freakin Twilight Background behind them. So, the UX question: how explicitly should we make the difference between Backgrounds and Themes in the user interface for the add-ons manager?

One solution is to ignore most of the complexity: allow users to use both a Theme and a Background and simply mark what is being used. This makes for the simplest interface, but can lead to the user being confused about results (“Why does using this Theme disable my other Theme, but my Background remains the same?”).

Or, we could be more explicit about it: give the user an indication that they can only have two items, and only one of each type.

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:

Relocating Firefox’s Add-ons Manager

In my last post, I described some of the ways that we’d like to improve the add-ons manager. First, we’d like to fix some of the add-ons manager’s usability problems, such as confusing installation processes and distracting notifications. There’s also some new functionality that the add-ons manager needs to provide, such as better information about add-ons and incorporation of newer projects such as personas. It was clear from the feedback that developers as well as users would like to see the maintenance and configuration of add-ons become easier.

The Add-ons Manager as a Tab

The current add-ons manager window sometimes gets in the way (with apologies to Gizmodo)

A few commenters on my last post highlighted problems caused by the add-ons manager being a separate window. It can get lost among other windows, be as distracting as a pop-up ad when giving a notification, and means part of the browser UI being modified is obscured. A potential solution that I think addresses these well is moving the add-ons manger into the content area of the Firefox, so that it runs in a tab. Here’s a few benefits this design provides:

  1. Gives more screen real estate to the add-ons manager. This would allow enough room for useful add-on information, scanning an entire add-ons inventory, and functionality like add-on preferences.
  2. Presents a less fragmented browser experience. Firefox’s chrome is basically a frame in which users go about their online life. But to modify that frame, users have to jump outside of it and onto a floating window. Modifying add-ons in the content space means the user never has to leave their tabbed browsing. Also, they can see all changes their add-ons make rather than having those changes obscured by a window.
  3. Allows for a similar add-ons experience across different devices. Running the add-ons manager in a tab means that an internet-capable device does not need a separate window or menu to modify add-ons – any device which can open a window can use add-ons in the same way as a desktop computer. Add-on management on mobile devices, tablet computers, and fullscreen mode would all provide the same experience. This is a huge win as the web becomes less about the device it runs on and more about the user, who may access the web on multiple devices.

Designing such an add-ons manager is a challenge we’re actively engaged in. The final design must feel like it’s a part of Firefox rather than a website, even if it’s displayed within a tab. It must also be unspoofable. Below is a rough wireframe of the design direction that we are considering.

Redesigning Firefox’s Addons Manager

When I ask Firefox users why they love Firefox, the answer often isn’t because of Firefox. Rather, it’s a particular Firefox add-on that provides functionality that has become invaluable to users. From developer add-ons like Firebug to social add-ons like StumbleUpon, a single add-on can fundamentally change how users interact with the web.

Firefox users get starry-eyed when describing their favorite add-ons

The reason add-ons are so important is because they are a fundamental way that users take control of their online life. Firefox touts its customizability as one of its main selling points, but users’ ability to customize their browsing experience is dependent on the talent and creativity of the add-on developer community. I’ve written in the past about the importance of Firefox providing a user experience ideal for as many people as possible right out of the box, without add-ons installed. But each user is truly unique and uses the web in increasingly different ways. That’s why it’s so important that add-ons be trivial to find, install, and begin using.

The Current Add-ons Manager

Add-ons are currently installed, maintained, and configured via the add-ons manager in Firefox. This window, found under the Tools menu, provides an inventory of installed add-ons and allows users to update, install, remove, enable, and disable them.

The current add-ons manager works, but could use some love

The add-ons manager has been largely unchanged since 2007, and it badly needs a redesign. One reason is that it has several usability problems that would provide significant benefit to users if fixed. For instance, the process of updating add-ons is currently characterized by interrupting important tasks such as startup. Locating a particular installed add-on currently involves navigating through categories such as extensions and plugins. Even experienced users I talked to find the distinction between these categories hazy. A redesign to address current issues should insure that installing and updating add-ons is trivial, notifications are non-disruptive, and the interface provides clear information about the state of a user’s add-ons.

However, a successful redesign of the add-ons manager must not only fix problems, but add functionality. This is because the scope and functionality of add-ons has increased dramatically and will continue to expand in future versions of Firefox. The current add-ons manager gives only the name of an add-on, an icon, a version number, and a one-sentence description. Users could benefit from more information, such as a description or a screenshot showing what UI the add-on will change. Added functionality is also needed because of new ways to modify Firefox, such as Jetpacks and Personas. These are similar to current add-ons in that users can choose items to download for added functionality, but they are installed, managed, and used differently. A redesigned add-ons manager must be able to incorporate emerging projects like these.

Redesign Priorities

From fixing current usability problems to adding needed functionality, there’s a lot that needs to be tackled in the add-ons manager redesign. To help focus the effort, the main areas to address can be described as five priorities:

1. Maintaining and Configuring

  • Allowing users to quickly locate a particular add-on by name or by type
  • Providing simple, usable controls for basic add-on operations
  • Allowing new forms of add-ons, such as Jetpacks and Personas, to be maintained and configured easily alongside traditional add-ons

2. Updating

  • Updating add-ons automatically by default. I’m increasingly convinced that most users, once they’ve decided an add-on is trusted, do not want to manually update it. They especially do not want to be reminded to update when they are starting the browser
  • Allowing users the option to update add-ons manually, update only a particular add-on manually, and possibly to undo an update

3. Installing

  • Streamlining the install process to as few steps as possible
  • Providing the user with clear indications of what action is needed, especially when some add-ons require a restart and some do not

4. Discovering

  • Providing a compelling first-run experience to new add-ons users, including clearly showing what functionality add-ons provide and what they will change
  • Providing a usable, findable way on the add-ons manager to search all existing add-ons, only requiring a visit to AMO when greater community involvement or information is sought

5. Troubleshooting

  • Providing ways to determine if a particular add-on may be causing performance problems, such as ranking by size, CPU, etc
  • Giving clear communication and instructions if there is a security problem with an add-on

This is still very much a working list open to feedback and changes (especially via comments here or on the wiki).  Basically, what I’d like to focus on is making add-on usage less disruptive and more accessible. Experienced and especially technical users tend to be very aware of add-ons and the functionality they provide. These users may see add-ons mentioned in the tech press, may talk to their friends about their favorite add-ons, and might even get involved in the add-on developer community. These are the users who say “I can’t imagine a world without add-on X.” But the benefit of add-ons is felt almost soley by this group. There are thousands of add-ons available that can improve the online experience of just about any user.  Both users and developers deserve an add-ons manager that helps make customizing the browsing experience simple.

Animation in Firefox: Area 1 of 3: Movement of toolbar items within rows

For the next three posts, I’m going to be highlighting three areas of the Firefox user interface that could benefit from animation. Stephen Horlander and myself have been looking at Firefox with an eye towards where movement could make Firefox an easier, more appealing, and perhaps even faster experience with movement.

First, it should be asked why we would add animation Firefox. Animation in the browser is a tool, but not a goal unto itself. Wherever animation is used, it should be with a purpose (not “it looks cool”) and benefit to the user (not “makes user look cool.”)


Like many web technologies, animation is a useful but easily abused tool. The early web and the dawn of the .gif saw animation heinously overused with blinking, spinning, and scrolling animations added to sites because they looked cool.

As the web calmed down a bit and web and interactive design began to develop, designers and developers found that animation could be beneficial to users. For instance, it can make tasks seem more like real-world affordances, and thus easier to visually understand. It could give users feedback on how digital objects were being moved or manipulated. And yes, they could make interactive experiences more visually appealing.

The first area we feel could benefit from animation is the movement of toolbar items within their rows on the Firefox chrome. This includes buttons like Home and Reload, the bookmark bar, and tabs. Currently, these items can all be shifted and reordered, but little visual feedback is given for these tasks. For tabs, only a thin strip shows where a dragged tab will be dropped.


By adding animation to the process of rearranging items, not only will Firefox feel more lightweight and adaptable, but it will be more visually clear what the user is manipulating and how the UI will be changed by letting go. For instance, animations of tabs being manipulated is essentially live preview of tab rearrangement: if a tab is slid to the right and an animation shows it doing so, releasing it only makes permanent what is being shown. This is similar to the tab animation motion currently in Safari and Chrome.


Because tab tearoff and tab rearrangement would utilize similar mouse movement, some thresholds should be added to prevent users from accidentally performing an unintended action. As Shorlander recommended, a “soft snap” could make tabs within a region of the tab bar slide, and falling outside that region causes them to tear off.

Slight animation could also give newly created tabs the feeling of organic growth into the browser.


(more details in the wiki)

The above sketches are based on work by Stephen Horlander.

Improving everyone’s favorite feature – address not found

One area of Firefox that could use some improvement are the warnings we give when pages are not found.  These could be network errors, firewall issues, URL typos, etc.  Curtis Bartley has been looking at this issue and documenting progress here, and Jesse Ruderman started a bug with some insightful comments here.

Ideally, a good error page does two things:

  1. Tells you what’s wrong in a way that’s both understandable and diagnosable
  2. Helps you decide what to do next

If I type “www.example.cmm” into Firefox now, here’s what I get:


Internet Explorer, Chrome, and Safari all have slight variations on this page.  IE’s isn’t very useful; it gives easy text but no tools. Safari’s design is very minimal, but it does offer search.  Chrome is cutesy, but also intelligently offers suggestions based on what was typed – the most useful of all three.  All three browsers offer additional information via a link, thus removing the bulk of explanation Firefox currently shows.


So what should Firefox do?

For blatant, common URL typos, I think we should redirect straight to the correct URL. currently goes to, why shouldn’t or URLs themselves are an example of forcing users to behave like machines – rather than the preferable reverse – so why not take a step in the right direction by making them more forgiving? (bug freakin’ 175634)

For the addresses that are not blatant typos for existing pages, there’s a few approaches we could take. User-experience-wise, I would love to be able to do better detection of what the problem is and direct the user towards the likely solution. Rather than presenting the user with questions as we do now, we could give them an answer.  We should aim to provide a consistent UI, but perhaps we could change the text sightly based on what the user inputted and try to find the most helpful suggestion. When there’s a very likely solution, that should be the most obvious next step available.

Here’s four scenarios that would cause a 404 today with text customized to what what the user imputed:


While catching all of these scenarios may not be feasible for now, we could be concentrating harder on giving users tools at a 404, not just a warning. I’d love to hear you feedback on this – especially what would help a tech-saavy person such as yourself when you hit a 404.

Just for fun… spoilers!

HTML 5 video tag, pirate edition

Ahoy mateys of the open source seas! Here’s another thing coming in Firefox 3.1: open source HTML 5 video support! This is going to bring some cool new functionality to developers, such as being able to access video elements through the DOM, intersperse video with other web content, and manipulate playback with JavaScript – all without the need for lubber bilge monkey plugins (see blizzard’s post).

A project I took over from the comely wench Wei was to design the controls for the video tag. So, how should they look? The first design iterations focused on geling with Firefox’s overall branding. However, thinking the problem over, these video controls are different from Firefox’s chrome and menus because they appear in the content of a page itself. So, though maintaining Firefox’s brand look & feel throughout the browser is important, I think not interfering with web content is more important. To create “Firefoxy” controls on videos would essentially brand a user’s videos. So, I’m proposing something more neutral and would love feedback: