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.