Closed
Bug 102991
Opened 23 years ago
Closed 23 years ago
Decide name for Links toolbar
Categories
(SeaMonkey :: UI Design, defect)
SeaMonkey
UI Design
Tracking
(Not tracked)
RESOLVED
FIXED
People
(Reporter: gerv, Assigned: gerv)
References
Details
Attachments
(1 file)
695 bytes,
patch
|
jwbaker
:
review+
asa
:
approval+
|
Details | Diff | Splinter Review |
We never finalised the UI name for the Links Toolbar; there was a view that this
was not the ideal name, but no consensus on the right name. This bug is for
having that discussion.
Gerv
Updated•23 years ago
|
QA Contact: sairuh → claudius
Comment 1•23 years ago
|
||
In that case let me add my vote for "Site Navigation Toolbar".
Other possibilities:
"Site Toolbar"
"Document Toolbar"
"Related Pages Toolbar"
Comment 2•23 years ago
|
||
Site Navigation Toolbar gets my vote.
As Alan Cooper wrote, menus are allowed to be verbose because they function as
teaching aids as well as being command vectors. Save brevity for toolbars (and
then make up for it with tooltips!).
Assignee | ||
Comment 3•23 years ago
|
||
How about "Site Navigation Bar"? It's shorter with no loss of information, and
we have a precedent with Status Bar.
Of course, it's not vital to have it short because there are no submenus of the
menu it's on, so menu width is not a key factor. Still, it would look strange to
have it a lot longer than the others. I wouldn't be too distressed if people
felt it was important for it to be called a "Toolbar".
Gerv
Comment 4•23 years ago
|
||
Site Navigation Bar sounds great and has my vote
Comment 5•23 years ago
|
||
Yeah, I like 'Site Navigation Bar' too. I believe the term 'toolbar' is
generally only used for bars of buttons that replicate menu items.
Assignee | ||
Comment 6•23 years ago
|
||
Site Navigation Toolbar or Bar has sr=hyatt; we'll go with Bar and see if it
looks bad.
Patch coming up.
Gerv
Assignee | ||
Comment 7•23 years ago
|
||
Comment 9•23 years ago
|
||
Comment on attachment 52166 [details] [diff] [review]
Patch v.1
r=jwbaker@acm.org,choess@stwing.upenn.edu
Attachment #52166 -
Flags: review+
Comment 10•23 years ago
|
||
Comment on attachment 52166 [details] [diff] [review]
Patch v.1
a=asa (on behalf of drivers) for checkin to 0.9.5
Attachment #52166 -
Flags: approval+
Assignee | ||
Comment 11•23 years ago
|
||
Checked in.
Gerv
Status: NEW → RESOLVED
Closed: 23 years ago
Resolution: --- → FIXED
Comment 12•23 years ago
|
||
Damn, missed the party.
"Site Navigation Bar" sounds good.
Comment 13•23 years ago
|
||
[3:16 PM] * blake sees View > Show/Hide > Site Navigation Bar
[3:17 PM] * blake blinks.
[3:17 PM] <mpt> blake: Just filed it
[3:17 PM] <blake> good
[3:17 PM] <mpt> blake: 103417
[3:17 PM] <blake> and of course most people know what the site navigation bar
is, in comparison to the navigation bar..
[3:18 PM] <mpt> ho ho ho, don't get me started about the `Navigation Toolbar'
[3:19 PM] <choess> mpt: well, reopen the friggin bug, then, and suggest a
better name...
[3:19 PM] <mpt> choess: May I really?
[3:19 PM] <choess> mpt: it got closed without much discussion. go ahead.
> As Alan Cooper wrote, menus are allowed to be verbose because they function
> as teaching aids as well as being command vectors.
With all due respect to Dr Cooper, I disagree. Long menu items are harder to
scan (whether or not you're still learning the interface), they make the menu as
a whole more daunting by increasing its surface area, and they make all submenus
in the same menu harder to use by making the mouse path more convoluted. (For
example, consider how much easier it would be to open `Show/Hide' itself if
`Languages and Web Content' was removed from `View'.) Yes, `Site Navigation Bar'
shouldn't be a submenu. Yes, `Navigation Toolbar' will eventually be renamed.
But I still think the links bar item is unnecessarily long.
I suggest `Links Bar'. (The `More' menu in the bar itself should be `Other
Links'; I'll file that shortly.)
Status: RESOLVED → REOPENED
Resolution: FIXED → ---
Comment 14•23 years ago
|
||
> I suggest `Links Bar'.
I could live with that. However, IE already has a Links Bar. It's their version
of the Personal Toolbar. Yeah, it's a stupid name (but then again 'Personal
Toolbar' isn't so hot). If we have a Links Bar that's different to IE's Links
Bar then the poor IE user that switches to Mozilla (or Netscape or whatever)
will get confused.
Comment 15•23 years ago
|
||
At the risk of being labeled a heretic, I'd suggest that "Toolbar" be changed
to "Bar" everywhere. The Show/Hide menu now lists:
Navigation Toolbar
Personal Toolbar
Site Navigation Bar
Status Bar
Component Bar
"Navigation Toolbar" says nothing to me that "Navigation Bar" doesn't.
I don't like "Personal Toolbar" or "Personal Bar". It sounds like Alex Bishop
doesn't think much of it either (comments of Oct 6th). It seems to me that the
"Personal Toolbar" is really just bookmarks. I can't personalize it other
than to add a bookmark, can I? And a permanent entry on the bar is
"Bookmarks", which has all the bookmark functionality in it.
So I'd suggest "Bookmark Bar". The result would be:
Navigation Bar
Bookmark Bar
Site Navigation Bar
Status Bar
Component Bar
I agree that there is a potential problem with the duplication of "Navigation".
Unfortunately, the best name that comes to me is "Document Link Bar". I think
of the links as being more related to a document than a site.
Comment 16•23 years ago
|
||
How about:
View > Show/Hide Bars
Web Navigation
Site Navigation
My Bookmarks
Status
Components
Comment 17•23 years ago
|
||
We seem to have settled on a name, while at the same time creeping outside the
scope of this bug. I propose that we resolve this bug as FIXED, with "Site
Navigation Toolbar" as the name. Then someone open a new bug to cover the
discussion we've moved on to: revising the "View -> Show/Hide" menu. Does that
sound alright?
I know some object to the length of "Site Navigation Toolbar", but Ian seems to
have hit on the proper solution with his previous comment, and "Site Navigation"
seems short enough to satisfy.
Comment 18•23 years ago
|
||
'Site Navigation Toolbar'? I thought we agreed on 'Site Navigation Bar'. Or
maybe 'Links Bar'.
Agree with you that this isn't the place to discuss the wholesale renaming of
all the bars in the product.
Assignee | ||
Comment 19•23 years ago
|
||
The fact that this bar is populated using <link> elements is a technical detail
and should not be reflected in the UI. I believe "Links Bar" is not descriptive
enough. I like "Site Navigation Bar" because it's about the same length as
"Navigation Toolbar", and describes what it does very well. The length is less
important on this menu than others because it has no submenus.
If you wish to revise Show/Hide, feel free to file a bug. It's been tried
several times, but I never got anywhere personally.
I plan to re-close this bug soon.
Gerv
Comment 20•23 years ago
|
||
I'll settle for "Site Navigation Bar", even if the distinction between what's a
Bar versus a Toolbar is based on string length and this toolbar is the only
toolbar not called a toolbar ;->
Comment 21•23 years ago
|
||
> The fact that this bar is populated using <link> elements is a technical
> detail and should not be reflected in the UI.
People know what `links' are, and they're called `links' regardless of what HTML
element is used to create them.
<link> being a technical detail is bug 103062.
Renaming `Navigation Toolbar' to `Toolbar' is part of bug 49543.
Renaming `Personal Toolbar' to `Bookmarks Bar' is bug 48820.
The Links Bar being a toolbar is bug 102990.
The `Site Navigation Bar' having an awkward name is this bug.
The `Links Bar' name is designed to work nicely with the fix for bug 103459.
Bug 103459, in turn, is designed to work nicely with a bug no-one has filed yet
about what happens when you make your browser window too narrow to show all the
items.
I apologize if all these bugs seem random at times. They're not, really. :-)
Comment 22•23 years ago
|
||
I'd like to drop the word "Navigation" from this toolbars name and have it
called simply "Site toolbar" (or possibly "Document toolbar").
This opens the toolbar to being used for other elements of site/document
specific UI such as a UI for choosing Alternate Stylesheets.
To me it makes sense to have all elements of the UI that are related solely to
the current site/document' are in the one toolbar.
Bugs involving getting Alternate Stylesheet UI added to this toolbar: bug 103062
and bug 6782
Comment 23•23 years ago
|
||
How about Site Links Toolbar. Shorter than Site Navigation Toolbar. Less
likely to be confused with IE's Links Toolbar. More accurately representative
of the toolbar's current design which mimics the Bookmarks Toolbar (erm, I mean
Personal Toolbar).
FWIW, links aren't limited to moving within the current site. I don't think
this is a problem if the user's mental model is the same as the Personal
Toolbar, which is highly likely since it looks similar. Documentation shouldn't
imply that the links are just for moving within the current site. At most it
means "toolbar of links provided by this site". The name should reflect this.
Comment 24•23 years ago
|
||
Sorry to double post.
Could we limit the discussion to coming up with a name for the toolbar *as it
exists now* instead of postulating what we might name it contingent on any
number of other bugs (adding stylesheets, making it a sidebar, loading it in
each content frame, etc.). If/when those other bugs come to pass, we can
revisit the name. Before we got distracted we were pretty darn close to
concensus on a name for the current incarnation of the toolbar.
I know some people used the "but it's called 'Site Navigation Toolbar'" argument
against the stylesheet camp. Consider that argument null and void.
Assignee | ||
Comment 25•23 years ago
|
||
> Could we limit the discussion to coming up with a name for the toolbar *as it
> exists now*
The problem with that approach is then it may have to change its name later,
after the name has got established. There will be resistance to this, and we may
be left with a sub-optimal name.
We need to decide 2 things, in the following order:
1) Whether it will have stylesheets, and other page transform/nearby nav stuff,
such as What's Related
2) If so, is the current name appropriate, or can we generalise it to be
applicable both to the current and future toolbars?
Gerv
Comment 26•23 years ago
|
||
I vote for keeping "Site Navigation Bar" as long as it only contains links. When
we add the stylesheets or other things, the name should change to "Document Bar".
Assignee | ||
Comment 27•23 years ago
|
||
Changing the name after an indeterminate period would be a bad idea from a
usability perspective. I think the body of opinion is with adding stylesheets
and possibly other related things to the toolbar, so we need to decide and use a
new name now. As I see it, there are three candidates (Bar or Toolbar):
"Document Bar".
or
"Site Bar". These suggestions are similar. Hyatt expressed a preference for
something including the word "Site", because you are moving around the site
using it. I agree. Also, changing from Site Navigation Toolbar to Site Toolbar
is not a complete reversal. Users understand the concept of a web "site", and,
in normal use, will probably see this bar appear on particular sites (which have
adopted <link> and/or alternate stylesheets.)
"Links Bar". Doesn't, in the mind of the user, cover alternate stylesheets, and
could be confused with IE's Links Bar, which is their name for our Personal Toolbar.
I vote for "Site Bar" or "Site Toolbar".
Gerv
Comment 28•23 years ago
|
||
"Site bar" or "Site toolbar" seconded.
Comment 29•23 years ago
|
||
> 1) Whether it will have stylesheets, and other page transform/nearby nav
> stuff, such as What's Related
I'd like to have alternate style sheets in the <link> bar. I don't want to have
"What's Related?" there.
<link> navigation and the alternate stylesheet list are displays of
author-provided data. "What's Related" isn't provided by the author. Putting it
in the same toolbar would make it look as if the "What's Related" sites were put
there by the site author, which would be a Bad Thing. Compare with the dropped
IE6 Smart Links [or whatever the feature was called].
As for the name, I prefer a name ending in "Bar" instead of "Toolbar". (The bar
has buttons, but those buttons don't represent tools in the "draw line tool" /
"selection tool" etc. sense.)
Developers and Web authors will consider it "Links Bar" anyway. Why should that
be denied? It's like "No, no, you can't call them cookies." (Is "Link Bar"
better than "Links Bar" from a grammatical point of view?) "Site Bar" is also
ambiguous to a random end user.
Comment 30•23 years ago
|
||
FWIW, I think I was the one who originally came up with the name "Site
Navigation Bar", and I never really liked it that much. I just had to think of
_something_ for the mock-up. :-)
There are at least two problems with "Links Bar":
1) users might confuse it with IE's Links bar
2) users might get the idea that it's got something to do with the things
they know as "links" (<a href>s, that is)
"Document Link(s) Bar/Toolbar" would probably be the most descriptive and
technically correct name, but it's really too long.
How about just "Document Links"? (Does each option under "Show/Hide" really
have to end with the word "Bar" or "Toolbar"?)
OS: Linux → All
Hardware: PC → All
Comment 31•23 years ago
|
||
Nominating mozilla1.0. We really should decide on a name before shipping.
Keywords: mozilla1.0
Comment 32•23 years ago
|
||
> 1) users might confuse it with IE's Links bar
Didn't we already have this debate ;)
I'm less convinced it's a real problem. I also proposed "Site Links Bar" to
reduce any confusion.
> 2) users might get the idea that it's got something to do with the things
> they know as "links" (<a href>s, that is)
Uhm...that was the idea. It's why the current toolbar was modeled after the
Personal Toolbar. It's why the toolbar and menu items resememble links (blue
and underlined). They *are* links. They just happen to be a set of links that
get special treatment becase there's a standard defining them (or in a few cases
we aim to make the standard).
> How about just "Document Links"?
Sounds like a way to toggle display of inline A links within the document.
You'd still need the "Bar" suffix. The problem of space consumed by the
repeated "Toolbar" or "Bar" was nicely solved by Ian Pottinger in his comment on
2001-10-07 09:17. Until such a menu is created, items in Show/Hide should
follow the convention of having "Toolbar" or "Bar" in the name.
Comment 33•23 years ago
|
||
Submitted bug 106868 - "Rename Show/Hide menu and subitems"
Comment 34•23 years ago
|
||
Out of all sudgestions above I like "Document bar" the most.
I think it most closely relates to the actual nature of <link> items.
The words I don't like and reasons I don't like them:
"Navigation" - we already have a navigation bar. And so does any other browser.
This is confusing.
"Site" - This word I believe is much too general for this. A site can contain
multiple unrelated documents, each with it's own structure, authors and
stylesheets described through <link>. "Document" is much better suited for this.
"Link" or "Links" - Once again this is way too general. IE Links bar, <a href=>
links. Confusing.
"Toolbar" - Long word. The bar doesn't actually have any tools.
------------------------------------------
"Document bar" I believe is a more-to-the-point, no-bullshit thing. It leaves no
room for confusion, and no doubt of where items in it came from. It also
perfectly accomodates alternative stylesheet selection.
I also must agree with Henri, "What's Related?" has no place there. It is alien
to the document.
Assignee | ||
Comment 35•23 years ago
|
||
Document Bar is bad because clicking the buttons does not alter the current
document, it switches to a completely new one (in the common case; few people
have anchor <link>s.) Hyatt's logic for Site [Navigation?] Bar was impeccable -
it's a bar of links for navigating around the site.
Re: What's Related. Are you saying a list of related links does not belong on a
bar full of links related to the current page?
I still want to know why this is the only Links toolbar bug that ever gets any
comments. Is it because it doesn't involve actually writing any _code_?
Gerv
Comment 36•23 years ago
|
||
> Document Bar is bad because clicking the buttons does not alter the current
document,..
I somehow fail to see how word "Document" implies that the bar should alter
content? Also if alternative stylesheet selection is placed in there, it does
modify the document presentation.
> ...it switches to a completely new one (in the common case;...
The way I see it, in the common case it actually switches to a page of the same
document. Take W3C XHTML spec for example. It's a document that consists out of
several web pages linked together through <link> tab.
Comment 37•23 years ago
|
||
Re: "What's Related?". Actually the bar is full of the links specified by the
document itself. "What's Related?" indeed does feel alien. It was not placed
there by the author (unlike all the other links).
I do prefer it the way it is - a sidebar that you can switch off and forget.
Placing it in this bar would be really unnessesary. I do want to use document
<links>, but I don't want to feel forced to use "What's Related?" in order to
use them.
Assignee | ||
Comment 38•23 years ago
|
||
We went with "Site Navigation Bar".
Gerv
Status: REOPENED → RESOLVED
Closed: 23 years ago → 23 years ago
Resolution: --- → FIXED
Comment 39•23 years ago
|
||
For those interested, I have filed bug 135619 - Rename "Site Navigation Bar" to
"Page Bar"
"Page Bar" haven't been considered here before.
Updated•20 years ago
|
Product: Core → Mozilla Application Suite
You need to log in
before you can comment on or make changes to this bug.
Description
•