|
|
mailto: link
news: link
When the menu bar has been hidden by a page author for a particular window, the following should be appended to the bottom of all context menus in the content area of that window:
Firstly, unlike a main menu, which is practically guaranteed to come down from near the top of the screen, a shortcut menu can be opened from anywhere. The longer the menu is, the more likely it is to appear in a direction other than in its expected place to the southeast of the cursor. When that happens, the user’s muscle memory is broken and she is slower at finding the item she wants. This makes the menu less useful overall, even when it does appear to the southeast — because the user had to pause to make sure it would.
And secondly, shortcut menus are less visible and therefore less familiar than main menus. So they need to be shorter to be memorable.
A good length for a shortcut menu is about six items; the longest ones in this spec are thirteen items, which is really far too long, but there isn’t any obvious way to make them shorter without dropping features.
That would make the problem much worse, not better. Even if the bugs in Mozilla's shortcut menu placement were fixed, there would be four different places a shortcut menu could open relative to the initial position of the cursor; if a submenu was used, there would be sixteen different places the submenu could open relative to the initial position of the cursor.
Firstly, because that would make it much more difficult to scan the menu to find the item you wanted — you’d have to read more than one word in most of the items, to distinguish it from the items before and after. And secondly, because it would make the position of items completely inconsistent between contexts.
Left to Right,
Right to Leftand
Insert Characterstuff?
It’s a compulsory part of supporting bi-di and Unicode text input. This is nothing special; similar items are included in the shortcut menu for every native text field in Windows 2000 and later.
Those shortcut menu items are for saving or bookmarking the current frame, not the page — they just happen to save or bookmark the whole page if you’re on a page which only has one frame. If you want to save or bookmark the whole page consistently, use the File
or Bookmarks
menu.
Send Page?
In the File
menu. It’s not contextual, and it's not used nearly often enough to deserve placement in the shortcut menu on frequency grounds either.
Edit Page?
See the answer to the previous question.
Encoding?
In the View
menu.
If a page doesn’t have a menu bar, changing the encoding is only one of dozens of things which you might want or need to do to it. But that doesn’t mean the shortcut menu for a page or frame should be made unusably long by duplicating all those items. That’s what the Show Menu Bar
item is for.
Set as Wallpaper?
In the Tools
menu. This item should open a dialog (which defaults to the selected image, if there is one), so you can:
Cancelif you selected the menu item by mistake, without Mozilla resorting to anything as obviously annoying as an alert.
Spell Checkfor a text field?
In the Tools
menu. Those most likely to need this function are the least likely to know of the existence of shortcut menus in the first place.
Search for {selected text}?
In the Tools
menu.
Because when you hover over an item for a fraction of a second before opening its context menu, it’s often not obvious whether the image you’re hovering over is a link or not, or whether the link you’re hovering over is a mailto: one or not. Including inactive items from the other context prevents you from getting hurt by assuming the wrong context and choosing the wrong item as a result. It also allows for greater consistency of position of items between contexts.
Once the main menus are restructured, the access keys for main menus and shortcut menus can be harmonized for even greater consistency.