<div dir="ltr"><div><div><div><div><div><div>Hi all,<br><br></div>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. <br>

<br></div>First, I oppose *all* removal of customizability.<br><br>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.<br>

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

<br>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)?<br>

<br></div>(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.)<br><br></div>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.<br>

<br></div>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. <br>

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

<br><blockquote>>"Small icons" mode will no longer be supported.
</blockquote>

<p>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?<br></p>



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

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

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



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

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

</p><blockquote>
<p>>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.</p>
</blockquote>

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

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

<blockquote>
<p>>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.</p>
</blockquote>

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

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

<p>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.</p>Thanks for reading. I do hope to hear about some major changes to the Australis proposal soon! :)<br></div>