(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."
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.
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?
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.
>"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! :)
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 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'
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.
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:
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.
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.
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.