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
In that case let me add my vote for "Site Navigation Toolbar". Other possibilities: "Site Toolbar" "Document Toolbar" "Related Pages Toolbar"
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!).
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
Site Navigation Bar sounds great and has my vote
Yeah, I like 'Site Navigation Bar' too. I believe the term 'toolbar' is generally only used for bars of buttons that replicate menu items.
Site Navigation Toolbar or Bar has sr=hyatt; we'll go with Bar and see if it looks bad. Patch coming up. Gerv
r=choess Worth a try.
Keywords: patch, review
Comment on attachment 52166 [details] [diff] [review] Patch v.1 email@example.com,firstname.lastname@example.org
Attachment #52166 - Flags: review+
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+
Checked in. Gerv
Status: NEW → RESOLVED
Last Resolved: 17 years ago
Resolution: --- → FIXED
Damn, missed the party. "Site Navigation Bar" sounds good.
[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 → ---
> 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.
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.
How about: View > Show/Hide Bars Web Navigation Site Navigation My Bookmarks Status Components
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.
'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.
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
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 ;->
> 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. :-)
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
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.
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.
> 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
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".
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
"Site bar" or "Site toolbar" seconded.
> 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.
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
Nominating mozilla1.0. We really should decide on a name before shipping.
> 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.
Submitted bug 106868 - "Rename Show/Hide menu and subitems"
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.
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
> 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.
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.
We went with "Site Navigation Bar". Gerv
Status: REOPENED → RESOLVED
Last Resolved: 17 years ago → 16 years ago
Resolution: --- → FIXED
For those interested, I have filed bug 135619 - Rename "Site Navigation Bar" to "Page Bar" "Page Bar" haven't been considered here before.
You need to log in before you can comment on or make changes to this bug.