All posts in Firefox

Do you know CSS? Make a Huge Difference in Firefox 4’s Add-ons Manager

Firefox 4 is right around the corner, and the Firefox’s community and team are working their butts off to make it as awesome as possible. The blocker list is going down every day, and the browser’s looking better than ever.

However, with everyone putting so much effort towards blockers, there are less people available to help with polish bugs for the add-ons manager. In particular, there’s a handful of bugs – mostly in CSS – that would take the add-ons manager from good to awesome. If you know CSS and are interested in helping with a feature used by millions, please consider taking a look at one of the remaining bugs. Not only will you be hailed as the people’s hero (by me anyway), but you’ll be helping millions of people customize their browsing experience.

Here’s a diagram of the remaining add-ons manager polish bugs:

www.donotlick.com

If you need any information or help, comment I’ll get in touch with you!

What’s New in Firefox’s Add-ons Manager

One of the best reasons to use Firefox is with thousands of add-ons available to customize it, you can turn it into exactly the browser you want. To make it easier for you to find and use add-ons, members of the Firefox team and community have been working to redesign the add-ons manager for Firefox 4.0. The new add-ons manager will be easier to use, sleeker, and faster than ever before.

Here are a few highlights of the new design:

Add-ons update automatically

No more warnings when your add-ons are out of date; Firefox will now update them automatically. This should happen without you even noticing, keeping add-ons safe and fast while eliminating the hassle of updating.

Make changes to add-ons without restarting

Restarting your browser is a pain. Developers can now build their add-ons for Firefox 4 such that no restart is required; add-ons built using the Add-on SDK get this for free. Restartless add-ons can be installed, modified, and removed without a single restart needed! More and more restartless add-ons are being created and made available on addons.mozilla.org every day.

Add-on manager in a tab, not a window

 


Instead of managing your add-ons in a small, separate window, the add-ons manager now loads in a tab. This means it won’t be so small and easily lost among other windows, and you can interact with it identically to other tabs, including resizing and moving.

New Get Add-ons pane

Justin Scott has been leading a project to create a new section in the add-ons manager we call the Get Add-ons pane. In the old add-ons manager, we displayed five featured add-ons that could be installed. This was done to show you some examples of add-ons – much like buying a picture frame with a stock photo already inside. Justin’s done a thorough revamp of Get Add-ons, building a page which introduces you to the concept of add-ons, highlights particular add-ons that are editorially selected, and helps you explore and discover other add-ons that match your interests. Justin’s currently working on a new feature for this pane which makes personal recommendations of add-ons you might enjoy based on which add-ons you already have installed.

Quickly find any add-on

If you want to make a change to an add-on but don’t know which category it’s in, you can now simply search for it in the new global search box. The add-ons manager can quickly locate an installed add-on or find you some matching add-ons that are available to install.

If you’re using Firefox’s nightly builds, you can already see many of the above changes in action. Blair McBride has recently put a lot of work into the new theme change, so now we’re working on the final few bugs and polish. If you’ve already used the new add-on manager, please share your thoughts by commenting or leaving a message on Firefox 4.0’s feedback page!

Changes for Firefox Mobile’s Add-on Manager

I’ve been blogging about Firefox’s add-ons manager lately. But what does the add-ons manager look like on Firefox Mobile?

Current Add-ons Manager on Mobile Firefox

Currently, the Android/Maemo add-ons manager in Firefox looks like the image below. At the top are the user’s installed add-ons. Below them, a “Get add-ons” section includes add-on catalog search and five recommended add-ons. Below these is a “Browse all add-ons” button which links to Mozilla’s Mobile Add-on page.

Current Add-on Manager in Firefox Mobile

How Should Mobile Users Learn More About Add-ons?

Giving users information about add-ons has been a continual focus in the non-mobile Firefox add-ons manager redesign. Justin Scott has been leading the design of Firefox’s “Get Add-ons” pane. This pane, which loads within the manager itself, introduces users to add-ons by recommending popular add-ons and promoting the community behind them. The pane also includes a “Learn More” button, which will eventually link to a site which provides add-ons help, information, and even videos about add-ons.

This solution works well on the desktop because of the space available in the add-ons manager and the ease of loading content within Firefox. But would should the mobile solution to add-on information be? And where should that pesky “Learn More” link lead on mobile?

The first option is for “Learn More” to go straight to Mozilla’s page for Mobile Add-ons. However, this site is a portal to our huge catalog of add-ons: it doesn’t provide the simple explanation that “Learn More” implies. Also, it forces the user to leave the add-ons manager and load a media-dense page. Both of these could negatively surprise users.

A second option is for “Learn More” to expand the current “What are add-ons” section within the column to provide more detailed information within the add-ons manager. This has the benefit of consistency with the current mobile UI, where some sections already expand to show more information. It also doesn’t require users to leave the add-ons manager. However, this design also has a few drawbacks. The page height becomes much taller, requiring more scrolling to go between the user’s add-ons and the recommended add-ons. Also, considering the “What are add-ons?” section already expands with a click, now there would either be three levels of zoom or a large surprise the first click.

A third option would be to create another page, within Mobile Firefox’s preferences, that provides an explanation of add-ons. This is better than an external page, because it would not require a lengthy load time while presenting the most relevant information. It also may provide less of a surprise than the expanding in line option. But, it would require users to leave the screen they are on, and would be inconsistent with how the UI works now.

Three Possibilities for Where "Learn More" Link could lead

A Simpler Design

After considering these options and their drawbacks, I went back and thought about exactly what purpose the explanation of add-ons is meant to provide. In Firefox, this section’s purpose is to tell users who have never encountered add-ons what they are and why they are useful. In fact, as soon as the user installs a few add-ons in Firefox, they never see that explanation again. There’s no need for the message to be persistent, as it is currently in Mobile Firefox. In fact, as soon as a user installs an add-on, they no longer need the explanation. Making the message dismissible is the first step towards a better Mobile Design.

So, how can users gain more information about add-ons? And what information would they want?

Assuming that the “What are add-ons” snippet gives a good summary of what add-ons are, and add-ons themselves explain what they do in their descriptions, there simply isn’t enough information left to tell mobile users that justifies a separate explanation link. Additionally, on Mobile Firefox, there are less than 100 add-ons currently available. I simply can’t think of information about these add-ons that would be important enough to users to include a link and a separate page about what add-ons are.

So, the design I’m recommending keeps the explanation of add-ons short but prominent in the add-ons manager. It’s dismissible, but also disappears automatically once the user installs one or more add-ons. If the user wants to browse Mozilla’s Mobile site, the “Browse all add-ons” link at the bottom of the list will direct them there. With such limited screen space, keeping the interface simple should provide the best experience.

Proposed Design for Mobile Firefox's Add-ons Manager

Add-ons Manager Design Update

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!)

Add-ons Manager Redesign Status Update

Meta-bug for redesign: bug 550048, wikiQA
Meta-bug for look and feel: bug 586066, wiki

The basic redesigned add-ons manager functionality is running in Minefield nightly builds.  Many smaller parts of the functionality, and especially edge cases, have open bugs and are being actively designed and fixed.  API changes are being made majoritively by David Townsend, and final CSS visual polish is being done majoritively by Blair McBride.  Majoritively is actually not a word.  Individual bugs are not being filed for most of the small steps required to visually style the manager to match the current mockups.

The add-ons manager consists of a separate panel for each category of add-ons, called List View (☑ bug 585950). Individual add-ons’ details can be viewed in Detail View (☑ bug 562902).  The other main parts of the add-ons manager are search, a client-side “Get Add-ons” pane (bug 558158, spec), and the Update Pane (bug 598738).

Unfinished Functionality

  • Extension manager API rewrite (bug 461973, wiki, documentation). Dave Townsend is making API improvements clean up a number of issues, including to allow the main UI to operate without having to speak RDF.  This bug currently has 52 dependencies, including some user experience issues:
    • Having extension compatibility controlled on a per-addons basis (bug 527861)
    • Controlling order of add-ons in manager (bug 595847) and adding a search plugin provider (bug 552747)
    • Installing and upgrading add-ons in the add-ons manager:
      • Allowing the user to pause installations (bug 553024)
      • Using Firefox’s download manager to manage add-on downloads (bug 555753)
      • Handling failed installations to bad directories (bug 557897)
    • Viewing add-ons in the add-ons manager:
      • Allowing thumbnails and full-size screenshots to display in Detail View (bug 553563)
      • Assuring multiple copies of add-ons don’t appear in manager (bug 562922)
  • UX-centric functionality bugs for viewing add-on information:
    • Implement lightbox-style viewer for add-on screenshots (bug 553462)
    • Create numbered badges for active items on category titles (bug 553486)
    • Hovering over backgrounds should give a live preview (bug 562832)
  • UX-centric functionality bugs for installing and updating add-ons:
    • Allow user to undo a cancelled restart (bug 562300)
    • Checking for updates needs more visual feedback (bug 562925)
    • Showing newly installed add-ons prominently in the UI (bug 565522)
  • UX-centric functionality bugs for using add-ons:
  • In-content UI work needed
    • The add-ons manager currently does not visually  incorporate the navigation bar.  Incorporating the navigation and (if applicable) bookmarks bar, as in the mockups, distinguishes in-content pages as a part of the browser, not a part of the web.  It presents a steamlined, simple interface for dealing with what is essentially a panel of Firefox itself.  It also makes such pages distinct and unspoofable.  Bug 571970 is tracking progress on this change.  An added challenge of this change is making in-content UI work when the user has set tabs to display on bottom (see comment 23).  While a decent design solution could be found, this may not be worth the work and time before Firefox 4, and fixing the multiple back forward buttons present with tabs on bottom (bug 597178) is likely a better temporary solution
  • Unresolved issues
    • Giving a better experience for third-party installed extensions. Namely, to outright disable them on upgrade or not? (bug 596343)

Unfinished Graphics

  • Gradients and texture files needed for background of all in-content pages.  This could get slightly tricky with window resizing, anchored images
  • Concept and icon for what we’ve been calling the “gear” menu.  Gear works fine for OSX, not so much for Windows and Linux.  Even current placeholder gear is too close to native OSX window “tasks” menu
  • Final images and colors on sorter bar and search header
  • Final mockup for Update panel and in-line updates

Add-ons Manager UI Update

I’ve posted quite a few mockups on this blog of Firefox’s redesigned add-ons manager’s features and interactions. What I haven’t shown are screenshots of how the manager will actually look in Firefox 4.0. The following are designs, based on Stephen Horlander’s work on the new Firefox theme, of the add-ons manager in OSX and Windows 7.  The icons are still placeholders, but the rest of the design is pretty near finalized.

In the image below, you’ll see three windows for each operating system.  The first row shows list view, where a short summary of each add-on and its description are shown.  Buttons allow the user to disable an add-on or launch its preferences.  Clicking “More” takes the user to detail view.

The second row shows detail view, where the user sees more information about a single add-on.  The full description is displayed as well as a contribution box if the add-on’s author chooses.

Finally, appearance view shows installed themes and backgrounds (previously personas).  Since these add-ons are primarily visual, the interface gives a large preview of each item and does not display a description.

Dave Townsend and Blair McBride have been working hard on implementing these visual changes as well as the slew of under-the-hood improvements that are making the add-ons manager faster and more stable.  To see how it’s coming along, try running a nightly build in your operating system of choice.  Hope you like it!

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

It’s World Cup month! Let’s start it out right. With another post about removing the status bar.

I know I implied in my last post that you’d be free of this topic forever, but something was bothering me. A piece of the puzzle was missing. I talked it over with my skilled user experience cohorts last week. Whiteboards were involved. I think the kinks were worked out.

The problem with putting add-on icons in the bookmark bar by default is that Firefox’s interface could become easily overcrowded if add-ons add more than just a 16 by 16 pixel icon. If an add-on creates a long horizontal widget, for instance, the whole bookmark bar could taken up after its installation.

Also, many add-ons have come to rely on bottom-anchored functionality – partially because of the location of the status bar. Firebug, for instance, uses a status bar button because its interface is anchored to the status bar.

My first post on this topic noted that users should be able to easily move their add-on icons and widgets wherever they want just by dragging it – to the bookmarks bar, the UI panel, the title bar, wherever. This is still going to be a huge benefit to users who wish to configure their browser. Where add-on icons should be encouraged to install by default is the open question. My proposal is this:

When a user has no add-on installed, there is no status bar.

As soon as the user installs one add-on that wants to use the status bar, a small bar appears in the bottom right of the Firefox window. It’s only long enough to accommodate the add-on icons and widgets the user currently has installed.

If the user hovers over the status bar, a small arrow appears on its left.  If the user clicks this arrow, the status bar shrinks into a small button in the bottom of the window.  This button gives a faint glow as the status bar animates into it.  If clicked, this button will bring the status bar into visibility again.  The button is only visible if the user mouses near it, minimizing visual clutter.

The benefit of this design is that only the smallest possible status bar is shown, and if the user prefers it can be entirely dismissed. The panels for rich interaction would still be added to the API, as well as a way for add-ons to identify themselves as acting on the current page content (perhaps via a subtle “glow” effect).

I think this design addresses the multiple goals for add-ons in the ui: minimal disruption to current add-on functionality, minimal visual clutter, and trivial configuration if the user wishes to modify the default behavior.

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

Recently, I wrote about Firefox’s status bar and how we’d love to remove it, relocate its functionality, and dedicate that area back to page content. Though many add-ons currently place icons in the status bar, these icons could be displayed elsewhere in Firefox’s user interface. By treating add-ons as UI elements that users can move within Firefox’s UI, the bottom of the browser window could be dedicated to content while the functionality of add-ons preserved.

I proposed that by default, add-on icons display in the bookmark bar of the Firefox window.

But, if the user wishes, he can move the add-on icons to other areas. Firefox can subtly change the appearance of an add-on icon to visually match where it is placed.

Several commenters on my previous post noted that they preferred add-ons in the bottom right of the window, both because of particular add-on functionality and familiarity. Indeed, it should certainly be an option to reenable the status bar, and one way to do this should be to drag an add-on icon to the bottom of the window in customize mode.

The cases that would be especially suited to enabling the status bar are add-ons that require long, horizontal space in the main UI. Especially newer add-ons built by Jetpacks are increasingly using this horizontal space in creative ways. If users want this kind of functionality, giving up a significant portion of the bookmark bar should not be the only way to achieve it.

While this horizontal layout that some add-on developers choose is useful for many kinds of information display, it takes up a lot of space in Firefox’s interface and may not always be necessary. Providing API support for rich content panels that launch off of add-on icons could allow add-ons to provide rich interactive content, accessible with a click, that takes up little UI.  This is a win for developers because it would enable them to easily add rich content to their add-ons.  It’s also a win for users, because accessing rich add-on content won’t always mean sacrificing interface space.  Some possible uses for such panels include:

Firefox engineer Dietrich Ayala and Labs engineer Myk Melez are already at work to add an API to Jetpack that will allow these panels to launch from add-ons.

Defeating the Cookie Monster: How Firefox can Improve Online Privacy

As we choose priorities for the next version of Firefox’s features and development, the Firefox team has been considering the state of the web and looking for areas where online content has changed faster than browser functionality. One area of concern is the growing use of private user data, especially by advertisers. User data being silently and persistently passed between sites and advertisers is disturbing for those with an interest in user choice and transparency on the web.

Privacy vs. Security

Privacy and security are related but distinct topics. Security refers to the prevention of material harm to the user. Avoiding theft, fraud, and data loss are all security issues. Browsers have been working to improve security for decades, prompted by increasingly sophisticated viruses, malware, and other exploits.
Privacy is a broader topic than security. It refers to users’ control over what they reveal about themselves online, whether or not what they reveal might lead to material harm. All internet users reveal some information about themselves to some sites, but the user has privacy if his discretion determines what information is shared with whom.

Firefox has Local Privacy but Needs Network Privacy

The Firefox team has already done some great work on local privacy with improvements such as Private Browsing mode, Clear Recent History, and Forget about this Site. These features give users better control over when their data is exposed and hidden on their own computer. However, wider privacy issues surface when data is shared over a network.

One major problem of the modern web is the ability for private user data to be collected by advertising companies via third-party cookies.

If sites provide rich interaction, they usually require user data. The problem occurs when users willingly share data with a site they trust, but unknowingly their data is shared with other sites and companies via third-party cookies. This is common practice and a growing revenue model online. It first received national attention in November of 1999, when the Federal Trade Commission held a workshop on online profiling and reported that it presented a privacy concern to consumers. The practice has grown since then, despite some failed attempts at regulation by the US’s Federal Trade Commission, the Interactive Advertising Bureau, and Britain’s Office of Fair Trading.

Any website you visit can contain ads and other components that send cookies from your browsing session on the domain you trust to an advertising domain. These third-party cookies can be used to track information about users across multiple sites and multiple browsing sessions, allowing web habits to be profiled and tracked. This data can tell companies limitless kinds of information, such as what purchases you make, what news you read, your income, if you’ve applied for work, and what dating sites you prefer. One manifestation of this data sharing is seeing to ads targeting users based on data and actions from other sites.

The ability for advertisers to gain and use this data violates user privacy for several reasons:

  • It’s nearly impossible to detect. Much of the data-sharing happens in the background during a browsing session without asking or notifying the user. Users usually only discover what has happened when they are seeing targeted ads (long after the data has been transferred).
  • It occurs without user consent. Of the sites that are even aware of third-party cookie sharing, few give users control over how their data is shared with advertisers. Sites that do offer preferences sometimes phrase them in ways that disguise their purpose, such as “do you want relevant content to be shown based on your usage” rather than “do you want ads to be shown based on your personal data.”
  • It contradicts the user’s reasonable expectation of privacy. Some sites that knowingly share data present a false image of being responsible with user data. They may show the user preferences that imply control, assure users that their data is “safe,” or offer to let users read a lengthy privacy policy in order to hide their actual practices. Of course there’s a very special hell set aside for sites that change privacy settings to be more permissive once users have already signed up and entrusted their data.
  • It’s nearly impossible to prevent. Even a user who is privacy conscious and reads all privacy policies, keeps his privacy settings up to date, and avoids sites that don’t guarantee privacy isn’t necessarily safe. Any site he’s given data to could potentially use it without asking, and third-party cookies could be sent via ads and web bugs without the knowledge of the site’s owners. Heck, any site could be scraping identifiable information from his digital fingerprint.
  • It potentially embarrasses the user. Data sharing via third-party cookies takes information given by the user at some point in time and exposes it at another time. While the user may be discrete about where he is viewing certain content and even use Private Browsing Mode for items to not appear in history, advertisers using third-party cookies can expose user actions at times out of the user’s control.

So what can Firefox do to improve its story on privacy?

1. Provide intelligent defaults for third-party cookie behavior

Simply disabling third-party cookies isn’t the solution. Third-party cookies are necessary for legitimate web functionality such as embedded content, session management, mashups, etc. Most bank websites depend on third-party cookies for functions such as bill paying. The goal should not be to outright disable third-party cookies, but to be more intelligent about what behavior is allowed.

The http-state working group is currently working to produce a specification in multiple documents to lay out how clients should behave with regard to cookies (see current drafts here). Dan Witte, the cookie module owner at Mozilla, has been in communication with them and is doing his own work to develop a modern cookie standard. The goal is to create a guideline that Mozilla can follow that aligns with our Manifesto to protect user choice on the web. Dan’s already working on one way Firefox could address the problem by enabling third-party cookies, but only temporarily. His idea is to keep third-party cookies active only for the life of one tab. When the tab is closed, the cookies are deleted – advertisers could not track users from site to site. Dan will be blogging about this later with more details on his work.

2. Give users better control over how sites can access their information in Preferences

Currently, Firefox gives users precise, fine-grained control over the many ways that sites can access user data. All the user needs to do is change their on each Preference panel that effects site privileges:

As can be seen above, the current Firefox interface gives each site privilege type – saving passwords, cookies, etc – its own separate preference window. This design is framed around the implementation model rather than the user’s mental model, meaning it’s designed in a way that corresponds with how it was built rather than how users perceive the action they want to take. Having an individual window for each permission makes sense from an implementation standpoint, because each site privilege is separate in code. From the user’s perspective, however, it’s impossible to tell what privileges a particular site has. A better design would present controls in a site-centric rather than technology-centric view. If a user decides that he doesn’t trust site X and doesn’t want it to have any access, it would be more efficient to control all of site X’s access in one – not 15 – Preference windows. Alex Faaborg made this mockup to illustrate how a site-centric UI could be achieved:

While all of Firefox’s Preferences need to be improved, including site-centric privacy controls like Alex’s above for Firefox 4.0 would go a long way towards putting users back in control of their data.

3. Give users better control of their data while they are browsing

While a site-specific Preference panel will help users have better fine-grained control of their privacy when they’re configuring Firefox, there’s some options and information that can be exposed while the user is browsing. If a site has access to geolocation, for instance, this should be constantly indicated in Firefox’s interface. If a site is storing a password, this should be easy to change or remove without opening Preferences. Firefox’s Site Identity Button, which currently gives very little information about a site, could be improved to give information about a site’s privileges and the ability to change them.

It’s our goal for Firefox 4.0 to give users more control of their data, both by literally giving them controls and, more importantly, creating intelligent defaults that protect a user’s privacy and anonymity without breaking web functionality. It’s my hope that even simply exposing what access sites have to data will be positive for the web by eroding the sense of false security that many sites try to create for their users and creating awareness of and control over how, where, and when data is being shared.

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.