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

Status: RESOLVED EXPIRED

(SeaMonkey :: UI Design, defect)

Description

[Matthew T (active 1999-2002)]

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 1

[Boris Zbarsky [:bzbarsky]]

ccing links bar people

Comment 2

[Gervase Markham [:gerv]]

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

Comment 3

[Blake Ross]

-->sballard (please reassign to the appropriate links bar person if not you)

Comment 4

[Stuart Ballard]

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

[Tim 'Tool-Man' Taylor]

Yeah, there's bug 103469, 'Need unified spec for rel=""'

Comment 6

[Per Ångström]

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.

Comment 7

[Robert Kaiser]

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

Comment 8

[Robert Kaiser]

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