Open Bug 130061 Opened 23 years ago Updated 11 years ago

Tabs should be a toolbar above urlbar

Categories

(SeaMonkey :: Tabbed Browser, enhancement)

enhancement
Not set
normal

Tracking

(Not tracked)

People

(Reporter: BenB, Unassigned)

References

()

Details

The tabs are below the main with the Back button and urlbar. This is semantically wrong, because the main toolbar applies to a certain page, not all of the tabs are once. Currently, when I switch tabs, the content of the urlbar above it changes, which is very odd. The idea of tabs is that you switch between different contents *below* (or above or left or right of) them. I.e. we currently violate the UI pattern of tabs. Suggestion: Make the Tab-bar a (minimizable) toolbar, located between the menu bar and the main toolbar.
marlon?
Assignee: jaggernaut → marlon
page tabs are indeed contained on a toolbar - the tab bar. at least that's how we chose to design the feature. the location of the tab bar is as designed. we explicitly decided not to promote the notion of distinct browsing instances underneath each tab, which is what you are proposing. the content area is what is being instanced, which is why it is located there.
At least the urlbar is instanced (logically), too, as the switching shows.
Summary: Tabs should be a toolbar → Tabs should be a toolbar above urlbar
what you propose duplicates everything from personal toolbar to sidebar. that's not how the feature was intended to function. instead, the url remains distinct but everything else persists. it was not essential to duplicate everything. technically, all of the performance gains would be lost as well.
> personal toolbar to sidebar hm, yes. (I have them always hidden) > instead, the url remains distinct but everything else persists. No, the same happen for the Back button. If I press "Back", only the page in the current tba goes back, not all tabs. Consequently, the Back history (the little down arrow with the popup menu) also swtiches when I switch tabs. Similarily, the throbber spins only, if something in the current tab loads. So, *all* of the main toolbar is specific to a certain tab. > technically, all of the performance gains would be lost as well. That's a different question. It depends on the implementation. It is thinkable (and probably also doable) to keep the current implementation of reusing the same instance of the main toolbar while still changing the order. If that is a good approach remains to be seen. (Compare bug 104778.)
>> personal toolbar to sidebar >hm, yes. (I have them always hidden) hm tell me, why should we care what *you* have elected to hide? >> instead, the url remains distinct but everything else persists. > >No, the same happen for the Back button. If I press "Back", only the page in >the current tba goes back, not all tabs. Consequently, the Back history (the >little down arrow with the popup menu) also swtiches when I switch tabs. >Similarily, the throbber spins only, if something in the current tab loads. >So, *all* of the main toolbar is specific to a certain tab. What purpose would it serve to locate the main toolbar, back, forward, stop and reload button, under each tab? it would be totally futile. there's no benefit, those features are the same for every tab. your 'semantics' are apparently just your own point of view. the main toolbar controls the content area - the content area is tabbed. no matter what's in view main toolbar applies to the tabbed content currently in view. i see no difficulty with this, please explain further. do you have only one remote for your television? oh, but you would need a separate remote for each channel to be semantically correct. then you'd need to store about 150 remotes in a library of some sort. then next to the library you'd have a chart of code numbers assigned to each remote, you just need to cross reference the channel you want to watch against the codes on that chart to get the right remote.
> hm tell me, why should we care what *you* have elected to hide? I meant to say that I completely forgot about the sidebar and that I have no solution for that case. > your 'semantics' are apparently just your own point of view. No, <http://www.iarchitect.com/tabs.htm> describes the same semantics. It says that the OK button should be placed outside the tabs, because it applied to the whole dialog, not just the currently open tab. It says that MS' failure to ddo so at first confused users. We have the opposite situation here: The Back button applies to the currently open tab only, so it should be part of it. IMO, placing the tab above the toolbar would make the UI clearer. But you are the UI guru.
I think moving the personal toolbar above the nav bar would approximate the function requested without imposing the drawbacks.
> The Back button applies to the currently open tab only, > so it should be part of it. Yes, but the reason for the criticism of MS's UI was that it would confuse the users if the buttons were where they were - they weren't quite sure what clicking it would do. Do you know of any user who is confused about what Mozilla's Back button will do? Is there anybody who thinks that hitting Back will cause *all* of the tabs to go back to a previous link? I don't think that there's a similar confusion here. People know exactly what the Back button (and other UI buttons) will do as it pertains to the tab that they're currently viewing. Given that there's no confusion about what the buttons actually do (point me to a reference if you do know of someone who's confused) it all comes down to what the elements themselves contribute in terms of the UI display. Keeping everything that's static at the top, and those things that are dynamic at the bottom makes the most sense. If a UI element will always display the same it should be "fixed". I don't think that the current arrangement is broken.
Jason, this is not so much about confusion, but correctness. > If a UI element will always display the same it But it doesn't. See above for e.g. the dropdown of the Back button.
> But it doesn't. See above for e.g. the dropdown of the Back button. Ah! Sorry, I missed that point. And, yes, you're right - that's inconsistent to some degree. (Although not in terms of the actual UI elements - just in terms of what they relate to.) Still, I find the current contextual dropdown (as well as the contextual URL bar itself) to be the lesser of two evils. I think that a redesign would introduce more wrong things than leaving it as it is. (I don't think that moving the toolbar on the basis of the dropdown is sufficient reason for doing so.) To carry your own argument further - the window title also changes as you switch tabs. Would you somehow want to redesign things (if it were technically possible, which I don't believe it is) so that the window title were below the tab bar?
> that the window title were below the tab bar? <http://fluxbox.sourceforge.net/zoom.php?shots/Mellerti_fluxbox1.jpg> :-) No, I am not seriously proposing that for Mozilla, of course.
Interesting, but it doesn't advance the proposal that all unchanging UI elements be at the top, while dynamic elements appear underneath. Note also that the menu item "Go" changes its history listing based on which tab you switch to. The menu bar (with Go), then, has exactly the same problem as the navigation bar (with its dropdown Back list). So - taking this into account - there actually is NO UI element which, itself or its contents, remains static. Considering that, it all just comes down to pure personal preference. To reword: Going back to comment 0, it appears that there are no (horizontal lines of) UI elements which apply to all of the tabs at once, so changing the order of any of them won't change the underlying problem.
QA Contact: sairuh → pmac
Assignee: marlon.bishop → nobody
Severity: normal → enhancement
QA Contact: pmac → tabbed-browser
Product: Core → SeaMonkey
Depends on: 347930
I don't think I'd like this
No longer depends on: 347930
https://wiki.mozilla.org/Firefox/4.0_Windows_Theme_Mockups#Large_Button_Mode_with_Bookmarks_Bar See "View / Toolbars / Tabs on top" in nightly (trunk / 3.7) builds of Firefox.
Having tabs-on-top possible, why not? I'd even say: great! Go for it! Having it mandatory (as in recent Firefox versions IIUC), not for me. Lets not imitate the Firefox guys when they forget the Mozilla Mission, which is about giving the user the choice, the power to make their own choices, and the certainty that their choices won't be reversed — not now, and not five years from now. Sure the Mission was developed for Web variety — the OS's proprietary browser *and* Firefox *and* SeaMonkey *and* Opera *and* what-have-you — but if we believe in choice, let's begin at home. Also, IMHO what made Mozilla products great is customizability: many extensions, many complete themes, many search engines, many preferences, many UI languages, many spellchecking languages, you name it. Choices again, and the mastery over them. SeaMonkey has (IMHO wisely) refrained (so far) from arbitrarily cutting down those choices. Users are a motley crew, any removal of a feature (if there is any) is going to be hated a lot by some, any feature we leave in won't much disturb those who don't use it. At most it will make about:config longer and the Preferences UI more detailed, but about the former, taking one pref away is like removing one drop from the ocean, and about the latter, the three or more levels of its structure (two levels of tree branching at left, plus the frames in each tab) make it both powerful and user-friendly (once you get the hang of it). I know that there are still some diehard users left who started using the Mozilla Suite before Firefox existed; I came the other way, to SeaMonkey from Firefox when they started removing features which could just as well have stayed in (saying "it is not discoverable, and anyway, nobody uses it", which was totally contrary to fact considering the protests that I saw in the newsgroups at the time). Our userbase is not identical to Firefox's, some salespeople would even say that SeaMonkey is a niche product, well, why not? Let's strive for quality, Firefox (and Chrome and even IE) can have quantity for all I care.
You need to log in before you can comment on or make changes to this bug.