104586 - LINKs in the Site Navigation Toolbar should also be in the main menus

Status: RESOLVED WONTFIX

(SeaMonkey :: UI Design, enhancement)

Description

[Tim 'Tool-Man' Taylor]

Functionality available from a toolbar should also be available from the menu
system.  LINKs that appear in the Site Navigation toolbar should also be
accessible through the main menu bar (File, Edit, View, ...).

The default location to represent LINKs should be in the "Go" menu.  Some LINK
types are more intelligently placed elsewhere in the menus.  In those cases,
they should be omitted from the Go menu.  Here's my first take at menu placement.

Most LINK types belong in the Go menu:

  Go
    Back
    Forward
    Home
    --------
    Site Home
    Up a level
    --------
    First Page
    Previous Page
    Next Page
    Last Page
    --------
    Document Links
      <same as Document menu on toolbar>
    --------
    About the page author
    Page copyright
    More Links
      Other Versions
      --------
      <unrecognized link types>
    --------
    <navigation history>


The rel="Alternate" LINK type presents us with an opportunity to do some really
intelligent placement of these links in the menu system.  Let's use hixie's LINK
test as an example, <http://www.bath.ac.uk/%7Epy8ieh/internet/eviltests/link1.html>:

<!--1--> <LINK title="The page in Dutch"
		type="text/html"
		rel="alternate"
		hreflang="nl"
		href="support/nl.html">

<!--2--> <LINK title="The manual in Portuguese"
		type="text/html"
		rel="alternate"
		hreflang="pt"
		href="support/pt.html">

<!--3--> <LINK title="The manual in Arabic"
		type="text/html"
		rel="alternate"
		dir="rtl"
		charset="ISO-8859-6"
		hreflang="ar"
		href="support/ar.html">

<!--4--> <LINK lang="fr" title="La documentation en Français"
		type="text/html" 
		rel="alternate"
		hreflang="fr"
		href="support/fr.html">

<!--5--> <LINK title="The manual for printing"
		type="text/html"
		rel="alternate"
		media="print"
		href="support/print.html">

Alternates in another language can be used to populate a Translate menu, instead
of only offering programmatic translation:

  View
    Show Hide
    Sidebar
    ....
    --------
    Translate
      The page in Dutch
      The manual in Portuguese
      The manual in Arabic
      La documentation en Français
      --------
      Other translations

The last LINK in hixie's test is a special case.  Instead of appearing in the
menu system, it should be used by the Print command to automatically select the
printable alternate (the UI would allow the user to override this and print the
original page).

All other alternate link types that we don't know how to handle intelligently
would need to be incorporated elsewhere in the menu system, probably in Go.

Two other LINK types afford intelligent placement: Search and Help.  The default
menu items and their placement would be as follows:

   Search
     Find in this page
     Find again
     --------
     Search this site
     Search the Web
   Go
   Bookmarks
   Tasks
   Help
     Help Contents
     Release Notes
     -------
     Help with this site
     -------
     About Plug-ins
     About Mozilla

However, we'll use the TITLE attribute if provided.  Given these LINKs:

  <LINK REL="Search" href="/product-search.html" TITLE="Search foo.com catalog" />
  <LINK REL="Help" href="/catalog-help.html" TITLE="Help using foo.com catalog" />

their respective menu items become:

  Search
    ...
    Search foo.com catalog
  ...
  Help
    ...
    Help using foo.com catalog


Similarly, the Bookmark LINK type can be incorporated into the Bookmarks menu:

  Bookmarks
    Add a bookmark
    File a bookmark
    --------
    Manage bookmarks
    --------
    Personal Toolbar Folder
    --------
    Mozilla Project
    --------
    Site Bookmarks


An alternate idea for Author and Copyright LINKs would be to omit them from the
Go menu and instead incorporate them into the Page Info dialog brought up by
View -> Page Info.

Implementing this enhancement would also fix bug 102909.

Comment 1

[Alex Bishop]

These are really good ideas. I especially like the integration with the Search
and Help menus etc. The only problem I can see is that this could make the Go
menu rather long. I'm pretty certain I saw a MachV menu spec that had the
history folders (Today, Yesterday etc.) accessible from the Go menu. We could
end up with a huge Go menu if both these enhancements are implemented.

Marking NEW.

Comment 2

[Tim 'Tool-Man' Taylor]

> The only problem I can see is that this could make the Go
> menu rather long.

Agreed.  Let's assume a few things:

  1. Author and Copyright get incorporated into the Page Info dialog
  2. we figure out another acceptable menu to put unrecognized link 
     types and the remaining Alternate LINK

Then we have a Go menu that looks like this (submenus collapsed):

 Go
    Back
    Forward
    Home
    --------
    Site Home
    Up one level
    --------
    First Page
    Previous Page
    Next Page
    Last Page
    --------
    Document Links
    --------
    <navigation history>


This is 7 new menu items.  The longest menu, excluding dynamic length menus (Go
with long history or Tasks with lots of windows open) is the View menu with 13
items.  Assuming a long browsing session the Go menu would grow to 23 items (7
static items + 15 history entries).  If we reduce the number of history items
shown to 10, then we're talking about 17 items, only 4 longer than View.  That
still close to enough to cause the menu popup to get scrollers at 640x480.  Is
there a spec for what the maximum number of items can be in a menu?

If we can't put all the LINKs in Go, we can at least put some.  I would omit the
LINK types in this order:

  First/Last
  Previous/Next
  Up
  Site Home

Lastly, I've always been afraid of the user experiencing confusion between
Back/Forward navigation and Previous/Next navigation.  Placing both in the Go
menu would certainly demonstrate whether there was confusion.  I can see someone
thinking Previous/Next is redundant with Back/Forward and believing that
First/Last are for jumping to the first and last page in their browsing history.

So, if for any of these reasons we can't put LINKs in the Go menu, we can still
incorporate my other enhancements.  "Search this site" in the Search menu, etc..

Comment 3

[Tim 'Tool-Man' Taylor]

Oops...the order of LINK types to sacrifice in the name of keeping the Go menu
short should have been:

  Document Links
  First/Last
  Previous/Next
  Up
  Site Home

And to avoid any confusion, I'm not suggesting any sort of dynamic behavior
here.  I'm talking about leaving the items out entirely.

Comment 4

[Blake Ross]

Link toolbar bugs should not go to me, but you probably know better who the
correct owner is.

Comment 5

[Tim 'Tool-Man' Taylor]

Actually, I can do this one.  Don't know if it's gauche to be both reporter and
assignee...

Comment 6

[Alex Bishop]

I think it's perfectly acceptable to report a bug and assign it to yourself.
Otherwise you end up fixing things without telling anyone else!

I found the MachV menu spec. Actually, I found three but the Go menu seems to be
the same in all of them:

http://www.mozilla.org/projects/ui/communicator/framework/menu_framework/menuproto_screenshots/a/nav/
http://www.mozilla.org/projects/ui/communicator/framework/menu_framework/menuproto_screenshots/b/nav/
http://www.mozilla.org/projects/ui/communicator/framework/menu_framework/menuproto_screenshots/c/nav/

I'm not sure who made them. My best guess is German Bauer so I'm CC'ing him and
MPT for UI input.

Comment 7

[Tim 'Tool-Man' Taylor]

Thanks for the links, alex.

Here's how I'd integrate LINK support with the MachV proposal:

  Go
    Back
    Forward
    Home
    --------
    Site Home
    Up one level
    --------
    Previous Page
    Next Page
    --------
    Site Just Visited 1
    Site Just Visited 2
    Site Just Visited 3
    Site Just Visited 4
    --------
    Complete History...
    --------
    Visited Today
    Visited Yesterday
    Visited 2-7 Days Ago
    --------
    More Than A Week Ago

That's 16 items, the same as the MachV proposed menu.  I sacrificed some of the
"Visited N Days Ago" submenus to make room for LINK menu items.  Submenus for
anything beyond 2-3 days back suffer from diminishing returns.  Most people have
a reasonable chance of remembering what they did today, yesterday, and before
yesterday.  From my experience, everything beyond yesterday starts blending
together.  Similarly people will have good success remembering whether they did
something this week or before this week.

So I've demonstrated that (some of) this enhancement can coexist in the Go menu
with the MachV proposal.  The question remains of whether they should.  I'm not
certain.  The LINK items seem somewhat out of place with the history navigation
emphasis of the MachV Go menu.  Again I'm concerned about confusion over the
meaning of Previous Page and Next Page.

Comment 8

[Matthew T (active 1999-2002)]

I can't think of any good reason for duplicating the contents of the Links Bar 
in a menu. We list author style sheets in a submenu; but they're things which 
the user may want to toggle quickly, and which aren't important enough to have 
UI in the content area for. Images are displayed in the content area, and we 
don't have a menu for those. Frames are displayed in the content area, and we 
don't have a menu for those. A HREF links are displayed in the content area, 
and we don't have a menu for those. Now LINK links are displayed in the content 
area (modulo bug 102990), so there's no point in having a menu for those. This 
just seems like a way of making the `Go' menu even *more* complicated than 
German's design, for no benefit.

Comment 9

[Tim 'Tool-Man' Taylor]

No suprise that I object to bug 102990, so now the argument becomes: Back is in
a toolbar *and* in a menu.  Bookmarks are in a toolbar *and* in a menu.  Open
location is in a toolbar, and in a menu...

If the "content area" camp wins and bug 102990 becomes the UI for LINKs, then
your argument is valid.  Otherwise, if the "chrome" camp wins, the precedent is
to have the functionality available from toolbars and menus.

Comment 10

[Paul K Egell-Johnsen]

I've read through all your comments, and there are some good input. Here is what
I say about the duplication of back and forward (and other duplicated elements
in the GUI):

These buttons and menus have always been duplicated, all the way since I first
tried the pre-Netscape browser, Mosaic, I believe, back and forward has been
both in the menu and in the toolbar. Therefore there is a good presedent for
keeping them there.

Dynamic menus are bad, so I'm pleased to see that no-one suggests it for this
feature.

Therfore, to the problem at hand, the site navigation bar. I belive it should be
kept in the content area. The flicker mentioned by someone is apparent in the
navigation bar today, so wheter it gets into the content area or not is irrelevant.

Another reason for keeping it in the content area is to always show it if it is
there, and to integrate it with the engine, so that other projects using the
engine will show the menu, regardless of if they know about this feature or not.

I remember I tried using links in the head after reading my first HTML spec. It
was back in the Mosaic days and I was disappointed that this really cool and
useful feature wasn't supported. Now that it is (and in many browsers) I think
it is important to let people see it.

It's just like the table, the frame, and dare I say it the blink and marquee, if
it offers something new (and this time allready in the specs!) which is useful,
people will use it.

Paul

Comment 11

[Tim 'Tool-Man' Taylor]

Haven't worked on Mozilla for several months and this is unlikely to change soon.

Comment 12

[Serge Gautherie (:sgautherie)]

Filter "spam" on "guifeatures-nobody-20080610".

Comment 13

[Philip Chee]

The SeaMonkey team won't devote any resources on this. Closing as WONTFIX. In addition this sounds like extension fodder as well as a UI nightmare.