Australis Customization

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! -Mike ==== 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 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 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: 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. 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. https://addons.mozilla.org/en-US/firefox/addon/small-nav-bar/?src=ss) ------------------------------------------------------------------------ # 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. 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: > 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