This should further streamline the UI. As a nice bonus, this would increase each button's hit region. The basic idea of the keyhole could be maintained by simply enlarging the back arrow, I think, although designing the icon so it looks decent may be tricky.

I pushed this to the UX branch for people to play around with it.

So we're trying to further emulate Chrome? What's the purpose of this?

Please don't copy chrome with looks. Fx should look different because it is different.

Chrome doing something neither means that we will do the same nor that we won't do the same. We should do whatever we believe is the right thing to do. The purpose, as I said, is to streamline the UI and increase the buttons' hit regions. Some historical context: One reason why we added the permanent button textures in Firefox 4 was to ensure the icons are visible on glass and personas. Bug 671553 provided an alternative solution for this, which we can leverage here.

I think it's good idea. I like it.

This appears to fix Bug 632207

I don't like it, especially the back button, it feels like it was roughly resized. I think the hit region was big enough before, I don't see the need to increase it.

(In reply to comment #8) > I don't like it, especially the back button, it feels like it was roughly > resized. It *is* only roughly resized in this prototype.

How much bigger is the hit region? how many px?

I really hope hover and pressed effects won't be left in current form.

(In reply to comment #10) > How much bigger is the hit region? how many px? 10 pixels vertically with this patch.

I don't understand how the hit region is 10px bigger with both buttons being 32px tall.

Such details aren't particularly interesting at this early stage, but (unless I read wrongly) it's 24 vs. 34 according to DOM Inspector.

I am fine with the general idea of stripping the buttons back so they have no border until on hover or pressed but I think we would be taking a big step back in terms of the visual experience if we remove the custom styling. I mean, we spent all that work getting from Firefox 3.6's outdated look to Firefox 4 and now we are basically going straight back again. What about this: http://stephenhorlander.com/pages/firefox-future-mockups/button-vs-nobutton-comparison.html The bottom version. I understand in this mockup the hit region would not be very big but things like that can be changed. I just think we should try to avoid Windows' default toolbarbutton style as much as possible because it really isn't very pleasant. Maybe some more mockups are in order?

Try the attached code in userChrome or Stylish. It keeps the large hover region but allows you to style the button however you like. Was just a quick experiment so small icons mode has not been done, as well as a lot of other stuff.

(In reply to comment #15) > I am fine with the general idea of stripping the buttons back so they have > no border until on hover or pressed but I think we would be taking a big > step back in terms of the visual experience if we remove the custom styling. > I mean, we spent all that work getting from Firefox 3.6's outdated look to > Firefox 4 and now we are basically going straight back again. > > What about this: > http://stephenhorlander.com/pages/firefox-future-mockups/button-vs-nobutton- > comparison.html The bottom version. I understand in this mockup the hit > region would not be very big but things like that can be changed. I just > think we should try to avoid Windows' default toolbarbutton style as much as > possible because it really isn't very pleasant. Maybe some more mockups are > in order? This is pretty much I said. :)

I actually like the native hover state. It works equally well on our custom toolbar texture, on glass and on persona backgrounds. I'm not sure what's there to dislike about it. Can you elaborate? It also has the obvious bonus of being native, letting Firefox integrate more with the host OS, which has always been a goal. I'm not a fan of the pressed state, but then you only see that for a split-second in most cases.

1. No CSS transition capability. 2. It is in no way unified with the other platforms. 3. Microsoft's own web browser does not use this native style for its toolbar buttons. 4. It limits the ability to customize the browser. You can't change anything about the button other than the size and glyph, which won't make add-on or theme devs happy. 5. Split menu buttons will not look as clean. We are not able to change the border radius and so we cannot "split" the buttons properly. 6. Why not go the whole way and scrap Aero Glass toolbars and use -moz-dialog colours for the window instead? Use native tabs and text fields, etc. too. Number 6 is what we have been trying to move away from. Just because the toolbar buttons can use system styling doesn't mean they should. Look at other native Windows 7 applications. Wordpad, Paint, Calculator, Messenger, IE9, they all have unique properties in their styling and none of them use system styled elements in the way that generic applications do. They all have something unique. I think we should be trying to differentiate between "native" and "system" styling here because clearly, native Windows applications have their own style, which is unique to that application and third party applications generally just use the generic system styling because it's there and it's easy and it doesn't require any extra coding for the developers. That's just my opinion on where we should be headed.

I just want to add that Windows' file manager do not use system style for back/forward buttons. So why Firefox should ?

(In reply to comment #19) > 1. No CSS transition capability. The glow transition has come to annoy me more than it pleases me. It feels slow, I think not having it is a win. > 2. It is in no way unified with the other platforms. What does this mean? On OS X as well as Linux, we have toolbar buttons that either are native or mimic native ones (bug 672050 fixes this). > 3. Microsoft's own web browser does not use this native style for its > toolbar buttons. Sure, when it comes to their own products, neither Microsoft nor Apple are dogmatic about their platforms. That's sometimes good, sometimes bad. Their behavior is pretty much random, it doesn't really imply any rule for us. We're not tied to IE as much as we're not tied to Chrome. > 4. It limits the ability to customize the browser. You can't change anything > about the button other than the size and glyph, which won't make add-on or > theme devs happy. No, it doesn't limit anything. Add-ons continue to have full access to CSS and can do whatever they want. > 5. Split menu buttons will not look as clean. We are not able to change the > border radius and so we cannot "split" the buttons properly. Yes, our implementation of the split toolbar button appearance is quirky and has been quirky since forever, but we don't ship such buttons anymore. Add-ons do, but that's a tradeoff we made before and I'm willing to make again. > 6. Why not go the whole way and scrap Aero Glass toolbars and use > -moz-dialog colours for the window instead? Use native tabs and text fields, > etc. too. Because -moz-dialog isn't supposed to be used for toolbars on Win 7, native tabs were designed for dialogs rather than tabbed browsers, etc.? > Number 6 is what we have been trying to move away from. No, we have not tried to move away from native theming. We bypass it when there's merit. We do not bypass it because native theming is inherently and universally bad or just because we can. Unfortunately, only point 1 and point 5 tried to really explain why this would be "a big step back in terms of the visual experience", which is what I was actually interested in.

(In reply to comment #21) > > 3. Microsoft's own web browser does not use this native style for its > > toolbar buttons. > > Sure, when it comes to their own products, neither Microsoft nor Apple are > dogmatic about their platforms. That's sometimes good, sometimes bad. Their > behavior is pretty much random, it doesn't really imply any rule for us. > We're not tied to IE as much as we're not tied to Chrome. Ok, you seem you want Firefox to look native, but what does it mean ? What is a native looking application ? Explorer ? The back and forward buttons are closer to the keyhole concept than this one. The toolbar, is not the same, icons are not monochrome, main items in toolbar are text. Paint ? The icons are colorfull and with text, the tabs are not similar, the Paint button is besides tabs etc. Current Firefox 5 looks less native that Firefox 3. If you want to look native with future Firefox, you will have to modify everyhting, not just the toolbar button, is it the goal ? Firefox won't look native if you only modify the toolbar buttons. Like SpewBoy said, there's a difference between looking native and using system toolbar/menu/buttons.

(In reply to comment #22) If you had read my entire comment, you would know that using native widgets isn't a question of all or nothing for me (and sometimes indeed the platform won't provide guidance about what's native). We're not going to use native theming exclusively across the board, and we're not on a crusade against native theming either.

Ok, the main goal is not to look native, it's to steamline the UI. But it shouldn't make the UI look worse. From my point of view the best way is the one that is shown in shorlander's mockup : http://stephenhorlander.com/pages/firefox-future-mockups/button-vs-nobutton-comparison.html The nobutton way looks great, and the UI is streamlined.

Agreed, that mockup looks damn sexi.

(In reply to comment #24) > Ok, the main goal is not to look native, it's to steamline the UI. But it > shouldn't make the UI look worse. As I indicated, I'm willing to discuss the outcome objectively. I'm not interested in a religious debate about native widgets. > From my point of view the best way is the one that is shown in shorlander's > mockup : > http://stephenhorlander.com/pages/firefox-future-mockups/button-vs-nobutton- > comparison.html > The nobutton way looks great, and the UI is streamlined. My view on this is that the back button circle feels lost; it's floating around and exists for no apparent reason. Also, "streamlined" is no on/off feature, it's a continuum. Take the circle away and you get a calmer, more streamlined UI. Terepin: If you have nothing to add, please don't comment. Details in <https://bugzilla.mozilla.org/page.cgi?id=etiquette.html>, point 1.

Why having bigger back button in the first place? Or even bigger back arrow for that matter? Just make all icons in same size (like Opera and Chrome doing it). The result would be: 1. Even more streamlined UI. 2. A few more pixels for for page content.

(In reply to comment #26) > My view on this is that the back button circle feels lost; it's floating > around and exists for no apparent reason. Also, "streamlined" is no on/off > feature, it's a continuum. Take the circle away and you get a calmer, more > streamlined UI. I think the circle exists for the same reasons the back button is bigger that other buttons. Anyway, I'm not against removing the circle around the back button, but I think the hover state should be like stephen's mockup, not like it currently is in the UX builds.

the circle adds a nice touch though. with a tab heavy top and an uber clean toolbar would look imbalanced with no button borders.

My experience with Opera and Chrome (and even with IE9) is the exact opposite.

The circle gives the user a starting point. The most used button in the browser is usually the back button, so it makes sense to make it more pronounced (circular) and easier to hit (larger), I thought that was why the back button has always had a keyhole design (in Windows) from FF3 onwards. I mean, in the current UX build the back button is bigger than any of the other buttons and to me, that has the exact same effect as if we were to round the button, except it looks chunky and awkward and doesn't flow with the other buttons, negating the streamlined effect in my opinion. You seem to be basing most of your arguments on personal preference. I get that the transition annoys you and my points are not what interest you but that doesn't make them invalid. If we were to style the toolbar buttons using CSS, it would make it easier for add-on developers to do what they want with the buttons (take Stratiform's button colouring feature for example). I think we have established that this method isn't native because native Windows apps don't use them in their main toolbars, so what is there going for this method? We get to draw the buttons with CoreUI and it looks more streamlined. The latter is based on opinion, so that isn't really a valid point, seeing as you can get it just as streamlined using custom styling (as I have shown). So how is it worth it? It's not native, it removes the unique keyhole design Firefox is known for (the circular one) and hence loses unity with the Mac platform, it allows for near zero CSS styling, there is no way of doing transitions (which I know some people like, myself included), combined or split buttons cannot be drawn correctly. It just doesn't allow for any breathing room in the design. To me (from a themer's perspective), we are filling a blank canvas with generic, predefined stencils instead of letting the design speak. And just to be clear on this, I am arguing that the system styled toolbar buttons are not "native". Internet Explorer and other apps, including Windows Explorer, define what "native" is. Both of these examples are browsers and so have a direct relation with Firefox and both do NOT use system styled toolbar buttons in their main navigation toolbar. They only ever use system styled toolbar buttons against a solid background, not Aero Glass (hence my -moz-dialog point earlier). Simply put, there is no apparent need for system styled toolbar buttons when the CSS alternative offers so much more.

(In reply to comment #31) > The circle gives the user a starting point. Not sure what this means. > The most used button in the > browser is usually the back button, so it makes sense to make it more > pronounced (circular) and easier to hit (larger), I thought that was why the > back button has always had a keyhole design (in Windows) from FF3 onwards. I > mean, in the current UX build the back button is bigger than any of the > other buttons and to me, that has the exact same effect as if we were to > round the button, All true, except that the circle doesn't directly make the back button larger, at also forces all other buttons to be smaller :( > except it looks chunky and awkward and doesn't flow with > the other buttons, negating the streamlined effect in my opinion. Yes, I'm only resizing a smaller icon to some random larger size. As said in comment 0, creating a proper icon for this is tricky. > You seem to be basing most of your arguments on personal preference. I get > that the transition annoys you and my points are not what interest you but > that doesn't make them invalid. Sure, this is all very subjective. (Yet, we should try to be as objective as possible.) All I was saying is that "transitions" isn't an end in itself. > If we were to style the toolbar buttons using CSS, it would make it easier > for add-on developers to do what they want with the buttons (take > Stratiform's button colouring feature for example). As I said, this argument is bogus. Firefox is not committed to shipping boilerplate code for Stratiform. Stratiform can set all the styles it wants. > I think we have established that this method isn't native because native > Windows apps don't use them in their main toolbars, so what is there going > for this method? Native apps like all other apps may depart from it one way or another, and so may we when we need to, but native theming still provides the directive. > We get to draw the buttons with CoreUI and it looks more > streamlined. We want to draw toolbar buttons natively on OS X because this gives us native look without the theme trying to serve various different OS X versions. > The latter is based on opinion, so that isn't really a valid > point, seeing as you can get it just as streamlined using custom styling (as > I have shown). When it's "just as streamlined", we'll use native theming, since this is the default. > And just to be clear on this, I am arguing that the system styled toolbar > buttons are not "native". Internet Explorer and other apps, including > Windows Explorer, define what "native" is. Both of these examples are > browsers and so have a direct relation with Firefox and both do NOT use > system styled toolbar buttons in their main navigation toolbar. We're not integrating with IE, we're replacing it. What IE defines or doesn't define is moot here. Windows Explorer is an interesting case. It seems to use native toolbar buttons on its toolbar, although it could be slightly modified. It sure looks close. > They only > ever use system styled toolbar buttons against a solid background, not Aero > Glass (hence my -moz-dialog point earlier). That may be true, but then buttons on glass isn't our default setup. > Simply put, there is no apparent need for system styled toolbar buttons when > the CSS alternative offers so much more. Ok, you really like CSS. Noted.

I just want the density to match in as much areas as possible. If the main toolbar is uber clean and you have tons of tabs open it starts to look funny. If we keep the current button borders it evens out the density. This is easier on people's eyes as well.

If the only problem with stephen's mockup is the circle around the back button, why this patch doesn't use it's hover state ?

To heck with this cat fight! Lets just use Ribbon's styling. We are already using it's toolbar background color, so why not use toolbar buttons styling as well? To me it's next logical step.

Minor adjustments. Note that it's still a prototype and I'm cheaply resizing the back arrow.

Comment on attachment 548182 [details] [diff] [review] prototype 2 this is now on the UX branch, by the way

(In reply to comment #37) > Comment on attachment 548182 [details] [diff] [review] [review] > prototype 2 > > this is now on the UX branch, by the way Thanks! You pushed it faster than I could download it and apply it to my build :) I will have some feedback tomorrow.

This look really bad. I agree with Spewboy. The back button is the most use in the browser. Firefox 2 have this button system style, you done a lot work to have big round back button for Firefox 3, and now you straightly go back. Why? To streamline the UI? No, this make Firefox UI become worse. Icon become white when you put in a glass background is a great ideal, but why you have to remove the custom button styling in both small icon mode and normal mode? Can't we have a white icon with custom button styling when put tabs on bottom? Chrome UI looks OK because is really simple and beautiful, Opera looks good too because the very smooth color scheme, Firefox mock-up is the best, it's really awesome, but you never make the Firefox UI looks exactly like the mock-up. You use the system button styling for just 10px more region. Have you try this bug on a Windows Classic theme? When you style the back button as a big circle with an arrow button, user will understand that it's the back button, you must to click that circle to go back the pages that you visited, not clicking near the back button. If you want to grain the back button's region, just move it to the edge of the nav-bar, that's enough. This bug looks good on Windows XP and Windows Classic theme but not in Windows Aero theme (especially Windows 7's color scheme), because the custom button style is not suitable for those theme. This bug should be applied for Windows Classic theme only. Current Aurora builds looks better then Nightly and UX builds. Please undo Bug 571454, restyle the custom button appearance for normal mode and small icon mode, move the back button nearer to the edge, delete the drop shadow, restyle the glowing hover state, adjust the color scheme to mach the mock-up, that will make Firefox better. If this bug apply on the release channel, Firefox will loose user, because the first thing that got in to user's eyes is the User Interface, if the speed is OK but the User Interface isn't good, user would rather switch to another browser, user not only want a fast browser but also a good looking browser.

I agree that there should be a bug to improve the native button appearance on Windows Vista/7 before landing a change like this.

You can't improve the native button appearance. It is what it is. The way in which it is being implemented in the current UX build isn't even native. Yeah, I get that tabs on bottom isn't the default setup but it is an option, and all you seem to want to do is overlook it. It is not native to put a system styled toolbar button against Aero Glass. There is no place in Windows where this is the case. The navigation (or lacking that, the main) toolbar is ALWAYS Aero Glass OR ribbon, and in both cases, system styling is never used. Live Messenger and Live Mail may be the only exceptions (although neither has a "main" or "navigation" toolbar). You are yet to convince me that we need system styled buttons when all evidence shows that they shouldn't belong and all we are doing is making compromises to use it in the first place. I like CSS, you like CoreUI (or whatever you want to call it). That doesn't change the fact that CSS is superior for Firefox's needs. No need to make the browser uglier and less controllable just so it can use CoreUI. No one is going to care about that because it isn't needed and it isn't relevant to them. All they care about is that their browser looks unique so they can tell it apart from the others, that it is in some way unified across platforms and that it fits into the operating system. Using system styled buttons accomplishes none of these in Windows 7. You may think it fits in but I know a lot of people who think otherwise.

(In reply to comment #41) > It is not native to put a > system styled toolbar button against Aero Glass. There is no place in > Windows where this is the case. Microsoft certainly does use system styled button against Aero Glass. Look at the Taskbar. Look at the "shut down" menubutton in the Start menu. Actually, look at all of the items in the right pane of the Start menu. It's not great and even Microsoft had to resort to a non-standard double-opacity glass for that to work at all, but it's certainly there. I realize that you all are attached to a non-standard UI mode (tabs on bottom) and that does pose some additional challenges but I think it would be wrong to let a mode that's used by (I'll wager) a no more than single digit percentage minority get in the way of building the best possible experience for our users who are on the default configuration. That's probably not going to be a satisfactory answer if you prefer the non-standard toolbar layout, but sometimes it simply becomes too difficult (or even impossible) to maintain two UI modes with equal usability.

(In reply to comment #42) > I realize that you all are attached to a non-standard UI mode (tabs on > bottom) and that does pose some additional challenges but I think it would > be wrong to let a mode that's used by (I'll wager) a no more than single > digit percentage minority get in the way of building the best possible > experience for our users who are on the default configuration. No, I'm using tabs on top and I think that stephen's style should be used for the hover state of the buttons on the navigation bar. Dão, currently the hover state of the buttons is heigher than the navigation. Will you change that (except for the back button of course) ?

but really what's wrong with the native controls?

(In reply to comment #44) > but really what's wrong with the native controls? 1st, it's not native, it's system. 2nd, native applications are wiser at using system controls, look at Windows Explorer, it doesn't use a system button for back/forward buttons. 3rd, native applications do not use this style over a ribbon background, look at paint or wordpad on Windows 7. This patch use toolbar button style over a ribbon background style and it's not nice, nor feel native.

(In reply to comment #43) > Dão, currently the hover state of the buttons is heigher than the > navigation. Will you change that (except for the back button of course) ? It seems that this would be a step back in terms of ergonomics, which I think we should avoid.

Bugspam What's this bug for, to increase each button's hit region, well I have to say it is VERY RIDICULOUS and STUPID. Users care about how the browser looks, each browser has its own User Experience designer team, each designer team has their own style, be native, don't be dependance on the OS system please, users don't care about the "each button's hit region". A big round back button? Oh, we know that circle is the back button, we have enough intelligent to understand that to go back one page, you must click somewhere IN the button, NOT somewhere Near the button. We don't care! We just care how beautiful is it, how native is it. The button style became worse in the recent Nightly builds, I'm sure that the current Aurora's one is really better. Most of the comment says it is really UGLY, you thinks its pretty, well right click on the toolbars -> customize -> restore default set -> done, Hide menu bar, hide add-ons bar and other toolbar installed by thirty party, keep the nav-bar, tabbar, tab on top, now compare your current looks with this mock-up: http://stephenhorlander.com/pages/firefox-future-mockups/button-vs-nobutton-comparison.html Well, which one do you like to see in Firefox. I love UX build, it has many new experiment UI, but this is a major mistake of you to pushed this bug to the UX builds, PLEASE BACK-OUT IT! Everyone who thinks this bug is UGLY, RIDICULOUS and NOT NECESSARY please put "Bugspam" before your comment, for those who thinks that this patch look pretty just say "Oh this patch looks pretty, I like it". We will have a vote.

Looking objectively to this bug is impossible. Everyone in here is clearly stating their preferences including Dao. What I don't understand is why do you need to fix something that is not broken. The current style looks pretty modern and I am sure a lot of users have grown to like it. The current button style with the back/forward button is like a trademark, something by which I've come to recognize and sympathize with this browser. I like what you did to the small icons mode. It does look very clean and minimalist but I don't think that should be true for the default version as well. With this bug you are stripping away Firefox's personality. This is the only thing that has been consistent for quite a few releases. Apart from the Firefox button, what are the differences between Firefox and chrome. You are stating you are not trying to copy chrome, i used to believe that. But by now i think it's plain as day that Firefox is fully trying to mimic chrome in every possible way - including the same features, achieving the same performance and now even styling it to look completely like it. You've got some good points but overall this is a step backward. I don't think this is native, it just looks like someone forgot to style the bloody thing before releasing it... What I would like to see is the opinion of a larger group of users before making such a radical change. Most of the people here disagree with you but I don't think that's gonna stop you. It's a shame really to see you guys dwindling with a bug like this instead of focusing on bugs like Bug 455694 or trying to create something innovative. Instead of you go copying the interface of another browser, I don't care who had the mockup first, and that about not implementing it because of Aero is bollocks. If you had really thought this was the correct style at the time you would have found a way to fix it, I'm sure.

(In reply to comment #42) > Microsoft certainly does use system styled button against Aero Glass. Look > at the Taskbar. Look at the "shut down" menubutton in the Start menu. > Actually, look at all of the items in the right pane of the Start menu. It's > not great and even Microsoft had to resort to a non-standard double-opacity > glass for that to work at all, but it's certainly there. > > I realize that you all are attached to a non-standard UI mode (tabs on > bottom) and that does pose some additional challenges but I think it would > be wrong to let a mode that's used by (I'll wager) a no more than single > digit percentage minority get in the way of building the best possible > experience for our users who are on the default configuration. Every UI element you just listed has nothing to do with toolbar buttons. The task bar is not a toolbar and doesn't use system toolbar button styling in the slightest - completely different in fact :/. The start menu shut down button is not a toolbar button and has borders when not hovered on (and therefore is not even styled like a toolbar button). The start menu text are not toolbar buttons and their styling includes an extra white border and no pressed state, so they do not use system styling. I use tabs on top for your information, and you are missing my point. The main / navigation toolbar NEVER uses system styled buttons, regardless of the background (talking Windows 7 here, not XP). The tabs on top mode is more like a ribbon interface and would therefore use it's own unique button style, like in any ribbon app. It is in no way correct to use system toolbar button styling for Firefox's nav bar. Sure, remove the borders and increase the hit region but do not use system styled buttons. We don't have a NEED to, the majority of people don't WANT it and it means we have to COMPROMISE. Everyone's going to question why we went from system styling in FF3 to CSS styling in FF4 after the UX team spent so long making fantastic looking mockups that the majority of people loved, only to go back to our old ways again. It just doesn't make any sense. You say "what's wrong with native controls?", when you should be asking yourself "what's wrong with CSS controls and would native controls be a better alternative?". I hope you are using the term "native" very loosely here because it is where you use the styling that determines whether or not it is native, not just the style itself, as I have tried to explain in many occasions now. I'd replace "native" with "system".

(In reply to comment #48) > Looking objectively to this bug is impossible. Everyone in here is clearly > stating their preferences including Dao. > > What I don't understand is why do you need to fix something that is not > broken. The current style looks pretty modern and I am sure a lot of users > have grown to like it. > The current button style with the back/forward button is like a trademark, > something by which I've come to recognize and sympathize with this browser. > I like what you did to the small icons mode. > It does look very clean and minimalist but I don't think that should be true > for the default version as well. With this bug you are stripping away > Firefox's personality. This is the only thing that has been consistent for > quite a few releases. Apart from the Firefox button, what are the > differences between Firefox and chrome. You are stating you are not trying > to copy chrome, i used to believe that. But by now i think it's plain as day > that Firefox is fully trying to mimic chrome in every possible way - > including the same features, achieving the same performance and now even > styling it to look completely like it. > You've got some good points but overall this is a step backward. I don't > think this is native, it just looks like someone forgot to style the bloody > thing before releasing it... > What I would like to see is the opinion of a larger group of users before > making such a radical change. Most of the people here disagree with you but > I don't think that's gonna stop you. > It's a shame really to see you guys dwindling with a bug like this instead > of focusing on bugs like Bug 455694 or trying to create something > innovative. Instead of you go copying the interface of another browser, I > don't care who had the mockup first, and that about not implementing it > because of Aero is bollocks. If you had really thought this was the correct > style at the time you would have found a way to fix it, I'm sure. I agree with this statement. I love the look of FF5 and current non UX builds. It's a trademark. Specially the "keyhole" buttons for back and forward. Kind of an icon for Firefox. If this was removed you lose the identity and trademark and then someone else may copy that off of you and it will be a mess. I was loose when I was referring to native as well. I also want to add "what is wrong with system" controls? based on what the OS is running. Here's the issue. We are having 5 disttinct OS looks now: winxp (luna) winvists/7/2008 (aero) windows 8 (metro) macosx (aqua) Linux (GNOME/KDE) and I think it would be a mess to get system looks for all. If we force one look on the entire spectrum like chrome does it will look goofy in the rest. just like having, for example, a metro syled one in OSX would look goofy and the other way around. we need to have an interface that would look good in all those, however that would be a Frankenstein freak of nature. So we need to come up with something. before we just had aero and osx and those two would interchange well. the intro of metro and the chrome style UI are making this harder for designers.

> It just doesn't make any sense. You say "what's wrong with native > controls?", when you should be asking yourself "what's wrong with CSS > controls and would native controls be a better alternative?". This will probably surprise you: I picked native toolbar buttons because I consider them a better choice than what we have, for various Windows versions and themes, including aero glass, and for the direction this bug is heading. (And you may disagree with that direction. That's a separate question.) It's a perfectly sensible question to ask "what's wrong with this control?", regardless of how it's implemented, but except for transitions and split buttons, all you say boils down to "It's native, don't use native!" This is ideological and not the kind of argument I'm willing to accept.

(In reply to comment #46) > (In reply to comment #43) > > Dão, currently the hover state of the buttons is heigher than the > > navigation. Will you change that (except for the back button of course) ? > > It seems that this would be a step back in terms of ergonomics, which I > think we should avoid. Step back from what ? Firefox 5 ? The buttons (except the back button) have the same height as the navigation bar, I don't see the step back here.

(In reply to comment #52) > (In reply to comment #46) > > (In reply to comment #43) > > > Dão, currently the hover state of the buttons is heigher than the > > > navigation. Will you change that (except for the back button of course) ? > > > > It seems that this would be a step back in terms of ergonomics, which I > > think we should avoid. > > Step back from what ? Firefox 5 ? From the current prototype. And yes, I think Firefox 5 isn't ideal when it comes to ergonomics. I'd like to improve this.

I think FF5 is very ergonomic. I can hit the buttons just fine from 10 feet away on my HTPC. The current UI is very usable even on an HTPC though.

(In reply to comment #54) > I think FF5 is very ergonomic. That's cool. I think we can make it better.

I've been trying to tell you over and over again, what you define as native, I don't. In my mind there are two styles; system and native. System is found in generic applications and in unimportant toolbars in some native Windows apps. It has a few system-wide uses but it is not used in any applications how you want to use it in Firefox. Native is found in applications that come with Windows. It is not generic, like system styling. For native styling, see Calculator, Windows Explorer, Internet Explorer, Wordpad, Office, Paint, the list goes on. None of these native Windows 7 applications use the toolbar button style you are employing. The toolbar button style you are employing is a generic system one. It is what applications use when the developers can't be bothered trying to make their own applications native. Native does not have a generic style. Each native application is a bit different. Classic = Unstyled (bare minimum). System = Generic OS styling used by generic programs that are not designed to be visually appealing but are integrated. Native = Unique styling that follows certain colour schemes and guidelines. Integrated into Windows and visually unique and appealing. Varies from app to app. This is only true for Windows 7 and Vista. XP uses just classic and system styling, 2000 uses classic. And that's how I see it. Three clear methods for styling the UI. You want to use the second one, while I want to use the third one. Advantages of native over system styling include the ability to keep our keyhole design, more control over the buttons, so we can mess around with private browsing colouring, border radii, animations and transitions, etc. System styling has the advantage of being easier to implement but that's not worth it in my opinion, as is the opinion of most users who have posted their opinions here.

(In reply to comment #56) > I've been trying to tell you over and over again, what you define as native, Please, feel free to think "system" whenever I say "native" if you think this makes more sense. (In reply to comment #53) > (In reply to comment #52) > > (In reply to comment #46) > > > (In reply to comment #43) > > > > Dão, currently the hover state of the buttons is heigher than the > > > > navigation. Will you change that (except for the back button of course) ? > > > > > > It seems that this would be a step back in terms of ergonomics, which I > > > think we should avoid. > > > > Step back from what ? Firefox 5 ? > > From the current prototype. Actually, I think it would be an ergonomics regression even from Firefox 5. A small-and-invisible target area seems worse than a small-but-visible target area...

http://i.imgur.com/lTia9.png I made a comparison between what I define as "native" and "system" If you want to see my windows explorer interface let me know. (please note my FF is styled as close as possible to match my windows explorer theme and experience)

I'd be comparing something like Wordpad or IE9 to OpenOffice instead of Firefox, because then we can say it is a native app and therefore a legit native style (since some people think Firefox currently is not native). The general idea is the same though.

IE9 is not installed on this system so I cannot demonstrate that in my image.

Why these NEED to be changed anyway? Did users complain about hard-to-hit buttons or something?

I don't know. I think the buttons are fine. Even using a wireless mouse on my HTPC where the screen is approx 10ft from the couch I sit on. I can hit the buttons just fine. My TV's res is 1366x768 and that's what the HTPC is hooked up to. No mods needed to be usable from 10ft away.

Very few bigger theme changes happened as responses to user complaint. Ergonomics, just like being streamlined, isn't something you just have or lack. It's again a continuum.

Then why can we just follow Stephen's mockup?

Did you follow this bug?

1. Some Windows users use custom themes, which looks NOT GOOD with what you've done here, Gottwald! 2. It's just FUGLY AS HELL. Revert it to what it was before, step away and don't touch anymore. 3. Spewboy is a real MAN, awesome designer, he is an author of such epic addons as Stratiform: https://addons.mozilla.org/en-US/firefox/addon/stratiform/ , Strata40: https://addons.mozilla.org/en-US/firefox/addon/strata40-14284/ and StrataBuddy. Listen to his opinion, he knows what he is talking about.

http://i.imgur.com/oDKhi.png Here is comparison. As you can see, NONE of the available browsers for Windows use native buttons, except Dao's "Frankensein's monster" with removed back/forward buttons style. That's a HUGE regression, I already showed latest UX build to my friends and all the was like "WTF?!! Who did that, I'll kill him!". I don't think you need negative reaction.

(In reply to comment #67) > "WTF?!! Who did that, I'll kill him!". Hi. Here's my address: Dao Gottwald St. Petersburger Straße 26 01069 Dresden Germany

(In reply to comment #53) > (In reply to comment #52) > > (In reply to comment #46) > > > (In reply to comment #43) > > > > Dão, currently the hover state of the buttons is heigher than the > > > > navigation. Will you change that (except for the back button of course) ? > > > > > > It seems that this would be a step back in terms of ergonomics, which I > > > think we should avoid. > > > > Step back from what ? Firefox 5 ? > > From the current prototype. And yes, I think Firefox 5 isn't ideal when it > comes to ergonomics. I'd like to improve this. What are the toughts of Alex Limi, for example ? Or Stephen Horlander.

I won't tell anyone your address. You should understand, that it's a very large step backward, whatever you said about ergonomic. At last, ergonomic is not on the first, neither on the second place. You should think about speed and UI. Make really modern UI, Stephen Horlander already made everything before you, you just got to put ready code into browser. Please don't ruin my favorite browser.

(In reply to comment #69) > What are the toughts of Alex Limi, for example ? Or Stephen Horlander. See comment 38.

This may be great on paper, but looks ugly as hell in practice. When I first saw it, I didn't about this bug yet and I thought it's a bug. Unfortunately, it was not. The issue here is you are trying to mix modern element (Ribbon's background) with legacy one (hover effect). That looks horribly and inconsistent. Period. This bug would be actual in pre-Firefox 4 era, but not now. As I suggested earlier today, use Ribbon's hover effect.

Probably the funniest bug I've read on here. What is it about the word native that generates such hilarity on bugzilla? There's been some interesting opinions put forward, but ultimately I feel this isn't a question of ergonomics. It's about a much bigger picture. Can Firefox afford to sacrifice it's visual identity/brand further? You take for example that every time the Daily Show shows something off the web, it uses Firefox and it's instantly recognisable as such. Of course, we have Personas, but so does Chrome now, we need to remain identifiable at a glance and the protection of brand value should supersede that of ergonomics.

(In reply to comment #73) > Probably the funniest bug I've read on here. What is it about the word > native that generates such hilarity on bugzilla? > > There's been some interesting opinions put forward, but ultimately I feel > this isn't a question of ergonomics. It's about a much bigger picture. Can > Firefox afford to sacrifice it's visual identity/brand further? You take for > example that every time the Daily Show shows something off the web, it uses > Firefox and it's instantly recognisable as such. Of course, we have > Personas, but so does Chrome now, we need to remain identifiable at a glance > and the protection of brand value should supersede that of ergonomics. Very much agreed. very much so.

(In reply to comment #73) > There's been some interesting opinions put forward, but ultimately I feel > this isn't a question of ergonomics. It's about a much bigger picture. Can > Firefox afford to sacrifice it's visual identity/brand further? I don't think it makes a lot of sense to consider the non-transient button style as part of the brand, but you may have a different view -- I'll say, then, yes, we should sacrifice this part of our brand. We should focus on building the best user interface possible. (And of course this includes ergonomics. You can't seriously make this a secondary question when rating a UI.) If we focus on being different for the sake of being different and lock up random parts of our UI to serve some dubious identity or brand idea, we'll build a Firefox that's rightfully perceived as being somewhat weird and quirky while our competitors do what we should have been doing.

But how is that button change more ergonomic? it's just a style change. How is having the keyhole less ergonomic then the simple arrows?

(In reply to comment #76) > But how is that button change more ergonomic? it's just a style change. > > How is having the keyhole less ergonomic then the simple arrows? I'll repeat it because I can see how it got lost between the rants. Removing the permanent button border (which we want in order to streamline the user interface) while keeping the current button size makes it harder to hit these buttons. It's great that some random guy with a laser mouse doesn't see this as a problem, but different people have different needs and different input devices have different constraints (think touch screens). Stretching buttons across the whole toolbar, which by the way is the platform standard on Windows, makes it super easy to hit the buttons. The keyhole in the sense of a more prominent back button is in fact an ergonomic improvement. It's the most used button. Ergonomics is why we introduced the keyhole. The keyhole in the sense of a circle around the back button is a problem because a circle doesn't really go with rectangles of the same height. The circle therefore forces the other buttons to be smaller (-> worse ergonomics, see above), which is ironic, as this is not at all the original intention of having the keyhole. In addition to this, the single circle as seen in the mockups just looks lost and weird to me, but I understand that people see this as a win for our identity or the brand.

But people will figure the hit region if they are smart enough. I have no problem using it with a wonky wireless mouse from 10 feet away from an HTPC with a 36 in HDTV. This is a tricky scenario and it still works great. Even two other people that have bad eyesight in my house can work it fine as well on the HTPC/HDTV and on thier PCs. This is a decent of a demonstration that the current incarnation is fine.

(In reply to comment #78) > But people will figure the hit region if they are smart enough. Good software generally tries to be intuitive (i.e. avoid relying on people figuring things out). > Even two other people that have bad eyesight in my house can work it fine as > well on the HTPC/HDTV and on thier PCs. This is a decent of a demonstration > that the current incarnation is fine. All you're really saying here is that Firefox is somewhat usable. I know that. We did a decent job with all previous versions of Firefox. There are very few people that can't handle Firefox at all. I'm saying, though, it can still be made more user-friendly.

but is it worth loosing your identity over?

See comment 75.

Is there no other way to achieve this that wouldn't completely revamp the interface? Simply enlarging the regions? Maybe create an additional style/theme shipped with firefox to which the user with such problems could switch to? Like windows that comes with multiple themes and offers the ability to enlarge the fonts or icons if the user has this kind of problems. Perhaps you could provide three options the default mode, small icons mode and the one created by this bug. By doing this you also score another point in customizability which is already one of the main firefox's strong fields. This way everyone is satisfied. Sounds reasonable enough to me.

Jake, Your comment is excellent. Great idea! ;-)

(In reply to comment #75) > (In reply to comment #73) > > There's been some interesting opinions put forward, but ultimately I feel > > this isn't a question of ergonomics. It's about a much bigger picture. Can > > Firefox afford to sacrifice it's visual identity/brand further? > > I don't think it makes a lot of sense to consider the non-transient button > style as part of the brand, but you may have a different view -- I'll say, > then, yes, we should sacrifice this part of our brand. We should focus on > building the best user interface possible. (And of course this includes > ergonomics. You can't seriously make this a secondary question when rating a > UI.) If we focus on being different for the sake of being different and lock > up random parts of our UI to serve some dubious identity or brand idea, > we'll build a Firefox that's rightfully perceived as being somewhat weird > and quirky while our competitors do what we should have been doing. That's an interesting view to take, but taken in the context of other comments within this bug, this is largely based on a desire to be ahead of the curve in a terms of browser UX. Is it correct to do such a thing as have what you perceive to be more touch-friendly buttons just to achieve that honour? This is like where you read about an idea for Mobile that works wonders on Tablets but fails completely on phones in their smaller workspace. It's jumping the gun. Until the point that there are a significant number of touch devices with what's considered the desktop UI, there is no need to cater for those or champion things in their honour over 'legacy devices' (non-touchscreen laptops and PCs). And even then, there are more effective design choices that can be made and are being challenged i.e. conversations like Chromeless Browsing and whether to go with a hover approach or to simply adopt the mobile route of draggable panels. Personally I favour the latter, that said, at that point, you're talking about effective huge changes to support new markets and concepts on more than a superficial level ala the achievements of a more minor (in scale) bug such as this.

(In reply to comment #82) > Is there no other way to achieve this that wouldn't completely revamp the > interface? Simply enlarging the regions? Maybe create an additional > style/theme shipped with firefox to which the user with such problems could > switch to? Opt-in accessibility and usability seems like a rather poor solution. We know that customizing something is more a power-user thing. Most users will just try to deal with what we ship as the default. (In reply to comment #84) Touch screens for desktops was just an extreme case. Another example would be notebook touch pads or the fact that many casual users just aren't very good with the mouse (my observation).

(In reply to comment #77) > Removing the permanent button border (which we want in order to streamline > the user interface) while keeping the current button size makes it harder to > hit these buttons. I don't see how is it harder since there's a hover effect > It's great that some random guy with a laser mouse > doesn't see this as a problem, but different people have different needs and > different input devices have different constraints (think touch screens). Correct me If I'm wrong, but if you have a touchscreen you don't fire hover events, even if you fire an hover event, you can barely see the hover/touch effect, so I don't see the point in making higher hover style in case of touchscreens. > Stretching buttons across the whole toolbar, which by the way is the > platform standard on Windows, makes it super easy to hit the buttons. Do you have examples where the buttons are higher than a text/combo box ? Windows explorer ? no Wordpad ? no Outlook, Word, Excel 2010 ? no IE 9 ? the only button bigger than the navigation bar is the back button, like in Firefox 5 I think there's no need to compare Firefox to a standard Windows application since I don't see a browser on windows that looks like a native/standard application. Most Windows application do not have buttons bigger than other, so I don't see the point of comparing to other (even browsers) applications. Again, Why did you choose to have a system toolbar button over a ribbon background ? Why didn't you use the ribbon button style ? Or why didn't you use the system toolbar background ? It feels badly mixed and out of place.

(In reply to comment #85) > Touch screens for desktops was just an extreme case. Another example would > be notebook touch pads or the fact that many casual users just aren't very > good with the mouse (my observation). Can't we just cheat ? The hit region would be different from the "button" area.

(In reply to comment #86) > (In reply to comment #77) > > Removing the permanent button border (which we want in order to streamline > > the user interface) while keeping the current button size makes it harder to > > hit these buttons. > I don't see how is it harder since there's a hover effect The permanent border provides guidance, whereas the hover effect only provides confirmation once you've reached the target area. > > It's great that some random guy with a laser mouse > > doesn't see this as a problem, but different people have different needs and > > different input devices have different constraints (think touch screens). > Correct me If I'm wrong, but if you have a touchscreen you don't fire hover > events Exactly! So you don't even get the confirmation there, thus we want larger hit regions. (In reply to comment #87) > > Touch screens for desktops was just an extreme case. Another example would > > be notebook touch pads or the fact that many casual users just aren't very > > good with the mouse (my observation). > Can't we just cheat ? The hit region would be different from the "button" > area. You can't just cheat the system -- you're also cheating users at that point. Users would still be tempted to hit the smaller region.

(In reply to comment #86) > > Stretching buttons across the whole toolbar, which by the way is the > > platform standard on Windows, makes it super easy to hit the buttons. > Do you have examples where the buttons are higher than a text/combo box ? > Windows explorer ? no Half-serious response: I can customize Windows Explorer to make it so. Counter question: Do you have examples where the buttons are significantly smaller than their parent toolbars?

(In reply to comment #89) > (In reply to comment #86) > > > Stretching buttons across the whole toolbar, which by the way is the > > > platform standard on Windows, makes it super easy to hit the buttons. > > Do you have examples where the buttons are higher than a text/combo box ? > > Windows explorer ? no > > Half-serious response: I can customize Windows Explorer to make it so. Actually, I don't need to customize it for buttons to be taller than a text box. What I meant is that I'd need to customize it for the buttons to be on one line with the text box.

Thing is the "new" buttons are harder to see with the following theme and visual setup: http://i.imgur.com/yQrUG.png I have my main version of Fx right next to the UX and you can see the arrows are not as visible in the UX version. the main version is more visible with dark themes with glass UI. I don't think that should be ignored!

(In reply to comment #91) > Thing is the "new" buttons are harder to see with the following theme and > visual setup: > http://i.imgur.com/yQrUG.png > > I have my main version of Fx right next to the UX and you can see the arrows > are not as visible in the UX version. > > the main version is more visible with dark themes with glass UI. > > I don't think that should be ignored! Seems like you made a bunch of modifications to Firefox. I'm not really sure what's going on there, but if you were using a dark persona, you should automatically get the white icons.

I know but a lot of people do what I do to get the fullglass look though. That should not be discouraged at all. There are lots who go beyond personas for customization and they should not be overlooked.

(In reply to comment #92) > Seems like you made a bunch of modifications to Firefox. I'm not really sure > what's going on there, but if you were using a dark persona, you should > automatically get the white icons. I believe he is using Stratiform, which is not currently compatible with the nighties (let alone the UX builds as you can imagine). I am happy to increase the hit region and remove the borders, but I still believe that system styling is the wrong choice. We should be looking for something similar to the ribbon buttons. I also believe that the back button should be rounded. In the prototype, the back button is bigger, so the other buttons don't take up the whole toolbar anyway. If we were to simply make this back button round, we would keep our unique keyhole design, but we would lose some of the hit region to the curves. I still think it would be the way to go. I have some time off today so I'll see if I can make a mockup of Firefox with a native ribbon interface.

In this bug's defence, it isn't trying to copy Chrome because Chrome's buttons do not fill all of the available toolbar space, which I believe is the primary goal of this bug. The simple fact of the matter is, if you want the buttons to fill up the entire toolbar to maximise their hit region, you have to remove the borders or the UI will appear cluttered. So removing those borders makes it look like Chrome, but that is not the objective here.

(In reply to comment #93) > I know but a lot of people do what I do to get the fullglass look though. > That should not be discouraged at all. There are lots who go beyond personas > for customization and they should not be overlooked. Your use of "a lot of people" and "lots" are a bit misleading here. I do not think it is really a very large number who go for the "fullglass look". It's certainly not a large portion of the whole of Firefox users. There are probably scores of customizations that are as common or more common than what you've shown here that don't look at all like the fullglass look and would conflict with Firefox's default UI choices in any number of different ways. Optimizing Firefox's default UI to take into account very uncommon customizations is not a recipe for success. If odd customizations just happen to work, great. But I don't think we can really afford to make sure that our UI works with every possible customization and that's essentially what you're asking for. Or are you suggesting we make an exception only for your uncommon customization and let everyone else with different uncommon customizations just deal with it?

(In reply to comment #96) > Optimizing Firefox's default UI to take into account very uncommon > customizations is not a recipe for success. If odd customizations just > happen to work, great. But I don't think we can really afford to make sure > that our UI works with every possible customization and that's essentially > what you're asking for. Or are you suggesting we make an exception only for > your uncommon customization and let everyone else with different uncommon > customizations just deal with it? As I said before, he is using Stratiform, which is not compatible with the UX builds, so the white icons you would normally see are not there. The comparison I believe was supposed to be between the UX build and a stable version, but to compare them he really should be disabling Stratiform.

> I am happy to increase the hit region and remove the borders, but I still > believe that system styling is the wrong choice. We should be looking for > something similar to the ribbon buttons. Maybe. I'm not really familiar with the ribbon UI stuff and have never used such an application regularly. I'm waiting for Stephen's input here.

If I remember correctly, there are also ribbons that are cluttered up with grids of small buttons. The strong hover state probably helps there to not lose track of things. For us I suspect it's overkill.

(In reply to comment #100) > If I remember correctly, there are also ribbons that are cluttered up with > grids of small buttons. The strong hover state probably helps there to not > lose track of things. For us I suspect it's overkill. That's correct. Also, standard ribbon buttons have 4 or 5 pixels of margin around them before they run into the ribbon toolbar borders. That's not the case with Firefox and the lack of margin makes the button hover state even that much more overkill. It's not an appropriate style (though I like the corner radius on the ribbon buttons better ;-)

Define overkill.

At first ưhen I tried Dão's prototypes, I thought this change is really awful, but then when I saw Asa's Attachment 548677 [details], I realized that if you remove the navigation toolbar's custom button appearance, that's OK, but please style the buttons' hover and pressed state. - Back button is the most use button in a browser, it's bigger then the other buttons, that's good, but because it's bigger, different from the others, please style its normal, hover, pressed state, for other buttons just style its hover and press state. (May be like the bottom one of these mock-ups: http://stephenhorlander.com/pages/firefox-future-mockups/button-vs-nobutton-comparison.html You can style the back button squared but must use the normal, hover, pressed state. For me, I preferred a round back button). - Ribbon button style doesn't suitable with Firefox, use another styling and smoother nav-bar color scheme - The current prototype make the back button's icon looks ugly, I think you should style the back icon bigger and different from the forward's one.

(In reply to comment #104) > Define overkill. <http://en.wiktionary.org/wiki/overkill>: (idiomatic) An unnecessary excess of whatever is needed to achieve a goal. The goal in this case is to provide feedback to the user.

That hover effect in---> https://bug673695.bugzilla.mozilla.org/attachment.cgi?id=548677 looks closer to Microsoft IE styling and look and feel rather then Mozilla Firefox look and feel. The thing is stratiform is really popular though. However I did just read some things about the FF8 support on the deviantart page. I think this whole situation is wierd. Perhaps there could be a separate edition of Fx geared for accessibility and can come shipped with assistive add-ons if one is very concerned with that.

I'm the co-developer of Stratiform and I said on dA that we would not be providing FF8 compatibility until it is in beta. It is not feasible to provide support for an interface that changes every day.

(In reply to comment #107) > I think this whole situation is wierd. Perhaps there could be a separate > edition of Fx geared for accessibility and can come shipped with assistive > add-ons if one is very concerned with that. First of all, accessibility is a core feature of Firefox. Firefox is for everyone. The matter in hand is not only about users with disabilities, though. It's rather a question of general usability which more or less affects everyone. (In reply to comment #108) > I'm the co-developer of Stratiform and I said on dA that we would not be > providing FF8 compatibility until it is in beta. It is not feasible to > provide support for an interface that changes every day. The interface should mostly be stable once Firefox 8 is on the Aurora branch.

Ok just wanted to clear up a few things. Thanks.

erm maybe i am late , but i think that current (FF7 and below) implementation does give enough hit region, and looks sleek. Its not broken that it needs a fix... However , stephen's mockups http://stephenhorlander.com/pages/firefox-future-mockups/button-vs-nobutton-comparison.html may streamline it more , without losing the consistency , and maintaining the unique image of Firefox 2011 look . If we see nativity of the application , then by the prototypes posted here, its nowhere native to windows 7 UI,where the buttons are round with custom borders. Also making the back button so large , we will have even smaller icons with bigger hit region , granted it is a plus according to accessibility , but in terms of consistency , its a flaw. Small icons having large borders will actually make them look fat and not sleek (excuse my layman terminology). In short , i dont see the point in removing custom borders in LARGE icon mode, for the back button has different size , which ruins consistency ... If we consider chrome's implementation , the sizes are even , so in opera , safari. In IE , custom borders are used , hence the size of back button being different , looks sleek. There must be a point that stopped three major browser vendors from going in this direction

as far as stephen's mockups are concerned , have at look at these , they maintain the consistency and yet try to look more sleek. http://www.stephenhorlander.com/pages/firefox-4-ui-evolution-slideshow/slideshow.html#105

This patch broke some custom CSS code I was using. I'm trying to figure out how to change the border radius of the toolbar buttons when they are in hover mode. Can someone help me out? Thanks.

(In reply to comment #114) > This patch broke some custom CSS code I was using. > > I'm trying to figure out how to change the border radius of the toolbar > buttons when they are in hover mode. Can someone help me out? Thanks. You can't with "native" buttons.

(In reply to comment #115) > You can't with "native" buttons. Wow, can't say I saw that coming. Why is that? =/

FYI, for the next prototype stage I plan to experiment with something based on http://people.mozilla.com/~shorlander/ux-presentation/01-Firefox-Australis-%28Windows%29-%28Fullscreen%29.jpg (but not just for fullscreen mode), so you get the beloved round back button without all the suboptimal implications it currently has.

(In reply to comment #116) > (In reply to comment #115) > > You can't with "native" buttons. > > Wow, can't say I saw that coming. Why is that? =/ Because they are native, they are images, not made of CSS. You need to apply CSS style to toolbar buttons.

(In reply to comment #117) > FYI, for the next prototype stage I plan to experiment with something based > on > http://people.mozilla.com/~shorlander/ux-presentation/01-Firefox-Australis- > %28Windows%29-%28Fullscreen%29.jpg (but not just for fullscreen mode), so > you get the beloved round back button without all the suboptimal > implications it currently has. Better this: http://people.mozilla.com/~shorlander/ux-presentation/01-Firefox-Australis-%28Windows%29.jpg Also... Looks GORGEOUS! *must... not... fap*

(In reply to comment #118) > Because they are native, they are images, not made of CSS. You need to apply > CSS style to toolbar buttons. Hmm ok. But surely the border radius that appears when you hover over the buttons isn't part of the image and hence can be manipulated by CSS? Because I can and am drawing custom border-styles and box-shadows around them right now (except that they appear permanently and not only when you hover the buttons), this seems to indicate that the "original" border itself must be manipulable somehow.

That "autralis" style looks very different. Not sure if I like it. The top part looks too distracting. It doesn't look very Firefoxy. The rounded tabs look too big becuase of the excessive curves. The curve tabs bring too much attention to the top of the browser and less of the focus is on the content. We need to draw more attention to the site content, not the browser chrome.

(In reply to comment #121) > We need to draw more attention to the site content, not the browser chrome. That's a good principle -- it rightly motivates getting rid of unnecessary visual complexity (e.g. this bug). As testers / designers / developers, we constantly look at the chrome, but end users aren't really interested in this; they want to use the Web and efficiently interact with the browser's user interface when they need to, not fall in love with the browser's bells and whistles. That said, please don't use this bug for discussing random parts of the posted mockups. Use the newsgroups or mozillazine for this.

One issue with Stephen's sexy mockups featuring the conditional forward button is that it promotes the jumping forwards and backwards of the URL start point.

(In reply to comment #123) > One issue with Stephen's sexy mockups [...] What did I just say? :( Please don't discuss this here.

(In reply to comment #122)As testers / designers / developers, we > constantly look at the chrome, but end users aren't really interested in > this; they want to use the Web and efficiently interact with the browser's > user interface when they need to, not fall in love with the browser's bells > and whistles. Bug 661075 disagrees with you. I don't have a fancy technical argument to throw out here, but I know enough to tell that this patch looks horrendous. At least please force toolbar buttons to be no taller than the URL bar (try placing the Stylish button on the toolbar to see what I mean). Still, I understand that developer ego has been steadily overtaking the practice of listening to users for some time now, so...

(In reply to comment #125) > (In reply to comment #122)As testers / designers / developers, we > > constantly look at the chrome, but end users aren't really interested in > > this; they want to use the Web and efficiently interact with the browser's > > user interface when they need to, not fall in love with the browser's bells > > and whistles. > > Bug 661075 disagrees with you. It doesn't. In fact, I agree with that bug. I very carefully wrote "unnecessary visual complexity" and "bells and whistles", none of which bug 661075 wants to add. It's mostly about language or some candy here and there /that doesn't put weight on the primary UI/. Borders around buttons may establish an emotional connection between you and Firefox, but it doesn't do this for end users. Don't mistake me disagreeing with you with me ignoring users. You're not representative for all Firefox users.

(In reply to comment #126) > You're not representative for all Firefox > users. I guess that excuse never fails.

It's pretty effective, yes, since you having a bugzilla account and posting here already singles you out :)

(In reply to comment #128) > It's pretty effective, yes, since you having a bugzilla account and posting > here already singles you out :) Yep, I guess the whole point of registering to provide feedback is so that the feedback can be ignored. And having ignored the feedback you DO receive, assume that the users who don't bother to go out of their way to provide feedback support your design decisions. Thanks for letting us know.

(In reply to comment #129) > (In reply to comment #128) > > It's pretty effective, yes, since you having a bugzilla account and posting > > here already singles you out :) > > Yep, I guess the whole point of registering to provide feedback is so that > the feedback can be ignored. I'm not ignoring it, but that doesn't mean that I need to agree either. Since participants here can hardly be representative, I *must* put their feedback it in perspective, and then I agree or disagree. (You're not representive for all bugzilla users either; I'm obviously not disagreeing with all of them.)

(In reply to comment #124) > (In reply to comment #123) > > One issue with Stephen's sexy mockups [...] > > What did I just say? :( > Please don't discuss this here. My apologies, I missed your request to move the discussion and in fact just assumed you'd be conducting the new UI prototype testing here as this is where you posted the mockup. What is the new bug number?

(In reply to comment #130) > I'm not ignoring it, but that doesn't mean that I need to agree either. > Since participants here can hardly be representative, I *must* put their > feedback it in perspective, and then I agree or disagree. (You're not > representive for all bugzilla users either; I'm obviously not disagreeing > with all of them.) You don't have to agree, I'm just hoping Mozilla has a more rogue-proof system in place that will prevent one developer disregarding everyone else's opinion but his own from hijacking the toolbar UI; feel free to read through the 100+ comments and tell me how many are in favor of this patch.

What makes this patch even more curious is that there seems to be no credible evidence at all of the existence of the issue that is supposedly to be solved. Has anyone actually been complaining that the Fx toolbar button regions are too small to reliably click on? I could at least understand if this patch was made in an effort to fix a real problem, but as far as I can tell this is simply an exercise in mangling the UI in search of an imaginary issue to resolve.

(In reply to comment #133) > What makes this patch even more curious is that there seems to be no > credible evidence at all of the existence of the issue that is supposedly to > be solved. Exactly , when its not broken , it should not be fixed, for it takes time , resources , and may not give better result.

As I understand, the main goal here is to streamline the UI by removing the borders around buttons. As Dão said, increasing the hit region (by using system/native button style) is a bonus.

(In reply to comment #135) > As I understand, the main goal here is to streamline the UI by removing the > borders around buttons. As Dão said, increasing the hit region (by using > system/native button style) is a bonus. But what about inducing inconsistency in sizes of borders due to this? Home button is smaller when compared to the large back button , but has such wide hit region which doesnt not look sleek at all...

I have never seen anyone complain that the hit regions are too small. Even my mom that's not too great with computers has never complained about hit regions or anything. She primarily uses an acer laptop with a not so great touchpad and she's fine with Fx5's UI.

I think we should stop talking about current patch until Dão push the future patch in UX.

(In reply to comment #117) > FYI, for the next prototype stage I plan to experiment with something based > on > http://people.mozilla.com/~shorlander/ux-presentation/01-Firefox-Australis- > %28Windows%29-%28Fullscreen%29.jpg (but not just for fullscreen mode), so > you get the beloved round back button without all the suboptimal > implications it currently has. If you don't want people talking about the mockups here, you probably shouldn't introduce them into the bug. I'd just like to add that this right here: http://people.mozilla.com/~shorlander/ux-presentation/01-Firefox-Australis-%28Windows%29.jpg looks like pure awesomeness. The selected tab is too rounded - wastes space, but everything about the nav bar looks about as streamlined as I can imagine Firefox to be, without any negative visual implications (it looks pretty).

(In reply to comment #139) > everything about the nav bar looks about as > streamlined as I can imagine Firefox to be, It's always convincing when people talk in absolutes. > without any negative visual implications (it looks pretty). That's only part of the deal, as you'd know if you had followed this bug. (Oh, you did follow it? Why did you write this comment then?)

Why are you even bothering attacking my comment? All I did was post a link to a mockup, much like you, and give my opinion on it. I feel that it makes Firefox as streamlined as I can imagine it to be. Literally when I close my eyes and think of a streamlined Firefox, this is what I see and I can't see any modifications that would need to be made that wouldn't negatively impact on the design. I'm not trying to convince you of anything. You don't listen 80% of people's comments on here because we are not representing the entire user base, so why do you assume I'm trying to make some kind of argument here? You cannot be convinced, I worked that out from the past 5 comments I've made, and the 100+ comments that are against using system styled buttons. I'm just letting everyone else here see what Stephen Horlander came up with because I believe it looks streamlined and is from the same set of mockups that you posted earlier. Get off my back and start making a concept that people on here actually like and stop kidding yourself, they don't like your previous ones.

Not this style again please... we would be regressing back to how Firefox 3.6 was and this doesn't look appealing at all... Bad idea.

(In reply to comment #141) > Why are you even bothering attacking my comment? Because I'd like you to understand that there are user interface design principles besides "pretty". (I won't repeat them.) This would allow you to actually make a valuable contribution here rather than posting random advocacy comments. And let me be very clear that I don't want to diminish prettiness. It's a central goal besides others. I'm not a graphics designer, though, so my patches (carefully labelled as prototypes) focused on other areas that I'd like to see improved, well knowing there's a lot of polish left. > I'm not trying to convince you of anything. You don't listen 80% of people's > comments on here because we are not representing the entire user base, so why > do you assume I'm trying to make some kind of argument here? I expect you to make some kind of argument because this is bugzilla. If you want to chat, go somewhere else on the Internet. > Get off my back and start making a concept that people on here actually like > and stop kidding yourself, they don't like your previous ones. Excuse me! Don't post in my bug if you want me to get off your back.

can i know how to apply the patch..thanks..

(In reply to comment #144) > can i know how to apply the patch..thanks.. http://ftp.mozilla.org/pub/mozilla.org/firefox/nightly/2011-07-28-04-02-23-ux/firefox-8.0a1.en-US.win32.zip If you're interested in building Firefox yourself, see https://developer.mozilla.org/En/Developer_Guide/Source_Code/Mercurial and https://developer.mozilla.org/En/Simple_Firefox_build#Windows

(In reply to comment #145) > (In reply to comment #144) > > can i know how to apply the patch..thanks.. > > http://ftp.mozilla.org/pub/mozilla.org/firefox/nightly/2011-07-28-04-02-23- > ux/firefox-8.0a1.en-US.win32.zip > > If you're interested in building Firefox yourself, see > https://developer.mozilla.org/En/Developer_Guide/Source_Code/Mercurial and > https://developer.mozilla.org/En/Simple_Firefox_build#Windows thanks friends..cant wait to use it...

Okay, I'm done arguing about anything in this bug so I'll just lay some stuff out and hope you don't go too overboard on the replies: You made a direct reference to a mockup in this bug. I posted a link to another mockup from that same iteration, so that other users could see what it looked like. I believed it to be an example of how something could look good from a graphic designer's perspective, and be streamlined. You can't argue about an opinion, and last I checked every comment didn't have to be an argument and every commenter is entitled to an opinion. The post was purely for informing other users of the mockup. I did not want to start any arguments or to convince you of anything. Now if you are done criticizing my comments or whatever you are trying to do can you please get back to that prototype? I want to see some progress because (opinion coming, not an argument) I don't like the current one.

lets not waste time on debating and criticizing each other... Dao we are looking forward to your next prototype , i hope the discussion here helped you to move it in a better direction. :)

This is all dragging on a fair bit by this point. The problem here is that Dao wants counter-arguments made to his proposal to be succinct. However, that's proving nearly impossible due to how vague his initial argument for this proposal is. From what I can gather, the crux of Dao's argument for such a change would be an enlarged hit region in order to meet the growing demand for touch interfaces. The counter arguments vary a lot, however the reduced customisation of the GUI is a poignant issue of which Dao hasn't countered. Looking at the new mockups by the people employed to guide the design/UX, there is a conflict with what Dao has presented here. Thus ultimately, prototype or not, the onus is on Dao to make the argument for this implementation properly. I don't feel that anyone feels this has been done as of yet and the nature of a community project such as Firefox dictates that Dao should either make his argument or concede.

(In reply to comment #149) > The problem here is that Dao wants counter-arguments made to his proposal to > be succinct. However, that's proving nearly impossible due to how vague his > initial argument for this proposal is. Exactly. No effective COUNTER-argument can possibly be made when there is no argument in favor of this patch in the first place. All this patch is doing is wrecking the UI so as to please the personal whims of one developer.

Thing is, going back to the original patch.... the plain arrows design (elim. borders for buttons and removing keyhole)... (just curious no flaming here) have you gotten any formal feedback about the button sizes? has anyone formally complained or was this entirely based on internal findings/concerns?

(In reply to comment #149) > The problem here is that Dao wants counter-arguments made to his proposal to > be succinct. However, that's proving nearly impossible due to how vague his > initial argument for this proposal is. I hardly made an "initial argument"; however, I elaborated repeatedly on the motivations. It's still all there if you scroll up, although you need to make an effort to find it between the rants. > From what I can gather, the crux of > Dao's argument for such a change would be an enlarged hit region in order to > meet the growing demand for touch interfaces. This a misunderstanding. Touch interfaces were only an example, as I have explained. (In reply to comment #151) > have you gotten any formal feedback about the button sizes? has anyone > formally complained or was this entirely based on internal findings/concerns? What's formal feedback? I did hear people complain about the reduced button sizes when bug 544999 landed, if that's your question.

> (In reply to comment #151) > > have you gotten any formal feedback about the button sizes? has anyone > > formally complained or was this entirely based on internal findings/concerns? > > What's formal feedback? I did hear people complain about the reduced button > sizes when bug 544999 landed, if that's your question. and i heard none...

Sure, I believe you.

Someone please explain with MORE DETAILS how to apply patch, so we could get rid of Dao's cr@p inside Firefox.

(In reply to comment #154) > Sure, I believe you. the bug number u posted showed none mentioning words hit , region , small , size etc

(In reply to comment #152) > I hardly made an "initial argument"; however, I elaborated repeatedly on the > motivations. It's still all there if you scroll up, although you need to > make an effort to find it between the rants. Isn't that in itself a problem then? You admit you made no argument for this patch and you're unable to reiterate an argument for this patch. Instead you've abused a position of power whereby landing a patch because you could and undermined the very community that supports the browser by claiming that the opinions here aren't valid enough. > This a misunderstanding. Touch interfaces were only an example, as I have > explained. Then please be responsible enough to clarify. No one other than you appears to understand the motivations behind this patch clearly. Instead of repeatedly telling people to scroll up, perhaps you can collate these motivations in list form. Please adhere to the standards you yourself set for arguments against this patch.

When I meant "formal feedback" I meant bug reports, forum posts directed at that exact issue, and from offical feedback forms. (not filed by any mozilla or associated people) when I meant "internal findings" I meant from other people within or associated with Mozilla and thier groups only (excluding users not associated with or in relation to mozilla)

(In reply to comment #157) > (In reply to comment #152) > > I hardly made an "initial argument"; however, I elaborated repeatedly on the > > motivations. It's still all there if you scroll up, although you need to > > make an effort to find it between the rants. > Isn't that in itself a problem then? No? Comment 0 does contain motivation, just no finalized argument, and I later elaborated on things. > You admit you made no argument for this > patch and you're unable to reiterate an argument for this patch. This is false. I reiterated various arguments repeatedly. > Instead > you've abused a position of power whereby landing a patch because you could I take it that you're not familiar with the rules of the tree I landed this patch on. > and undermined the very community that supports the browser by claiming that > the opinions here aren't valid enough. I never declared opinions as invalid. There are, however, heavily skewed or irrational ones, and not every point a passionate community member tries to make is automatically a good one, let alone the absolute truth, just because it was written by a passionate community member. > > This a misunderstanding. Touch interfaces were only an example, as I have > > explained. > Then please be responsible enough to clarify. I clarified in comment 85. In a rational conversation, you would have responded "ah, ok" or "I still don't understand", but you chose to not respond at all, people moved on and posted the same old rants, and now you come back and criticize my style.

Whats going on here!!! One is attacking someone , other is defending , this is not gonna work. Not just we aren't reaching to any conclusion , devs are wasting time fighting in here for nothing...

(In reply to comment #160) > Whats going on here!!! One is attacking someone , other is defending , this > is not gonna work. Not just we aren't reaching to any conclusion , devs are > wasting time fighting in here for nothing... This particular dev seems to be unwilling to accept the fact that the majority of users do NOT like his solution, and is simply bent on dismissing all opposing opinions as inaccurate. Him doing nothing - as opposed to wreaking further damage to the UI - is a good thing in this case if you ask me.

(In reply to comment #160) > Whats going on here!!! One is attacking someone , other is defending , this > is not gonna work. Not just we aren't reaching to any conclusion , devs are > wasting time fighting in here for nothing... Right, and I was actually going to close this bug. I'll continue exploring this privately with Stephen and Asa. I'm sorry for everyone who was genuinely interested in tracking this process and tried to stay calm, civilized and rational.

Strop trolling guys! In anycase the UX TEAM has to accept the design he proposes. Just leave it for him to develop on it , and to get to some conclusion and leave UX team to decide.

(In reply to comment #162) > (In reply to comment #160) > > Whats going on here!!! One is attacking someone , other is defending , this > > is not gonna work. Not just we aren't reaching to any conclusion , devs are > > wasting time fighting in here for nothing... > > Right, and I was actually going to close this bug. I'll continue exploring > this privately with Stephen and Asa. I'm sorry for everyone who was > genuinely interested in tracking this process and tried to stay calm, > civilized and rational. thats pretty much cool with everyone , please close it.

after that, backout cset 3bd604c4601b on hg, please.

(In reply to comment #160) > Whats going on here!!! One is attacking someone , other is defending , this > is not gonna work. Not just we aren't reaching to any conclusion , devs are > wasting time fighting in here for nothing... I'm not sure what you're seeing here. There was an attempt by me to clarify this bug and have some definitive arguments made both for and against this bug, whereby the community could get together and decide what's best for the progress of the browser given all of the facts and statistics that motivated this bug. However, I've found that impossible. This is exemplified by the fact that Mozilla the champion for the open web has now decided to take development of an idea such as this behind closed doors due to the fact that there is, by Dao's own admission no concrete argument for this, but rather loosely based vague motivations of which the closest we've come to pinpoint is that "people aren't good at clicking on buttons in this day and age". Had this patch/idea come from a community volunteer, they'd have been asked to provide a much more concrete argument. And as people that care about the browser, we may not agree with all decisions, but we at least have the right (based on openness) to understand the train-of-thought/motivations behind it. The fact that Dao was unable to succinctly present such ideas has been a problem and one that I attempted to solve by asking in a civilised and rational manner. Sadly, I'm left just as confused now as when this bug was buried under people throwing insults. But I maintain, that if someone cannot state succinctly in a post on bugzilla why they believe a patch should be included when it's requested of them, it should never get the opportunity to get pushed. Please note this is not a negative reflection on Dao in the least, he's a hard worker and has been the developer that has coded a number of my more favourable features/experiences in Firefox 4+ as well as generally being available to speak to/answer questions from the wider community.

>Status: RESOLVED INVALID Oh yeah...

(In reply to comment #167) > >Status: RESOLVED INVALID > Oh yeah... Please stop forum-style comments without content as they trigger email. If you have nothing useful to say as in this case, just don't comment.

Dao, I am not very happy with this idea of yours. Firefox shouldn't look native or look too similar to another browser. Firefox is Firefox. It's a different browser from others.

I think it is unfortunate to see this bug being closed this way. I am only going to post this comment with my opinions regarding the situation. First, I'd like to address some of the misconceptions. * Even if the default style resorts to native widgets, it is still possible to have the custom designs, including the current one, made trough userstyles, themes or even extensions. Theme developers would in no way be harmed by this, they'd just have to change the -moz-appearance CSS property to "none" instead of toolbarbutton on the appropriate places. * It is possible to have a brand recognition while resorting to native widgets for the rendering, one is not necessarily compromised by the other. * It is possible that a lesser emphasis on the brand can actually improve the user's relation with the brand, if that lesser emphasis allows the user a streamlined experience. * The original goal of having the toolbar buttons enlarged was related to having improved usability. This is not only related to being able to click the button, but also with being able to click it quicker. By having a larger area, it is necessary less precision to move the cursor or place the finger over the button, by being necessary less precision, the user can make it more quickly, thus improving his experience with the software. This applies to both traditional mouse navigation as well as touch based navigation. * The styles exemplified in previous screenshots ( http://i.imgur.com/lTia9.png ), should not be classified as native and system respectively. More intuitively, we can classify interfaces as follows: ** Classical interfaces - these resort to the absolute minimum and simplest system widgets to achieve any interface at all (that would be equivalent to the "System" screenshot above). ** Native interfaces - by taking advantage of modern APIs (as the Aero API), these applications resort to native widgets and careful positioning to make the most usable and pleasant interface possible (Windows Explorer, if it wasn't for some smaller conditions which actually don't affect usability, would be a perfect example). ** Native inspired interfaces - by mimicking native widgets with only slight changes, these interfaces achieve something which was not possible by the native interfaces and was absolutely essential to these (ribbon based applications, which have too many tools to be able to give good usability by simply providing these in a toolbar, are examples) (Windows Explorer is a Native Inspired Interface, although it could easily be an actual Native Interface and still be perfectly usable and presentable). ** Non native interfaces - these applications ignore the interface guidelines at all to make their own appearance (most anti-virus apps do this). Each one has it's own advantages and disadvantages. While native inspired interfaces can provide a better usability, they come with the shortcoming of increased complexity (for example, Firefox developers had a hard time making sure that the current style developed worked and was usable, for example, in the high contrast windows theme), and inconsistence (all Ribbon apps behave slightly differently, as no specific API unifies their behavior). While native interfaces are more limited, their (compared) simplicity and much larger consistency with other windows apps makes them a plus when advanced features are not required (as it is in Firefox' toolbar). By following the Windows User Interface Guidelines ( http://msdn.microsoft.com/en-us/library/aa511258.aspx ) we make sure new users are not confused or bothered with any possible cross-application inconsistence. The easiest way to follow it starts by resorting to native widgets, as these are already programmed to behave properly. This also does not harm the brand, as a more usable interface will make users less frustrated in certain situations. Furthermore, other visual hints (as, for example, the Firefox menu button on Aero) will make sure to transmit the brand properly. Also, if the brand does get in front of usability, the brand itself might get hurt, as users will be bothered by the brand putting itself in front of their goals and delaying them, even if ever so slightly. At last, providing two versions for Firefox would be harmful. By making so, we'd be providing confusion to users, who would be uncertain of which version to get, possibly choosing an inappropriate version for them as well as we'd deliver an inconsistent approach among different users (the interface would not longer be the same with only slight appearance changes across users), thus harming the brand. These are most of my points so far. I might not answer replies as I found this bug after the discussion got finished and I simply wanted to put my point across. At last, I want to emphasize that the people discussing bugs in here are not the average Firefox user one might encounter. Most of us probably trained ourselves to detect certain inconsistencies and annoyances. The Firefox developers probably in regard mostly of usability, the other people in this discussion regarding mostly visual quirks. I want to emphasize the average user is not aware of these bugs when he encounters them, but his judgment will be affected by these. For example, regarding this discussion, when encountering sub-optimal target sizes, the Firefox developers will notice they require more precision to hit a certain button than normal or expected, and will try to make a mental note of it, to later fix it. Normal users will not, they will subconsciously notice that the target was harder to reach, but they will not equate that with the actual problem. Instead, they might reach conclusions as "Firefox is slower" or "Firefox is harder to use". The people who posted in this bug mostly were trained to spot visual bugs, and forgot to notice this was a rough, unpolished ongoing process of improvement which would have the visual quirks polished with time by the actual artwork developers. I myself ended up training myself to spot visual inconsistencies between applications, and pushing this bug live would seriously help improve this situation (and even more if also the urlbar and searchbar used native textboxes and the Aero version of the widgets was shown when the background is not opaque). That is all I have to say.

That's all very well and good but you are saying that this was a rough, ongoing process of development and yet here is Dão, arguing that this rough system (or native, whatever you want to call it) styling is better than using our own style. I understand that things like the back arrow need work and I hav no problem with that, but one of the underlying drives behind this bug was to use system styling, and that is largely what people are having problems with on here. That and we have not seen any proof that the average user finds Firefox "too slow" or "too hard to use" and so there is no need to suddenly drive for this streamlined look. In the end, the people that blog about the browser and actually get it out there for the average person to use (you know, review it, compare it to the competition, praise it) are going to be the people that spot these visual "inconsistencies". That is how I see it.

I still would like to see the feedback of actual users complaining that the hit regions are too small. I am on tons of forums and I have never seen anyone complain about that issue.

(In reply to comment #171) > That's all very well and good but you are saying that this was a rough, > ongoing process of development and yet here is Dão, arguing that this rough > system (or native, whatever you want to call it) styling is better than > using our own style. I understand that things like the back arrow need work > and I hav no problem with that, but one of the underlying drives behind this > bug was to use system styling Don't put stuff I never said in my mouth. Early on in this bug, I asked for shortcomings of the native toolbar button style. You were able to list a few arguable ones (transitions, split buttons, glass with tabs on bottom) but nothing useful beyond that. It's impossible to argue about this when people constantly fail to bring up concrete points (such as the corner radius that Asa said he would like to see reduced).

(In reply to comment #171) > That and we have not seen any proof that the average > user finds Firefox "too slow" or "too hard to use" and so there is no need > to suddenly drive for this streamlined look. (In reply to comment #172) > I still would like to see the feedback of actual users complaining that the > hit regions are too small. > > I am on tons of forums and I have never seen anyone complain about that > issue. Actually, a clear evidence that shows that people sometimes perceive Firefox that way is the slow but steady decline Firefox is having, in which people change to Chrome for the exact same reasons I exemplified (they say Chrome is nicer, faster or easier). Their perception of this is related to either actual performance problems or performance perception. That is why any work made that improves any of these (and that includes the streamlined look) is beneficial. (In reply to comment #171) > That's all very well and good but you are saying that this was a rough, > ongoing process of development and yet here is Dão, arguing that this rough > system (or native, whatever you want to call it) styling is better than > using our own style. I understand that things like the back arrow need work > and I have no problem with that, but one of the underlying drives behind this > bug was to use system styling, and that is largely what people are having > problems with on here. Nothing can look better in regards to appearance than what a graphic designer or artist can do. That is absolutely true. But that does not necessarily apply to user experience. Something can look great, but that won't automatically translate into improved experience. It all depends on how the interface details are taken into account. It is also important to know that resorting to native widgets does not necessarily lead to what you call a system styling. There is a lot of room for adaptation inside native widgets. A person can resort to normal widgets, Aero ones, margin and padding changes can lead to great differences, and all of the icons used in these widgets can be changed. Windows Explorer as it is shown on Windows Vista and 7 could be made up of entirely native styling and nobody would notice any major differences. When I said this was a rough process of improvement is because this bug does a single thing: implement the base to have the toolbar use native widgets. All of the other parts that can be manipulated would then be adapted by the artistic developers to provide a better appearance than the one seen in the initial patches by changing the exact same margins, paddings and button glyphs. Long story short, of course the non-native look will have more possibilities to look far better, but the native appearance, after it is improved, would not only be pleasant to look at as well as be far more usable, versatile and stable than the current non-native look. And thanks to Mozilla's advanced theming system, reverting back to non-native widgets for any specific theme a themer would like to do would be as easy changing a CSS property (-moz-appearance) and setting the button's style.

Thing is if a user is used to, for example riding a normal bike. Then someone hands them a bike with training wheels and they get used to riding it. When the time comes that they need to ride a regular bike again (thier other bike gets broken or stolen) they can't ride the regular bike again and just give up. This is the same with software. If a user is used to having an extremely babied down interface and they use someone else's system with a normal interface they panic and can't use it. and they give up. when it was simply the norm. There are people that are only used to using smartphones. Try getting one of those users to pick up photoshop and they panic. should adobe cater to the lowest common denominator and remove features and functionality to please those people and leave the core users and pro editors that have been loyal to adobe since the beginning? There would be OUTRAGE. Firefox has always been known of as the powerful browser. I would much rather see people learn to use the more complex software and develop as human beings and become smarter, rather then have everything dumbed down for so many people who don't want to learn and improve themselves. The latter is the toxic trend the tech industry is taking and it's very depressing and very detrimental to the advancement of technology and intellect of humans.

I will also add that chrome's interface is not modern, as a matter of fact it looks more from the highly dated windows xp luna UI days rather then the modern windows 7/2008 aero days.

(In reply to comment #175) > This is the same with software. If a user is used to having an extremely > babied down interface and they use someone else's system with a normal > interface they panic and can't use it. and they give up. when it was simply > the norm. > > There are people that are only used to using smartphones. Try getting one of > those users to pick up photoshop and they panic. should adobe cater to the > lowest common denominator and remove features and functionality to please > those people and leave the core users and pro editors that have been loyal > to adobe since the beginning? There would be OUTRAGE. > > Firefox has always been known of as the powerful browser. > > I would much rather see people learn to use the more complex software and > develop as human beings and become smarter, rather then have everything > dumbed down for so many people who don't want to learn and improve > themselves. It is possible for something to have a powerful interface while being simple to use at the same time. An example is the first image of this Microsoft tutorial: http://msdn.microsoft.com/en-us/library/aa511332.aspx Firefox originally gained market-share because, unlike the Mozilla Suite, it had much saner defaults, which streamlined the interface much more than any other Internet Explorer competition at the time. Yet, even tough Firefox was the simplest of the browsers out there, it was the most powerful and versatile. The easy generally accessed things were in the main window of the browser while more complex parts were hidden down deeper, although being easy to bring back up. Nonetheless, this bug does not make any change in complexity. The controls are still the same, in the same position, with the same overall expectations. The only difference is how they look. Instead of looking like the custom made pressable buttons used in Firefox 4 and 5, they have the native toolbar look (closer to the one used in Firefox 2 and 3, but without the colored glyphs). Although your argument is understandable and important (it is important to keep the user in control of the browser, while still trying to constantly make it easier to do the exact same things he does now), it does not apply in this specific bug. (In reply to comment #176) > I will also add that chrome's interface is not modern, as a matter of fact > it looks more from the highly dated windows xp luna UI days rather then the > modern windows 7/2008 aero days. Then you'll be happy to know that the approach Dão is trying to make is not in any way attempting to clone Chrome's layout. At most, it's a potentially more streamlined and usable interface which would look like Luna in XP and Aero in Vista and 7.

I still don't see why we need to step backwards as far as the look is concerned. Why are we going back to Fx 2.0 and 3.0's look?

(In reply to comment #175) > There are people that are only used to using smartphones. Try getting one of > those users to pick up photoshop and they panic. should adobe cater to the > lowest common denominator and remove features and functionality to please > those people and leave the core users and pro editors that have been loyal > to adobe since the beginning? Our answer to "pro" users is extensibility and features that people can opt in to. Firefox does not try to be the photoshop of web browser. Where this appears to be the case, we're doing something wrong. > Firefox has always been known of as the powerful browser. This may be the case, but: - We certainly don't target power users exclusively. See above. - Nothing brought up in this bug makes Firefox more powerful or less powerful. > I would much rather see people learn to use the more complex software and > develop as human beings and become smarter, rather then have everything > dumbed down for so many people who don't want to learn and improve > themselves. Obviously, this is a very broken view when it comes to user interface design. People will use software that meets their needs. If your software doesn't meet their needs, they'll at some point use alternative software (if available). And of course, nothing you were fighting for in this bug empowers users or makes them smarter.

Ok. Just wanted to clarify your positions on this matter. Thank you.

I've already argued that native applications never use that styling in their main toolbars. I never received a response about this and this is my main argument. If we want this to feel native, surely we should be using a similar vibe to other native applications, which I feel Horlander's mockups do very well. They aren't without faults. I'm just praising the styling at this point. I have few issues about the streamlining idea. I just think we shouldn't be using the "native widget" toolbar button styling.

(In reply to comment #181) > I've already argued that native applications never use that styling in their > main toolbars. I never received a response about this and this is my main > argument. You've got your responses, just none you would accept. What you consider "main toolbar" seems to be directly on glass or linked to a ribbon, none of which applies to us. Lamenting over some rule that simply isn't there is tiresome. I wanted to hear concrete flaws.

I meant main toolbar as in... the main toolbar. For IE and Explorer, that is on Aero glass. For Wordpad that is the ribbon. It doesn't matter. You find me a native Windows application with a main toolbar that uses the system styling for all of the buttons and I'll agree that my argument isn't concrete.

> You find me a native Windows application with a main toolbar that uses > the system styling for all of the buttons and I'll agree that my argument > isn't concrete. XPS Viewer? Snipping Tool? Sound Recorder? Windows Journal? Widows Help and Support? Want me to go on?

I think we have different definitions of native... so this is never going to work.

More convenient, more active firefox

But, you did just list some of the ugliest applications I can find in Windows. Admit it, they ain't too good to look at. That's why the stuff that gets more user attention (Explorer, IE, Calculator, Wordpad) tends to look nicer. Because Microsoft got its priorities right. All of the stuff you mentioned gets used by a minority of people, and hence Microsoft hasn't put much time into styling them beyond the system level. All the stuff I mentioned gets used by the majority and hence it uses its own native style and most people would agree, it looks far better. So I'll admit here and now, my definition of native is rubbish (I don't even know what it is) and therefore my argument is not concrete, but I know to a graphic designer's eye, the system styling looks a lot worse than any of the stuff in Wordpad or Explorer. Just about everyone on here agrees (and most are not graphic designers), and I bet most of the UX team agrees too. And with that, I end my terribly put together argument. Now you can take it to pieces and send me off to the naughty corner if you so choose.

(In reply to comment #187) > to a graphic designer's eye, the system styling looks a lot worse than any of > the stuff in Wordpad or Explorer. That's a fine opinion to have, it just needs to be linked to some concrete weaknesses to be useful. Mentioning Wordpad and Explorer doesn't help at all, since our toolbar is neither ribbon nor glass.

Tabs on bottom: glass. Tabs on top: Ribbon background.

Well it's not a toolbar background.

Then waht is it, button background?

At the moment it is what I'd call native. Toolbar backgrounds use -moz-appearance: toolbox or toolbar. So really, if we were to use toolbar button styling we should be coupling it with a toolbar background like you find in Sound Recorder for example. And then, my friends, we would be back to pre-Firefox 4 times.

OK here's the thing about the levels of styling: 1)Classic (barebones minimum) win9x/me/2000 Older MMC snap ins from 2000 2)System (notepad/mspaint/openoffice/mmc snap ins like computer management/server manager) windows vista/2008 and parts of windows 7 windows xp explorer.exe 3)native (windows explorer, windows media player, newer ms paint, ms office, apps that use the ribbon) Firefox, most windows 7 appls like WLE 4)custom skinned applications (media jukebox, firefox skins, adobe spplications like PS,FL,FW,DW, RealPlayer,)

(In reply to comment #193) > OK here's the thing about the levels of styling: > > 1)Classic (barebones minimum) win9x/me/2000 Older MMC snap ins from 2000 > > 2)System (notepad/mspaint/openoffice/mmc snap ins like computer > management/server manager) windows vista/2008 and parts of windows 7 windows > xp explorer.exe > > 3)native (windows explorer, windows media player, newer ms paint, ms office, > apps that use the ribbon) Firefox, most windows 7 appls like WLE > > 4)custom skinned applications (media jukebox, firefox skins, adobe > spplications like PS,FL,FW,DW, RealPlayer,) How to explain? When a person makes a program, they can choose to make it appear on the screen in 2 different ways. They can either design each button by hand, either using images, vector images, or custom drawing APIs (like we could call XUL and CSS in Firefox), or they can call a set of predefined objects, which have all of their behavior and appearance in all states possible already defined by the system itself (the equivalent of setting -moz-appearance to anything besides none in Firefox). When you call these predefined objects, the operating system itself (Windows, in this case) will take care of everything, with you only being worried with making the buttons work when the system tells you they were clicked. The system objects have advantages because they will automatically adapt to disability preferences (like high contrast), performance preferences (when someone chooses to use the classic style on purpose) or custom themes (when someone uses, for example, WindowBlinds to change the appearance of the system). While the first and second situations can be worked around when drawing the buttons yourself, it takes a lot of work, and it is impossible to adapt to the situation in which someone uses 3rd party themes (as WindowBlinds). That is why it is preferred to have native widgets being used. Actually, the only difference between the Classic and System styles you refer to is that the same widgets are rendered differently according to the users preferences (or the limitations of the OS itself). Actually, if you set Windows Vista and Windows 7 to the Classic appearance, almost all applications you define as native will also render using the Classic style. They do this because Windows Vista and Windows 7 also define more native widgets that can be used by the user. Both in Windows Vista and 7, Windows Explorer resorts to native (or, as you'd call it, system) widgets to render most of the things you see, including the Aero toolbar, the colored toolbar beneath it and the sidebars. Any of those stylings are options when wanting to use a native style as Dão suggests. But, as we can see in http://msdn.microsoft.com/en-us/library/cc872782.aspx#rightui the Ribbon UI is not appropriate for the kind of application Firefox is. We don't have a set of several commands which need to be immediately available to the user, we have a simple set of tasks the user needs. In this case, toolbars http://msdn.microsoft.com/en-us/library/aa511500.aspx#rightui are more appropriate. And any of the toolbar styles shown on that page are available for us to use as native styling using only native widgets (with the exception of the Windows Movie Maker dark toolbar, but another dark toolbar style is available for us and was used in Firefox 3 for the library). What Dão proposes is mostly an appearance similar to IE7/8's command toolbar next to the tab bar, as shown in http://www.howtogeek.com/wp-content/uploads/RemovetheIE7BuiltinSearchBar_BF4B/image0.png . The proper way to reach that appearance is to use "-moz-appearance: toolbarbutton;" as it has been shown and developed so far. The only thing lacking is proper margins, proper padding and adequate glyphs to the new button styling. The result in the end should be exactly like Horlander's mockup, with the exception that the hover effects are different. And once again, I emphasize, themers could and would override this and any styling they can by simply setting the css properties of those toolbar buttons to "-moz-appearance: none;"

Please don't post IE8 screenshots and refer to them as something partly positive. I know you didn't say we should generally try to match IE8, but people will assume exactly this and consequentially reject everything you say.

But system and native styling are two different things. Jose, when you refer to "native" you are mixing that in with "system".

This bug is reaching the 200 comment limit of reason, but after passively reading I wanted to add a few notes on future considerations: -There are two types of targeting that we have to consider: first visual targeting, which is then followed by physical targeting. Regardless of the actual size of the control's hit area, controls that visually appear to be larger end up performing better for the visual targeting part. -brand identity is an obviously large consideration here -a conditional (as opposed to usually disabled) forward button really helps to visually simplify the UI, but also only works when the navigation buttons have their own button appearance, as opposed to appearing as glyphs floating in space.