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.
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.
> 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..
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.
Link toolbar bugs should not go to me, but you probably know better who the correct owner is.
Actually, I can do this one. Don't know if it's gauche to be both reporter and assignee...
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.
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.
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.
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.
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
Haven't worked on Mozilla for several months and this is unlikely to change soon.
Filter "spam" on "guifeatures-nobody-20080610".
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.