109467 - Proposed tweaks to Link Toolbar's rel->button mapping

Status: RESOLVED EXPIRED

(SeaMonkey :: UI Design, enhancement)

Description

[Ben Bucksch (:BenB)]

I'm trying to use the Link Toolbar in Mozilla on my site. I find some few
unfortunate behaviours. In essence, the UI doesn't reflect common structures of
websites, but looks more targetted toeards docbook or similar.

1. Childs
If we have a notion of "Up", "Next" and "Prev", there are also childs (i.e.
subpages). However, there's no good way to reflect those childs in the Link
Toolbar. I currently use "chapter", but that has the following problems:
  - It is rendered as Document > Chapters > <childs>.
    This means 2 more clicks than as if the user clicked on a corresponding
    link within the page.
  - If I add a sitemap as "toc" or "contents", it is added to the same
    "Document" menu. This means that "Documents" is always enabled and the
    user has to click on the menu to discover, if the current page has subpages.
    Very unfortunate.

2. Main sections
Most websites have very prominent links to something like "main sections", i.e.
the subsections directly under the root.
E.g. for www.aol.com, they are "Main", "My AOL", "Mail", People", "Search",
"Shop" etc..
For Netscape, they are "Mail", "Calendar", "IM", "my netscape", "Download",
"Search".
For CNET, they are "Price comparisons", "Product reviews", "Tech news", "Downloads".
Personally, I don't see the point, but it seems very popular.
3. Common pages missing
I miss support for the following special, but common pages:
3.1. About this page
(a page about the page, listing document history, authors etc.). Neither Authors
not Copyright is really applicable. Not sure, how common that really is.
3.2. Privacy
3.3. Legal notes
     Often called "Terms of Service".
     I hate it (visiting a company's page is advertizing, not a contract),
     but it is very common.


I suggest the following:
- We add more menus (one for top-level sections, one for childs of the current
page) to the toolbar, but hide all unused menus.
- Sitemap, however the <link>-rel is called, is moved to "More".
- The pages in 3. are added to "More".

Comment 1

[Ben Bucksch (:BenB)]

On a second thought, forget about 3.3. and maybe 2..

Comment 2

[Ben Bucksch (:BenB)]

Another issue that came up in bug 109427 is that home != top. Maybe, we could
have separate buttons for Top and Home, hiding the unused one, but displaying a
disabled Top button, if none is specified.

Comment 3

[Ben Bucksch (:BenB)]

Found an old (expired) IETF draft
<http://www.csd.uwo.ca/~jamie/.Refs/LinkTypes/draft-ietf-html-relrev-00.txt>.

For 1. it specifies "child"; for 3.1., it specifies "meta"; "disclaimer" for 3.3.

Comment 4

[Stuart Ballard]

The current toolbar interprets "child" as "next" - this is a bug imho.

My personal opinion would be to have:

[Top] [Up|v] [[Down]]
[First] [Previous|v] [Next|v] [Last]
[[Document]] [[More]]

(all on one line in the toolbar of course, but I separated them to avoid
wordwrapping problems)

Here [Foo] is a button (like the current "top" button), [Foo|v] is a button with
a popdown menu to the right of it (like the forward and back buttons) and
[[Foo]] is a menu (like the current "document" and "more").

This would allow multiple up, previous and next links, but still allow a single
click to go to the parent, previous or next page. "Down" would be equivalent to
"child", to match the fact that it's the opposite of "up".

Thoughts?

Comment 5

[Eric Hodel]

Re comment 2:
The difficulty of this is multiple uses of `home' we can't be getting `home' as
the user's home page confused with `home' as the site's home page.  We ended up
scrapping `home' in the toolbar for this reason.  See also the expired draft
from comment 3, section 4b

Re comment 4:

As far as child == next, I disagree, this follows the convention used on several
documentation pages, ie:

http://www.python.org/doc/current/mac/using.html
http://www.freebsd.org/doc/en_US.ISO8859-1/books/handbook/introduction.html
http://www.php.net/manual/en/getting-started.php

among others where the child element of a section is a subsection and also the
next link.

I believe most importantly it should be a best practice to use `next' to specify
the next page in a sequence regardless of whether it is a child or whatever,
specifying explicit relationships will only be a sugar coating for more
interested users.

Comment 6

[Ben Bucksch (:BenB)]

Eric,
Child = next:
it might be a /convention/, but it is not /always/ true. Thus, you cannot
hardcode it into the app (at most as a fallback, if there is no "next" at all
specified). I agree that this is a semantic bug.

Comment 7

[Stuart Ballard]

I think that on pages within documents where the first child can also be
considered the "next" page, the page should specify <link rel="child next">. The
toolbar already copes with this pattern as far as I can tell from the code, so
it's really not a problem.

Of course, it causes another evangelism issue that we need to deal with:
persuading document authors and tool authors to use "child next" rather than
just "child". But I think that doing it right now, before this gets even more
widespread, is better than just letting the current mess propagate.

Comment 8

[Ben Bucksch (:BenB)]

Stuart, it *is* a problem when:
- The site specifies all childs
- The "child"s are listed before "next" in the HTML file (we use the first found
  <link> for the button) and
- The first "child" listed is not "next" (or there is no "next" at all (you
  cannot force pages to use "next"))
Then the Next button will do the wrong thing.

Comment 9

[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 10

[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 11

[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 12

[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 13

[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