|
Mach V |
UI Specification |
|
Context Menus Specification Rev 2, 3rd Draft |
Last Modification:
|
|
Author Marlon Bishop |
Status: Framework Specification for Review |
|
Contents
|
Feature Team Blake Ross |
Menu Interaction and Design
This document assumes a fundamental understanding of the interaction design for conventional context/pop up menus. For background, consult platform specific UI documention. The method described here is for designing context sensitive menus in applications of high content density, such as web content. Considering the increasing number of novice Windows users who use right mouse click as a means of discovering features, the menus are decidedly geared toward more general use, rather than containing exclusively hidden or esoteric features. Also, by representing multiple contexts in cases which are ambiguous, we provide convenience from having to right click in multiple targets, or zones, and increase the liklihood for the user to hit their intended feature.
Supported Cases
The following cases listed below are specified in this document. For yet-to-be-specified cases, or, if changes to a case are necessary, follow the Menu Design Principles.
Content:
- Content Area
- Selected Content
- Text as Link - includes Button as Link
- Inline Image
- Image as Link
- Image as URL
- Text as Mailto: Link
- Image as Mailto: Link
- Text as News: Link
- Image as News: Link
- Form/Input Field
- The Frame Subset - applies to all menus
Chrome:
- Sidebar Tabs
- Toolbar Area - (Customizable Toolbars and Chrome cross ref)
- Page Tabs
- Page Tab Bar
- Personal Toolbar and Items
- Component Bar Items - tbd
Feature Dependencies
This spec depends on the following features:
- Inline spellchecking or a user invoked alternative for Text Input - see Form/Input Field
- Add a [View Source] button to the general tab of the page info dialog. Rename Page info to Page Properties - see Content Area
- [Send Image to Buddy] allow user to seamlessly share images. IM should include a reference link, if available. - see Inline Image
- [Send as Quote...] When a user decides quote a page in an email message, provide a feature which save several copy-paste operations and formating operations.- see Selected Content
- [View Selection Source] - bug 49721 - see Selected Content
Menu Design Principles
The following are a set of design principles to keep in mind when creating, or making changes to context menus.
- Provide convenience by offering the most common File Menu commands
- Provide power by combining context sensitivity with the most common File/Edit menu commands
- Provide speed by making menus brief, to make identification quicker and selection easier.
- Menu items should be ordered by frequency and/or relevancy to the immediate context and task
- Define a core subset for each context. When placing in new contexts, never allow core items to loose their arrangement. (cut, copy, paste, delete, select all)
- Menus are often used as "cue cards" to reveal features available for related cases
- Maintain 4.x feature parity when possible
- Use Netscape familiar terminology
- Follow platform fundamentals when possible (or make compromises between different platforms)
- Identify items which are "expendable", or offer little or less utility in other contexts. Expendable items should always have alternate, 2-step methods in their absence.
- When necessary, structure menu subsets to "degrade gracefully"
- Identify high traffic menu items and label them less expendable.
- Identify expendable menu Items - actions which can be done relatively easily by other means (usually by performing one more step that is common)
- Compromise menu items for subsequent descendents of a context (children or kin).
- Expend items based on the degree of ambiguity for a given case. Highly ambiguous contexts generally want more cores represented
- Using dividers: provide dividers between each domain and/or provide dividers between each task category. Rule of thumb should be no more than 4 or 5 items between each set of dividers.
- Identify menus that are kin. That is, menus which share familial characteristics, thus are dependent on each other for consistency, and should be kept in parity. This will propogate family characteristics which can then later be easily identified by the user.
- In very general terms, menus should be no more than 12-14 items in length, with a "sweet spot" of around 8-9 items. Menus which are 13 items or longer are lacking ease of use, while menus shorter than 5-6 are possibly lacking innovation.
- Duplicate the "default action" for an object which could receive single or double click mouse action. - this principle is left open to interpretation.
- the unofficial Click-and-Hold mac behavior should be retained as long as principle 15 is followed.
- Minimize use of 'Valued Tasks' which apply to links. for example [edit link in composer], or [send this link], or manipulating some sort of element which we can assume has not been traversed, or was traversed and then returned from to send, instead of sending directly.
- In general terms, contextual nodes such as links and images can receive actions of the storage type: bookmark, save, send
Anatomy of a Context Menu
NOTE: Menu items identified as "expendable" are by no means of lesser value. Branding certain menu functions as expendable, simply implies that function might offer less utility in the next context. A core set of functions should always retain their internal order.
|
Content Area Menu (see alternate Macintosh terms indicated by an *)
The Menu
|
Core Set
|
• alt text:[bookmark this page]?
* [Alias in Finder] for mac • [View Background Image] is enabled only if there is a background image in the page. • [Stop] is enabled if a page is still loading * [Alias in Finder] for mac • [Character Encoding] should be off by default for English/US users, toggled in the view menu, or shipped only in "internationalized" versions of the product. - consider duplicity of Create Desktop Shortcut and Save Page as... - [Page Source] and [Page Info] to be combined into [Page Properties] feature. the shortcut, discrete access of [page source] and [page info] individually is archaic. combining both into a [Page Properties] (replaces page info) feature which adds a button to the [General] Tab which would launch View Page Source window. -Replace [Add Page to Bookmarks] with [Bookmark This Page] which is no longer 'silent'. This change is in lieu of a Bookmark feature redesign, which will streamline the application model for bookmarking. The redesigned Bookmark Menu should have only on Menu item:[Bookmark This Page] and not [Add Bookmark] - the resulting dialog will allow user to choose silent bookmarking preference. -[Show Menu Bar] would only be visible if one were missing, for example in chromeless window, to relieve the need for duplication of any menu items in context menus. -** What happened to [View Source] and [Page Info]?? Propose a new consolidated Page Properties dialog which consolidates the two previous items into a tabbed interface of Page Properties. If this dialog cannot be implemented in Mach V, then keep the menu item broken out into two items everywhere Page Properties is currently. |
||||||||||||||||||||||||||||
| items in square brackets are only visible under certain circumstances |
|
|||||||||||||||||||||||||||||
|
4.x |
IE5.5 |
Opera 6.0 |
Opera Flyouts |
|||||||||||||
|
|
|
|
|||||||||||||
<- Top
Selected Content Menu
The Menu
|
Core Set
|
alt:bookmark this page?
- *RFE [Send Quoted Selection...] - quote formatting in email with URL provided by reference source URL followed by content indented example in the body of a mail message: quote from: http://foo.com/foo ipsum lorem foo ipsum lorem foo ipsum lorem foo ipsum lorem foo ipsum lorem foo ipsum llorem foo ipsum lorem foo ipsum lorem foo... - Perform Search on... - tthe context ambiguity for this menu is fairly low, because 2 certain conditions must be met: 1) highlighting a selection; 2) right clicking within the selection or in the 'horizontal vicinity' of that selection. Right clicking outside of selection would still bring up a menu pertaining to the text portion of the selection unless it were outside the 'horizontal region' (check out the IE behavior). if outside this horizontal region, then we would *deselect*, and produce the more immediate context underneath the cursor. this is the best way to deal with forgotten or accidental highlighting (user scrolled out of view) if another contextual node were contained within a selection, such as a link or an image within a selection, then right clicking directly on that element should produce the context menu for that element combined with a *core* Selected Content menu, and while keeping the selection (so not exclusively the [selected content] menu). - "Cut, Copy, Paste, Select All" - Visit Selection as URL - is open to negotiation. idea found in bug #15176 - if inserting "foo..." proves to be too lengthy then suggest using the term, "selection" in it's place. - *if selected content contained links and or images, we should still treat this context as 'selected content' exlusively, to avoid growing menus and complexity.. Since the tolerance for mistaken intent for this context is extremely low - [Change Text Direction] turning on bidi option in the main menus (use the same switch as Character Encoding), or by detecting the region and language, will allow user to access 2 new features in context menus: change text direction in text fields and in selected text - * RFE [Highlight Selection >] Would produce a color picker which allow user to highlight content on a page. |
||||||||||||||||||||||
| items in square brackets are only visible under certain circumstances |
|
|||||||||||||||||||||||
|
4.x |
IE5.5 |
Opera 6.0 |
Opera Flyouts |
|||||||
| Ignored - same as previous context |
||||||||||
|
|
|
|
<- Top
Text as Link Menu (kin: text as mailto: link, text as news: link) (child: image as link)
The Menu
|
Core Set
|
would link properties be useful?
- ambiguous context is fair - since it could a link could potentially be mistaken for the page • button as link could also use this same menu (bug 63823) - ctrl-right click would change [Open Link in New Tab] and [Open Link in New Window] to [Open Link in New Backround Tab], [Open Link in New Backround Window] - [Copy Link Location] copies only the URL, not the HREF. copying a URL is much more valuable and practical for most users than copying a bunch of code. You can retrieve a link HREF by selecting Link Properties, and copying it from there. The reason it must be left out is to keep the image as link menu from growing beyond 16 items. - * consider the addition of highly requested [Send Link] item - would alleiviate ambiguity between [Send Page] on this menu. |
||||||||||||||||||||||
| items in parenthesis are for clarification to reviewers of this spec. |
|
|||||||||||||||||||||||
|
4.x |
IE5.5 |
Opera 6.0 |
Opera Flyouts |
|||||
| [Page >] provides entire previous context | ||||||||
|
|
|
|
<- Top
Inline Image Menu (see alternate Macintosh terms indicated by *)
The Menu
|
Core Set
|
- very high potential for mistaken context -
an image could be mistaken for the content area. keep 4 of the core content area menu items for contextual ambiguity's sake - the utility of [copy image location] is questionable, since it could be accomplished a number of other ways. However at this menu's current length, it's not posing much harm. - removing [Create Desktop Shortcut] to spare the [image as link] menu. - * Netscape Commercial RFE - Send image to online buddy shortcut. Would display a submenu which allow user to quickly transmit an image to an online buddy. - |
||||||||||||||||||||||||||
|
||||||||||||||||||||||||||||
|
4.x |
IE5.5 |
Opera 6.0 |
Opera Flyouts |
|||||||
| [Page >] provides entire previous context | ||||||||||
|
|
|
|
<- Top
Image as Link Menu (see alternate Macintosh terms indicated by *) (kin: image as mailto: link, image as news: link)
The Menu
|
Core Set
|
- fair potential for 3 mistaken contexts -
could potentially be mistaken for page - link context should have higher priority than the image. - Formula for this menu is to combine Link Menu and Image Menu. The Link subset should take precedence over the Image subset. - 16 items - [page source] not included because of rarity that a single linked image dominates the entire page. - Are [Link Properties] and [Image Properties] both useful as features? If not then consider replacing with [Page Properties] only. |
||||||||||||||||||||||||||||||||||||||||
|
||||||||||||||||||||||||||||||||||||||||||
|
4.x |
IE5.5 |
Opera 6.0 |
Opera Flyouts |
|||||||
| [Page >] provides entire previous context | ||||||||||
|
|
|
|
<- Top
Image as URL Menu (see alternate Macintosh terms indicated by *)
The Menu
|
Core Set
|
- [Back] returns user to previous page, if available.
|
||||||||||||||||||||||
|
||||||||||||||||||||||||
|
4.x |
IE5.5 |
Opera 6.0 |
Opera Flyouts |
|
|
Text as mailto: Link Menu (kin: text as link, text as news: link)
The Menu
|
Core Set
|
what is link properties?
- context ambiguity is fair - - [Select All]? |
||||||||||||||
|
||||||||||||||||
|
4.x |
IE5.5 |
Opera 6.0 |
Opera Flyouts |
|||||
| Uses same menu for Text Link |
[Page >] provides entire previous context | |||||||
|
|
|
|
<- Top
Image as mailto: Link Menu (kin: image as link, image as news: link)
The Menu
|
Core Set
|
what is link properties?
- Formula for this menu is to combine Link Menu and Image Menu. The Link subset should take precedence over the Image subset. |
|||||||||||||||||||||||||||||||||
|
|||||||||||||||||||||||||||||||||||
|
4.x |
IE5.5 |
Opera 6.0 |
Opera Flyouts |
|||||||
| Uses same menu for Text Link |
tack on the image subset to the mailto mailto subset. |
[Page >] provides entire previous context | ||||||||
|
|
|
|
<- Top
Text as news: Link Menu (kin: text as link, text as mailto: link)
The Menu
|
Core Set
|
* [Alias in Finder] for mac
|
|||||||||||||
|
|||||||||||||||
|
4.x |
IE5.5 |
Opera 6.0 |
Opera Flyouts |
|||||
| same menu for text link | Uses same menu for Text Link |
[Page >] provides entire previous context | ||||||
|
|
|
|
<- Top
Image as news: Link Menu (kin: image as mailto: link, image as link)
The Menu
|
Core Set
|
what is link properties?
- contextual ambiguity is fair - - Formula for this menu is to combine News Link Menu and Image Menu. The News Link subset should take precedence over the Image subset. |
||||||||||||||||||||||||||||||||
|
||||||||||||||||||||||||||||||||||
|
4.x |
IE5.5 |
Opera 6.0 |
Opera Flyouts |
|||||
| same menu for text link | Uses same menu for Text Link |
[Page >] provides entire previous context | ||||||
|
|
|
|
<- Top
Form/Input Field Menu
The Menu
|
Core Set
|
• - [New Feature] toggle autocheck spelling checker
- editiable text menu cross reference - turning on bidi option in the main menus (use the same switch as Character Encoding), or by detecting the region and language, will allow user to access 2 new features in context menus: change text direction in text fields and in selected text -Redo: Mac Shift-Z Others Y |
|||||||||||||||||||||||||
|
|||||||||||||||||||||||||||
|
4.x |
IE5.5 |
Opera 6.0 |
Opera Flyouts |
|||||
| -Opera 6 takes you to form fill settings/presets |
||||||||
|
|
|
|
<- Top
The Frame Subset (see alternate Macintosh terms indicated by *)
Sample: Content Area Menu
|
The Subset
|
-Insert the frame subset to any Context which lives within a frame - place the flyout item between the first group of items and the subsequent groups as shown in the example of the Content Area menu to the left.
- totally ambiguous - frame context could be mistook for page,or anything else for that matter. - any contextual menu element which exists on a framed page should be treated as part of the most global context. for example - [view background] doesn't belong in the frame context or the user model of a site, because our users by and large aren't concerned that frames exist. So, if there is background to view then it should appear to belong to the page, not in any particular frame to which it actually belongs. the same would be true for: - form items, background images, etc. - *[Alias in Finder] for mac • [Character Encoding] should be off by default for English/US Western Users, toggled in the view menu, or shipped only in "internationalized" versions of the product. |
||||||||||||||
|
4.x |
IE5.5 |
Opera 6.0 |
Opera Flyouts |
|||||||||||
| IE makes no distinction between the frame and regular content. |
Opera adds a single flyout to provide disctinction between contexts |
|||||||||||||
|
|
|
|
<- Top
Sidebar Tab Menu
The Menu
|
|||||||
|
4.x |
IE5.5 |
Opera 6.0 |
Opera Flyouts |
n/a |
n/a |
n/a |
n/a |
<- Top
Page Tab Menu
The Menu |
||||||||||||
|
formula = tab / content area - [bookmark tab set] - page tab properties takes you to prefs |
|||||||||||
|
4.x |
IE5.5 |
Opera 6.0 |
Opera Flyouts |
n/a |
n/a |
n/a |
n/a |
<- Top
Page Tab Bar Menu
The Menu |
||||||||
|
formula = tab / content area - [bookmark tab set] -page tab properties takes you to prefs |
|||||||
|
4.x |
IE5.5 |
Opera 6.0 |
Opera Flyouts |
n/a |
n/a |
n/a |
n/a |
Toolbar / Chrome Menus
Feature Menu |
Button Menu |
Personal Toolbar Menu |
Generic Toolbar Menu |
|||||||||||||||||||||||
|
|
|
|
|||||||||||||||||||||||
|
4.x |
IE5.5 |
Opera 6.0 |
Opera Flyouts |
n/a |
n/a |
n/a |
n/a |
<- Top
Personal Toolbar Menu
Personal Toolbar Menu |
Personal Toolbar Items (bookmarks) |
Personal Toolbar Items (folders) |
|
|||||||||||||
|
|
|||||||||||||||
|
4.x |
IE5.5 |
Opera 6.0 |
Opera Flyouts |
n/a |
n/a |
n/a |
n/a |
<- Top
Manage Bookmarks Menu (incomplete)
Personal Toolbar Menu |
Personal Toolbar Items (bookmarks) |
Personal Toolbar Items (folders) |
|
||||||||||||||
|
|
||||||||||||||||
|
4.x |
IE5.5 |
Opera 6.0 |
Opera Flyouts |
n/a |
n/a |
n/a |
n/a |