Open
Bug 130061
Opened 23 years ago
Updated 11 years ago
Tabs should be a toolbar above urlbar
Categories
(SeaMonkey :: Tabbed Browser, enhancement)
SeaMonkey
Tabbed Browser
Tracking
(Not tracked)
NEW
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.
Comment 2•23 years ago
|
||
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.
Reporter | ||
Comment 3•23 years ago
|
||
At least the urlbar is instanced (logically), too, as the switching shows.
Reporter | ||
Updated•23 years ago
|
Summary: Tabs should be a toolbar → Tabs should be a toolbar above urlbar
Comment 4•23 years ago
|
||
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.
Reporter | ||
Comment 5•23 years ago
|
||
> 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.)
Comment 6•23 years ago
|
||
>> 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.
Reporter | ||
Comment 7•23 years ago
|
||
> 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.
Comment 8•23 years ago
|
||
I think moving the personal toolbar above the nav bar would approximate the
function requested without imposing the drawbacks.
Comment 9•23 years ago
|
||
> 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.
Reporter | ||
Comment 10•23 years ago
|
||
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.
Comment 11•23 years ago
|
||
> 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?
Reporter | ||
Comment 12•23 years ago
|
||
> 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.
Comment 13•23 years ago
|
||
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.
Updated•23 years ago
|
QA Contact: sairuh → pmac
Updated•17 years ago
|
Assignee: marlon.bishop → nobody
Severity: normal → enhancement
QA Contact: pmac → tabbed-browser
Assignee | ||
Updated•17 years ago
|
Product: Core → SeaMonkey
Comment 14•17 years ago
|
||
I don't think I'd like this
Reporter | ||
Comment 15•15 years ago
|
||
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.
Comment 16•11 years ago
|
||
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.
Description
•