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)
SeaMonkey
UI Design
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.
Comment 2•23 years ago
|
||
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
Updated•23 years ago
|
QA Contact: sairuh → claudius
Comment 3•23 years ago
|
||
-->sballard (please reassign to the appropriate links bar person if not you)
Assignee: blakeross → sballard
Comment 4•23 years ago
|
||
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?
Comment 5•23 years ago
|
||
Yeah, there's bug 103469, 'Need unified spec for rel=""'
Comment 6•23 years ago
|
||
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.
Updated•20 years ago
|
Product: Core → Mozilla Application Suite
Updated•16 years ago
|
Assignee: sballard → jag
QA Contact: claudius
Comment 7•15 years ago
|
||
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
Comment 8•15 years ago
|
||
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.
Description
•