User-Agent: Mozilla/5.0 (Windows; U; Windows NT 6.1; WOW64; en-US; rv:1.9.3a6pre) Gecko/20100613 Minefield/3.7a6pre Build Identifier: Mozilla/5.0 (Windows; U; Windows NT 6.1; WOW64; en-US; rv:1.9.3a6pre) Gecko/20100613 Minefield/3.7a6pre We need as much free space as possible in Title Bar when tabs will be in there. Keeping Firefox Menu so huge is unecessary and there will be even less space, when edit tray appears and/or acces to profile appears. Reproducible: Always

From the mockups, the tabs aren't actually inside the title bar, so this won't be a problem. I think it's to make it easier to move the window around.

Having ability to draw in titlebar and yet not able to put tabs into it is stupid. Not to mention users demand it and they will bury Mozilla if they will not allow it.

Tabs should only move into the title bar when the window is maximised if at all

Of course.

I think Tabs should only move into the title bar if users allow them to. There should be an option allowing people to choose to let tab in Title Bar or to remain below the title bar. Is there a bug for this? Are there other mock-ups that shows tabs inside the title bar?

Good catch, thanks.

Probably worth doing to save screen space. Just hypothetically, what do people think of only reducing the Firefox button to an icon in the case of tab overflow? In terms of visual design, I think we would need to go with a white silhouette, the orange on orange with the glow gets really messy.

(In reply to comment #7) > Just hypothetically, what do people think of only reducing the Firefox button to > an icon in the case of tab overflow? I dont understand this question. Button will be reduced all the time.

I think the only real issue of the iconic-button is that people don't recognize it's a button, nor a menu, and I think maximized window is the most common status for users. For sure my mother would not recognize she has to click that icon, and she uses Firefox everyday for her work. The textual button is far more attractive.

Well, we can highlight button until user clicks on it. Something like „Ooo, what this shiny thingy do?”.

since it is bright orange, I'm hoping that people will find it. Also the down arrow will help to express that it contains commands. The image versus text shouldn't really come into play too much with discoverability (although with an image the button is smaller). If anything the image is more expected since it's externally consistent with common applications like paint and wordpad. The main consideration with the image versus button was that we wanted this thing to be easy to communicate, both verbally and in text.

Could you not redesign the firefox button to have the firefox logo in the background and upon shrinkage, the text will disappear and the logo goes from see-through to solid?

Why don't we make the Firefox button like that? When Firefox has only small number of tabs the Firefox button show the wording "Firefox". When Firefox has tabs overflow(aka a lot of tabs), the Firefox button become the Firefox logo. This would help save space when it is required. Although I believe this would mean a lot more work need to be done for the Firefox button. This is my suggestion I hope it can help with the development of Firefox 4.

For discoverability, see also <http://my.opera.com/desktopteam/blog/2010/05/31/opera-10-60-alpha-1>: 'the O menu button now says "Menu" for easy discovery'

I think it will be quite obvious that the Firefox button is a menu since it is orange in colour. But you can always tell users about it in the Home Tab. In a small information like Do You Know: That The orange button above the Home Tab is a Menu. It is called the Firefox Menu. It is the minimalist version of the classic menu that you love and like to use.

I feel like the name of their application is "Menu" looking at that mockup. Also one of the things that is really nice about the traditional menu bar was that the command sequence formed a sentence: edit copy view status bar using Firefox still sort of works, in that you are commanding the browser: firefox save firefox print kind of like a dog doing tricks :) this doesn't seem to work with menu, it's too meta menu save menu print

(In reply to comment #7) > Probably worth doing to save screen space. Just hypothetically, what do people > think of only reducing the Firefox button to an icon in the case of tab > overflow? I think that's a good idea if you can do it smoothly. Personally, I think how Opera does it now looks great (easier to do with an O than with Fx logo) and that they're going backwards adding menu. The hover over which shows "Menu" should be enough but your suggestion would help discoverability and have no loss to users like myself with constant tab overflow.

Regardless of whether it says Menu or an icon is used, please provide a keyboard command for opening the dropdown menu like the Compact Menu extension and some of its' clones have had over the last 7 years, using the {Alt + M} key combination.

So is this feature confirmed to be in Firefox 4?

Requesting to block beta3+ along with bug 572160. It would be nice if both bugs landed for same beta.

what about this : we change the square button to a round button? so it will depict the real 'taste' of the firefox, and place the button inline with the home tab.

(In reply to comment #14) > For discoverability, see also > <http://my.opera.com/desktopteam/blog/2010/05/31/opera-10-60-alpha-1>: 'the O > menu button now says "Menu" for easy discovery' yeah, that's good, but we don't want to make Firefox just like Opera, consider to replace the odd square button with a round button. reference : see the style of ms office 2007 button!

Nice idea - doesn't block but would be interested to see a low risk patch with tests for approval.

>Nice idea - doesn't block For context, if we move the tabstrip to the top of the window frame we are going to need this fix, otherwise the Firefox button and window controls will take up a significant amount of the tab strip. A lot of netbooks will be running with Firefox maximized, so this is a pretty important aspect of our window layout.

(In reply to comment #22) > yeah, that's good, but we don't want to make Firefox just like Opera, consider > to replace the odd square button with a round button. reference : see the style > of ms office 2007 button! Office 2007 really had bad UI. The Office 2010-style which is similar to Paint and Wordpad under Windows 7 would be much better.

Keeping this separate from the Beta 4 work in bug 583386, but I still very much think that this needs to block final release since there are more windows users running maximized then there are [insert fun fact including very large number here] :)

is 'home tab' also set to block the final release?

not sure if it has been set blocking yet, but yes

I agree that it's wanted and desired for this configuration, but still don't think it blocks the release.

I think that implementing this change to the Firefox Menu button is a bad mistake. One really bad decision that Microsoft took in the design of Office 2007 was to implement the "Office button" as a circle with non-descriptive Office logo. How did you then describe the "Office button" to a new user? - "Click the big circle thingy in the top-left"?? The same would apply here - instead of saying "click on Firefox", you would have to say "Click on the orange fox swirling around the globe logo in the top-left"!! Having the word "Firefox" (as at present) is more menu-like and makes the menu options seem like a syntactically structured command. Why not instead just reduce slightly the amount of left and right padding around either side of the word "Firefox"?

(In reply to comment #30) > Why not instead just reduce slightly the amount of left and right padding > around either side of the word "Firefox"? Because that wouldn't be enough. Do you even have netbook? Try it yourself before you make judgment "this will fail!!". We NEED as much free space as possible and drop-arrow is enough for everybody. If someone will fail understanding what drop-arrow means, it's probably because he doesn't understand PC at all; even if you get him fat manual "how-to", he would be still asking stupid questions like "how to turn the PC on". Complex software like web browser isn't aiming for that kind of users, never was and never will be.

(In reply to comment #31) > (In reply to comment #30) > > Why not instead just reduce slightly the amount of left and right padding > > around either side of the word "Firefox"? > > Because that wouldn't be enough. Do you even have netbook? Try it yourself > before you make judgment "this will fail!!". We NEED as much free space as > possible and drop-arrow is enough for everybody. If someone will fail > understanding what drop-arrow means, it's probably because he doesn't > understand PC at all; even if you get him fat manual "how-to", he would be > still asking stupid questions like "how to turn the PC on". Complex software > like web browser isn't aiming for that kind of users, never was and never will > be. Please take a look at the attachment which illustrates how much padding you can strip off the text-based menu button design. Also shown for comparison is the Firefox button as it is now and your proposed icon menu version (scaled to a 1:1 ratio). The icon-button is only 10px narrower than the padding-stripped textual button. The point that you are failing to recognise is that the Firefox button (which is a great idea) is a new concept that isn't standard across any other applications. Anything new like this needs to be intuitive by design - you can't seriously be saying that a loss of intuition is worth a mere extra 10px!: Advantages of a textual button over basic icon: - more intuitive given that it is not a standard Windows UI to have a button in the top-left. - consistent interface when tabs are in title bar and when they aren't (an icon when in title bar and then no icon when not is just plain inconsistent). - The Firefox menu is a fairly important button, therefore it should have a reasonable size. - The textual button gives commands in the menu a more logical command-like syntax. - The textual button has a double function of giving the name of the application in view. - much easier to describe and support (Microsoft support must have had a nightmare trying to explain how to do anything with the "orb" in Office 2007!) A web browser may be "complex software" under the hood, but its interface certainly should not be - in fact a web browser is probably the one computer program that every single novice computer user will want to use (my relatively computer illiterate aunt just uses Internet Explorer and nothing else - IE has a more intuitive name, but that is getting off topic...). Besides, this has nothing to do with users who are too stupid to use a computer - sometimes you need to *describe* how to do something to even the most advanced of computer users, and the icon is just non-descriptive. Look, I just don't want my quite computer-literate father to be asking me "How do I do x in this new fancy version of Firefox?", and then having to respond "Click on the little swirly fox-globe icon thing in the top-left". Save everyone the hassle and just let us say "Click on Firefox". Besides, Firefox is known for its customization - let the *minority* of netbook users save the 10px if they wish by customizing the appearance of the menu in the options.

(In reply to comment #32) > Please take a look at the attachment which illustrates how much padding you can > strip off the text-based menu button design. Ugly, incosistent.

(In reply to comment #33) > (In reply to comment #32) > > Please take a look at the attachment which illustrates how much padding you can > > strip off the text-based menu button design. > > Ugly, incosistent. You could add a couple of extra pixels if it looks like a bit *too* much padding has been stripped. And what is inconsistent about it? I think a *completely* different icon when the screen is maximized is more inconsistent.

(In reply to comment #13) > Why don't we make the Firefox button like that? > When Firefox has only small number of tabs the Firefox button show the wording > "Firefox". When Firefox has tabs overflow(aka a lot of tabs), the Firefox > button become the Firefox logo. > > This would help save space when it is required. Although I believe this would > mean a lot more work need to be done for the Firefox button. This is my > suggestion I hope it can help with the development of Firefox 4. I also like this idea of scaling the size of the Firefox button depending upon the number of open tabs. This is much easier to do and will look like a much smoother transition if you just change the amount of padding in the textual button, rather than using a completely different icon version of the button.

(In reply to comment #34) > (In reply to comment #33) > > (In reply to comment #32) > > > Please take a look at the attachment which illustrates how much padding you can > > > strip off the text-based menu button design. > > > > Ugly, incosistent. > > You could add a couple of extra pixels if it looks like a bit *too* much > padding has been stripped. And what is inconsistent about it? I think a > *completely* different icon when the screen is maximized is more inconsistent. Huh? What "completely different" icon you're talking about? Certainly it isn't icon from default state, because it doesn't have any icon. And it can't be the original icon either, because that icon was there for years in the same place. So I have absolutely no idea about which icon your are talking about...

> Huh? What "completely different" icon you're talking about? Certainly it isn't > icon from default state, because it doesn't have any icon. And it can't be the > original icon either, because that icon was there for years in the same place. > So I have absolutely no idea about which icon your are talking about... I'm talking about the fact that when the Firefox button is not in the title bar it has just the word "Firefox and no icon, and then when you maximize and tabs shift into the title bar the Firefox button changes appearance entirely. In this situation Firefox 4 would not be being consistent with itself.

(In reply to comment #37) Correction: that should read "I'm talking about the fact that when the tabs are not in the title bar"

Firefox as text = Firefox as icon Simple as that. I don't think users are *so* stupid they can't realize the equality between the icon and text with the same meaning.

(In reply to comment #39) > Firefox as text = Firefox as icon > Simple as that. I don't think users are *so* stupid they can't realize the > equality between the icon and text with the same meaning. Maybe they aren't, but it's still unnecessarily inconsistent.

If it would be incosistent, then it wouldn't be confirmed by UX team.

(In reply to comment #41) > If it would be incosistent, then it wouldn't be confirmed by UX team. That's a bit of a weird argument. Something that looks completely different depending on window size is inconsistent, even if someone else has noticed it or not. As much of a good job the UX team do, they are hardly a bunch of super-human beings - all designs are compromises, and this is something more for them to think about. Besides, I think the strongest argument against the icon isn't the one about consistency - it's that the icon is difficult to communicate/describe both verbally and in writing.

Oh yeah, lets replace all icons with text, so we can be be consistent as (insert word).

(Please do not re-add me to the cc: list of this bug - the discussion here is no longer useful)

(In reply to comment #43) > Oh yeah, lets replace all icons with text, so we can be be consistent as > (insert word). You know that's not what I was suggesting - I won't comment further. Let's just leave it up to the UX team.

(In reply to comment #7) > Probably worth doing to save screen space. Just hypothetically, what do people > think of only reducing the Firefox button to an icon in the case of tab > overflow? > > In terms of visual design, I think we would need to go with a white silhouette, > the orange on orange with the glow gets really messy. I think it looks great.

46 comments is a bit too much for an otherwise simple change, to reduce confusion (and the extent to which developers feel the need to read all of the comments before working on a patch) I'm duping this forward to a slightly modified version of the bug.