<html>
<head>
<style><!--
.hmmessage P
{
margin:0px;
padding:0px
}
body.hmmessage
{
font-size: 12pt;
font-family:Calibri
}
--></style></head>
<body class='hmmessage'><div dir='ltr'>Hello,<br>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...<br><br>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.<br><br>The biggest thing is also that which David brought up and that is the removal of the Add-On bar.<br><br>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.<br><br>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:<br>--They take up large amounts of horizontal space<br>--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)<br>--They function as "mini-toolbars," groups of buttons that move together and generally /also/ take up large amounts of horizontal space<br><br>Examples of these things would be weather toolbars, music players, website statistics, etc.<br> 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.<br><br>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.<br><br>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.<br><br>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.<br><br>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.<br><br>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.<br><br>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.<br><br>That was my main set of points to add, and I only really had the one other comment:<br>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?<br><br>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!<br><br>--Stephen/Duke9509<br><br><div><div id="SkyDrivePlaceholder"></div>> Date: Thu, 2 May 2013 15:45:25 -0500<br>> From: dsmith@datasync.com<br>> To: firefox-dev@mozilla.org<br>> Subject: Re: Australis Customization<br>> <br>> > Sorry it took so long to respond, but this was a pretty epic post and I<br>> > wanted to make sure I had enough time to sit down, read it closely, and<br>> > think about it fully before replying.<br>> <br>> Thank you for responding. I was getting a bit concerned after two days <br>> of no discussion at all. On the other hand, I've been fairly busy the <br>> last few days too, so sorry for the long delay there as well. I wanted <br>> to make sure I had the time to make a proper response, so didn't want to <br>> send the first draft when I wrote it a few days ago.<br>> <br>> <br>> >> I somehow have a hard time believing that all of these page views are<br>> >>due to flaky mice. It sounds pretty unlikely to me.<br>> <br>> Quite unlikely, but that wasn't my point. The point is that there are a <br>> lot of page hits on that SUMO page, but absolutely no information on <br>> -why- people are hitting that page. What sequence of events led people <br>> to have a 'broken' browser? What in particular is problematic about the <br>> current design? What is it that people don't understand (assuming it's <br>> entirely internally related), and can you use that to be sure you don't <br>> just create a different "difficult-to-understand" system?<br>> <br>> In the case of the mouse, I've had the problem crop up on three <br>> consecutive Logitech mice, so I'm suspecting a driver problem, or maybe <br>> some wierd interaction with a Windows update. Regardless, the issue <br>> could be subtly widespread (though I have absolutely no data one way or <br>> the other), but wouldn't have any apparent direct correlation with SUMO <br>> page hits. How consistant are the hits on the SUMO page? Has it been <br>> steady throughout its history, or have there been periods of spikes?<br>> <br>> I wasn't saying it was due to flaky mice so much as giving an example of <br>> things that are entirely outside of the scope of Mozilla to account for, <br>> but could lead to the problem. In that case, the issue isn't 'breaking' <br>> the browser so much as not being able to 'unbreak' the browser. Your <br>> approach is to prevent the problem from happening in the first place <br>> (which is generally good), but seems far more limited on the other half <br>> of the problem -- to make a clean and obvious means to escape from the <br>> 'broken' state.<br>> <br>> <br>> <br>> >> Removing the ability to customize only masks the original mistake.<br>> <br>> > This idea keeps coming up, and I have no idea how it happened. When did<br>> > anybody say that we were removing the ability to customize?<br>> <br>> And then followed by:<br>> > We had toyed with the idea of binding the back, forward, URL bar, and<br>> > stop / reload buttons into a single item, but after lots of feedback..<br>> <br>> <br>> <br>> > We're attempting to lower the barrier to entry so that *more* people<br>> > can customize.<br>> <br>> You're making it easier to customize small bits of the browser, but <br>> adding an extra barrier to entry for stepping beyond the most trivial <br>> changes (ie: require one or more add-ons just to be allowed to make <br>> additional customizations). As such, one must consider that the <br>> definition for 'customize' that you are using is not quite the same as <br>> what others are. It's a bit like considering a persona the same thing <br>> as a theme; technically, you can consider a persona as a theme that only <br>> makes one modification, but it's a bit disingenuous to call them the <br>> same thing.<br>> <br>> It wouldn't be quite as much of an issue if you were also releasing a <br>> means of accessing the extended customizability (either via about:config <br>> prefs, or a simple addon that unlocks the browser) at the same time.<br>> <br>> <br>> >> As such, I must question the gain that is expected from preventing<br>> >> removal of the buttons entirely<br>> <br>> > We're attempting to make it harder to break the browser for every day<br>> > users out of the box. A browser without a URL bar, a back and forward<br>> > button, and a stop and reload button is almost assuredly not the kind of<br>> > browser that the average user would want. I'm not sure how one could<br>> > disagree with that statement.<br>> <br>> I'm not questioning the -purpose-, I'm questioning the -gain-. How much <br>> are you gaining for each individual change you make, and how much is <br>> more annoyance than gain? Just like the 80/20/2 thing you (I think) <br>> brought up in another post, which of these changes are a significant <br>> gain in your stated purpose (eg: reducing the likelihood of someone <br>> needing to consult that SUMO page; reducing barrier to entry, and <br>> increasing general customizability), and which are just chasing that <br>> 99th percentile?<br>> <br>> To an extent, this goes back to the lack of data on why people are <br>> having problems in the first place. Are you actually fixing the <br>> problems, or is this just another shiny band-aid? I am not discounting <br>> that problems are actually being fixed, but the justifications for some <br>> of the changes seem lacking.<br>> <br>> <br>> > As long as they're on AMO, you can be sure that they've been code <br>> reviewed, and<br>> > that the AMO reviewers have done their utmost best to ensure their <br>> security.<br>> <br>> That's nice. What if they're not on AMO? As I recall, there's a *huge* <br>> number of extensions not on AMO (it was one of the issues that came up <br>> for the memshrink group when they started tackling addon-based memory <br>> leaks).<br>> <br>> <br>> > I think the add-on bar plays very much into all of this, because its<br>> > very existence seems to suggest that add-ons are "second-class citizens"<br>> > that have to be split out into their own toolbar, far away from the rest<br>> > of the browser UI.<br>> <br>> What exactly does it mean to be a "second-class citizen"? Who are they <br>> second-class to? I might say, "The very existance of the addons options <br>> panel shows that they are not part of the browser itself, and thus <br>> second-class citizens." Does such a statement have any meaning <br>> whatsoever? Does it mean we need to get rid of that configuration panel <br>> so people don't suddenly start thinking less of addons?<br>> <br>> If I run Word or Excel or whatever, there's stuff at the top of the <br>> window, and there's stuff at the bottom of the window. Is the <br>> information presented at the bottom "second-class"? Maybe; I'm still <br>> not sure what you mean by that. All I know is that there's some stuff <br>> that's useful to me at the top of the window (navigation, menus, etc), <br>> and some stuff that's useful to me at the bottom of the window (status, <br>> time, zoom levels, little bits of detail describing what's going on or <br>> what I'm doing, etc).<br>> <br>> To me, stuff at the bottom of the window is just 'different'. It's <br>> stuff that's not relevant to general navigation. Firefox already puts <br>> other things at the bottom of the window -- link addresses when you <br>> hover over them, and the quick-find bar. I expect (in a very general <br>> sense; trying to make a useful delineation off the cuff, here) stuff at <br>> the top to be "where I want to go", and stuff at the bottom to be "what <br>> I'm doing or want to know about". I wouldn't want the URL bar at the <br>> bottom, but I wouldn't want the weather report at the top.<br>> <br>> Now, obviously that's just me. But in general, people like to <br>> 'categorize' stuff. "A place for everything, and everything in its <br>> place", for an old aphorism. Many people will only need one place to <br>> put stuff, but many others could use at least one other 'place'. A <br>> mental map, to cognitively associate things together. You want to dump <br>> the add-on bar and relegate it to an extension, yet weren't you also <br>> trying to lower the barrier to entry of customization? If you remove <br>> even the idea of such a thing being possible, how are you improving <br>> towards that goal?<br>> <br>> A most basic definition of customization would be, "Putting things where <br>> (I think) they belong." There are very few places where things can <br>> 'belong' in a browser window (at least as far as where a user can put <br>> buttons and stuff): the top of the window, the bottom of the window, and <br>> the side of the window. The sidebar is rather difficult to make use of, <br>> so all you're left with is the top and the bottom. And now you want to <br>> remove the default ability to put things on the bottom.<br>> <br>> As I'm sure you're aware, simply from the fact that you're trying to <br>> lower the barrier to entry for more people to perform such <br>> customization, people often won't go beyond what's given to them. If you <br>> want to increase the likelihood of people customizing the browser, why <br>> would you at the same time want to limit them in such a fundamental <br>> manner? Not even being fancy with custom toolbars and everything, just <br>> a very basic "stuff at the top or stuff at the bottom"?<br>> <br>> <br>> <br>> What seems to be here is three different categories of changes:<br>> <br>> 1) Limited control of placement during customization, to prevent <br>> 'breaking' the browser. Prevent removal of parts of the browser that <br>> are considered fundamentally required, and don't allow placement of <br>> buttons on surfaces that aren't going to exist during normal use (ie: <br>> hidden toolbars).<br>> <br>> 2) Pretty up the interface for making customizations, so that it's <br>> easier to find what you need. Improve mapping between customization <br>> view and usage view.<br>> <br>> 3) Controlling the scope of what you're allowed to customize, and <br>> particularly where addons can appear.<br>> <br>> #1 and #2 are clearly intended to work towards the same goal. Aside <br>> from the lack of an immediate means to bypass those restrictions, I <br>> generally don't have any issue with their intended purpose; it seems <br>> like a decent path for improved usability.<br>> <br>> #3, however, starts to breach the "out of scope" boundary. It's no <br>> longer, "Reduce confusion, and keep the user from doing something <br>> stupid.", it's "This is what the user is allowed to do."<br>> <br>> <br>> There's actually an interesting correlation between point 3 and point 1: <br>> You want default placement of addon icons in a space where people know <br>> they can find them. That is, if someone adds a new addon, they know <br>> they can always go to the same place in order to find the button for <br>> it. You'd like to prevent addons placing the buttons willy-nilly on the <br>> browser surface. One could consider various means of doing so:<br>> <br>> a) A default button-adding API that takes the addon's button(s) and puts <br>> it in the 'pool' of all addon buttons, so that the user can go there <br>> during customization, pull the button out, and put it where they want it <br>> to belong, rather than wherever the addon happened to decide to place <br>> it. The main problem here is the "It didn't install!" reaction -- that <br>> if the user doesn't know about this default pool of buttons, the addon <br>> will never be obviously visible.<br>> <br>> b) A restriction on the ability of addons to automatically place buttons <br>> during install, in the same manner as restricting the user's options: <br>> don't allow buttons to be placed on hidden toolbars. The addon bar is <br>> hidden by default, so if no addon has been placed there already it will <br>> be hidden, and thus not be a valid default placement target. Obviously <br>> the addon must use a default API function to be properly restricted in <br>> this way (eg: AddInterfaceButton(preferredLocation, fallbackLocation)), <br>> but that's wanted regardless.<br>> <br>> c) Simply removing the addon bar, such that any attempts to add a button <br>> to it fail. I would guess that if the addition fails, the fallback is <br>> the default pool of buttons that the user can customize from. A <br>> clumsier approach than #1 (and with the same drawback of the uncertainty <br>> of the addon being installed), but works even with older addons if it <br>> indeed uses that fallback.<br>> <br>> #b in particular is a means of addressing the issue using the same <br>> guidelines as #1 above.<br>> <br>> <br>> <br>> Now, having said all that, I can understand the perspective that Mozilla <br>> might want to explicitly "get out of the way", as it were, of those who <br>> might want to create specialized target surfaces for use somewhere in <br>> the browser. If the idea is to remove a somewhat restrictive form of <br>> target area that never makes any renovations due to being a default <br>> built-in, that would seem a viable justification, so as to allow a <br>> greater variety of third-party options to flourish. However it's not <br>> being presented that way. And there's certainly advantages in having a <br>> guaranteed reliable, stable target area, even if it doesn't do much.<br>> <br>> Even if that were the case, however, Mozilla should still be providing a <br>> 'default' addon that performs the same function as what's being removed, <br>> and release it simultaneously with the changes being made.<br>> <br>> In addition, one must also provide at least some demonstrated use-case <br>> of a third-party-defined target area that isn't fulfilled by the <br>> existing addon bar. At the moment I'm having a hard time thinking of <br>> such a use case that doesn't also lead to simply having every major <br>> addon create its own addon bar. In fact, the potential ramifications of <br>> what could happen following this change seems like it could very quickly <br>> create even greater confusion and instability.<br>> <br>> If you end up with a Vanilla addon bar, a TabMixPlus addon bar, a <br>> Status-4-Evar addon bar, a Firebug addon bar, a ForecastFox addon bar, <br>> and a dozen others, each with subtly different implementations and <br>> interactions, that seems ripe for causing tons of issues and headaches <br>> that would be quite difficult to track down. To what extent has thought <br>> been given to this sort of evolution? Or is this to be treated as <br>> "somebody else's problem" as well?<br>> <br>> <br>> _______________________________________________<br>> firefox-dev mailing list<br>> firefox-dev@mozilla.org<br>> https://mail.mozilla.org/listinfo/firefox-dev<br></div> </div></body>
</html>