Australis Customization

1211 views
Skip to first unread message

Mike Conley

unread,
Apr 17, 2013, 6:29:30 PM4/17/13
to firef...@mozilla.org
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
firef...@mozilla.org
https://mail.mozilla.org/listinfo/firefox-dev

Mike Conley

unread,
Apr 18, 2013, 10:56:16 AM4/18/13
to firef...@mozilla.org
I should emphasize a point, since I've been seeing posts in various
webby places misinterpreting it:

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

Of course I want to hear from everybody, not just the UX team. I just
wanted the UX team to correct me if my representation of our v1 plan was
incorrect.

-Mike

sabre...@yahoo.co.uk

unread,
Apr 18, 2013, 2:35:20 PM4/18/13
to firef...@mozilla.org
Is there research data available to demonstrate that there are more users who "render their browsers un-usable with their customizations" than there are users who customise their browser's UI (move buttons, etc) and retain usability?

While I'm genuinely generally excited about Australis, removing the ability to move buttons is deeply confusing to me. I'm all for the most of the changes, but I implore Mozilla to retain the ability to move and place buttons freely.

Mike Vaughn

unread,
Apr 18, 2013, 11:43:46 AM4/18/13
to firef...@mozilla.org

(This is in response to this comment .)

> We want to make customization better.

Making customization better != completely removing customization options. Being able to put all of the UI elements I need (and *only* the ones I need) on one toolbar is pretty much the only thing that's kept me from switching browsers for the past 8 years. I can understand the desire to protect "casual" users from themselves, i.e., trying to keep them from doing something like removing the address bar. However, from a user perspective, I see no reason why this couldn't be implemented differently. Maybe make a new about:config option like "browser.chrome.fully_customizable_toolbars," which is set to "false" by default. This would prevent casual users from potentially breaking the browser, while still allowing the type of customization that so many users have come to expect from Firefox.

Furthermore, the current ability to "break the browser" by removing critical UI elements is pretty much nullified by the "Restore Default Set" button in the "Customize Toolbar" dialog. AFAIK, it's impossible to remove the menu button (which gives easy and intuitive access to said dialog), so there's literally no way to "break" the browser in a way that it can't be easily "fixed."

Madhava Enros

unread,
Apr 18, 2013, 2:55:01 PM4/18/13
to sabre...@yahoo.co.uk, firef...@mozilla.org
Hi all -

In case there's confusion here -- there's no intent or current action here to take away people's ability to move and place buttons. In fact ( and this is why I'm a bit confused here) a huge part of the whole *point* of the Australis customization mode is to make it easier to move add and remove buttons, and to make this ability hugely more discoverable than it's been before (i.e. a "Customize" item right in the main menu rather than a difficult to find right click on the toolbar).

The only restriction that we've been proposing is to make it impossible to remove the cluster of back button / url bar from the toolbar, given that, without them, the browser becomes very hard to use. The rationale here is that with easier to access customizability, we're going to encounter people doing some of it by accident, and we'd like to make it harder for people who don't understand what they're doing to shoot themselves in the foot.

Does that clarify things at all? Or have I missed something?

Madhava

-- 
Madhava Enros
Firefox User Experience

On Thursday, April 18, 2013 at 2:35 PM, sabre...@yahoo.co.uk wrote:

Is there research data available to demonstrate that there are more users who "render their browsers un-usable with their customizations" than there are users who customise their browser's UI (move buttons, etc) and retain usability?

While I'm genuinely generally excited about Australis, removing the ability to move buttons is deeply confusing to me. I'm all for the most of the changes, but I implore Mozilla to retain the ability to move and place buttons freely.

Gavin Sharp

unread,
Apr 18, 2013, 2:55:27 PM4/18/13
to Mike Vaughn, Firefox Dev
On Thu, Apr 18, 2013 at 8:43 AM, Mike Vaughn <mike.va...@gmail.com> wrote:
> However, from a user perspective, I
> see no reason why this couldn't be implemented differently. Maybe make a new
> about:config option like "browser.chrome.fully_customizable_toolbars," which
> is set to "false" by default. This would prevent casual users from
> potentially breaking the browser, while still allowing the type of
> customization that so many users have come to expect from Firefox.

There are a few good reasons. The primary one is that supporting
arbitrary customization is not necessarily trivial in this new model.
If the only people who would make use of the feature are the set of
users who would be willing to flip a hidden about:config preference,
then we'd be spending significant development and maintenance work
supporting a feature that a small minority of our users actually
benefit from. That's not a good way for us to spend our time.

> Furthermore, the current ability to "break the browser" by removing critical
> UI elements is pretty much nullified by the "Restore Default Set" button in
> the "Customize Toolbar" dialog. AFAIK, it's impossible to remove the menu
> button (which gives easy and intuitive access to said dialog), so there's
> literally no way to "break" the browser in a way that it can't be easily
> "fixed."

"restore default set" is only useful if people know how to find it. So
its mere existence isn't a magic solution to the problem, we also need
to make sure that the customization experience as a whole is as
intuitive as possible. But I agree with the sentiment that a properly
exposed "reset" feature could mitigate many of the concerns about
unintentional "breaking" of the browser.

Gavin

Mike Conley

unread,
Apr 18, 2013, 3:58:55 PM4/18/13
to firef...@mozilla.org
I've gone through some posts on Reddit, distilled some recurring
questions, and answered them from my perspective.


"Toolbars created by add-ons are being untouched. Why?"

We're focusing on the type of customization where users can drag and
drop items to and from their toolbars and toolbar palette. The toolbars
that add-ons inject do not by default fall under this category, so we're
not doing anything to them. It's out of scope for the project.


"Do we know how many users customize their UI's, beyond what add-ons do
for them automatically?"

We have lots of anecdotal data from user interviews, but as one might
expect, we don't actively collect data about UI customizations. The
heatmap Test Pilot study[1] is a tempting datapoint, since we can detect
how many users in that study clicked on the "Customize" menu item -
however, the datapoint is skewed by sample bias, and by the fact that
customizations could have occurred before the study began. And it
certainly doesn't tell us what type of customizations these are. It's
simply not reliable.

Whatever the number of users is, remember that the goal is to *increase*
that number. We want *more* users to be able to customize their browser,
not less. We want more users to feel comfortable moving toolbar buttons
to where they want them, while at the same time, making it harder for
them to break the browser.


"Can't we make these changes pref-offable?"

This might be something to consider, if the benefits truly outweigh the
development and maintenance costs. But I think we'd need a really,
really, *really* compelling reason to take on that kind of maintenance
burden.


"Why is small icons going away?"

We're proposing this[2] because it's not the default view for icons, and
the majority of Firefox users arguably don't even know this mode exists.
Plus, there's the maintenace burden - it doubles the number of icons our
designers have to create for GTK Linux, and it's yet another mode to
test. We propose that if this is a really useful feature for some users,
that it should exist as an optional theme.

1: https://heatmap.mozillalabs.com/
2: https://bugzilla.mozilla.org/show_bug.cgi?id=863299



On 17/04/2013 6:29 PM, Mike Conley wrote:

Mike Conley

unread,
Apr 18, 2013, 4:09:10 PM4/18/13
to firef...@mozilla.org
> removing the
>> ability to move buttons is deeply confusing to me

Right - and it's definitely not the goal. The end result of this should
(hopefully) be that *more* users feel comfortable adding, moving and
removing toolbar buttons in Firefox.

Mike Conley

unread,
Apr 18, 2013, 4:12:05 PM4/18/13
to firef...@mozilla.org
Correction - that first footnote link should have gone to the up-to-date
study results:

https://blog.mozilla.org/ux/2012/06/firefox-heatmap-study-2012-results-are-in/

Timothy Warren

unread,
Apr 18, 2013, 5:36:12 PM4/18/13
to firef...@mozilla.org
From the bug:
> == Addons Toolbar ==0 > > The add-ons toolbar will be removed. The items in this toolbar will be placed in the customization target of the nav-bar.

What is the rationale behind this? The addon bar can display much more information/ addon buttons than crowding the main chrome area. 
This is especially important for smaller screens. 

Is there something about the addon bar that is different from other toolbars?

Nicholas Nethercote

unread,
Apr 18, 2013, 8:33:43 PM4/18/13
to Madhava Enros, sabre...@yahoo.co.uk, firef...@mozilla.org
On Thu, Apr 18, 2013 at 11:55 AM, Madhava Enros <mad...@mozilla.com> wrote:
>
> In case there's confusion here -- there's no intent or current action here
> to take away people's ability to move and place buttons.

Are there Australis-enabled builds available? If the people who are
worried could try them out and see if it's still possible to do the
customizations they want, that would make this discussion vastly more
productive.

Nick

Jared Wein

unread,
Apr 18, 2013, 8:39:35 PM4/18/13
to Nicholas Nethercote, sabre...@yahoo.co.uk, Madhava Enros, firef...@mozilla.org
----- Original Message -----
> From: "Nicholas Nethercote" <n.neth...@gmail.com>
>
> On Thu, Apr 18, 2013 at 11:55 AM, Madhava Enros <mad...@mozilla.com>
> wrote:
> >
> > In case there's confusion here -- there's no intent or current
> > action here
> > to take away people's ability to move and place buttons.
>
> Are there Australis-enabled builds available? If the people who are
> worried could try them out and see if it's still possible to do the
> customizations they want, that would make this discussion vastly more
> productive.

Yes, users who want to play with Australis can download the UX Nightly builds that are linked to from http://msuja.ws/ux

- Jared

Geoff Lankow

unread,
Apr 19, 2013, 2:56:22 AM4/19/13
to firef...@mozilla.org
On 19/04/13 06:55, Madhava Enros wrote:
The only restriction that we've been proposing is to make it impossible to remove the cluster of back button / url bar from the toolbar, given that, without them, the browser becomes very hard to use.
What if these items were movable but trapped in the toolbar? Personally I can't stand the stop/reload/home buttons in their default place, because when I'm switching browsers constantly (website testing) it's much easier to have the buttons in the same place in each.

GL

Benjamin Smedberg

unread,
Apr 19, 2013, 8:35:00 AM4/19/13
to Geoff Lankow, firef...@mozilla.org
I second the notion. I fully agree that removing the back button/url box shouldn't be supported (and causes all sorts of headaches in the code). But I currently arrange my toolbar like this:

back | forward | refreshstop | searchbox | downloadbutton | location box | screengrab

And I'd be a little annoyed if I couldn't keep my search box where it is. (FWIW, I do this because 'K' is to the left of 'L' on the keyboard, and it helps me have the kinetic memory that Ctrl-K is search and Ctrl-L is location bar.

--BDS

Mike Conley

unread,
Apr 19, 2013, 10:04:49 AM4/19/13
to firef...@mozilla.org
>> What is the rationale behind this?

I think the primary rationale is that it clusters all of the tools into
a single area - the top of the browser.

We're proposing this as the out-of-the-box state. We want to support
add-ons injecting toolbars and registering themselves as customization
targets, so for the users who really need the add-on bar, an add-on to
provide it should be built[1]. Not sure who will build it, but it
wouldn't be a difficult job.

-Mike

1: An add-on to add an add-on bar. Might need to call it the Metabar. :)

On 18/04/2013 5:36 PM, Timothy Warren wrote:
> From the bug:
>> == Addons Toolbar ==0
>>
>> The add-ons toolbar will be removed. The items in this toolbar will be placed in the customization target of the nav-bar.
>
> What is the rationale behind this? The addon bar can display much more information/ addon buttons than crowding the main chrome area.
> This is especially important for smaller screens.
>
> Is there something about the addon bar that is different from other toolbars?
>
>
>
> - Timothy J. Warren
> http://timshomepage.net
> t...@timshomepage.net <mailto:t...@timshomepage.net>
>
>
> On Thu, Apr 18, 2013 at 4:12 PM, Mike Conley <mco...@mozilla.com
> <mailto:mco...@mozilla.com>> wrote:
>
> Correction - that first footnote link should have gone to the
> up-to-date study results:
>
> https://blog.mozilla.org/ux/__2012/06/firefox-heatmap-study-__2012-results-are-in/
> 1: https://heatmap.mozillalabs.__com/
> <https://heatmap.mozillalabs.com/>
> 2: https://bugzilla.mozilla.org/__show_bug.cgi?id=863299
> https://bugzilla.mozilla.org/__show_bug.cgi?id=860814#c3
> <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/
> <http://people.mozilla.org/~jwein/ux-nightly/>
> 2: a UI prototype to illustrate:
> https://people.mozilla.com/~__bwinton/australis/__customization/mac/
> http://people.mozilla.com/~__zfang/Customization/__AustralisCustomization_Q4Spec.__pdf
> <http://people.mozilla.com/~zfang/Customization/AustralisCustomization_Q4Spec.pdf>
>
>
> _________________________________________________
> firefox-dev mailing list
> firef...@mozilla.org <mailto:firef...@mozilla.org>
> https://mail.mozilla.org/__listinfo/firefox-dev
> <https://mail.mozilla.org/listinfo/firefox-dev>
>
> _________________________________________________
> firefox-dev mailing list
> firef...@mozilla.org <mailto:firef...@mozilla.org>
> https://mail.mozilla.org/__listinfo/firefox-dev
> <https://mail.mozilla.org/listinfo/firefox-dev>
>
> _________________________________________________
> firefox-dev mailing list
> firef...@mozilla.org <mailto:firef...@mozilla.org>
> https://mail.mozilla.org/__listinfo/firefox-dev

Myk Melez

unread,
Apr 19, 2013, 12:13:06 PM4/19/13
to Mike Conley, firef...@mozilla.org
On 2013/04/19 07:04, Mike Conley wrote:
>>> What is the rationale behind this?
> I think the primary rationale is that it clusters all of the tools
> into a single area - the top of the browser.
In my experience it's also unpopular with addon developers and users,
because it feels like a second-class location, all the way at the bottom
of the screen, and far away from Firefox's core tools, which live in the
more visible and accessible toolbar at the top of the Window.

-myk

Jared Wein

unread,
Apr 19, 2013, 12:54:18 PM4/19/13
to Benjamin Smedberg, Geoff Lankow, firef...@mozilla.org
----- Original Message -----
> From: "Benjamin Smedberg" <benj...@smedbergs.us>
>
>> On 4/19/2013 2:56 AM, Geoff Lankow wrote:
>>
>> Personally I can't stand the stop/reload/home buttons in their
>> default place, because when I'm switching browsers constantly
>> (website testing) it's much easier to have the buttons in the same
>> place in each.
>
> I second the notion. I fully agree that removing the back button/url
> box shouldn't be supported (and causes all sorts of headaches in the
> code). But I currently arrange my toolbar like this:
>
> back | forward | refreshstop | searchbox | downloadbutton | location
> box | screengrab
>
> And I'd be a little annoyed if I couldn't keep my search box where it
> is.

We are planning to allow users to move items to the left- and right-side of the "navigation controls". This would still allow the search box to be placed to the left of the URL bar.

I don't think we've made a decision about the ability to separate the back|forward|location box|refresh-stop buttons. I see the main benefit for allowing users to rearrange these is to support users who migrate frequently between various browsers.

However, the front-end code ends up getting pretty nasty to support the infinite variations of these buttons that we currently allow.

One of the largest benefits of Australis that isn't getting talked about often is the future ability for the front-end team to move faster in implementing new features and fixing bugs. Supporting dynamic button-combining (like we do for stop+reload and the back/forward+location box) makes fixing bugs in those areas much more difficult than it should be.

I propose that if we want to keep supporting users who frequently migrate between browsers, that we add a checkbox to the customization area that allows the refresh/stop to be moved from the end of the location bar to between the back/forward and location box. For example, here are how other browsers have their "navigation controls" arranged:

IE10: Back/forward/location box/reload+stop
Chrome: Back/forward/reload+stop/location box
Firefox: Back/forward/location box/reload+stop
Safari: Back/forward/iCloud/share/location box/reload+stop

This would help the users who frequently migrate between the browsers, and also help to clean up some of the crazy code that we have in the front-end.

Thanks,
Jared

dgrn...@gmx.com

unread,
Apr 18, 2013, 3:07:02 PM4/18/13
to firef...@mozilla.org
In the current proposal the Social, WebRTC, Panel Menu and Page Control buttons and URLbar may not be moved at all. Nothing may be placed before the URLbar or the Tabs. These restrictions show a disappointing lack of faith in the new Customization Mode.

I'm all for a more beautiful Default Firefox - Australis looks lovely. But if I need to customize, it's because the defaults don't meet my requirements in some way - limiting my customization to small variants on the default is actively working against me. Firefox has always been able to approximate other browsers' layouts (or invent new ones) to make switching easier. That is a valuable asset.

Feature discoverability has long been one of Firefox's failings, and I had hoped that the new Customization Mode would go a long way to helping users realize they can really make Firefox their own, but instead they'll find there's really not much they can affect - confined to a safe zone where they can't hurt themselves.

If the metrics prove that users are screwing up their interfaces so horribly they can't work, then fine - but the data needs to come from *users using Australis*, not the current theme. Please give the more prominent "Restore Defaults" button, itself located in the more prominent Customization Mode, a chance to let users resolve any issues themselves before stepping in and saying you know better.

Mitchell Ferguson

unread,
Apr 19, 2013, 1:32:39 PM4/19/13
to firef...@mozilla.org
Hi all,

Good to see lots of conversation going on about this proposal, but I haven't seen anyone present a complete alternative for the UX changes yet. So, that is what I aim to provide.

First, I oppose *all* removal of customizability.

I propose that specific defences be put in place to prevent breakages of the browser. My main weapon in this fight would be education. If the user attempts to remove the back button from the browser, how about the browser gives an alert, telling the user what they are about to do, and giving a one-click button to put the Back button where it was before the user grabbed it.

This strategy could be used all over Firefox. User tries to turn the Nav bar off? Pop up a warning! (Once.) User removes the URL bar? Tell them what they did and make it easy to reverse it! There are other ways to solve this problem without killing most customization.

Another possible strategy is putting a "Restore default Interface settings" button in the Preferences window (I know there is already one in the Customization window, but this one would be in a more visible spot, and perhaps reset some other settings which can break the browser?) What about a "Reset Firefox to Factory Defaults" icon in the start menu (or equiv)?

(Also, it should be fairly simple to put in a pref to turn these warnings off. No need to step on the toes of power users who just want to modify stuff.)

I believe this is the best solution. It saves normal users from accidentally rendering their browsers unusable, and doesn't prevent people who want to customize, from, well, customizing.

I imagine one criticism of my plan will be that this will be a lot of work for the developers, because it will have to be put into place for every single scenario where the browser can be broken - but I believe the current proposal is similar - only some customizability is targeted by the changes, so in essence, each individual browser breakage scenario must be addressed.

Now I'll address the individual points in the plan. This is a copypaste from my reddit post at http://reddit.com/r/firefox/comments/1cl352/psa_the_ux_team_is_destroying_firefoxs/c9hke1b

>"Small icons" mode will no longer be supported.

I understand what the purpose behind this is (lower icon-making burden), but I don't really think it matters anymore. We have a good icon set already, why throw it out? Do they truly not fit the new theme?

>The add-ons toolbar will be removed. The items in this toolbar will be placed in the customization target of the nav-bar.

The addon toolbar is already off by default, easily disabled if a user doesn't want it, and I'm sure the maintenance burden is next-to-none. It's just a bland toolbar!

It deserves to stay because it keeps addons easily accessible (I.e. not under a menu, like I understand UX is proposing in http://people.mozilla.com/~zfang/Customization/AustralisCustomization_Q4Spec.pdf), while taking up a minimum of screen space.

Putting those icons in the nav bar ensures they are large, garish (addon developers aren't known for their icon design skills), and take up lots of horizontal screen space - on the addon bar, they take up none.

I saw another comment somewhere in this thread saying that icons in the addon bar are 'second class citizens' due to their size and isolation. I believe that 'second class citizens' are necessary in a functional UI, because not all functions are used with the same frequency - I don't fiddle with ABP often, but that doesn't mean I want it off the screen. The Australis proposal seeks to put those icons on a submenu, but that makes them even *more* of a second class citizen, requiring two precise clicks rather than one. Our current solution works well, and there is no need to change.

Another issue with removing the addon bar is that badly coded addons with start forcing their icons in the nav bar - by force, I mean that they are not movable in the Customization window. If possible, I hope this behaviour can be disabled (It already happens with some addons - usually they have a preference to turn it off, but some don't. I can't name examples because I don't keep such addons installed long.). If the addon bar is removed, then I imagine this behaviour will become more common, and even if users manually readd the addons bar, it will become more difficult to move addons down there as addon authors assume there is only one place they can put their icon.

>The menu toolbar (File / Edit / View) will no longer be a customization target. Items that have been placed in the menu toolbar will be placed in the nav-bar customization target.

This, I can actually see where you're coming from. In theory, a user could accidentally drop a toolbar icon onto the menu toolbar, which then disappears and they never see their icon again. (Or at least, until they press alt again.)

However, in defense of people who, I'm sure, do indeed use the menu bar for something useful, I again propose a single-shot warning when an icon is dropped there. An explanation of the disappearing menu bar, one button to leave it there and one button to move it back to its previous location. Simple, transparent, and solves the problem.

>Custom toolbars (the type created from the "Add New Toolbar" button in toolkits customization window), will be removed. The items that were in those custom toolbars will be appended to the nav-bar customization target.

This is unnecessary. No novice user is going to stumble upon this feature, and if they do, all it does is add some blank space to their browser. This is simply torpedoing a useful, albeit obscure, function for no benefit.

I think I have mostly addressed my points of concern (I should note that I pretty much object to all of your feature-removing plans, so If I missed one, please assume that I don't like it.)

The new toolbar-submenu idea actually sounds like a good idea - but only if it's optional, just another button to add or remove from the nav-bar as the user sees fit. This allows you to set up Firefox, by default, how you described in the aforelinked pdf. However, for people who prefer it our own way, you can still maintain the features necessary for Firefox's greatest asset in the browser wars - customizability.

Thanks for reading. I do hope to hear about some major changes to the Australis proposal soon! :)

sabre...@yahoo.co.uk

unread,
Apr 19, 2013, 4:41:09 AM4/19/13
to Madhava Enros, firef...@mozilla.org
I think the problem is that the customisable area is so much smaller in Australis than it has ever been previously. So many buttons are locked in place and unmovable and what's left is a tiny area for users to rearrange things. If we're being honest, that's not customisation.

Could I propose that rather than lock items such as Back/Forward/Awesome Bar/Reload in place. You simply lock them so they're unremovable from the navigation bar. You retain the logic whereby users can separate/have them interrupted (in terms of order/placement) and but for the menu button, users can truly customise the Navigation bar while users that need saving from themselves are prevented from being able to remove key features from the primary UI.

From: Madhava Enros <mad...@mozilla.com>
To: "sabre...@yahoo.co.uk" <sabre...@yahoo.co.uk>
Cc: "firef...@mozilla.org" <firef...@mozilla.org>
Sent: Thursday, 18 April 2013, 19:55
Subject: Re: Australis Customization

Gavin Sharp

unread,
Apr 19, 2013, 2:57:28 PM4/19/13
to dgrn...@gmx.com, Firefox Dev
On Thu, Apr 18, 2013 at 12:07 PM, <dgrn...@gmx.com> wrote:
> In the current proposal the Social, WebRTC, Panel Menu and Page Control buttons and URLbar may not be moved at all. Nothing may be placed before the URLbar or the Tabs. These restrictions show a disappointing lack of faith in the new Customization Mode.

Mike Conley is preparing an updated proposal based on discussions we
had yesterday. He will post it here; I think it may address most of
your concerns.

(Note that the social button is not customizable even in current
builds, due to some implementation issues.
https://bugzilla.mozilla.org/show_bug.cgi?id=804283)

Gavin

Gavin Sharp

unread,
Apr 19, 2013, 2:58:56 PM4/19/13
to sabre...@yahoo.co.uk, firef...@mozilla.org, Madhava Enros
On Fri, Apr 19, 2013 at 1:41 AM, sabre...@yahoo.co.uk
<sabre...@yahoo.co.uk> wrote:
> Could I propose that rather than lock items such as Back/Forward/Awesome
> Bar/Reload in place. You simply lock them so they're unremovable from the
> navigation bar. You retain the logic whereby users can separate/have them
> interrupted (in terms of order/placement) and but for the menu button, users
> can truly customise the Navigation bar while users that need saving from
> themselves are prevented from being able to remove key features from the
> primary UI.

Mike can confirm, but I believe this is exactly what several of us
agreed upon yesterday when discussing the original proposal.

Gavin

Mike Conley

unread,
Apr 19, 2013, 3:02:15 PM4/19/13
to firef...@mozilla.org
Yep, confirming - I'll have a new proposal posted soon.

Wadhah

unread,
Apr 19, 2013, 2:39:38 PM4/19/13
to sabre...@yahoo.co.uk, firef...@mozilla.org
Why not have ALL the customization, but when detecting the disappearance of some parts there would be a popup/button/notification to restore the missing essential stuff?
I think it will make it easier to code and maintain , and service everyone.

Gavin Sharp

unread,
Apr 19, 2013, 3:11:03 PM4/19/13
to Wadhah, Mitchell Ferguson, sabre...@yahoo.co.uk, firef...@mozilla.org
Mike will be posting an updated proposal soon, so we should use that
as a basis for further discussion. But I wanted to address one point
that came up in both your post and Mitchell's:

"why not just add some alerts/notifications to allow undoing 'bad'
customizations?"

Allowing users to shoot themselves in the foot and then prompting them
to undo it is really not a great experience - no one likes being
prompted/notified when they're otherwise just trying to get something
done. We're not going to be removing as many customization points in
the new proposal, which I hope will address most of your concerns, but
for the few limitations that will be put in place, just adding a
prompt will not be a suitable alternative.

Gavin

Madhava Enros

unread,
Apr 19, 2013, 3:14:00 PM4/19/13
to sabre...@yahoo.co.uk, firef...@mozilla.org
So, as it turns out: 
Could I propose that rather than lock items such as Back/Forward/Awesome Bar/Reload in place. You simply lock them so they're unremovable from the navigation bar. You retain the logic whereby users can separate/have them interrupted (in terms of order/placement) and but for the menu button, users can truly customise the Navigation bar while users that need saving from themselves are prevented from being able to remove key features from the primary UI.

This is actually the conclusion that we reached talking through this yesterday in an Australis design/engineering check-in meeting. Again - the goal was not to lock anything in place so much as to keep people from removing the one really vital bit of navbar UI by accident.

Madhava

-- 
Madhava Enros
Firefox User Experience

Timothy Warren

unread,
Apr 19, 2013, 3:30:23 PM4/19/13
to firef...@mozilla.org, Gavin Sharp


On Fri, Apr 19, 2013 at 3:11 PM, Gavin Sharp <ga...@gavinsharp.com> wrote:
Mike will be posting an updated proposal soon, so we should use that
as a basis for further discussion. But I wanted to address one point
that came up in both your post and Mitchell's:

"why not just add some alerts/notifications to allow undoing 'bad'
customizations?"

Allowing users to shoot themselves in the foot and then prompting them
to undo it is really not a great experience - no one likes being
prompted/notified when they're otherwise just trying to get something
done. We're not going to be removing as many customization points in
the new proposal, which I hope will address most of your concerns, but
for the few limitations that will be put in place, just adding a
prompt will not be a suitable alternative.

Is there a way to do the opposite, a notification that they WILL do something before it happens?

Gavin Sharp

unread,
Apr 19, 2013, 3:51:31 PM4/19/13
to Timothy Warren, firef...@mozilla.org
My primary point was that notifications in general are not the right way to approach this problem.

Gavin

Shane Caraveo

unread,
Apr 19, 2013, 4:23:00 PM4/19/13
to dgrn...@gmx.com, firef...@mozilla.org
On 13-04-18 12:07 PM, dgrn...@gmx.com wrote:
> In the current proposal the Social, WebRTC, Panel Menu and Page
> Control buttons and URLbar may not be moved at all. Nothing may be
> placed before the URLbar or the Tabs. These restrictions show a
> disappointing lack of faith in the new Customization Mode.

Speaking for social, the button being non-re/movable has nothing to do
with the customization mode or any lack of faith in it.

Shane

Jared Wein

unread,
Apr 19, 2013, 5:02:22 PM4/19/13
to Shane Caraveo, dgrn...@gmx.com, firef...@mozilla.org
----- Original Message -----
> From: "Shane Caraveo" <scar...@mozilla.com>
> To: dgrn...@gmx.com
> Cc: firef...@mozilla.org
> Sent: Friday, April 19, 2013 4:23:00 PM
> Subject: Re: Australis Customization
>
> On 13-04-18 12:07 PM, dgrn...@gmx.com wrote:
> > In the current proposal the Social, WebRTC, Panel Menu and Page
> > Control buttons and URLbar may not be moved at all. Nothing may be
> > placed before the URLbar or the Tabs. These restrictions show a
> > disappointing lack of faith in the new Customization Mode.
>
> Speaking for social, the button being non-re/movable has nothing to
> do
> with the customization mode or any lack of faith in it.

Right, we just need to operate under the assumption that bug 804235 won't be fixed before we finish Australis.

~Jared

Mitchell Ferguson

unread,
Apr 19, 2013, 8:42:40 PM4/19/13
to firef...@mozilla.org, Gavin Sharp
>Allowing users to shoot themselves in the foot and then prompting them
to undo it is really not a great experience - no one likes being
prompted/notified when they're otherwise just trying to get something
done. We're not going to be removing as many customization points in
the new proposal, which I hope will address most of your concerns, but
for the few limitations that will be put in place, just adding a
prompt will not be a suitable alternative.

I vehemently disagree. Under my proposal, the only time anyone is annoyed is the first time a power users wants to move some buttons around. If an average user
accidentally moves something essential, they are *saved* from shooting themselves in the foot! Under your proposal, normal users are again, not annoyed - assuming they don't want to move anything around. Power users are now seething because they have to head off to AMO to download addons to remove lost functionality.

It may not be 'elegant', but my solution solves the problem, provides minimum irritant (and only to power users), and most importantly does not sacrifice any functionality in the process.


On Fri, 19 Apr 2013 at 12:11 AM, <ga...@gavinsharp.com> wrote:
>"why not just add some alerts/notifications to allow undoing 'bad'
>customizations?"
>
>Allowing users to shoot themselves in the foot and then prompting them
>to undo it is really not a great experience - no one likes being
>prompted/notified when they're otherwise just trying to get something
>done. We're not going to be removing as many customization points in
>the new proposal, which I hope will address most of your concerns, but
>for the few limitations that will be put in place, just adding a
>prompt will not be a suitable alternative.
>

Gavin Sharp

unread,
Apr 19, 2013, 10:26:11 PM4/19/13
to Mitchell Ferguson, Firefox Dev
Mike hasn't yet posted about the latest proposal, but when he does we
can discuss any specific concerns. Prompting the user is not an
acceptable solution for the problem of it being too easy to make "bad"
customizations.

Gavin

Robert 'Bobby' Zenz

unread,
Apr 19, 2013, 4:54:58 PM4/19/13
to firef...@mozilla.org
Hello Mike.

Thanks for opening this discussion, I'll try hard to be as constructive
as positive, so if I strafe from that, please smack me back in shape or
something. ;)
And sorry if I'm asking questions you've already answered elsewhere,
I've read through the thread and did not find answers to this.

First of all, I'd like to show you how the top of my Firefox looks
like, so that you understand why I reply: http://i.imgur.com/B6GUApz.png

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

Does that mean that you can only drag and change icons within certain
areas of the toolbar?

> 2. We want to remove (or deprecate) the add-ons bar

I have to thank you for that! No seriously, in some version you guys
removed the addon bar from the default...and despite my first instinct
that something changed, I *love* my additional screen estate now.

> 3. We want to have an in-content customization palette to replace the
> old window palette

So we'll be able to drag'n drop stuff like it was possible in the
Gnome2/Mate panels? That's awesome.

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

If you're introducing a menu button, does that mean that the menubar
will be removed (or not visible by default)? And if the menubar is
visible, can I remove that button then?

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

Given my layout, that's not great news for me. I moved everything into
the menubar because I want to save screen real estate and *still* have
the menubar readily available.
You already said elsewhere that making that configurable (fixed/not
fixed) is an additional maintenance cost which you're not sure if you
want it or not. Of course I'd opt for it so that I still have a fully
customizable menubar and toolbar.

As I said before on Reddit, I think one of the biggest problems people
have with these changes is that all they see is how Firefox starts to
look and work like Chrome. I don't want to mitigate the work you're
doing, but from the outside it seems like you're trying to copy Chrome,
and the screenshots which are circulating from Australis seem to
support that fear.
We're all very happy and very glad that you people are driving the
browser market and deliver a better browser with every version. But
these changes seem to be driven by two ideas:
1. To pursue that mystical "average user".
2. To copy something successful, Chrome.
Of course both are not going down well in the community. If the people
would like to use a Chrome like browser, they'd use Chrome...but we're
using Firefox because of the benefits.
And for the first, I can only speak for myself, the last few times
developers set off to chase that mystical average user, I ended up with
hours and days of work to replace those applications. Seriously, there
is no replacement for Firefox...not even close!

May I suggest something, which will result in more work, though:
Provide us with an option to unlock all locked items on the toolbar. I
think that was stated before, but it would end all discussion around
those changes. The benefit is that the "average user" can not break the
experience, but everyone else can switch the flip and happily customize
the toolbars and menubar to whatever they want.

> Sorry for the long post,

Thanks for taking your time to write it and to read this.

Bobby

Daniel Cardin

unread,
Apr 19, 2013, 11:37:13 PM4/19/13
to firef...@mozilla.org
However, the front-end code ends up getting pretty nasty to support the infinite variations of these buttons that we currently allow. 
I propose that if we want to keep supporting users who frequently migrate between browsers, that we add a checkbox to the customization area that allows the refresh/stop to be moved from the end of the location bar to between the back/forward and location box. For example, here are how other browsers have their "navigation controls" arranged:
 
I think that an obvious, if not necessarily ideal situation, if supporting the dynamic nature of what you have now, would be to just have 4 location bars available to be placed. one with nothing, one with stop/reload, one with back, and one with both attached. You could, I suppose also have it simply replace (in the current spot) the one you already have down when you drag it in.

Gavin Sharp

unread,
Apr 19, 2013, 11:44:19 PM4/19/13
to Daniel Cardin, Firefox Dev
It's not only the mechanism by which the toolbar is customized that
makes supporting the different variations complicated - there's also
actually supporting the different combinations. Your suggestion
doesn't really address that aspect, and results in somewhat confusing
UI, so I don't think it's a feasible solution.

Gavin

Mike Conley

unread,
Apr 21, 2013, 4:13:32 PM4/21/13
to firef...@mozilla.org
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:
> http://people.mozilla.com/~zfang/Customization/AustralisCustomization_Q4Spec.pdf

Mike Conley

unread,
Apr 21, 2013, 5:27:59 PM4/21/13
to Mitchell Ferguson, firef...@mozilla.org
>> Looking good! I'm glad to see you have truly taken most of our concerns
>> on board.

Yep, we hear you - glad we can collaborate on this.

> There have been a number
>> of addons which force place a button somewhere on the UI - this button
>> is not movable using the standard customize UI. Is it possible you could
>> disable this behaviour?

I doubt we could disable it - add-ons really do have a ton of power, and
we're not about to curtail that. What is probably a better approach is
to give add-on authors a *better and easier alternative* to add toolbar
items. We're hoping to expose an API to them to make this possible,
without having to fiddle about splicing strings into currentset /
defaultset attributes and injecting toolbaritems manually.

> Also, is it possible for addons to place
>> non-buttons (like, a button plus some text, like ghostery's display) in
>> a toolbar, and have it customizable?

Our aim is to have this still be possible, yes - via the API mentioned
in my last paragraph.

> This proposal
>> still treads on some toes, but it's drastically better.

Glad to hear it - yes, I think we're converging towards a final plan.

>> Small icons mode is not mentioned, does this mean it's back in? (Please
>> say yes!)

Gah, I knew I forgot to add something. We still want to sunset Small
Icons mode from the main product. Support for that could / should be
supplied by an add-on instead.

-Mike

On 2013-04-21 5:11 PM, Mitchell Ferguson wrote:
> Hi Mike,
>
> Looking good! I'm glad to see you have truly taken most of our concerns
> on board.
>
> I'm still worried about the addon bar, though. There have been a number
> of addons which force place a button somewhere on the UI - this button
> is not movable using the standard customize UI. Is it possible you could
> disable this behaviour? Also, is it possible for addons to place
> non-buttons (like, a button plus some text, like ghostery's display) in
> a toolbar, and have it customizable? I would assume addon authors place
> forced widgets because they can't make them customizable. Can any
> changes be made to disallow forced buttons, or allow non-buttons to be
> made by addons and customized?
>
> I still prefer my way - easy reversal button on warning popup when
> making 'user-unfriendly' customizations, as described elsewhere on this
> mailing list - because it doesn't tread on anyone's toes. This proposal
> still treads on some toes, but it's drastically better. I have a heavily
> customized browser that I love dearly - http://i.imgur.com/QRTbDyc.jpg -
> and this proposal only requires me to get an addon to replace my addons
> bar. I hope.
>
> Small icons mode is not mentioned, does this mean it's back in? (Please
> say yes!)
>
>
>
> On Mon, Apr 22, 2013 at 8:13 AM, Mike Conley <mco...@mozilla.com
> <mailto:mco...@mozilla.com>> wrote:
>
> 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
> <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
> <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.
>
> ------------------------------__------------------------------__------------
> https://bugzilla.mozilla.org/__show_bug.cgi?id=860814#c3
> <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/
> <http://people.mozilla.org/~jwein/ux-nightly/>
> 2: a UI prototype to illustrate:
> https://people.mozilla.com/~__bwinton/australis/__customization/mac/

The Wanderer

unread,
Apr 21, 2013, 7:21:20 PM4/21/13
to firef...@mozilla.org
On 04/21/2013 04:13 PM, Mike Conley wrote:

> 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'm afraid I may not have managed to be as constructive, but I hope at least I'm
not being disruptive - and at the very least, my questions are sincere.

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

At least on the surface, all of this sounds good.

I apologize if I'm asking stupid questions or rehashing existing discussion,
below; although I've read the previous parts of the thread in the archive, and
am reading through the Bugzilla entry and some discussions liked from there, I'm
still not sure I have the full context and nuance of the existing discussion -
or that I've managed to entirely avoid rehashing what's already been gone over.


I will say, however, that at an uninformed glance at least three of the proposed
changes look more like *removing* customizability than improving it.

Even if that does change on becoming less uninformed - at least one of the three
seems more reasonable now that I've read through the preceding discussion than
it did at first glance - that apparent mismatch between the stated
customizability goals ("improving how users can customize Firefox") and the
proposals being made for actual implementation seems likely to be a bad thing in
terms of avoiding user backlash.

It might be worth the trouble to explain, with each proposed change, why it is
*not* a move towards worse instead of better customizability. (If it *is* a
move towards worse customizability, it might be worth reconsidering whether to
make it at all, at least under an improved-customizability banner.)

Some attempt at that may have already been made, in the inclusion of a comment
about the ability to restore the removed functionality with an add-on. That may
not be enough by itself, however; it may come across as simply a way of saying
"if you don't like this, you can put in the effort to undo it yourself", not
"this will actually (ultimately) help you customize things more easily".

> # List of proposed changes
>
> * Join the Stop and Reload buttons into a single button for customizing, like
> the back / forward buttons.

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

This would be unlikely to bother me personally, but I believe I've run across
comments from quite a number of people who would strongly object to it. The main
objection they've raised, that I remember, is the potential to accidentally
click on "Reload" because the load process stops right when they were trying to
click on "Stop" - producing an effect exactly opposite what they were asking
for.

Would such an add-on as you mention be written "in advance" and provided as
available alongside the release of the first non-development version containing
this change?

Would there be a commitment to guarantee that the add-on would be maintained
across incompatible changes? (If not by Mozilla manpower directly, then by
opening official maintenance of the add-on up to the public, in such a way that
if existing maintainers stop working on it the fix-it-up contributions of others
can be folded in to new releases of the add-on on AMO - and I mean the same
add-on, not forks thereof.)


A more general comment in relation to the two preceding questions, to provide
context for why I ask them:

With each of these proposed changes which attempts to remove or limit a feature,
you've attempted to reassure people that the feature won't go away entirely
because it can still be restored with an add-on. This is an argument I've seen
frequently in regard to Firefox feature removals, and it generally - including
now - comes with one important flaw which I don't think I've ever seen commented
on.

IMO this line of argument would be acceptable if presented as "We're not
removing it, we're just splitting it out into an add-on instead of shipping it
with the core browser" - in other words, if the necessary add-on to restore the
removed feature were being created and published in parallel to the removal of
the feature, and if a commitment were being made to maintain the functionality
of that add-on across core-browser compatibility changes.

However, the vast majority of the time no attempt seems to be being made to
create such an add-on or make such a commitment, and indeed the goal of the
removal sometimes (often?) seems to be to remove the need to maintain the
feature. The only exception to this rule which I remember off the top of my head
is the creation of Status-4-Evar in parallel with the removal of the status bar,
and even in that case I'm not sure the replacing add-on wasn't created by a
motivated third party who disliked the change rather than by Mozilla
contributors as part of the change.

There can be many reasons for a potentially desirable feature to not be a good
fit for the mainline browser product, and although I seem from past experience
to disagree with many developers about where the line should be drawn, I can
recognize and (potentially) accept the decision in many cases.

However, there is a vast difference between "We want this feature / think this
feature is okay, but we don't think it belongs in core Firefox" and "We don't
want to have to bother with this feature, even if people want it". In too many
cases, the combination of the argument "this feature can be restored with an
add-on" with the lack of any move towards creating such an add-on seems to imply
that the latter is what that argument really means.

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

Sounds reasonable; I can think of a few contexts where removing one or more of
these might be desirable, but they seem likely to be rare enough that requiring
use of an add-on would not be unreasonable.

I might still prefer to allow removing these buttons from the nav bar, but
presenting a "Warning!!"-type alert in response to the removal attempt and
asking for confirmation. I can see where that might not be enough to prevent
problems for the stereotypical "click OK on any dialog without reading it" user,
however.

Again, would such an add-on be written "in advance", and a promise to maintain
it be made? It seems less necessary in this case, but the principle remains.

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

Again, though I doubt this would bother me personally, I suspect others would
object - and I can think of a few contexts where it might make working with
Firefox harder even for me, if only because automatically deploying an add-on
with Firefox in a seamless fashion seems (from my past research) considerably
harder than just modifying built-in Firefox configuration settings.

Again, would such an add-on be written "in advance", and a promise to maintain
it be made?

> * Toolbars that are collapsed will not be visible while customizing

I can see no reason to object to this at all. (And given how good I am at
finding things to point out as problems, that's saying something.)

> * Remove the add-on bar from the core product

What would this mean, in practice? That is: what, in the definition being used
here, does the term "add-on bar" mean?

The two definitions which spring to my mind offhand are "the customization area
where add-on icons are placed by default" and "a customization area which is
located at the bottom of the browser window".

While I would have no objection to removing the former, i.e. placing add-on
icons in another area when neither the user nor the add-on has explicitly
specified a location, I would greatly dislike removing the latter. I actively
prefer some of my add-on icons and buttons to be located at the bottom of the
browser window, in specific locations (and to be small, as the height of the
add-on bar appears to enforce); I also use Status-4-Evar, which AFAIK presently
relies on the bottom-of-window customization area provided by the add-on bar.

Also, with this removed, what would happen to the area reserved for the icons
provided by add-ons which still use the old "place an icon on the status bar"
API, which presently appears on the add-on bar and is displayed (when in
customize mode) with "zebra stripes"? Will support for that API be dropped,
producing a compatibility break with such add-ons? If not, where will icons
created by way of it appear?

> 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

Just as a note, another term for such clustering in some cases is "cluttering".

It also seems worth mentioning that dropping all of these icons into the
top-of-browser toolbar(s) seems to run counter to the desire, which I believe is
one of the goals of Australis, to reduce nav-bar and similar toolbar clutter.

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

And, again, would such an add-on be written "in advance" and a promise to
maintain it be made? This is one feature I actually use and indeed (indirectly)
rely on, in Firefox versions recent enough to have removed the status bar.

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

What is meant here by "primary UI"? The term seems to imply that there are
multiple (levels of / forms of) UI for this, and that only the "primary", most
readily user-accessible set will be removed.

If creating and modifying such toolbars via a more hidden and less accessible -
but still built-in - UI will still remain, I don't think there would be much to
object to in removing the most user-facing form of the UI. I'm not even sure a
commitment to the creation and maintenance of the referenced add-on would be
needed.

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

By failing to mention it, this seems to imply that the point above about
removing the "add-on bar" is indeed intending to remove the customization area
at the bottom of the browser window.

What would be the problems with including such an area, at least as an
off-by-default option (whether with visible UI or with only an about:config
entry), but not using it as the default location for new add-on icons/buttons?

--
The Wanderer

Warning: Simply because I argue an issue does not mean I agree with any
side of it.

Every time you let somebody set a limit they start moving it.
- LiveJournal user antonia_tiger

Justin Dolske

unread,
Apr 21, 2013, 11:50:25 PM4/21/13
to firef...@mozilla.org
On 4/21/13 4:21 PM, The Wanderer wrote:

> I will say, however, that at an uninformed glance at least three of
> the proposed changes look more like *removing* customizability than
> improving it.

Any change to how something works out-of-the-box may appear to limit
some particular use-case. But that's not really a useful metric, since
we're trying to make customizability more accessible/useful to a broader
set of users.

And, as noted, add-ons will be able to replicate most (all?) of the
previous behavior that's changing.


> It might be worth the trouble to explain, with each proposed change,
> why it is *not* a move towards worse instead of better
> customizability.

That's pretty perjorative phrasing, so that's a non-goal.

I think Mike's "v2 proposal" is on a fine track here. Wouldn't hurt to
expand on the reasoning (to address discussion here) as we reach a final
proposal, though.


> Would such an add-on as you mention be written "in advance" and
> provided as available alongside the release of the first
> non-development version containing this change?

I think it's unlikely Mozilla will be writing this add-on (or add-ons to
revert any of the other changes). If there's a large swath of the
community interested in wanting to revert to the previous UX, there
shouldn't be any shortage of people wanting to write and maintain it.

I'd point to a couple other messages on firefox-dev, regarding tab
groups and search-by-image... Both of these threads have mentioned
add-ons implementing the things being discussed.


> With each of these proposed changes which attempts to remove or
> limit a feature, you've attempted to reassure people that the feature
> won't go away entirely because it can still be restored with an
> add-on. This is an argument I've seen frequently in regard to Firefox
> feature removals, and it generally - including now - comes with one
> important flaw which I don't think I've ever seen commented on.
>
> IMO this line of argument would be acceptable if presented as "We're
> not removing it, we're just splitting it out into an add-on instead
> of shipping it with the core browser"

The point is that Firefox is _extremely_ customizable, and so features
which we believe are not interesting or relevant to the bulk of our
users can still be provided by way of add-ons. (As opposed to most other
software, where once the developers change some bit of functionality,
you basically have no choice but to live with it.)

"Splitting stuff into an add-on" isn't, as a general rule, what we do.

> I might still prefer to allow removing these buttons from the nav
> bar, but presenting a "Warning!!"-type alert in response to the
> removal attempt and asking for confirmation.

As noted elsewhere in this thread, notifications and warnings are poor
UI that we strive to avoid.


>> * Remove primary UI for adding custom toolbars
>
> What is meant here by "primary UI"? The term seems to imply that
> there are multiple (levels of / forms of) UI for this, and that only
> the "primary", most readily user-accessible set will be removed.

"Primary UI" broadly refers to the main or most-exposed way to doing
something. EG, the back-button is primary UI, using the History --> Back
menu would be secondary UI.

But I think you're right here. It's already not exactly primary UI
(being hidden in a customize dialog), nor do I know of other UI to do
this. So this is probably best stated simply as "Remove UI for adding
custom toolbars".

Justin

Mitchell Ferguson

unread,
Apr 21, 2013, 5:11:51 PM4/21/13
to Mike Conley, firef...@mozilla.org
Hi Mike,

Looking good! I'm glad to see you have truly taken most of our concerns on board.

I'm still worried about the addon bar, though. There have been a number of addons which force place a button somewhere on the UI - this button is not movable using the standard customize UI. Is it possible you could disable this behaviour? Also, is it possible for addons to place non-buttons (like, a button plus some text, like ghostery's display) in a toolbar, and have it customizable? I would assume addon authors place forced widgets because they can't make them customizable. Can any changes be made to disallow forced buttons, or allow non-buttons to be made by addons and customized?

I still prefer my way - easy reversal button on warning popup when making 'user-unfriendly' customizations, as described elsewhere on this mailing list - because it doesn't tread on anyone's toes. This proposal still treads on some toes, but it's drastically better. I have a heavily customized browser that I love dearly - http://i.imgur.com/QRTbDyc.jpg - and this proposal only requires me to get an addon to replace my addons bar. I hope.

Small icons mode is not mentioned, does this mean it's back in? (Please say yes!)

Wadhah

unread,
Apr 19, 2013, 10:43:13 PM4/19/13
to Robert 'Bobby' Zenz, firef...@mozilla.org
Isn't the be aware screen at about:config a notification ?
Why there and not for customizing the interface ?
That dose not make any sense, for anyone to know what about:config is he/she is either a power user or a normal user following a tutorial, no one will just randomly come up with the adress and start changing stuff. yet there is a warning there.
As for the interface I could very well see someone right clicking and messing everything up with one click.

Daniel Cardin

unread,
Apr 19, 2013, 11:59:49 PM4/19/13
to Gavin Sharp, Firefox Dev
I didn't expect that it would be a great solution, just that it might result in simpler code. And unless you lock it into only having them all together you'd have the problem of supporting the individual configurations, without addressing the concerns of people who want to have parity with other browsers. Slash you support them already.

I can even think another solution that would be somewhat preferable (given 2 seconds to think after seeing the first example wouldnt work): if the location bar didnt show any extras in the customization method, and as long as there is a reload or stop button placed on the toolbar, you dont combine that. As long as there is a back button placed on the toolbar you dont combine that. When they aren't they will combine.

As long as you start with that by default, I would think it would be fine. Albeit, it is still a somewhat user-confusing solution if they notice the discrepancy and try to put it on, then lose the combining, though it wouldn't result in a loss of functionality, at least. While I find that situation a little unlikely, the combined elements could be drawn at 50% transparency (when customizing) and disappear when a real button is placed on (which makes consistent at least).

Even if that isn't a good solution for your proposed problems, it would be a good improvement over the existing way of automagically combining elements when in specific places.

On Fri, Apr 19, 2013 at 11:44 PM, Gavin Sharp <ga...@gavinsharp.com> wrote:
It's not only the mechanism by which the toolbar is customized that
makes supporting the different variations complicated - there's also
actually supporting the different combinations. Your suggestion
doesn't really address that aspect, and results in somewhat confusing
UI, so I don't think it's a feasible solution.

Gavin

On Fri, Apr 19, 2013 at 8:37 PM, Daniel Cardin <thadan...@gmail.com> wrote:
>
>> However, the front-end code ends up getting pretty nasty to support the
>> infinite variations of these buttons that we currently allow.
>>
>>
>> I propose that if we want to keep supporting users who frequently migrate
>> between browsers, that we add a checkbox to the customization area that
>> allows the refresh/stop to be moved from the end of the location bar to
>> between the back/forward and location box. For example, here are how other
>> browsers have their "navigation controls" arranged:
>
>
> I think that an obvious, if not necessarily ideal situation, if supporting
> the dynamic nature of what you have now, would be to just have 4 location
> bars available to be placed. one with nothing, one with stop/reload, one
> with back, and one with both attached. You could, I suppose also have it
> simply replace (in the current spot) the one you already have down when you
> drag it in.
>
>

Justin Dolske

unread,
Apr 22, 2013, 12:24:04 AM4/22/13
to firef...@mozilla.org
On 4/19/13 8:59 PM, Daniel Cardin wrote:
> I didn't expect that it would be a great solution, just that it might
> result in simpler code. [...]
> I can even think another solution that would be somewhat preferable
> (given 2 seconds to think after seeing the first example wouldnt work):
> [...]
>
> On Fri, Apr 19, 2013 at 11:44 PM, Gavin Sharp <ga...@gavinsharp.com
> <mailto:ga...@gavinsharp.com>> wrote:
>
> It's not only the mechanism by which the toolbar is customized that
> makes supporting the different variations complicated - there's also
> actually supporting the different combinations. Your suggestion
> doesn't really address that aspect, and results in somewhat confusing
> UI, so I don't think it's a feasible solution.

I don't really understand your suggestion. But it still doesn't seem to
address implementation complications. If anything, it's sounding more
complicated and confusing.

Justin

Dão Gottwald

unread,
Apr 22, 2013, 4:55:09 AM4/22/13
to firef...@mozilla.org
On 19.04.2013 18:54, Jared Wein wrote:
> I propose that if we want to keep supporting users who frequently migrate between browsers, that we add a checkbox to the customization area that allows the refresh/stop to be moved from the end of the location bar to between the back/forward and location box. For example, here are how other browsers have their "navigation controls" arranged:
>
> IE10: Back/forward/location box/reload+stop
> Chrome: Back/forward/reload+stop/location box
> Firefox: Back/forward/location box/reload+stop
> Safari: Back/forward/iCloud/share/location box/reload+stop
>
> This would help the users who frequently migrate between the browsers, and also help to clean up some of the crazy code that we have in the front-end.

What code in particular would it clean up, given that you'd still
support two back/forward/stop/reload button styles depending on their
context? Allowing these buttons to be moved arbitrarily in the toolbar
doesn't sound any more complicated from a theme's perspective.

Axel Hecht

unread,
Apr 22, 2013, 7:42:37 AM4/22/13
to firef...@mozilla.org
On 4/21/13 10:13 PM, Mike Conley wrote:
> * 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.

This is probably more of a wish to get full fullscreen back than being
able to hide the navigation toolbar.

On our hacking meetup last weekend, I yet again saw people hiding their
navigation bar to get to a fuller fullscreen on mac.

Axel

Jared Wein

unread,
Apr 22, 2013, 12:19:22 PM4/22/13
to Dão Gottwald, firef...@mozilla.org
----- Original Message -----
> From: "Dão Gottwald" <d...@design-noir.de>
> To: firef...@mozilla.org
> Sent: Monday, April 22, 2013 4:55:09 AM
> Subject: Re: Australis Customization
>
> On 19.04.2013 18:54, Jared Wein wrote:
> > I propose that if we want to keep supporting users who frequently
> > migrate between browsers, that we add a checkbox to the
> > customization area that allows the refresh/stop to be moved from
> > the end of the location bar to between the back/forward and
> > location box. For example, here are how other browsers have their
> > "navigation controls" arranged:
> >
> > IE10: Back/forward/location box/reload+stop
> > Chrome: Back/forward/reload+stop/location box
> > Firefox: Back/forward/location box/reload+stop
> > Safari: Back/forward/iCloud/share/location box/reload+stop
> >
> > This would help the users who frequently migrate between the
> > browsers, and also help to clean up some of the crazy code that we
> > have in the front-end.
>
> What code in particular would it clean up, given that you'd still
> support two back/forward/stop/reload button styles depending on their
> context? Allowing these buttons to be moved arbitrarily in the
> toolbar
> doesn't sound any more complicated from a theme's perspective.

Yeah, I still wish we could simplify the conditional-forward button code. This proposal does simplify our combined stop-reload code though, which was described in Mike's v2 write-up.

- Jared

Robert 'Bobby' Zenz

unread,
Apr 22, 2013, 1:14:29 PM4/22/13
to firef...@mozilla.org
On Sun, 21 Apr 2013 16:13:32 -0400
Mike Conley <mco...@mozilla.com> wrote:

Hello again.

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

I did not know that. If I would have I wouldn't have complained that
loudly. ;)

I guess to suggest to simply keep the already used icons in the
customization window with an icon indicating that those are on a
toolbar (and dragging them from the customization window moves them to
the new position) isn't an option anymore?

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

As asked before, are those addons going to be provided by Mozilla? Or
does the community need to the create and maintain them?

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

As The Wanderer pointed out, there are cases which prefer separate
buttons. Wanting to stop the loading and then hitting reload is
frustrating, this can even easier happen on a touchscreen device were
the button can be hidden by the finger before pressing it (or am I the
only one who's fingers cover UI elements completely?).

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

That's...not a solution in my opinion, that's working around the core
functionality, circumventing the Firefox UI completely and removing
that newly created feature.

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

I have those buttons in my menubar and my navigation bar hidden, so I
might be biased about that.

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

I have to be honest here, I completely ignored that functionality since
ever...

Best Regards,
Bobby

Jared Wein

unread,
Apr 22, 2013, 1:36:00 PM4/22/13
to Robert 'Bobby' Zenz, firef...@mozilla.org
----- Original Message -----
> From: "Robert 'Bobby' Zenz" <Rober...@bonsaimind.org>
>
> > * Join the Stop and Reload buttons into a single button for
> > customizing, like the back / forward buttons.
>
> As The Wanderer pointed out, there are cases which prefer separate
> buttons. Wanting to stop the loading and then hitting reload is
> frustrating, this can even easier happen on a touchscreen device were
> the button can be hidden by the finger before pressing it (or am I
> the
> only one who's fingers cover UI elements completely?).

This sounds like a bug that should be filed. We have a delay between when it switches from reload->stop. Perhaps we need to investigate how many times people hit stop->reload? Either way, if people feel that they need to change their UI because it is too easy to make a mistake, they should file a bug so we can investigate it further and potentially get a fix out for all users of the product.

It also sounds like a bug could be filed about the UI of the browser when on a touch screen.

Thanks,
Jared

The Wanderer

unread,
Apr 22, 2013, 8:44:01 AM4/22/13
to firef...@mozilla.org
On 04/21/2013 11:50 PM, Justin Dolske wrote:

> On 4/21/13 4:21 PM, The Wanderer wrote:
>
>> I will say, however, that at an uninformed glance at least three of
>> the proposed changes look more like *removing* customizability
>> than improving it.
>
> Any change to how something works out-of-the-box may appear to limit
> some particular use-case. But that's not really a useful metric,
> since we're trying to make customizability more accessible/useful to
> a broader set of users.

True enough. My point was more in terms of how this proposed change may
appear to the user base; articles such as

http://www.ghacks.net/2013/04/18/firefoxs-australis-theme-may-have-disastrous-consquences-for-users-who-customize-the-browser/

, which admittedly seems to be based on the previous version of the
proposal AFAICT, seem to have received the impression that this change
will reduce customizability to a considerable degree.

There will be some degree of user backlash against any feature removal,
and probably against any UI change. (I may even be part of it in many
cases.) That much is probably unavoidable. User backlash against a
perception of an effect which runs counter to Mozilla's stated goals,
however, seems like it *should* be avoidable - and concern about
avoiding the backlash which can result from even the appearance of such
a mismatch seems like a worthwhile, and potentially even important,
goal.

> And, as noted, add-ons will be able to replicate most (all?) of the
> previous behavior that's changing.

I do understand that.

>> It might be worth the trouble to explain, with each proposed
>> change, why it is *not* a move towards worse instead of better
>> customizability.
>
> That's pretty perjorative phrasing, so that's a non-goal.

I apologize; I made a fairly extensive attempt to avoid that sort of
thing in composing my previous response.

I think the reason I used that phrase was that "a move towards worse
compatibility" is the way the sort of user whose impression I was
concerned with (the one who has a negative reaction based on a mistaken
interpretation) is likely to see this.

To attempt to rephrase: When a specific proposed change may appear to
work against a stated overall goal, presenting an attempt to explain why
that appearance is false - why and/or how the proposed change actually
supports that goal - might serve well to help reduce the likelihood of,
or otherwise mitigate, such a negative reaction.

> I think Mike's "v2 proposal" is on a fine track here. Wouldn't hurt
> to expand on the reasoning (to address discussion here) as we reach a
> final proposal, though.

I agree overall that the revised proposal is, as you put it, on a fine
track. It certainly appears far better than the previous version.

>> Would such an add-on as you mention be written "in advance" and
>> provided as available alongside the release of the first
>> non-development version containing this change?
>
> I think it's unlikely Mozilla will be writing this add-on (or add-ons
> to revert any of the other changes). If there's a large swath of the
> community interested in wanting to revert to the previous UX, there
> shouldn't be any shortage of people wanting to write and maintain
> it.

While this is true, this question is more about the philosophy behind
feature removal, and the mindset behind the suggestion of restoring a
feature via an add-on.

I had a paragraph in relation to that in one draft of my previous
response, but I dropped it since it didn't really seem to fit anywhere.

I'd also have considerably less problem with leaving maintenance of the
add-on (once written) up to the community. I just don't think it's
appropriate to dump the task of writing an add-on to replace a feature
being removed on the community, especially not when promising at removal
time that the feature can be replaced by an add-on.

> I'd point to a couple other messages on firefox-dev, regarding tab
> groups and search-by-image... Both of these threads have mentioned
> add-ons implementing the things being discussed.

In the case of tab groups, I believe implementing an add-on to replace
it is an explicit goal (and stated prerequisite) of removing it; see bug
836758.

>> With each of these proposed changes which attempts to remove or
>> limit a feature, you've attempted to reassure people that the
>> feature won't go away entirely because it can still be restored
>> with an add-on. This is an argument I've seen frequently in regard
>> to Firefox feature removals, and it generally - including now -
>> comes with one important flaw which I don't think I've ever seen
>> commented on.
>>
>> IMO this line of argument would be acceptable if presented as
>> "We're not removing it, we're just splitting it out into an add-on
>> instead of shipping it with the core browser"
>
> The point is that Firefox is _extremely_ customizable, and so
> features which we believe are not interesting or relevant to the bulk
> of our users can still be provided by way of add-ons. (As opposed to
> most other software, where once the developers change some bit of
> functionality, you basically have no choice but to live with it.)

True enough. But this doesn't mean that those add-ons must be, or even
should be, created (only) by third parties; they can, and IMO in
feature-removal cases probably should, be created by Firefox developers.

It may also be relevant that users do have an option other than putting
in the (potentially considerable) effort to create an add-on or living
with the changes: they can simply stay with the old version, which is a
bad result all around, and many of them do. I've done exactly that in
the past, and am indeed *still* on old Firefox versions on at least a
few of my computers (including the primary one, where I'm writing this).

> "Splitting stuff into an add-on" isn't, as a general rule, what we
> do.

And the argument I'm presenting is approximately that if you're going to
be presenting "the feature can be restored by an add-on" as an argument
when removing a feature, then it *should* be what you do. This applies
especially to features which have ever been enabled by default, which
some of those involved here arguably have been.

One of the reasons for that "should" is a matter of what I think would
be called development philosophy. The other is, again, about negative
user interpretation.

(This is drifting somewhat offtopic for the thread...)

The comment "the feature can be restored by an add-on" is plainly an
attempt to reassure the parts of user base which may like the removed
feature; however, if/when no such add-on ever materializes, this
reassurance seems hollow. Repeat the experience of encountering such an
apparently hollow reassurance often enough, and it starts to appear as
if the developers presenting it are being hypocritical.

Note that I'm *not* saying that the developers in question *are*
hypocritical. This is simply a matter of user perception - or, put
another way, a PR issue.

"The feature can be restored by an add-on, but no such add-on exists,
and one may never exist unless you create it yourself" sounds awfully
much, from some users' perspective, like "we don't care, but we'll
pretend we do long enough to get you off our backs". I neither do nor
want to believe that that's true, but the perception remains.

This ties in to the oft-repeated "Mozilla doesn't listen" complaint
(which I acknowledge is not accurate). Mozilla has a perception problem,
with a number of contributing factors; this is just one of them, but
where it does factor in, I think it can be a not insignificant one.

>> I might still prefer to allow removing these buttons from the nav
>> bar, but presenting a "Warning!!"-type alert in response to the
>> removal attempt and asking for confirmation.
>
> As noted elsewhere in this thread, notifications and warnings are
> poor UI that we strive to avoid.

I saw that, yes, and I considered dropping this section from the
response. I left it in both to register my preference as a possible
minor weight on the scale against that decision, and to acknowledge (in
the part that you snipped) at least one reason against it.

I don't agree that notifications and warnings are always poor UI, but I
can see argument against them in many cases, including this one.

>>> * Remove primary UI for adding custom toolbars
>>
>> What is meant here by "primary UI"? The term seems to imply that
>> there are multiple (levels of / forms of) UI for this, and that
>> only the "primary", most readily user-accessible set will be
>> removed.
>
> "Primary UI" broadly refers to the main or most-exposed way to doing
> something. EG, the back-button is primary UI, using the History -->
> Back menu would be secondary UI.

That's about what I expected; thanks for confirming it.

> But I think you're right here. It's already not exactly primary UI
> (being hidden in a customize dialog), nor do I know of other UI to do
> this. So this is probably best stated simply as "Remove UI for
> adding custom toolbars".

And on that level, this could indeed seem like something objectionable.
The only saving grace is that the likelihood of someone wanting this
badly enough to implement a general-purpose "create as many
customization areas as you want wherever and however you want them"
add-on is high enough - and the difficulty of creating such an add-on
likely to be low enough - that it seems nearly certain such an add-on
will indeed be created.

Thanks for the response!

--
The Wanderer

Warning: Simply because I argue an issue does not mean I agree with any
side of it.

Every time you let somebody set a limit they start moving it.
- LiveJournal user antonia_tiger

Florian Bender

unread,
Apr 22, 2013, 5:19:09 PM4/22/13
to firef...@mozilla.org, Justin Dolske, The Wanderer
Is it possible to keep the add-on bar, off by default? Or rather merge the 
custom and add-on bars. I guess it's not really a feature that deserves 
much attention by the developers thus keeping it does not harm the 2nd 
goal of Australis: To remove complexity. Of course, the add-on bar has to 
be disabled and "cleaned" at first install (or remove it and add a "footer" 
bar, as already suggested). 

Additionally, is it possible to have one huge widget that is the address bar 
+ forward/backward button + stop/reload button combined, and also have 
each forward and backward as well as stop and reload buttons separately. 
Then, if a user moves the separate backward and forward buttons and/or 
stop and reload buttons into the nav bar, each respective button is hidden 
from the huge-address-bar-widget (which itself cannot be deleted by 
default). Thus, if you add the forward, backward, stop and reload button, 
the huge-address-bar-widget is rendered as a sole address bar. 
(This has been somewhat proposed before if I understood that correctly.) 
Is that a feasible option? To reduce dev burden, the buttons in the widget 
can inherit their style from the standalone versions (or vice-versa) if that's 
possible. 

Am 22.04.2013 um 05:51 schrieb Justin Dolske:
> I think it's unlikely Mozilla will be writing this add-on (or add-ons to 
> revert any of the other changes). If there's a large swath of the 
> community interested in wanting to revert to the previous UX, there 
> shouldn't be any shortage of people wanting to write and maintain it.

Although I agree with you, I also think that having an add-on with "Mozilla 
Approval" (although there is no such thing) released alongside the release 
of Australis will mitigate a lot of negative feedback! 

Would it be possible to have some kind of mentoring by Mozilla / the 
Australis and add-on SDK team for the developers of such an add-on 
(codename: "Australis on Steroids" ;-) )? 

If the add-on is spec'ed sufficiently, covers (at best) all functionality hidden 
resp. removed by Australis, using GitHub for dev, and having the support of 
the designers of Australis, I think this add-on can be released alongside 
Australis and actually survive for a long time. To ease the last part, I think 
it's crucial to use the add-on SDK, and I even think that most, if not all 
discussed changes can be solved using the add-on SDK (if not, we may 
try to extend the functionality of the SDK in time for Australis!). If it is not 
possible to cover all necessary features via the SDK and it cannot be 
extended sufficiently, there may be two versions of the add-on, one using 
the SDK, and one "legacy" add-on that only includes functionality not in the 
other add-on. 

I'm no add-on developer myself thus I cannot assess the feasibility of my 
proposal. I'm willing to support this add-on on the management side, 
although I will not be missing any features with the current Australis design, 
and I don't have that much spare time in the next 6 months, but I'll do what I 
can (however, I probably won't write any code) … who's in? 

Best Regards,

Florian Bender


quantumedia · Kalchthaler, Müller & Partner Media Services GbR
Münsterplatz 32 · 79098 Freiburg · Tel. 0761 458 99 28-0 · Fax 0761 458 99 28-9
USt-IdNr: DE280390014 · Geschäftsführer: Gregor Kalchthaler, Philipp Müller

Alex Limi

unread,
Apr 22, 2013, 5:27:02 PM4/22/13