Closed Bug 103459 Opened 23 years ago Closed 15 years ago

`Document' and `Other' menus in Links Bar don't make sense

Categories

(SeaMonkey :: UI Design, defect)

defect
Not set
normal

Tracking

(Not tracked)

RESOLVED EXPIRED

People

(Reporter: mpt, Assigned: jag+mozilla)

References

Details

The Links Bar currently contains two menus for listing LINK links other than those which have dedicated UI of their own. These menus are labelled `Document' and `Other', so as to be guaranteed to make sense to the user only in the highly unlikely event that she is familiar with the relevant section of the HTML specification. In addition, the division of links between the two menus seems completely arbitrary: most of the (almost always disabled) items in the `Document' menu don't apply just to the current document, whereas most of the (almost always disabled) items in the `Other' menu *do* apply to the current document in particular. I suggest combining the menus into a single menu labelled `Other Links'. This is a better explanation of the contents of the menu, and it simultaneously helps explain what the previous items in the bar are as well.
Blocks: 103053
ccing links bar people
OS: Mac System 9.x → All
Hardware: Macintosh → All
To prevent people having to go and find pages which allow them to check the menus, I will enumerate their contents: Document: More: Table of Contents Help Chapters > Search Sections > ------- Subsections > Authors Appendices > Copyright Glossary ------- Index Bookmarks > ------- Other Versions > ------- <unrecognised links> mpt has a point; these could be rethought. Although I wish he'd given his input earlier in the process. Maybe he did. Anyway. I think that there should be a top level menu called Other Versions which contains the current Other Versions (such as translations and printable versions) plus author styles. Question: if bookmarks were top-level, would it encourage authors to have one big internally-anchored page rather than a number of smaller ones? If Document is an inappropriate name for a top level menu implementing moving around a conceptual document, then what is a better one? Gerv
QA Contact: sairuh → claudius
-->sballard (please reassign to the appropriate links bar person if not you)
Assignee: blakeross → sballard
I think we need a spec for this... the Document and More menus make sense to me, but perhaps I'm just too close to the situation. Is there a bug to produce a full linktoolbar UI spec?
Yeah, there's bug 103469, 'Need unified spec for rel=""'
My site <http://www.autark.se/> uses links quite extensively, ever since Mozilla started supporting them. I have noticed that "Document" and "More" are both disabled in 0.9.8-2002022700, although the documents contain "search", "content", and "index" links that ought to be available - they used to be enabled in earlier builds. I'm wondering whether this bug has anything to with the disabling.
Product: Core → Mozilla Application Suite
Component: XP Apps: GUI Features → UI Design
Assignee: sballard → jag
QA Contact: claudius
This bug report is registered in the SeaMonkey product, but has been without a comment since the inception of the SeaMonkey project. This means that it was logged against the old Mozilla suite and we cannot determine that it's still valid for the current SeaMonkey suite. Because of this, we are setting it to an UNCONFIRMED state. If you can confirm that this report still applies to current SeaMonkey 2.x nightly builds, please set it back to the NEW state along with a comment on how you reproduced it on what Build ID, or if it's an enhancement request, why it's still worth implementing and in what way. If you can confirm that the report doesn't apply to current SeaMonkey 2.x nightly builds, please set it to the appropriate RESOLVED state (WORKSFORME, INVALID, WONTFIX, or similar). If no action happens within the next few months, we move this bug report to an EXPIRED state. Query tag for this change: mass-UNCONFIRM-20090614
Status: NEW → UNCONFIRMED
MASS-CHANGE: This bug report is registered in the SeaMonkey product, but still has no comment since the inception of the SeaMonkey project 5 years ago. Because of this, we're resolving the bug as EXPIRED. If you still can reproduce the bug on SeaMonkey 2 or otherwise think it's still valid, please REOPEN it and if it is a platform or toolkit issue, move it to the according component. Query tag for this change: EXPIRED-20100420
Status: UNCONFIRMED → RESOLVED
Closed: 15 years ago
Resolution: --- → EXPIRED
You need to log in before you can comment on or make changes to this bug.