Australis Customization

Mike Conley mconley at
Wed Apr 24 04:07:54 UTC 2013

Hey all,

We've come up with our final proposal, so I think this is the direction 
we're going to be going. Keep in mind that no plan survives battle, so 
there's a very remote possibility that this plan might still get tweaked 
here and there as we run into things, but I think this more or less sums 
it up correctly.

The proposal is very much the same to v2, but I've included some more 
justifications, and made the small icons mode removal more explicit.

Anyhow, thanks everybody for the feedback!


==== Customization Final Proposal ====

# Goals

* Lower the barrier to entry for end-users to customize the UI - make it 
an experience that more users can find and want to try

As a caveat, this means protecting the user from the few customizations 
that break the browsing experience. We get a ton of hits on 
Resetting Firefox is a ham-fisted solution, and so we're going to try to 
make it harder for these critical bits of UI to disappear

* Make it easier for add-ons to add buttons to toolbars and the new menu 
panel on installation

* Do our best effort to allow power users to retain their heavily 
customized UIs.  In some cases, certain customizations will need an 
add-on to manipulate some UI.


# List of proposed changes

* Join the Stop and Reload buttons into a single button for customizing, 
like the back / forward buttons.

There's quite a bit of magic with the stop and reload buttons. If 
they're in the order of Stop + Reload, they merge into a single button. 
If they're next to the URL bar in that order, they merge into the URL 
bar. If they are in the Reload + Stop order, they stay as separate 
buttons. They can also be set on opposite sides of the browser window. 
The two buttons' enabled state is mutually exclusive. This is an attempt 
to reduce some of those hacks by getting rid of a case (Stop and Reload 
in a different order from one another).

This change could be undone with an add-on by hiding the combined 
stop/reload and supplying two discrete new buttons.

* Prevent back, forward, url bar, stop and reload buttons from leaving 
the nav-bar, while still allowing them to be re-ordered.

A popular SUMO page is: - it is 
far, far too easy for users to move these critical items into collapsing 
toolbars, or into the palette.

These toolbar items would never get moved to the overflow panel.

This change could also be undone with an add-on.

* Remove the ability to hide the Navigation Toolbar

Users who are seeking to match the IE9+ theme (navigation controls 
inline with the tabs) will need to install an add-on.

* Toolbars that are collapsed will not be visible while customizing

* Remove the add-on bar from the core product

This helps to cluster tools into the top portion of the browser by 
default and avoids incurring an entire toolbar when a user only has a 
couple of add-ons installed

Anecdotal data also suggests that this toolbar is not broadly useful for 
the majority of our users.

Finally, we hope this will make add-on-installed features feel more like 
"first class citizens" and equal to shipped-in-the-browser features by 
allowing them to all live together in the same menu panel. This 
co-mingling will hopefully make it clear to end-users that both add-on 
features and built-in ones are addable and removeable by them.

The add-on bar could be re-inserted with another add-on.

* Remove UI for adding custom toolbars

 From anecdotal user data, this is not a heavily used feature. This 
feature could also be restored with an add-on.

* Small icons mode, as well as text and text+icons modes for toolbar 
items will be removed

The "small icons" mode does very little. On Mac, it only affects the 
appearance of the back/forward button. On Windows, it additionally only 
affects the padding between icons, not the size of the icons themselves.

We don't have good usage data (as far as I know), but since it is a 
non-default option that must be enabled through secondary UI, it's quite 
likely that usage across the user base is very low.

Given Firefox's very powerful add-ons capabilities, it's possible to 
"work around" the lack of the feature in Firefox with an add-on (e.g.


# Possibly Asked Questions:

Q: List for me all of the areas in Firefox that will be customizable.

A: Where "customizable" means "I can drag and drop toolbar items while 
in customize mode", the following areas will support this activity out 
of the box

* The entire nav-bar (including areas to the left of the back, forward, 
URL bar, stop and reload buttons) will be customizable (with the 
exception that the back, forward, URL bar, stop and reload buttons 
cannot leave the nav-bar, and cannot overflow)

* The tab strip - although the tabs themselves will not be moveable by 

* The entire menu bar if not autohidden (as is currently the case, the 
File | Edit | View menu will not be removable)

* The entire bookmarks bar if not autohidden

Q: If I've moved my back, forward, URL bar, stop and/or reload button 
out of the nav-bar, what happens when I suddenly start using this new 
version of Firefox?

A: Your back, forward, URL bar, stop and reload buttons will be 
clustered together and put back into the nav-bar. An add-on will need to 
be written in order to move those items out of the nav-bar.

Q: Explain the back/forward, URL bar, stop/reload clustering again. Can 
I put my back button on the right side of my nav-bar? Can I put my URL 
bar into my tab toolbar?

A: The stop and reload buttons will be merged into a single toolbar 
item. This means that it will not be possible by default to separate 
them from one another.

The three items - back/forward, URL bar, and stop/reload will be 
restricted to the navigation toolbar by default, and cannot be removed. 
They can, however be reordered - meaning that items can be placed around 
and between them.

So, for example, the navigation bar could be customized to have the 
following items in this order:

URL bar, downloads, stop/reload, search input, home, bookmarks, back/forward

On 2013-04-17 6:29 PM, Mike Conley wrote:
> Hello folks,
> So the Australis project is chugging along nicely (if you haven't tried
> the UX branch build[1], you should check it out).
> One of the things we've started to work on is improving how users can
> customize Firefox. We want customization to be easy and pleasant to do,
> and hard to get wrong (ie, hard to break the browser).
> Customization is a hot-button topic, and it's not surprising that once
> we start fiddling with it, users who customize their browser UI are
> going to get concerned. So I wanted to open up the discussion here so we
> can perhaps discuss those concerns, and ideas for mitigating them.
> For those who aren't familiar with the project[2], I'm going to try to
> summarize the high-level changes to customization that we're proposing.
> I should emphasize that while we've started to write these things down,
> nothing is set in stone. It's just a place to start.
> Anyhow, so here are our thoughts:
> 1. We want to introduce more specific customization targets into
> Firefox's UI. An example of a customization target would be a box
> immediately to the right of the AwesomeBar, or one to the right of the
> tabstrip, or one in our new menu panel. These boxes are places where
> toolbar items can be dragged to and from.
> 2. We want to remove (or deprecate) the add-ons bar
> 3. We want to have an in-content customization palette to replace the
> old window palette
> 4. We're introducing a fixed Menu button at the end of the toolbar which
> opens the "menu panel". The menu panel will contain one or more
> customization targets.
> 5. We're considering moving the back, forward, URL bar, refresh and stop
> buttons to the start of the nav-bar, and making them immovable when
> using the customization mode.
> We're going to need to migrate incompatible customizations over to this
> new world. Jared and I have started talking about that, and we wrote our
> initial plan down here:
> - again, not set
> in stone.
> So, let's chat. In particular, I'd like to hear from the UX team in case
> I've forgotten something or made a mistake in my outlining of these
> points. But I'd also like to just hear from the firefox-dev community at
> large in case what we're looking at doing is in need of more tweaking.
> Sorry for the long post,
> -Mike
> 1:
> 2: a UI prototype to illustrate:
> and a
> spec to read:
> _______________________________________________
> firefox-dev mailing list
> firefox-dev at

More information about the firefox-dev mailing list