Australis Customization

Sun Apr 21 20:13:32 UTC 2013

Hello all,

There's been a lot of really great discussion here. Thanks for proving 
that firefox-dev can be a venue for constructive criticism and 
collaboration. :)

I've got a second draft of a proposal for changes to customization. Here 
goes:

==== Customization Proposal - V2 ====

# Goals

* Lower the barrier to entry for customizing the UI - make it an 
experience that more users would want to try

As a caveat, this means protecting the user from customizationsthat 
break the browsing experience. We get a ton of hits on 
https://support.mozilla.org/en-US/kb/navigation-buttons-missing. 
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 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 or overflowing out of view, while still allowing them to be 
re-ordered.

A popular SUMO page is: 
https://support.mozilla.org/en-US/kb/navigation-buttons-missing - it is 
far, far too easy for users to move these critical items into collapsing 
toolbars, or into the palette.

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 addons installed

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

* Remove primary 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.

------------------------------------------------------------------------

# 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 
default.

* 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.

Feedback?

-Mike

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:
> https://bugzilla.mozilla.org/show_bug.cgi?id=860814#c3 - 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: http://people.mozilla.org/~jwein/ux-nightly/
> 2: a UI prototype to illustrate:
> https://people.mozilla.com/~bwinton/australis/customization/mac/ and a
> spec to read:
> http://people.mozilla.com/~zfang/Customization/AustralisCustomization_Q4Spec.pdf
>
> _______________________________________________
> firefox-dev mailing list
> firefox-dev at mozilla.org
> https://mail.mozilla.org/listinfo/firefox-dev