Australis Customization

[Mike Conley]

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]

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]

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]

(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]

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

mozilla.org/firefox

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]

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]

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]

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

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]

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

[Nicholas Nethercote]

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]

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

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]

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]

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

> <https://people.mozilla.com/~bwinton/australis/customization/mac/>
> and a
> spec to read:

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

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]

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

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]

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]

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]

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]

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]

Yep, confirming - I'll have a new proposal posted soon.

[Wadhah]

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]

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]

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

mozilla.org/firefox

[Timothy Warren]

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]

My primary point was that notifications in general are not the right way to approach this problem.

Gavin

[Shane Caraveo]

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]

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

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

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]

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]

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]

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]

Hello all,

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

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



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

# Goals

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

As a caveat, this means protecting the user from customizationsthat
break the browsing experience. We get a ton of hits on
https://support.mozilla.org/en-US/kb/navigation-buttons-missing.
Resetting Firefox is a ham-fisted solution, and so we're going to try to
make it harder for these critical bits of UI to disappear


* Make it easier for add-ons to add buttons to toolbars on installation


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

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

# List of proposed changes

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

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

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


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

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

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


* Remove the ability to hide the Navigation Toolbar

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


* Toolbars that are collapsed will not be visible while customizing


* Remove the add-on bar from the core product

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

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


* Remove primary UI for adding custom toolbars

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

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

# Possibly Asked Questions:

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

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


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


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


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


* The entire bookmarks bar if not autohidden



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

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


Feedback?

-Mike

On 2013-04-17 6:29 PM, Mike Conley wrote:
> Hello folks,
>
> So the Australis project is chugging along nicely (if you haven't tried
> the UX branch build[1], you should check it out).
>
> One of the things we've started to work on is improving how users can
> customize Firefox. We want customization to be easy and pleasant to do,
> and hard to get wrong (ie, hard to break the browser).
>
> Customization is a hot-button topic, and it's not surprising that once
> we start fiddling with it, users who customize their browser UI are
> going to get concerned. So I wanted to open up the discussion here so we
> can perhaps discuss those concerns, and ideas for mitigating them.
>
> For those who aren't familiar with the project[2], I'm going to try to
> summarize the high-level changes to customization that we're proposing.
> I should emphasize that while we've started to write these things down,
> nothing is set in stone. It's just a place to start.
>
> Anyhow, so here are our thoughts:
>

> 1. We want to introduce more specific customization targets into
> Firefox's UI. An example of a customization target would be a box
> immediately to the right of the AwesomeBar, or one to the right of the
> tabstrip, or one in our new menu panel. These boxes are places where
> toolbar items can be dragged to and from.
>

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

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

> 4. We're introducing a fixed Menu button at the end of the toolbar which
> opens the "menu panel". The menu panel will contain one or more
> customization targets.
>

> 5. We're considering moving the back, forward, URL bar, refresh and stop
> buttons to the start of the nav-bar, and making them immovable when
> using the customization mode.
>

> We're going to need to migrate incompatible customizations over to this

> new world. Jared and I have started talking about that, and we wrote our
> initial plan down here:

> https://bugzilla.mozilla.org/show_bug.cgi?id=860814#c3 - again, not set
> in stone.
>
>
> So, let's chat. In particular, I'd like to hear from the UX team in case
> I've forgotten something or made a mistake in my outlining of these
> points. But I'd also like to just hear from the firefox-dev community at
> large in case what we're looking at doing is in need of more tweaking.
>

> Sorry for the long post,
>

> -Mike
>
> 1: http://people.mozilla.org/~jwein/ux-nightly/

> 2: a UI prototype to illustrate:

> https://people.mozilla.com/~bwinton/australis/customization/mac/ and a
> spec to read:

> http://people.mozilla.com/~zfang/Customization/AustralisCustomization_Q4Spec.pdf

[Mike Conley]

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

> <https://people.mozilla.com/~bwinton/australis/customization/mac/>
> and a
> spec to read:

> 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

[The Wanderer]

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]

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]

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]

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]

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]

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]

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]

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]

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

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]

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

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]

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]

On Monday, April 22, 2013 at 14:19, Florian Bender wrote:

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.

Yes, this is what we have proposed as the initial design. I haven't had time to get completely caught up on the discussion here yet, but the original design goal was to get rid of the current "magic" behavior like buttons combining when placed in a particular order, etc.

Having standalone stop/reload buttons that you can add as an alternative to the back/URL/stop/reload widget should solve this.

I guess I should catch up with Mike Conley if anything has changed since the original proposal. :)

— Alex Limi · Product Design Strategy, Mozilla · http://twitter.com/limi · http://limi.net

[The Wanderer]

On 04/22/2013 05:19 PM, Florian Bender wrote:

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

I believe I would support this as described.

However, I think it's still important to define exactly what is meant
when referring to "the add-on bar". The current add-on bar is a
(vertically narrow) customization area at the bottom of the browser
window; it is also the customization area where add-on icons and buttons
go by default.

I think these two things (a bottom-located customization area, and a
separate customization area as the default location for add-on icons)
are not fundamentally linked, and I would like clarification on which of
the two it is that the developers are proposing to remove.

It's entirely possible that the answer might be "both", but if so I
would at least like that to be made explicit.

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

Agreed. At the very least, Firefox-developer eyes on the development of
the add-on replacing a particular removed feature would make it easier
to confirm that that add-on does cover all of the functionality of the
feature which is being removed.

(Firefox developers might also have an easier time of implementing the
add-on well, by borrowing code with which they are already familiar from
the previous implementation of the feature in core Firefox, than a
third-party member of the community would. That may not apply - or, if
it does apply, be a good idea - in all cases, though.)

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

While I like most of this suggestion, I want to clarify that I do not
think that all of the functionality being removed should be provided by
a single add-on. Separating out unrelated functions into different
add-ons has advantages from modularity, lack of bloat for people who
want some but not all of the features being the most obvious one.

IMO, as with the Unix philosophy for utilities and tools, a good Firefox
add-on should "do one thing and do it well".

[Mike Conley]

Hey all,

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

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

Anyhow, thanks everybody for the feedback!

-Mike


==== Customization Final Proposal ====

# Goals


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

As a caveat, this means protecting the user from the few customizations

that break the browsing experience. We get a ton of hits on
https://support.mozilla.org/en-US/kb/navigation-buttons-missing.
Resetting Firefox is a ham-fisted solution, and so we're going to try to
make it harder for these critical bits of UI to disappear

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

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

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

# List of proposed changes

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

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

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

* Prevent back, forward, url bar, stop and reload buttons from leaving

the nav-bar, while still allowing them to be re-ordered.

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

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

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

* Remove the ability to hide the Navigation Toolbar

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

* Toolbars that are collapsed will not be visible while customizing


* Remove the add-on bar from the core product

This helps to cluster tools into the top portion of the browser by

default and avoids incurring an entire toolbar when a user only has a
couple of add-ons installed

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

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

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

* Remove UI for adding custom toolbars

From anecdotal user data, this is not a heavily used feature. This

feature could also be restored with an add-on.


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

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

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

Given Firefox's very powerful add-ons capabilities, it's possible to
"work around" the lack of the feature in Firefox with an add-on (e.g.
https://addons.mozilla.org/en-US/firefox/addon/small-nav-bar/?src=ss)

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

# Possibly Asked Questions:

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

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


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


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


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


* The entire bookmarks bar if not autohidden


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

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

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

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

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

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

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

On 2013-04-17 6:29 PM, Mike Conley wrote:
> Hello folks,
>
> So the Australis project is chugging along nicely (if you haven't tried
> the UX branch build[1], you should check it out).
>
> One of the things we've started to work on is improving how users can
> customize Firefox. We want customization to be easy and pleasant to do,
> and hard to get wrong (ie, hard to break the browser).
>
> Customization is a hot-button topic, and it's not surprising that once
> we start fiddling with it, users who customize their browser UI are
> going to get concerned. So I wanted to open up the discussion here so we
> can perhaps discuss those concerns, and ideas for mitigating them.
>
> For those who aren't familiar with the project[2], I'm going to try to
> summarize the high-level changes to customization that we're proposing.
> I should emphasize that while we've started to write these things down,
> nothing is set in stone. It's just a place to start.
>
> Anyhow, so here are our thoughts:
>

> 1. We want to introduce more specific customization targets into
> Firefox's UI. An example of a customization target would be a box
> immediately to the right of the AwesomeBar, or one to the right of the
> tabstrip, or one in our new menu panel. These boxes are places where
> toolbar items can be dragged to and from.
>

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

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

> 4. We're introducing a fixed Menu button at the end of the toolbar which
> opens the "menu panel". The menu panel will contain one or more
> customization targets.
>

> 5. We're considering moving the back, forward, URL bar, refresh and stop
> buttons to the start of the nav-bar, and making them immovable when
> using the customization mode.
>

> We're going to need to migrate incompatible customizations over to this
> new world. Jared and I have started talking about that, and we wrote our
> initial plan down here:
> https://bugzilla.mozilla.org/show_bug.cgi?id=860814#c3 - again, not set
> in stone.
>
>
> So, let's chat. In particular, I'd like to hear from the UX team in case
> I've forgotten something or made a mistake in my outlining of these
> points. But I'd also like to just hear from the firefox-dev community at
> large in case what we're looking at doing is in need of more tweaking.
>

> Sorry for the long post,
>

> -Mike
>
> 1: http://people.mozilla.org/~jwein/ux-nightly/
> 2: a UI prototype to illustrate:
> https://people.mozilla.com/~bwinton/australis/customization/mac/ and a
> spec to read:
> http://people.mozilla.com/~zfang/Customization/AustralisCustomization_Q4Spec.pdf
>

[David Smith]

>> We get a ton of hits on
https://support.mozilla.org/en-US/kb/navigation-buttons-missing.

How much is "a ton"? Is it a greater percentage of the userbase than
the number of users who keep 100+ tabs open?

What is the underlying cause of so many users needing to consult that
page? That is, what exactly led people to make mistakes that made the
browser 'unusable'? I've seen examples of what an unusable state is,
but I've never seen anything addressing what led users to reach that
state in the first place.

Things I can think of:

1) Mouse flakiness (and possibly extended to touchscreen flakiness). My
own mouse has been a pain in the ass lately, where, when holding down
the mouse button and dragging, it will occasionally 'skip' -- that is,
signal that the mouse button was released and then re-pressed in a
nearly instantaneous fashion -- such that I don't get the proper
selected text that I was aiming for, or something I was doing a
drag-and-drop operation on ends up in the wrong place, etc.

While it's likely that at least some of the problems stem from such a
hardware issue, it seems somewhat less likely that that's the cause of a
permanent breakage in the browser since you still need to 'OK' any
changes you make (though you can also Esc out, which may be a natural
reaction when you make a mistake, and may further promote this issue).
If something was dropped in the wrong place due to hardware flaws, you
can just try moving it again. However the options for Mozilla to
account for this are quite limited, so the presence of reports that were
caused by such problems is not in itself a means of justification.

2) Not understanding what all the buttons are for. Ever since the
introduction of the magic combining buttons, customize mode shows more
buttons than actually appear in the UI. It even took me a bit to figure
out what the hell was going on after that initial change. A user may
feel that their toolbar has reached some sort of 'corrupted' state when
they see these extra buttons show up, and try to get rid of the extras
to clean it up.

In this case, the source of the problem is the original design change,
along with the manner of interacting with this changed UI paradigm.
Removing the ability to customize only masks the original mistake.

3) Dropping buttons on an auto-hidden toolbar. (Example provided by Mike
on Reddit) When leaving customization mode, the toolbar disappears
along with the moved buttons.

In this case, the flaw is allowing hidden toolbars to be targets of
customization. That appears to be getting addressed in the current
proposal.

4) 'Losing' a button. For example, dragging a button somewhere and
accidentally putting it in the palette window, it can be somewhat
difficult to find it again in amongst all the junk in that window. This
actually seems like the most difficult to do accidentally, since there
are only a handful of places you can 'release' a button that you're
dragging, and (assuming #3 was fixed) the only way a button can
disappear completely is by putting it back in the customization window.

Preventing the user from being allowed to remove the buttons from the
toolbar does keep them from getting hit by this particular issue.
However I question whether the primary difficulty is moving the button
off of the toolbar, or whether it's the difficulty in finding the button
again once it's been removed.

The current main difficulty in finding the button again is that
accessing the customization palette requires use of a context menu
item. With the introduction of a primary UI element (the UI button for
invoking customization), and presumably making sure that it's not
possible to remove that button, that removes a large portion of the
difficulty in recovering a removed button. Improvements in the general
UI display to make it easier to find the customizable elements
themselves further lowers the barrier.

As such, I must question the gain that is expected from preventing
removal of the buttons entirely vs simply having better accessibility to
the buttons, so that they're not 'lost' (as well as fixing the other
real issues).

5) Extensions that force certain changes due to a lack of a standardized
API for adding their buttons to a toolbar when installed. Multiple
add-ons that do such things in their own hacky ways may end up creating
a bit of a mess.

To fix this, just set up a proper API. Appears to be part of the
current proposal.

6) Anything else? I can't think of any other means of interacting with
the UI that would lead to such a problem.


From what I can see, addressing this issue would be:

1) Do not allow hidden toolbars to be customization targets. (done)
2) Improve the customize palette window to make finding things easier.
(done)
3) Eliminate 'magic' button combinations. Provide 1:1 mapping between
what you put on the toolbar when customizing, and what you actually get.
3a) Make it easy to use alternate forms of buttons, whether provided as
part of the default or via add-ons.
4) Set up a simple, standard API for add-ons that wish to add toolbar
buttons on install.

Examples for 3a:
Combined back/forward/URL bar
Combined back/forward (both always visible), separate from URL bar
Separate back, forward


Essentially, the magic combining buttons were made to solve the issue of
how to allow variations in the UI without changing the number of base
elements the UI was built from. That is, you don't want a plain URL
bar, a URL bar with combined back/forward, a URL bar with stop/reload at
the end, a URL bar with combined back/forward/stop/reload, and all those
variations with the bookmark star, etc.

The sheer number of possible combinations is problematic, such that you
don't want to create one UI element for every possible combination. At
the same time, you don't want 'magic' combinations that confuse users
and cause extra hassle for developers. Your original solution to the
dilemma seemed to just be "don't allow customization".

Aside: An alternate approach would seem to be to to provide only a
single UI element per type of interface element, but allow the user to
scroll though the varying 'types' that it can exist as (eg: combined
stop/reload vs separate stop and reload that are linked together).
Would probably be a bit more complicated on the dev side, but would
avoid the 'magic' combinations; every UI element would be explicit.

So suppose we move forward, where the default UI only has some very
simple, basic elements, and you depend on add-ons to fill in the gap for
those who want to customize their interface (ignoring that this is in
direct opposition to the stated goal of wanting people to be more
comfortable customizing the interface themselves). To what degree can
an add-on replace all elements? In particular, can you have an add-on
that provides a simplified URL bar, divorced from the merged
back/forward buttons, that can properly mimic site security
information? Allowing an add-on to mimic such things seems like a huge
potential security hole, but not allowing it means that the user can't
replace the hard-coded elements that Mozilla decides on.

Further, how does this affect theming? Creating an add-on that allows
you to set any various and sundry combinations of buttons as what gets
used in the customization window would seem easy enough, but if those
buttons are (necessarily) different from the default ones, it would seem
difficult for a theme to properly handle skinning all the variations,
particularly when there may be multiple (potentially conflicting)
add-ons all attempting to compensate for the new issues that Mozilla
introduced.

Also note that the add-on bar is entirely separate from any and all of
the above issues (as evidenced by the fact that what few justifications
have been presented for its removal have had nothing to do with
customizability), and using this proposal as a means to force its
removal seems out of scope.

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

I think that this actually has the potential to be counter-productive.
This goes back to point #4, above -- it's easy for buttons to be 'lost'
in amongst the tons of options in the palette window, and possibly
similarly with the customization panel (all mockups so far have been
extremely limited; how do they look with a dozen add-on icons mixed
in?). Trying to promote every single add-on as a "first class citizen"
in the UI does not serve the actual level of interaction value any given
add-on provides.

Some add-ons are low-profile and only used occasionally; you don't want
them cluttering up the main UI (eg: music player, color picker, proxy
adjustments, etc). Some merely provide status information that would be
gaudy and annoying in the main toolbar (eg: weather, flags, time, etc).
Putting everything into a single bucket, trying to force everything into
a top-level display position, increases the issue of 'losing' buttons in
a cluttered area, while also increasing the amount of 'noise' in the UI
since you propose to no longer have the add-on bar to hold lesser-used
items.

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

No matter how many times I read this, it still boggles my mind.

>> * Remove UI for adding custom toolbars

Will agree that that seems like something more suited to an add-on.

[Mike Conley]

Hey David,

Sorry it took so long to respond, but this was a pretty epic post and I
wanted to make sure I had enough time to sit down, read it closely, and
think about it fully before replying.

>>> How much is "a ton"? Is it a greater percentage of the userbase than
>>> the number of users who keep 100+ tabs open?

I don't know. I've just been told that it's a disturbingly popular SUMO
page.

>
>> However the options for Mozilla to
>>> account for this are quite limited, so the presence of reports that were
>>> caused by such problems is not in itself a means of justification.

I somehow have a hard time believing that all of these page views are
due to flaky mice. It sounds pretty unlikely to me.

>
>> Ever since the
>>> introduction of the magic combining buttons, customize mode shows more
>>> buttons than actually appear in the UI.

This is true - certain buttons appear differently when in customization
mode; we make them more "grab-able". Perhaps we could be a little less
abrupt when switching to customization mode, and leave most buttons as
they normally appear.

The unified back-and-forward button with the conditional forward always
has the keyhole appearance when immediately preceding the URL bar, but
anywhere else, it appears as two individual square buttons. Perhaps we
can persist the keyhole shape in customization mode *until* the unified
back/forward button is dropped somewhere else.

I'm not totally crazy about some of our magic button stuff. We had toyed
with the idea of binding the back, forward, URL bar, and stop / reload
buttons into a single item, but after lots of feedback, opted to keep
them separate for customizability's sake.

Combining the stop and reload buttons into a single item is one way of
reducing all of this magic, anyhow.

>>> Removing the ability to customize only masks the original mistake.

This idea keeps coming up, and I have no idea how it happened. When did
anybody say that we were removing the ability to customize? This is
manifestly *not* what we're doing. We're attempting to lower the barrier
to entry so that *more* people can customize.

>>> As such, I must question the gain that is expected from preventing
>>> removal of the buttons entirely

We're attempting to make it harder to break the browser for every day
users out of the box. A browser without a URL bar, a back and forward
button, and a stop and reload button is almost assuredly not the kind of
browser that the average user would want. I'm not sure how one could
disagree with that statement.

A browser where those items are scattered about the UI is almost
assuredly the kind of browser a power-user would want. And they can
still have that UI, but will need to install an add-on to gain that
capability.

So, in short, the gain is a safer customizability environment for
non-power users.

>> Your original solution to the
>>> dilemma seemed to just be "don't allow customization".

No, this is absolutely incorrect. "Don't allow customization" is a
phrase that is being slung around, and it's really quite misleading.

Remember the goal here - we're trying to make customization easier and
safer for average users. We think we've found a balance point between
the options and capabilities that average users would need and care
about, and the capabilities that power users expect.

"Not allowing" implies that we're actively trying to suppress. This is
simply untrue. We're trying to allow *more* people to customize. We
*want* people to customize, we want them to be *more* in control of
their browsers.

Doing so means making the customization experience something that feels
safe, easy and forgiving for the average user. It means making the
experience something that the user *wants to try*.

And for the power users that want full control of every pixel of the
browser, this is where add-ons are (and have always been) useful.

>> To what degree can
>>> an add-on replace all elements? In particular, can you have an add-on
>>> that provides a simplified URL bar, divorced from the merged
>>> back/forward buttons, that can properly mimic site security
>>> information? Allowing an add-on to mimic such things seems like a huge
>>> potential security hole, but not allowing it means that the user can't
>>> replace the hard-coded elements that Mozilla decides on.

It wouldn't surprise me if there were add-ons out there for replacing
the Awesomebar. In fact, it'd surprise me if there *weren't*. As long as
they're on AMO, you can be sure that they've been code reviewed, and
that the AMO reviewers have done their utmost best to ensure their security.

But if the goal of the add-on is to simply allow those items to be
removeable again (or movable to other toolbars), it's almost certainly
going to be simpler. I imagine the add-on would simply need to remove an
attribute from the toolbarbuttons in question. Re-implementing each
individual element in order to remove them (or move them to other
toolbars) is overkill.

>>> Further, how does this affect theming? Creating an add-on that allows
>>> you to set any various and sundry combinations of buttons as what gets
>>> used in the customization window would seem easy enough, but if those
>>> buttons are (necessarily) different from the default ones, it would seem
>>> difficult for a theme to properly handle skinning all the variations,
>>> particularly when there may be multiple (potentially conflicting)
>>> add-ons all attempting to compensate for the new issues that Mozilla
>>> introduced.

Theme authors have probably always run into this difficulty, but you
should read my previous paragraphs about how I think re-implementing
each individual toolbar item to make them removeable (or movable to
other toolbars) is sheer overkill.

>>> Also note that the add-on bar is entirely separate from any and all of
>>> the above issues (as evidenced by the fact that what few justifications
>>> have been presented for its removal have had nothing to do with
>>> customizability), and using this proposal as a means to force its
>>> removal seems out of scope.

No, I do very much think this is in-scope, since the add-on bar, up
until now, has been a customization target. You can put items there, and
you can take items away.

I think the add-on bar plays very much into all of this, because its
very existence seems to suggest that add-ons are "second-class citizens"
that have to be split out into their own toolbar, far away from the rest
of the browser UI.

>>> I think that this actually has the potential to be counter-productive.
>>> This goes back to point #4, above -- it's easy for buttons to be 'lost'
>>> in amongst the tons of options in the palette window, and possibly
>>> similarly with the customization panel (all mockups so far have been
>>> extremely limited; how do they look with a dozen add-on icons mixed
>>> in?).

We will be finding and placing an upper-limit on the items that can be
in the panel. The items in the toolbar will overflow into an "overflow
panel" if there are too many to show all at once.

Thanks for the epic email, David. I appreciate your constructive tone,
and I look forward to future discussion.

-Mike

[The Wanderer]

On 04/27/2013 02:23 PM, Mike Conley wrote:

[that on 2013-04-23 at 02:15, David Smith wrote:]

>> Removing the ability to customize only masks the original mistake.
>
> This idea keeps coming up, and I have no idea how it happened. When
> did anybody say that we were removing the ability to customize? This
> is manifestly *not* what we're doing. We're attempting to lower the
> barrier to entry so that *more* people can customize.

But you are placing limits on built-in customizability. While the
overall potential to customize the browser may not be reduced in the
large picture, the ease of doing so in the ways covered by the changes
being proposed does seem to be being reduced, and not everyone is going
to see past that first impression.

This is a matter of presentation and user perception again. You're
asking the right questions here, I think, but answers to those questions
aren't as ready to hand.

>> As such, I must question the gain that is expected from preventing
>> removal of the buttons entirely
>
> We're attempting to make it harder to break the browser for every day
> users out of the box. A browser without a URL bar, a back and
> forward button, and a stop and reload button is almost assuredly not
> the kind of browser that the average user would want. I'm not sure
> how one could disagree with that statement.
>
> A browser where those items are scattered about the UI is almost
> assuredly the kind of browser a power-user would want. And they can
> still have that UI, but will need to install an add-on to gain that
> capability.

And this is fine, if and only if that add-on is guaranteed to exist.
(Not necessarily to be up-to-date, but to at least have existed and been
functional for some previous version - and to be available in that
previously-functional form.)

> Remember the goal here - we're trying to make customization easier
> and safer for average users. We think we've found a balance point
> between the options and capabilities that average users would need
> and care about, and the capabilities that power users expect.
>
> "Not allowing" implies that we're actively trying to suppress. This
> is simply untrue. We're trying to allow *more* people to customize.
> We *want* people to customize, we want them to be *more* in control
> of their browsers.
>
> Doing so means making the customization experience something that
> feels safe, easy and forgiving for the average user. It means making
> the experience something that the user *wants to try*.

For the record, I completely understand, agree with and support this
goal. I simply may (and, apparently, do) disagree as to what is
acceptable and/or desirable in attempting to reach that goal.

>> Also note that the add-on bar is entirely separate from any and all
>> of the above issues (as evidenced by the fact that what few
>> justifications have been presented for its removal have had nothing
>> to do with customizability), and using this proposal as a means to
>> force its removal seems out of scope.
>
> No, I do very much think this is in-scope, since the add-on bar, up
> until now, has been a customization target. You can put items there,
> and you can take items away.

And it's precisely that customization target that I want to retain...

> I think the add-on bar plays very much into all of this, because its
> very existence seems to suggest that add-ons are "second-class
> citizens" that have to be split out into their own toolbar, far away
> from the rest of the browser UI.

So is the objection to having a customization area specifically
designated for add-ons, or to having a customization area at the bottom
of the browser window, or to having a customization area sized like the
old status bar, or...?

The add-on bar appears to fill all of those niches AFAIK, but the
arguments I've seen presented for removing it don't seem to separate
them out; the one you give here seems, at a glance, to only address the
first one.

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

[Robert 'Bobby' Zenz]

Hello again.

I hope I made my objection of these changes already clear, so I will
not go into that again. But I'd like that you consider some additional
points.

The auto-update feature in combination with the
"all-versions-are-equal" versioning scheme might yield a not so good
user experience in this case. F.e. imagine someone (like me) has used
those customization options, with the update which contains these
changes the UI would revert to a "mess" with no easy way to undo it.

Also about the "it can be undone via an addon". Only a small percentage
of the users which are customizing the UI in these ways are also
programmers (yeah, is a guess), and it is unknown how many of those are
Firefox addon developers. So it is possible that someone installs the
update and has no way to restore the customized UI until someone
writes an addon.

I suggest that, if those changes get merged into the main Firefox line
(objection?!), that you notify the users somehow before they install
the update that this might break their UI customizations. That will
minimize the negative impact of this update on people which are used to
customize Firefox to their needs.

Anyway, are those changes already planned to for version 23(?), or is
this still a proposal.

Bobby

[David Smith]

> Sorry it took so long to respond, but this was a pretty epic post and I
> wanted to make sure I had enough time to sit down, read it closely, and
> think about it fully before replying.

Thank you for responding. I was getting a bit concerned after two days
of no discussion at all. On the other hand, I've been fairly busy the
last few days too, so sorry for the long delay there as well. I wanted
to make sure I had the time to make a proper response, so didn't want to
send the first draft when I wrote it a few days ago.

>> I somehow have a hard time believing that all of these page views are
>>due to flaky mice. It sounds pretty unlikely to me.

Quite unlikely, but that wasn't my point. The point is that there are a
lot of page hits on that SUMO page, but absolutely no information on
-why- people are hitting that page. What sequence of events led people
to have a 'broken' browser? What in particular is problematic about the
current design? What is it that people don't understand (assuming it's
entirely internally related), and can you use that to be sure you don't
just create a different "difficult-to-understand" system?

In the case of the mouse, I've had the problem crop up on three
consecutive Logitech mice, so I'm suspecting a driver problem, or maybe
some wierd interaction with a Windows update. Regardless, the issue
could be subtly widespread (though I have absolutely no data one way or
the other), but wouldn't have any apparent direct correlation with SUMO
page hits. How consistant are the hits on the SUMO page? Has it been
steady throughout its history, or have there been periods of spikes?

I wasn't saying it was due to flaky mice so much as giving an example of
things that are entirely outside of the scope of Mozilla to account for,
but could lead to the problem. In that case, the issue isn't 'breaking'
the browser so much as not being able to 'unbreak' the browser. Your
approach is to prevent the problem from happening in the first place
(which is generally good), but seems far more limited on the other half
of the problem -- to make a clean and obvious means to escape from the
'broken' state.

>> Removing the ability to customize only masks the original mistake.

> This idea keeps coming up, and I have no idea how it happened. When did
> anybody say that we were removing the ability to customize?

And then followed by:

> We had toyed with the idea of binding the back, forward, URL bar, and

> stop / reload buttons into a single item, but after lots of feedback..

> We're attempting to lower the barrier to entry so that *more* people
> can customize.

You're making it easier to customize small bits of the browser, but
adding an extra barrier to entry for stepping beyond the most trivial
changes (ie: require one or more add-ons just to be allowed to make
additional customizations). As such, one must consider that the
definition for 'customize' that you are using is not quite the same as
what others are. It's a bit like considering a persona the same thing
as a theme; technically, you can consider a persona as a theme that only
makes one modification, but it's a bit disingenuous to call them the
same thing.

It wouldn't be quite as much of an issue if you were also releasing a
means of accessing the extended customizability (either via about:config
prefs, or a simple addon that unlocks the browser) at the same time.

>> As such, I must question the gain that is expected from preventing
>> removal of the buttons entirely

> We're attempting to make it harder to break the browser for every day
> users out of the box. A browser without a URL bar, a back and forward
> button, and a stop and reload button is almost assuredly not the kind of
> browser that the average user would want. I'm not sure how one could
> disagree with that statement.

I'm not questioning the -purpose-, I'm questioning the -gain-. How much
are you gaining for each individual change you make, and how much is
more annoyance than gain? Just like the 80/20/2 thing you (I think)
brought up in another post, which of these changes are a significant
gain in your stated purpose (eg: reducing the likelihood of someone
needing to consult that SUMO page; reducing barrier to entry, and
increasing general customizability), and which are just chasing that
99th percentile?

To an extent, this goes back to the lack of data on why people are
having problems in the first place. Are you actually fixing the
problems, or is this just another shiny band-aid? I am not discounting
that problems are actually being fixed, but the justifications for some
of the changes seem lacking.

> As long as they're on AMO, you can be sure that they've been code
reviewed, and
> that the AMO reviewers have done their utmost best to ensure their
security.

That's nice. What if they're not on AMO? As I recall, there's a *huge*
number of extensions not on AMO (it was one of the issues that came up
for the memshrink group when they started tackling addon-based memory
leaks).

> I think the add-on bar plays very much into all of this, because its
> very existence seems to suggest that add-ons are "second-class citizens"
> that have to be split out into their own toolbar, far away from the rest
> of the browser UI.

What exactly does it mean to be a "second-class citizen"? Who are they
second-class to? I might say, "The very existance of the addons options
panel shows that they are not part of the browser itself, and thus
second-class citizens." Does such a statement have any meaning
whatsoever? Does it mean we need to get rid of that configuration panel
so people don't suddenly start thinking less of addons?

If I run Word or Excel or whatever, there's stuff at the top of the
window, and there's stuff at the bottom of the window. Is the
information presented at the bottom "second-class"? Maybe; I'm still
not sure what you mean by that. All I know is that there's some stuff
that's useful to me at the top of the window (navigation, menus, etc),
and some stuff that's useful to me at the bottom of the window (status,
time, zoom levels, little bits of detail describing what's going on or
what I'm doing, etc).

To me, stuff at the bottom of the window is just 'different'. It's
stuff that's not relevant to general navigation. Firefox already puts
other things at the bottom of the window -- link addresses when you
hover over them, and the quick-find bar. I expect (in a very general
sense; trying to make a useful delineation off the cuff, here) stuff at
the top to be "where I want to go", and stuff at the bottom to be "what
I'm doing or want to know about". I wouldn't want the URL bar at the
bottom, but I wouldn't want the weather report at the top.

Now, obviously that's just me. But in general, people like to
'categorize' stuff. "A place for everything, and everything in its
place", for an old aphorism. Many people will only need one place to
put stuff, but many others could use at least one other 'place'. A
mental map, to cognitively associate things together. You want to dump
the add-on bar and relegate it to an extension, yet weren't you also
trying to lower the barrier to entry of customization? If you remove
even the idea of such a thing being possible, how are you improving
towards that goal?

A most basic definition of customization would be, "Putting things where
(I think) they belong." There are very few places where things can
'belong' in a browser window (at least as far as where a user can put
buttons and stuff): the top of the window, the bottom of the window, and
the side of the window. The sidebar is rather difficult to make use of,
so all you're left with is the top and the bottom. And now you want to
remove the default ability to put things on the bottom.

As I'm sure you're aware, simply from the fact that you're trying to
lower the barrier to entry for more people to perform such
customization, people often won't go beyond what's given to them. If you
want to increase the likelihood of people customizing the browser, why
would you at the same time want to limit them in such a fundamental
manner? Not even being fancy with custom toolbars and everything, just
a very basic "stuff at the top or stuff at the bottom"?



What seems to be here is three different categories of changes:

1) Limited control of placement during customization, to prevent
'breaking' the browser. Prevent removal of parts of the browser that
are considered fundamentally required, and don't allow placement of
buttons on surfaces that aren't going to exist during normal use (ie:
hidden toolbars).

2) Pretty up the interface for making customizations, so that it's
easier to find what you need. Improve mapping between customization
view and usage view.

3) Controlling the scope of what you're allowed to customize, and
particularly where addons can appear.

#1 and #2 are clearly intended to work towards the same goal. Aside
from the lack of an immediate means to bypass those restrictions, I
generally don't have any issue with their intended purpose; it seems
like a decent path for improved usability.

#3, however, starts to breach the "out of scope" boundary. It's no
longer, "Reduce confusion, and keep the user from doing something
stupid.", it's "This is what the user is allowed to do."


There's actually an interesting correlation between point 3 and point 1:
You want default placement of addon icons in a space where people know
they can find them. That is, if someone adds a new addon, they know
they can always go to the same place in order to find the button for
it. You'd like to prevent addons placing the buttons willy-nilly on the
browser surface. One could consider various means of doing so:

a) A default button-adding API that takes the addon's button(s) and puts
it in the 'pool' of all addon buttons, so that the user can go there
during customization, pull the button out, and put it where they want it
to belong, rather than wherever the addon happened to decide to place
it. The main problem here is the "It didn't install!" reaction -- that
if the user doesn't know about this default pool of buttons, the addon
will never be obviously visible.

b) A restriction on the ability of addons to automatically place buttons
during install, in the same manner as restricting the user's options:
don't allow buttons to be placed on hidden toolbars. The addon bar is
hidden by default, so if no addon has been placed there already it will
be hidden, and thus not be a valid default placement target. Obviously
the addon must use a default API function to be properly restricted in
this way (eg: AddInterfaceButton(preferredLocation, fallbackLocation)),
but that's wanted regardless.

c) Simply removing the addon bar, such that any attempts to add a button
to it fail. I would guess that if the addition fails, the fallback is
the default pool of buttons that the user can customize from. A
clumsier approach than #1 (and with the same drawback of the uncertainty
of the addon being installed), but works even with older addons if it
indeed uses that fallback.

#b in particular is a means of addressing the issue using the same
guidelines as #1 above.



Now, having said all that, I can understand the perspective that Mozilla
might want to explicitly "get out of the way", as it were, of those who
might want to create specialized target surfaces for use somewhere in
the browser. If the idea is to remove a somewhat restrictive form of
target area that never makes any renovations due to being a default
built-in, that would seem a viable justification, so as to allow a
greater variety of third-party options to flourish. However it's not
being presented that way. And there's certainly advantages in having a
guaranteed reliable, stable target area, even if it doesn't do much.

Even if that were the case, however, Mozilla should still be providing a
'default' addon that performs the same function as what's being removed,
and release it simultaneously with the changes being made.

In addition, one must also provide at least some demonstrated use-case
of a third-party-defined target area that isn't fulfilled by the
existing addon bar. At the moment I'm having a hard time thinking of
such a use case that doesn't also lead to simply having every major
addon create its own addon bar. In fact, the potential ramifications of
what could happen following this change seems like it could very quickly
create even greater confusion and instability.

If you end up with a Vanilla addon bar, a TabMixPlus addon bar, a
Status-4-Evar addon bar, a Firebug addon bar, a ForecastFox addon bar,
and a dozen others, each with subtly different implementations and
interactions, that seems ripe for causing tons of issues and headaches
that would be quite difficult to track down. To what extent has thought
been given to this sort of evolution? Or is this to be treated as
"somebody else's problem" as well?

[Justin Dolske]

On 5/2/13 1:45 PM, David Smith wrote:
> [...]

It feels like this thread is wandering into the weeds and has played out
its useful life. So I think we're largely done, but I'll reply to a
couple of parts.

> You're making it easier to customize small bits of the browser, but
> adding an extra barrier to entry for stepping beyond the most trivial

> changes [...]

> It wouldn't be quite as much of an issue if you were also releasing a
> means of accessing the extended customizability (either via about:config
> prefs, or a simple addon that unlocks the browser) at the same time.

This has been explained a few times now, so I think we'll just have to
agree to disagree.

> > I think the add-on bar plays very much into all of this, because its
> > very existence seems to suggest that add-ons are "second-class citizens"
> > that have to be split out into their own toolbar, far away from the rest
> > of the browser UI.
>
> What exactly does it mean to be a "second-class citizen"?

Basically what Mike wrote. Buttons/widgets provided by add-ons should
generally be able to be used and customized just like any other
browser-provided widget. A number of add-on authors had expressed
concern (especially when the bar first landed) that Firefox was going to
destroy customization (sound familiar?) by only allowing add-ons to put
stuff in the add-on bar at the bottom of the window. That was never the
intent.

Justin

[Emanuel Hoogeveen]

I haven't really seen this mentioned here, but I wouldn't be surprised if it's come up before: why not make the addon bar into something more generic that can be placed on any edge of the window?

There's a simple need for icons when you have addons to interact with, and there's not a lot of space with the address bar there - but I find it strange that the current addon toolbar has to be at the bottom. Personally I'd much rather have it either to the left or the right of my screen, with a column of addons in it, or just below the address bar where the rest of the UI is located.

I found myself wishing for something like this when I recently tried out the Facebook integration. This adds a number of buttons next to the address bar - so many in fact, that I eventually decided to get rid of it to reclaim the space they took up (the other reason I disabled it was that it didn't track my timeline, making it not very useful).

The current addon toolbar seems like a special case because it's not very tall (looking much like the status bar of old). But a more generic toolbar could simply be as wide or as tall as the widest or tallest icon on there, and could use the same API as is used for placing icons next to the address bar - perhaps even default to placing them there, since the user could move them easily enough.

Has this come up in discussion? What's the UI team's stance on this?

Regards,

Emanuel Hoogeveen

[Mike Conley]

Hey Emanuel,

>> Personally I'd much rather have it either to the left or the right of my
>> screen, with a column of addons in it, or just below the address bar
>> where the rest of the UI is located.

You could turn on your Bookmarks Toolbar and drag items into there.
That'd put your buttons below your address bar.

>> Has this come up in discussion? What's the UI team's stance on this?

The plan is to overflow "overflowable" toolbar buttons in the nav-bar to
a special panel when there are too many to display.

Alternatively, you could (with the new proposal) move some of those
items into your tab strip, or menu bar if you have it exposed.

Alternatively, an add-on could inject a new toolbar for you to use, and
register it with our customization code to give you a new target to drop
items on to.

-Mike

[Stephen Cohen]

Hello,
I've been following these discussions for a while but couldn't find an obvious way to respond without switching to individual mail (I was on digest) and waiting for another related message, which is what I did. Sorry I got into this a bit late...

Anyway, I've always liked the direction I saw Australis going in design and UI-wise, but this thread has brought things to my attention that I have seen others, including the very individual to whose message I am responding, bring point to and I thought I'd throw my own two cents in as I have a few perspectives I don't think have been brought up yet.

The biggest thing is also that which David brought up and that is the removal of the Add-On bar.

I understand that your logic for its removal is that you wanted to give add-ons a "more prominent" place in the browser and make them less "second-class" citizens, and I agree with it wholeheartedly. However, my biggest complaint at this idea is the same one brought up several other times here and that is that it is very useful, and at times almost necessary, to have a small toolbar/customization target at the bottom of the browser.

As several have brought up, many add-ons create toolbar items that are simply not appropriate for the main navigation area for one or more of the following reasons:
--They take up large amounts of horizontal space
--They display information long-form and are not interactive as simple buttons (these items, when placed on the Nav Bar, would also seem out of place as that toolbar has generally only had buttons on it)
--They function as "mini-toolbars," groups of buttons that move together and generally /also/ take up large amounts of horizontal space

Examples of these things would be weather toolbars, music players, website statistics, etc.
     These items would take up too much valuable horizontal space on either the Navigation or Tab Bar, and possibly on the Bookmarks Bar as well, depending on how many bookmarks the user has on it. Traditionally, such items have either been placed on the Menu Bar (for those who still use it), or the Add-On Bar. I cannot recall if the Menu Bar was restored as a customization target, when not hidden, in the "final" proposal; if it was not, most of my arguments for the Add-On bar apply to it as well. Removing the Add-On bar leaves a feature-gap for a proper location for such add-ons.

The second main reason for my objecting to the Add-On Bar's removal is actually the very reason for which you wish to remove it: add-ons should not be treated as "second-class," whenever possible.

You are removing the Add-On bar because you feel that by having add-ons appear there upon installation, they are being portrayed as "having" to be there because, as David pointed out, users will often just take what they're given. However, this problem could be fixed without removing the toolbar altogether, as it is only the *automatic placement* of items in this area that produces this undesired effect, not the mere *existence* of a target area at the bottom of the browser, though I do also agree with the notion of renaming it, as to not imply that the add-ons somehow "belong" there. The problem could be addressed by merely hiding the toolbar by default (thus making it an invalid target) and preventing add-ons from "spawning" to it.

There are also users who wish to *make* particular add-ons "second class," and you have already provided for that in some ways by the introduction of a target area inside the main Menu, which is itself a VERY good idea. However, it could be said that, while there are some buttons that it makes sense to have added to a menu rather than a toolbar, for others which are only used occasionally but which the user wishes to still be able to access quickly/provide at-a-glance info, this system makes them *more* second-class as now *two* clicks, rather than *one* are required to access them. Also, in the mockups and designs I have seen, the buttons in this menu area are arranged in a sort of "grid." The items I mentioned earlier which take up more horizontal space than a single button could, at the worst, break such a grid, and at the best, stretch it out a considerable degree, which wouldn't look very pretty.

It is correct to say that these functions could be filled by an add-on, and I'm certain one would be made, but that is not the problem. The problem would be that add-ons whose developers think that a separate toolbar is more appropriate for their add-on's functionality would likely be more inclined to create their own toolbar for said add-on, opening up the possibility of IE's infamous "stack of toolbars" as these toolbars would likely be exclusive to their respective add-ons. In addition, the items on these toolbars might be locked to them, making those add-ons /less/ customizable. Other developers who would want to avoid this issue might instead point users to "first install [add-on that recreates an add-on bar] before installing this add-on;" as pre-reqs are not something generally seen with Firefox add-ons, the user would not expect this behavior and might be confused by it.

Another problem created by the removal of the Add-On Bar, even only as a "spawn" point for add-ons, is that items would then be forced to appear on places like the Nav Bar which might lead to sudden crowding on those toolbars. A solution for this would be that, when an add-on is installed and adds buttons, the user is prompted with a dialogue themed similarly to the main Customize view, as to create a link between them, that reads something like: "The recently installed add-on [ADD-ON NAME] has added the following toolbar items. Drag the ones you'd like to use to any of the highlighted targets. Press Okay when done." and then, next to Okay: "Any unused items can be found later in the main Customize view." Add-on developers could perhaps also be given the option to provide descriptions for each item, reducing confusion as to how the ad-on works. This would completely avert the "did it install??" problem and also prevent any issue with bad button placements while making it clear to the user that the buttons aren't going to disappear if they choose not to place them. This would not be disruptive as the user is already making a series of conscious actions (clicking install, clicking allow...) in installing the add-on and would not be "surprised" by a need to give input. In fact, this would serve almost as confirmation that the add-on was installed correctly and make customization even MORE accessible by making it an integral part of installing add-ons in the first place. In addition, this would prevent the auto-placement on the Add-On Bar, as it would not even be highlighted as a target unless it was already in use.

Another idea that might allow for a little more confidence that the user will not "lose" a button would be to have adding/removing toolbars be part of the main Customize view (if it isn't already) and having it so that, when a toolbar is removed, the buttons placed on it by the user would "fly" back into place in the main palette of buttons, creating an obvious link as to "where they just went." A visible-yet-unobtrusive "undo" option could then appear, similar to what already appears when a New Tab thumbnail is removed. The removal of individual items, and anything else that could be considered "breaking" the browser could all have a similar effect. This avoids overt "WARNING"s while still providing an obvious visual explanation for what has happened and providing an easy way to undo the action, even if said action was accidental.

That was my main set of points to add, and I only really had the one other comment:
I agree with locking the nav buttons to the main toolbar. I just saw that it was noted earlier in the thread that an add-on wanting to allow a locked button to be more moveable after these changes would likely only have to modify a single attribute of said buttons. Isn't the modification of a single attribute something more appropriately left to about:config, since that's generally what about:config flags do?

I understand that my replying so "late in the game" might make these points less "influential" (for lack of a better word) than they could have been and I apologize again for not posting sooner. I might be habitually wordy in my arguments, but overall I REALLY like where you guys are going with Firefox!

--Stephen/Duke9509

> Date: Thu, 2 May 2013 15:45:25 -0500
> From: dsm...@datasync.com
> To: firef...@mozilla.org
> Subject: Re: Australis Customization