544815 - Allow for placing Tabs over the Navigation Bar with option for Tabs under the Navigation Bar (add tabs on top option)

Status: VERIFIED FIXED

(Firefox :: Tabbed Browser, enhancement)

Description

[Stephen Horlander [:shorlander]]

Attachment: [Mockup] Tabs above and below the Navigation Bar

For the new Firefox theme/UI we would like to place the Tabs above the Navigation Bar by default. This would be beneficial for the following reasons:

* Gives Firefox a correct UI hierarchy where the controls are tab specific
* Fix a redundancy in having both a titlebar with page title as well as a tab with the page title
* A Fitt's Law win if the window is maximized
* A small vertical space savings allowing more room for content
* Creates a more streamlined UI

The ability to have Tabs underneath the Navigation Bar would also be needed. Potential entry points for this preference could be in a contextual menu on the tab bar, under the tab preferences pane or more ideally in the Customization dialog. The Customization dialog would need to be reworked to fit in this option.

See attachment for mockup.

Comment 1

[WildcatRay]

Steven,

Is there a group or news group where this is being discussed? I want to express my concerns about this change. Thanks.

Comment 2

[Stephen Horlander [:shorlander]]

(In reply to comment #1)
> Steven,
> 
> Is there a group or news group where this is being discussed? I want to express
> my concerns about this change. Thanks.

There have been discussions on this previously on the Newsgroup and the Wiki:

Newsgroup: http://groups.google.com/group/mozilla.dev.apps.firefox/browse_thread/thread/9e569626887ae703?tvc=2&q=Proposed+Direction
Wiki: https://wiki.mozilla.org/Talk:Firefox/4.0_Windows_Theme_Mockups

There isn't a d.a.f post for this specific change though.

Comment 3

[WildcatRay]

Thanks.

Comment 4

[Alex Faaborg [:faaborg] (Firefox UX)]

Should note that the default window configuration will vary by platform in order to fit in interactively with all of the other apps the user regularly uses on that platform.

Windows 2000:  tab bar below, traditional menu bar
Windows XP:    tab bar below, traditional menu bar
Windows Vista: tab bar above, application button
Windows 7:     tab bar above, application button

OS X:          tab bar below, menu bar at top of screen

Linux: [we have no idea, we don't want to appear "old" at the cost of being native, but Chrome is now picking some some shiny points by ignoring native interactive design.  Distros will also be able to control the way Firefox is deployed, so to some extent we don't have to make this call ourselves]

Comment 5

[Dão Gottwald [:dao]]

(In reply to comment #4)
> Should note that the default window configuration will vary by platform in
> order to fit in interactively with all of the other apps the user regularly
> uses on that platform.
> 
> Windows 2000:  tab bar below, traditional menu bar
> Windows XP:    tab bar below, traditional menu bar
> Windows Vista: tab bar above, application button
> Windows 7:     tab bar above, application button

Which other apps with regards to the tab bar position?

Comment 6

[Darren Kalck [:D-Kalck]]

there are tabs on top with Paint and WordPad on Windows 7

Comment 7

[Dão Gottwald [:dao]]

Really? Is this for multiple documents or ribbon?

Comment 8

[Darren Kalck [:D-Kalck]]

This is for the ribbon, the only native app I know who use multiple documents is IE and the tab bar is below.

Comment 9

[Alex Faaborg [:faaborg] (Firefox UX)]

>Which other apps with regards to the tab bar position?

In terms of interactive consistency I was thinking more about the application button than tabs on top (since multiple documents isn't really the same thing as ribbon, interactively speaking).  The application button doesn't necessarily have to be tied to the placement of the tabs. Tabs can really be in any configuration with the application button present.

In terms of visual consistency, using tabs on top for documents is visually kind of similar to the ribbon layout (although really not the same interactively).  This is I think why there were erroneous press reports that we were going to deploy a ribbon interface, primarily due to the visual consistency.

Comment 10

[Dão Gottwald [:dao]]

(In reply to comment #9)
> In terms of visual consistency, using tabs on top for documents is visually
> kind of similar to the ribbon layout (although really not the same
> interactively).

That's a pretty big "although". I thought we wanted this because it fit our interaction model better, but presumably this would apply across platforms.

I really think this needs to be backed by usability considerations strong enough to not depend on the ribbon (non-)simile, anyway.

Comment 11

[Alex Faaborg [:faaborg] (Firefox UX)]

I was just explaining what I meant when I was referring to external consistency (of the application button).  In terms of rational for placing tabs on top for on modern versions of Windows:

Pros:
-Clear conceptual model (back/forward effect the tab, not the application)
-Externally consistent with actual physical tabs
-Ability to create chromeless application tabs and home tab
-Visually simpler (less redundancy with title and favicon) 
-Easy to distinguish from IE at a glance

Cons:
-Minor efficiency loss due to the mouse having to travel slightly farther (it would be great to run a Test Pilot study on this so we can understand exactly what the difference costs in terms of average time for tab selection with the mouse)
-Harder to distinguish from Chrome (which is admittedly less common of a situation than distinguishing from IE).

Unrelated to Usability:
-There is a general perception that placing tabs in a more conceptually pure configuration is "modern and sleek" while the traditional placement is "old and clunky."  This is purely an emotional design and brand level consideration, primarily caused by Chrome being the "new" product in the marketplace, and Firefox presently being the "old" product in the marketplace.  Had we made the change with Firefox 3 on Vista, we would not currently be facing this situation.  However we are now at a state where deploying the more conceptually pure design is "copying" or "catching up," and failing to deploy it may be interpreted as "stagnating" or "falling behind."  The product perception issues related to tab placement appear to be a lose/lose at this point.

Comment 12

[Dão Gottwald [:dao]]

(In reply to comment #11)
> I was just explaining what I meant when I was referring to external consistency
> (of the application button).  In terms of rational for placing tabs on top for
> on modern versions of Windows:
> 
> Pros:
> -Clear conceptual model (back/forward effect the tab, not the application)
> -Externally consistent with actual physical tabs
> -Ability to create chromeless application tabs and home tab
> -Visually simpler (less redundancy with title and favicon) 

These are all OS-independent. (Actually, I don't understand the second point, does this refer to ribbon again?)

> -Easy to distinguish from IE at a glance

This one indeed is OS-dependent, but I'm sure it's not a deciding factor.

> Cons:
> -Minor efficiency loss due to the mouse having to travel slightly farther (it
> would be great to run a Test Pilot study on this so we can understand exactly
> what the difference costs in terms of average time for tab selection with the
> mouse)

This is the most common argument against tabs on top, and yes, it would be very helpful to meet it with some hard facts.

> -Harder to distinguish from Chrome (which is admittedly less common of a
> situation than distinguishing from IE).
> 
> Unrelated to Usability:
> -There is a general perception that placing tabs in a more conceptually pure
> configuration is "modern and sleek" while the traditional placement is "old and
> clunky."  This is purely an emotional design and brand level consideration,
> primarily caused by Chrome being the "new" product in the marketplace, and
> Firefox presently being the "old" product in the marketplace.  Had we made the
> change with Firefox 3 on Vista, we would not currently be facing this
> situation.  However we are now at a state where deploying the more conceptually
> pure design is "copying" or "catching up," and failing to deploy it may be
> interpreted as "stagnating" or "falling behind."  The product perception issues
> related to tab placement appear to be a lose/lose at this point.

This is also OS-independent.

So... some users who're probably using Chrome already would say we stagnate. I think that's ok, as long as the rest appreciates the consistency and as long as we refresh the look regardless of the tabs' position.
I'm not saying that we cannot move the tab bar, but we should have good reasons beyond a vague coolness factor.

Comment 13

[IU]

(In reply to comment #12)
> I'm not saying that we cannot move the tab bar, but we should have good reasons
> beyond a vague coolness factor.

Wouldn't the most reasonable solution be to fix bug 347930?  Then people can do with the tab bar whatever floats their boat.  Then this debate would be pretty much moot.

Comment 14

[Dão Gottwald [:dao]]

The debate is about the default position.
But I agree that just making it customizable could satisfy the users who'd think we're stagnating.

Comment 15

[Alex Faaborg [:faaborg] (Firefox UX)]

>IU: Then people can do with the tab bar whatever floats their boat.  Then
>this debate would be pretty much moot.

We want the arrangement to be fully customizable by the user, so we won't be taking away any control.  However the debate is more specifically about what default interface we want to ship to users on each platform, since the vast majority of users will simply stick with the default configuration that they are given.

>Dao: These are all OS-independent.

Yeah, the only reason we are looking at different tab configurations for each OS right now is that placing the traditional menu bar below the tabs (for instance on XP or Linux) would feel really strange, and clash with the surrounding applications both visually and interactively.  Also in general XP users may value consistency with the past over what we believe is a better design.

>Actually, I don't understand the second point

Giving the user a metaphor to something from the real world:
http://upload.wikimedia.org/wikipedia/commons/4/43/43foldersexample.jpg

Comment 16

[Alex Faaborg [:faaborg] (Firefox UX)]

>just making it customizable could satisfy the users who'd think we're stagnating

But wouldn't help us with the tech press who are going to write generalizations based on their first run experience and set a larger narrative that will filter out to general users who repeat universally agreed upon memes and assertions.

Comment 17

[Damian Shaw [Quan]]

This discussion is becoming a little fragmented and off topic and this bug is only a mix of older bugs.

The point I see is if this bug is fixed properly you want have UI redyndancy:

* Default or option to not have title displayed twice
* Only 1 'new tab' button as apposed to the currently situation of 1 customisable one and 1 static one

The only other 'real' win as I see it is:

* Default or option to have more screen space for content

This is clearly not to do with fitting in with the OS, if you remember what IE8 did was stick the address bar above the menu bar and there's been no push to do that on Windows. Either these 3 points are a big enough win for users (logical hierarchy and minuscule situational win on Fitt's law don't seem to stand strong enough for me) or they're not.

But almost all of this would of been doable by planning and fixing pre-existing bugs (this one doesn't seem very axiomatic and hence the fragmented discussion).

Comment 18

[Marco Bonardo [:mak]]

(In reply to comment #12)
> > -Minor efficiency loss due to the mouse having to travel slightly farther
> This is the most common argument against tabs on top, and yes, it would be very
> helpful to meet it with some hard facts.

On the other side, in the default configuration (tabs on bottom with bookmarks toolbar), i have to pay more attention selecting a tab to avoid clicking on bookmarks. With tabs on top i could better use peripheral vision, paying less attention to the "surroundings" (Apart the pathological case of the window's close button. So i feel like the movement is longer but i can pay less attention to it, and so it's faster.
This could be seen as a problem of the bookmarks toolbar more than the tab bar, but it somehow exists.

Comment 19

[WildcatRay]

(In reply to comment #18)
> (In reply to comment #12)
> > > -Minor efficiency loss due to the mouse having to travel slightly farther
> > This is the most common argument against tabs on top, and yes, it would be very
> > helpful to meet it with some hard facts.
> 
> On the other side, in the default configuration (tabs on bottom with bookmarks
> toolbar), i have to pay more attention selecting a tab to avoid clicking on
> bookmarks. With tabs on top i could better use peripheral vision, paying less
> attention to the "surroundings" (Apart the pathological case of the window's
> close button. So i feel like the movement is longer but i can pay less
> attention to it, and so it's faster.
> This could be seen as a problem of the bookmarks toolbar more than the tab bar,
> but it somehow exists.

FYI-As someone who has used Firefox dating back to before it was Firefox, I cannot recall ever going to select a tab and clicking on a bookmark instead.

As for "hard" data, I use a Microsoft Wheel Mouse Optical with minimal acceleration on WinXP. I adjust the pointer speed to one that allows me to cover the screen in reasonable movements.

I prefer no acceleration at all as I have found any form of pointer acceleration totally unintuitive. (When I switched to WinXP from Win2K, the mouse control software stopped offering the UI to turn acceleration off. Go figure.) When I have tried using acceleration, it seems like I have to sneak up on whatever I was going to click or I'd overshoot it.

Even since I added the Compact Menu 2 extension which allows me to hide the menu bar, I have yet to have a situation where I mistakenly clicked on a bookmark in the bookmark toolbar when I intended to select a tab.

Recently, I installed Ubuntu. It has the mouse set up as a generic Mac OS mouse with only acceleration and sensitivity adjustments. It makes me wonder if many of the issues being discussed about the merits of where the tabs should be located are not more issues of how the mouse or other pointing device is set up. Does the choice of high vs. low or no acceleration have a greater impact on whether the user clicks on the tab than does the choice of tab position being on top or on bottom?

Comment 20

[Marco Bonardo [:mak]]

(In reply to comment #19)
> FYI-As someone who has used Firefox dating back to before it was Firefox, I
> cannot recall ever going to select a tab and clicking on a bookmark instead.

indeed, that's because you actually look at the tab bar with attention when selecting a tab. Trying Chrome i've noticed i look less at the tab bar, i recall the position of various open pages and i just move up the pointer and click. I never pointed out that as a "common issue", indeed i also never mis-clicked, but my eyes spend more time on tabs.

Comment 21

[IU]

A possible solution:

For the first build (and minor updates) with relocatable tab bar:
1. Default it to on-top for everyone, but...
2. Have a per-profile first-run notification (or start page) that introduces the user to the option and includes a toggle that immediately show and sets the user's selection.  A start page (tab) would likely be better, because it would be less intrusive and users already familiar with the option can casually ignore it.  Dismiss the tab once the user chooses to commit the selection.

For subsequent major builds:
1. Default to on top for new installations, but maintain the user's setting for upgrades
2. By now there should have been sufficient coverage that the start page (tab) should no longer be needed.

Comment 22

[Alex Faaborg [:faaborg] (Firefox UX)]

>With tabs on top i could better use peripheral vision, paying less
>attention to the "surroundings" (Apart the pathological case of the window's
>close button. So i feel like the movement is longer but i can pay less
>attention to it, and so it's faster.

It's definitely the case that an increased number of targets makes it more difficult for the user to locate a specific target (not necessarily in terms of misclicks, but just in terms of identifying what they want to click on, quantified in milliseconds of cognitive processing time).  So when I said a minor efficiency loss, I guess it is fair that that was meant in terms of the physical action of targeting the tab, and we could potentially even make up the difference if we happen to cut down the user's conceptual processing time.  Unfortunately, humans are way more complicated than computers so it's hard to know ahead of time which interface is more efficient. (although efficiency is really just one aspect of the overall design, with conceptual complexity and visual design also coming into play).

Here are two potential studies we could do to answer the specific efficiency question:

1) Using Test Pilot, we could record a time stamp and screen coordinates when the mouse has transitioned from being in a resting position to now moving.  If the user clicks on a tab, we record a second time stamp and coordinates (and if the user clicks on something that isn't a tab, we just throw away the initial data). This will allow us to calculate average distance and time on task for all mouse based tab selections.  We can then run the study with both interface to get a sense of the change.  Since we are aggregating across a large number of users this allows us to hopefully account for variations like the number of items on the bookmarks toolbar, the user's mouse sensitivity (which as discussed above definitely comes into play), environmental aspects like if the user is in a noisy coffee shop, etc.

2) We could also reach out to NASA Ames to see if they are interested in running another cognitive modeling study for us.  This simulates everything and doesn't involve actual users, and the data is based on what are believed to be baseline values for normal human mental and physical abilities. (critics would argue that these values are simply representative of 20-something college students forced to complete cognitive science experiments for extra credit at a number of American universities).   Normally this kind of study is done for physical interfaces like the controls of a fighter jet, but NASA previously did a study for us on the positioning of the tab close button:

http://people.mozilla.com/~faaborg/files/20070509-CHI2007/p1783.pdf

However, I really do expect that if we run these studies the result will be that tabs on top is a less efficient interface (although perhaps only slightly).  It would be interesting to finally quantify this, but I'm primarily interested in the design for the reasons beyond pure efficiency, like the cleaner conceptual model and sleeker visual design.

Comment 23

[Ria Klaassen (not reading all bugmail)]

My opinion is that Firefox should not change the existing position of the tabs. The arrangement of toolbars and objects on the toolbars is usually already based on tabs below the toolbars. The majority can't be converted anymore.

But for new users that's another story and in that case the best presentation should be offered. Maybe Firefox could do a check on startup if there is an existing profile (e.g. a localstore.rdf file with data) and in that case it should decide to leave the tabs below the toolbars. If there is no localstore data in the profile it is a new configuration and then the tabs should be positioned on top.

A great idea would be a set of 3 choices in the Options window:

1. tabs on top
2. tabs under toolbars
3. tabs between page content and statusbar

Comment 24

[Koogle]

So long as this **** doesn't effect the design of my private awesome skin then I'm fine with it with power functionality in the menu bar!.. the new FF4.0 style looks ****, tabbar over navigation is just stupid and retarded, when the importance is on the tabs being closer to the page layout, and representing the current tab page  ...tabs above navigation is the sort of retarded Google chrome **** design.

Navigation/address bar is better above tab buttons, where tab buttons are closer to window content! 

"* Fix a redundancy in having both a titlebar with page title as well as a tab
with the page title"

Only a **** moron wouldn't understand that having a window application/document  Title in the same fixed position helps with user desktop management and alt-tab.. keeping the title location in a fixed locations helps user navigation. Much like XP, until those **** morons at Microsuck decided that lets **** up the Explorer shell, and have some windows not show a title in a fixed window location properly.. and then more morons like the idiots redesigning whats going to end up being SHITFOX at its current pace of **** added and useless effort going in decided that not allowing users to see a window/app site address in a fixed location... and instead have to look in some other VARYING position was some sort of **** bright idea.. well its **** not you idiots!

"* A Fitt's Law win if the window is maximized"

Fitts Law FAIL, if window isn't maximized! WHICH IT MOST OFTEN ISN'T YOU PRICKS

"* A small vertical space savings allowing more room for content"

hey what **** content.. you effing morons are taking away content and functionality.. heck you **** idiots haven't actually done anything to improve content and functionality since like forever.. the majority of content and functionality provided in the browser is by third party developers, adding the power browsing useful features. 

And reducing toolbar height is not the **** problem.. the problem is in your **** retarded design.. Go **** check Maxthon2 for how a window layout could have been achieved and still allow for a title bar! Aswel as reduced UI space allowing for extra page content height!

"* Creates a more streamlined UI"

Creates a pathetic piece **** designed for noobtards! And forces any other real theme designed to have to work around defaulty ****! and make heavy changes just to get back to how its already a better setup.

Comment 25

[Wes Kocher (:KWierso) (Not reading bugmail; email directly if needed)]

I vote you make the tabs on top change the default AND unchangeable, just for the guy in comment 24...

Comment 26

[Koogle]

Go ahead make my day, Firefox 3.6, 3.7 /4.0 have already shown plenty of signs of heading down the **** anyway. The only thing holding this bucket of junk up is the third party developer support in addons anyway.

UN-Customizable **** designed for retards like Google Chrome was, for such nooblets like the above poster, will do nothing to keep the real professionals around.

I'd sooner head back to Maxthon, they at least have a clue about innovation and providing users with decent browsing features, before its much later ripped off by other browsers.

Comment 27

[u88484]

(In reply to comment #24)
(In reply to comment #26)
If you actually want the developers to listen to your complaints you should start by not acting immature and then spell out your complaints with examples rather then cursing immaturely and attempting to put people down.  Grow up!

You need to read the bugzilla etiquette (https://bugzilla.mozilla.org/page.cgi?id=etiquette.html) and then take your spam to the newsgroups, like here http://groups.google.com/group/mozilla.dev.apps.firefox/browse_thread/thread/9e569626887ae703?tvc=2&q=Proposed+Direction

Comment 28

[Alex Faaborg [:faaborg] (Firefox UX)]

As Kurt suggests discussion over the advantages and disadvantages of the change should really move to the newsgroups.  Debating in bugs focused on specific development work limits broader discussion and is less transparent to the community.

Comment 29

[Ivan Ičin]

(In reply to comment #28)
> As Kurt suggests discussion over the advantages and disadvantages of the change
> should really move to the newsgroups.  Debating in bugs focused on specific
> development work limits broader discussion and is less transparent to the
> community.
Well, I won't answer here for rebellious reason to be contrary to the above, but because discussion here is much more developed than in that link on news groups, and I don't see how to port it there. And my comment is serious, and not the one that caused critics anyway.

I think that efficiency should measure Fitt's law against longer traveling of mouse on the one side, and importance (frequency of click) of toolbar items vs tabbar items on the other.

So, first question is whether people more quickly click on items positioned directly above content, or at the top of the window (if maximized)

And then next question is which items people use more - toolbar or tabbar. And then more important items should be positioned in more prominent place.

Comment 30

[Koogle]

users goto click on the tabs way more often than toolbar buttons or even the location bar.

completely fcking retarded design, I'll just go suggest notepad++ place the tabbar above those toolbar icons.. I'll just go suggest to a bucket load other developers that document tabs now need to be above TOOLBAR buttons and any other less important ****, because the actual document view and document tabs now must be placed further apart, because retards like Google and Firefox designers think this is better more intelligent design, its hardly intuitive or fluid for any user let alone a power user. I'll just put this down as designed for clueless noobs by noobs.

And Google couldn't design anything properly, like their newsgroup -sucks, the simple and dumbed down they can make something the easier for them, its the only reason their search is successful. And just look at the chrome browser ain't nothing good in that. Simplified garbage, much like Firefox 4.0 will be when all menu items get crammed into one button.. that is the kinda **** you see coming out of MSIE

and the extra fail is removing a fixed position title window/tab title (+ or any extra info)  at the top of the window layout.. only retards could screw up desktop window management and  UI layouts this badly, its like a combined effort of megatardation supported by idiots at Apple, Microsuck, Google and now Mozilla, who've really only had the success on the backs of good third party extension developers anyway.

Really disappointingly weak changes (they ain't even improvements by a longshot)

by now I should be seeing a browser going into supporting a intuitive power features like giving users the ability to pull out videos objects into a seperate window with extra options like Always ontop so users can carry on browsing ie http://forum.maxthon.com/viewthread.php?tid=74749

And more features improvements, not removing things like 'element properties'  no no don't IMRPOVE IT.. just remove it for the retards, how dumbed down are things going to get.

or many other actually useful browser and feature enhancements.

Comment 31

[Ivan Ičin]

(In reply to comment #0)
> * Gives Firefox a correct UI hierarchy where the controls are tab specific
Actually, this is only half true. I think it more adds to inconsistent UI hierarchy than it helps. 

My argument is that sidebar is in no way Tab related, and it seems that it will appear under tabs in new design. If it is meant to squeeze all panels on open, then this is not the case, but then there is another problem, and that is Fitt's law and position of back button.

Comment 32

[Leman Bennett [Omega]]

Ria Klassen has a really solid idea.

Those upgraded to 4.0 should have their minimal customizations intact. As in, Default Strata user made a button move to a specific position or the Bookmarks ToolBar active, the upgrade should have no affect on them other than aesthetics and tabs below the location bar exactly how they remembered it.

A mention should be made on the Firefox Upgrade landing page that the tab bar could be repositioned above or below at will. Because the Firefox selling point is all about customization and choice.

New Users that are installing Firefox for the first time should get the default layout, which would be tabs above location bar and bookmarks toolbar off. The Landing page once again will take care of communicating that it can be changed if its unsettling.

Its a very friendly and thoughtful approach.

Comment 33

[Ivan Ičin]

(In reply to comment #0)
> * Gives Firefox a correct UI hierarchy where the controls are tab specific
I thought some more on this...

I think that opening new tab with middle click is somewhat weird with tabs on top, but probably not so much that people can't get used to. But opening new tab with alt+enter from location bar, or middle clicking go, or middle clicking bookmark... it is pretty confusing and not proper hierarchy.

(In reply to comment #32)
> Ria Klassen has a really solid idea.

> New Users that are installing Firefox for the first time should get the default
> layout, which would be tabs above location bar and bookmarks toolbar off. The
> Landing page once again will take care of communicating that it can be changed
> if its unsettling.
There is no argument for this. If you want to say that some people got used to tabs below, and you shouldn't change that, then it doesn't apply just to Firefox users, but also to IE and Opera users, and why you have right to confuse them more than you confuse Firefox users? (Of course, if that's confusing at all)

Comment 34

[Leman Bennett [Omega]]

The only (In reply to comment #33)

> There is no argument for this. If you want to say that some people got used to
> tabs below, and you shouldn't change that, then it doesn't apply just to
> Firefox users, but also to IE and Opera users, and why you have right to
> confuse them more than you confuse Firefox users? (Of course, if that's
> confusing at all)

I'm sorry. If you're confused, then I invite you to read it again. Its pretty straight forward.

Comment 35

[Ivan Ičin]

I am sorry, I can only repeat what I said above, and add that tabs below are not customization but default, as there is no way to put them in any other position in Firefox 3.6.

Comment 36

[IU]

Why not fix bug 347930, which this bug depends on, then run a trial with users trying the alternate positions and submit reports of which works best?

Then you will know for sure, instead of spending weeks arguing about what might be, could be, should be, isn't.

Comment 37

[Peter Lairo]

Lugging the UI around with each tab *feels* sluggish and bloated and disorienting. This is just one more reason (of the MANY given in this bug) why tabs on top is a bad idea. I have read very few reasons (none convincing) why tabs on top would be better. Another case of personal whim combined with power winning over reason.

Comment 38

[Josh Tumath]

There is absolutely no point in discussing where it should go. The only way that we can possibly be sure of this is with usability testing. If we argue about it, we are only wasting each other's time.

Comment 39

[d]

(In reply to comment #38)
> There is absolutely no point in discussing where it should go. The only way
> that we can possibly be sure of this is with usability testing. If we argue
> about it, we are only wasting each other's time.

And the good thing is that when we get it done, we can always offer the option, even though it may be disabled by default.

Comment 40

[mucinch]

I don't think we should bother with UI parity with Microsoft products. They are not known for maintaining UI consistency and nativity within their own products. Mac is a different scenario, but most Windows users never expect consistency between Windows and a 3rd Party UI.

Also most people are used to tabs-on-bottom as only Chrome implements to tab-on-top version. So implementing the new version as default for 95% internet users breaks familiarity and is illogical.

There doesn't seem to be a big gain in space between the two versions. If I can change to my preferred version without resorting to an addon, I will be definitely happy.

Comment 41

[David Vo [:auscompgeek]]

(In reply to comment #40)
Opera also has a tabs-on-top UI. Of course (to repeat), there will be an option for tabs-on-top and this will only be the default on Vista/7.

Comment 42

[Peter Lairo]

(In reply to comment #41)
> tabs-on-top [...] will only be the default on Vista/7.

And that default is exactly the problem.

There is a thread in news://news.mozilla.com:119/mozilla.dev.apps.firefox (Subject: New Theme/UI Work Initiated) that addresses this issue. It would be great if someone could summarize (via a bullet list) all the disadvantage and advantages of placing the tabs separate from the content (that were brought up in the various comments here) in that discussion thread.

Comment 43

[Dão Gottwald [:dao]]

Attachment: wip, optional tabs on top

Comment 44

[Paul [pwd]]

I'd be all for tabs on top if they were presented like a ribbon, with a container coming down from the tab to encapsulate the navigation bar and bookmarks toolbar. At the moment, in all the mockups, it looks messy and rather like it's just an attempt to follow a new standard rather than that it's been a real design goal. If it's given the feel of the Microsoft Office, you somewhat deviate from what Opera and Chrome has done, while sticking to the principles but allowing for real integration of feel and an innovative approach.

I'd even go as far as to say you can then have the bookmarks toolbar slide out from the right and 'hover' over the ribbon pushing all the navigation buttons to the left slightly. Or simply have it as another permanent tab like the home tab.

The possibilities are endless but the ideas proposed in current mockups are a little off and unimaginative.

Comment 45

[Paul [pwd]]

Also, using a ribbon would allow for application of personas on a glass based themed, even if there's transparency on the ribbon by default.

Comment 46

[Peter Henkel [:Terepin]]

(In reply to comment #24)
> **** retarded design.. Go **** check Maxthon2 for how a window layout
> could have been achieved and still allow for a title bar! Aswel as reduced UI
> space allowing for extra page content height!

http://blog.blog.zive.cz/files/2010/03/mx3084.png
Wana say something intelligent about that?

Comment 47

[Alex Faaborg [:faaborg] (Firefox UX)]

The purpose of this bug is for design and implementation discussion, please disregard the trolls.

Comment 48

[Peter Henkel [:Terepin]]

My appologize. But too late, troll has already infected my mail.

Comment 49

[Al Billings [:abillings - ex-MoCo]]

Mr. Henky, don't feed the trolls.

Comment 50

[u310142]

What about tabs on the side? Is that still planned? Is there a separate bug for that?

Comment 51

[Darren Kalck [:D-Kalck]]

AFAIK, it has never been *planned*

Comment 52

[u310142]

Oh... well, that's disappointing. :(

Comment 53

[Peter Henkel [:Terepin]]

Aside the fact that there are add-ons for that, most of today's monitors are 16:9, or 16:9. They have plenty of width space, but reduced height space. Whats the point placing them vertical instead of horizontal? Do you want from page to look like cube?

Comment 54

[Dão Gottwald [:dao]]

That discussion doesn't belong in this bug.

Comment 55

[Paul [pwd]]

In regards to the bookmarks toolbar, it's current use is about the quick loading of frequently used sites and with tabs on top, you generally break the hierarchy IMO. Could it not be considered in having them in a panel that drops down over the tab and navigation bar once the mouse is moved to the top of the screen? Or even have the favicons sit beside the app button ala Office 2010 (Save, Print, Undo)?

Comment 56

[RNicoletto]

(In reply to comment #50)
> What about tabs on the side? Is that still planned? Is there a separate bug for
> that?

This is Bug 218280.

Comment 57

[Dão Gottwald [:dao]]

Attachment: patch

Comment 58

[Peter Henkel [:Terepin]]

After landing this in trunk, could be the next step drawing in titlebar?

Comment 59

[Darren Kalck [:D-Kalck]]

I think the next step will be the new style for tabs.

Comment 60

[Peter Henkel [:Terepin]]

Oh, yeah, I forgot about that.

Comment 61

[:Gavin Sharp [email: [e-mail]]]

Comment on attachment 436744 [details] [diff] [review]
patch

>diff --git a/browser/base/content/browser.js b/browser/base/content/browser.js

>+var TabsOnTop = {

>+  set enabled(val) {

>+    //XXX: Trigger reframe. This is a workaround for bug 555987 and needs to be
>+    //     removed once that bug is fixed.
>+    gNavToolbox.style.MozBoxOrdinalGroup = val ? 2 : 3;

Where do 2 and 3 come from? Just arbitrary non-default values?

>+  toggle: function () {
>+    this.enabled = !this.enabled;
>+    this.syncCommand();
>+  },

Makes more sense to put the syncCommand() in the enabled setter, doesn't it?

Do you really not need border/margin style changes based on position for windows/linux, as in attachment 432165 [details] [diff] [review]? I only tested this on Mac.

Probably wouldn't hurt to get UI-review for the menu items.

Comment 62

[:Gavin Sharp [email: [e-mail]]]

Comment on attachment 436744 [details] [diff] [review]
patch

Oops, I submitted that too early. It looks like this patch doesn't work in my Mac build, I think because the "force a reframe" hack isn't effective.

Comment 63

[:Gavin Sharp [email: [e-mail]]]

Actually it doesn't seem to work even after a restart or for new windows, so maybe there's more to it than that. I don't have time to investigate further at the moment.

Comment 64

[Dão Gottwald [:dao]]

(In reply to comment #61)
> >+    //XXX: Trigger reframe. This is a workaround for bug 555987 and needs to be
> >+    //     removed once that bug is fixed.
> >+    gNavToolbox.style.MozBoxOrdinalGroup = val ? 2 : 3;
> 
> Where do 2 and 3 come from? Just arbitrary non-default values?

Yes.

> >+  toggle: function () {
> >+    this.enabled = !this.enabled;
> >+    this.syncCommand();
> >+  },
> 
> Makes more sense to put the syncCommand() in the enabled setter, doesn't it?

Yes.

> Do you really not need border/margin style changes based on position for
> windows/linux, as in attachment 432165 [details] [diff] [review]? I only tested this on Mac.

It's not really needed, and since the tab styling is going to change anyway, I didn't bother.

Comment 65

[Dão Gottwald [:dao]]

(In reply to comment #63)
> Actually it doesn't seem to work even after a restart or for new windows, so
> maybe there's more to it than that. I don't have time to investigate further at
> the moment.

If you had the earlier patch applied, the 'ordinal' attribute might still be set on TabsToolbar. It will override any -moz-box-ordinal-group setting.

Comment 66

[Dão Gottwald [:dao]]

Attachment: patch v2

Moved the syncCommand call.

Alex, this adds a separator and a "Tabs on top" checkbox at the bottom of the View > Toolbars menu and to the similar toolbar context menu. Is this ok? Doesn't necessarily need to be the final UI.

Comment 67

[:Gavin Sharp [email: [e-mail]]]

Comment on attachment 436849 [details] [diff] [review]
patch v2

> the 'ordinal' attribute might still be set on TabsToolbar

indeed, that was the problem...

Comment 68

[Alex Faaborg [:faaborg] (Firefox UX)]

Comment on attachment 436849 [details] [diff] [review]
patch v2

Ok for now, but we'll likely revisit the UI later.

Comment 69

[Dão Gottwald [:dao]]

http://hg.mozilla.org/mozilla-central/rev/4918e122e6eb

Comment 70

[Philipp von Weitershausen [:philikon]]

Very cool to see this land! If I may nitpick, the menu item's label should probably be capitalized ("Tabs On Top"). At least that seems to be the convention for English menu items. Of course feel free to ignore me if this UI is just temporary :)

Comment 71

[Peter Henkel [:Terepin]]

Very cool indded. Now, only new tabs and we have basic FX4. That is even cooler!

Comment 72

[u88484]

Verified fixed Mozilla/5.0 (Windows; U; Windows NT 6.1; en-US; rv:1.9.3a4pre) Gecko/20100406 Minefield/3.7a4pre

(In reply to comment #70)
> Very cool to see this land! If I may nitpick, the menu item's label should
> probably be capitalized ("Tabs On Top"). At least that seems to be the
> convention for English menu items. Of course feel free to ignore me if this UI
> is just temporary :)

File a new bug but there are two menu options that aren't all capitalized (Help -> Check for Updates, Bookmarks -> Subscribe to This Page)

Comment 73

[Alex Faaborg [:faaborg] (Firefox UX)]

I'm not sure if "on" counts as a capitalized word in title case.  We could really use a contributor who is an actual real life editor :)

Comment 74

[Philipp von Weitershausen [:philikon]]

(In reply to comment #73)
> I'm not sure if "on" counts as a capitalized word in title case.  We could
> really use a contributor who is an actual real life editor :)

You're right, I forgot about title case. Of course the question is which variant of title case to use... I'm not an editor, but it seems to me that menu items capitalize all words except internal articles, prepositions, and conjunctions (cf. http://en.wikipedia.org/wiki/Title_case#Headings_and_publication_titles). That's why it's "Check for Updates", "Subscribe to This Page" and "Open in New Tab" but "Save As…" and "Zoom In" (the preposition isn't internal in the latter).

So I'll change my nit to "Tabs on Top". ;)

Comment 75

[Alexandre Folle de Menezes]

Maybe I got this wrong, but shouldn't the Tabs bar be under the menu bar?  Actually, shouldn't I be able to rearrange the order of the bars?

Comment 76

[Philip Chee]

Rearranging the order of the toolbars is a long standing (existing bug).

Comment 77

[tymerkaev]

Attachment: That option can be moved to Options window (screenshot)

Comment 78

[Peter Henkel [:Terepin]]

I was wondering why it wasn't done this way in the first place.
Keybord shortcut would be nice and practical.

Comment 79

[Paul [pwd]]

(In reply to comment #76)
> Rearranging the order of the toolbars is a long standing (existing bug).

Not due to be fixed any time soon I take it?

Comment 80

[u88484]

This bug is fixed so please file new bugs for whatever enhancements/changes keep spamming this bug.

Comment 81

[Dennis Jacobfeuerborn]

(In reply to comment #76)
> Rearranging the order of the toolbars is a long standing (existing bug).

Does this bug have a number? As it stands the only thing the "tabs on top" feature does is mess up the UI.

Comment 82

[Paul [pwd]]

(In reply to comment #81)
> (In reply to comment #76)
> > Rearranging the order of the toolbars is a long standing (existing bug).
> 
> Does this bug have a number? As it stands the only thing the "tabs on top"
> feature does is mess up the UI.

https://bugzilla.mozilla.org/show_bug.cgi?id=172818

Comment 83

[Manoj]

This isn't completely fixed on Mac. After selecting "Tabs on top" from the View menu, tabs did in fact move to the top of the window (yay!). The Tab bar returned to its original position after I clicked the "Minimize Chrome" button in the upper right hand corner of my firefox window twice. I thought the "Tabs on top" menu-item's state would have toggled as well; it still showed that "Tabs on top" was enabled. I considered filing a new bug for this, but this isn't a new bug; the current implementation doesn't cover all the use-cases on Mac.

Comment 84

[Markus Stange [:mstange]]

Please file a new bug anyway; it needs a fix that doesn't have much to do with the fix in this bug. (I think it's something about frame construction and the ordinal attribute.)