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