|
Mach V |
UI Specification |
|
Context Menus Specification Rev 2, 2nd Draft Digest of Responses to Bugzilla #75338 and it's Dependencies |
Last Modification:
|
|
Author Marlon Bishop |
Status: Discussion |
|
Contents
|
Feature Team |
I have made some responses to many of the viewpoints presented in
the above bug and dependencies which may be at odds with the spec
I have produced. A careful look at the design principles at the top of
the spec will provide insight behind many of the decisions made in the
menu, as will taking a look at the supplementary 'yellow boxes' which
now accompany each menu.
*my responses are indicated in italics
| a note about frames in context menus: A web page designer intends to convey content and navigation. A user is concerned with viewing, finding content and generally "browsing" anything of interest. However the point made in the abstract below, rings clear that most times poorly designed software (or webpages), can be characterized by a mismatch in intentions. The way browsers have modeled frames for the user in the past, has contributed to such a mismatch. The blame for this lies not on web page authors for using them, but on web browsers for failing to offer users a non-salient content model for manipulating a framed page. This is partly why Jakob Nielsen in 1996 wrote his now (in)famous article, "Why Frames Suck". In my proposal, the Frame Subset context menu is designed so that: 1) frame specific items are relatively burried in a flyout, and 2) structured to offer users *site-driven, goal-oriented* functions, not *engineering-driven, document oriented* functions. This model promotes bookmarking of "netscape.com", not "nav.html" for reference background please check out the idea presented in: Coding behaviour of human and computer in terms of intentions B. Hofmann, R. Freitag and W. Dzida Abstract Summary: The background of an intention-based coding of interactive behaviour is the theory of human action regulation [3]. A basic concept of this theory is the notion of "complete task", elements of which are preparatory action, exploratory action, conduct of intermediary steps, error management, assessment of intermediary or final results, etc. Starting from these rather abstract elements of a task structure one can develop a refined intention-based coding scheme for analyzing the interaction. |
|
Bugzilla Bug 75338 - Clean up context menus for Navigator/Messenger content area ------- Additional Comment #15 From Matthew Thomas (mpt) 2001-07-05 10:46 ------- >2. Keep the menus as consistent as possible between contexts. The most > noticable manifestation of this is that for a non-link image, the > link-specific items are dimmed but still present; this is because it > is often not obvious whether a particular image is a link or not. "consistency" is a fundamental aspect of good design, but like anything which carried to an extreme without consideration of _all_ the practical aspects of design, considering user intent for one, consistency just because it sounds good, doesn't really. This strict, inter-context consistency adds value that is very marginal. Matthew's model is great for aiding memorization of *position* of a command - to look for the same menu item to appear in the same spot every time. However if that rule must be adhered to so strictly that it begins to impose an additional burden on other design aspects, or simply goes against user intention, then a mismatch is born. A mismatch between the user's model for completing a given task using the application, and the software designer's model for the feature. If you were a plumber, went to a job with one single giant toolbox that included automotive tools laying on top of your piping, welding and plunging items, it would be a real pain to fumble through to the right tool. the monkey wrench and the teflon tape belong on top, because you're gonna need to grab them while you're laying upsidedown under the sink and with crap spraying in your face. Why would you carry around the same all-inclusive toolbox for every job? Why would you bring an extra solenoid for a 1984 Dodge Daytona Turbo with you to fix the bathroom sink? Why would you bring a jackhammer when fixing a squeaky faucet. In what way is this sort of cross-toolbox consistency useful? The purpose of context menus is not one massive carry all to aid memorization of command positions, the menus in this product simply aren't used in such a way. The 3 most popular menus are image-as-link, inline-image, and text-as-link. there's no need to build so much cross menu memorization in the first place if you only have really 3 commonly used menus. In summary, users won't have a need for this level of menu item persistance because unused or less relevant menu items will just be in the way of their task. Users need context menus to access commands related to the item the cursor is under (quoted from Windows Guidelines Ref). They need a brief subset of commands that pertain to their immediate task (offer 'value' tasks that may be of interest), the more unrelated the items at the top of the menu are, the less useful and gestural the menu becomes. >3. Follow a general two-part structure. The first two items in each >menu are for quick gestural navigation, and for indicating what an >ordinary click would do. The rest of the menu concentrates on items >specific to the context. this sounds somewhat contradictory to me. The items which are gestural aren't the items which are specifally contextual? i believe they should be. i too agree with default menu items, so i've incorporated them in the latest draft. ------- Additional Comment #26 From Gervase Markham 2001-07-09 08:46 ------- >"We (regular users) really need an "E-mail this page" for web pages." >Anyone who emails random web pages to anyone else should be shot. >Well, that's a bit strong, but it's context menu items like "Email this page" which lead to me >having to take half an hour to download netscape.public.mozilla.reviewers on my >56k because half of the review requests have the entire bug web page attached >needlessly. >This is what _links_ are for. Why would you ever want to email anyone >a web page when you could mail them a link? I doubt there's a significant number of people >who have email access but not web access any more. However frusting it may be, it's up to end user discretion to make use of the feature and determine it's prudence. It _can_ be put to good use when a user wants to send the current state of a site before it gets updated or expires for example. ------- Additional Comment #23 From Peter Lairo 2001-07-09 02:19 ------- >How about "Bookmark this Frame"? since "bookmark" isn't a verb yet, i thought i'd check with our pubs group to see if they'd have any objections. otherwise it would work well to provide some semantic distinction with having too many of these scenarios: [file link in bookmarks] [file link in address book] [file link in subscriptions] [file .... in .....] instead we should use more diverse phrasing to aid selection and sound more appealing, less technical: [bookmark this link] [add to address book] [subscribe to newsgroup] ------- Additional Comment #30 From Jake 2001-07-09 11:57 ------- >> Why not "Change Text Direction" instead of Left To Right and Right To Left >> usability gain *is* greater than the usability loss > >Not for me. I have no use for Right-to-Left text so that item is something >I'll aways be flying over (and if there's two of them, I'll be flying farther). Only when Hebrew or Arabic is selected in region encoding should this feature appear in CM menus. I would propose a switch in either prefs or turned on for internationalized builds. >> Bookmarking a mailto link is a bit strange. > Firstly, it's present for all other browsers I've tried. > >I guess it is, but I personally agree that it really shouldn't be. Address >books are for holding e-mail addresses, not bookmarks (but that is just IMHO). I agree, it's going to confuse users especially if the appearance of the item still used a bookmark icon. Either way, we shouldn't promote bookmarking as a way to manage email, since it doesn't do a good job of that. >>> We (regular users) really need an "E-mail this page" for web pages. >> Nope. It's neither contextual nor extremely common. > >I agree, for the most part. The one time I can think of this being useful is >where you submit some information and get a page with what you submitted (and >possibly a confirmation number on it) and don't either have a printer handy or >want to print the information. It would then be useful to be able to send the >page (as retrieved from cache) to yourself (possibly at another address than >where your are) or somebody else. But really doesn't warrent a context menu, >so I guess it's not applicable to this bug... This is a good scenario. Also for the reason of expiring webpages, or time sensitive news updates. A way to preserve those items appearance is needed. In general, we need more feedback like Jake's. He makes very good points, a real pity he's not more active. ------- Additional Comment #33 From Matthew Thomas (mpt) 2001-07-10 06:27 ------- >> Not for me. I have no use for Right-to-Left text so that item is something >> I'll aways be flying over (and if there's two of them, I'll be flying >> farther). > >The only case when you'd ever be flying over it would be if you were inserting >a Unicode control character, for the first time in a given session (after which >you'd probably leave the character palette window open). Eeeeeeeedge case. also for reasons i mention above. this feature should be active only for locales that require it, not only in text field, but for content with mixed encodings. nevertheless, none of them should appear for every locale by default. >> There's still no way to bookmark a frameset (i.e. the equivalent of File >> Bookmark... when you right click somewhere in a frameset.) > >Yes there is. `Bookmarks' > `Add Bookmark'. I don't believe users will appreciate that. If the spec provides a bookmark for a normal page in CM, why should user be prevented to bookmark a page in the same way just because a seemingly normal looking page contains frames? Again, our users rarely care about frames specifically, most times they'll be more interested in the page, and when they do only want just a frame, that's where context menus help. That sort of inconsistency just doens't jive. >> Change Text Direction would not be a checkmark item. It would merely change >> the direction of the text in the textbox. When would a user want to change >> the text direction? When it looked wrong. So a menu item to change it to the >> right way (which it would) is what you want. >It's not as obvious as that. The first time I accidentally pressed the keyboard >shortcut for this function, I really thought that it was a bug in Internet >Explorer. My words were all jumbled, but it wasn't obviously related to text >*direction* at all. It was the mention of `Right to Left' in the context menu >which enlightened me. I think it's obvious that something to the effect of, "change text direction", "reverse text direction" will be convincing enough for our users. Hopefully the pubs group could provide some expertise here for concise phrase to alleviate having two items instead of a toggle/checkmark solution. >> I don't like having Reload at the bottom. It just looks out of place there. > >I pondered not having it at all, but it is reasonably useful for windows >without a menu bar. You're correct, it is useful - but that didn't answer the question. Why is towards the bottom? >> Muscle memory is only useful for the first few items on the context menu; >> after that it becomes "click the last item on the context menu" or "click the >> first item after the first separator". > >As it is now, the first half dozen items *are* consistent in position. Putting >`Reload' near the top would disrupt that. 'Consistent in postion' does not answer the question about muscle memory or eye scanning performance being most efficient at the top most region, or bottom most. the use of dividers provide a good way to aid visual performance, and i'd say that visual performance is nearly as high around these. ------- Additional Comment #51 From fantasai@escape.com 2001-08-02 14:48 ------- >I suggest changing "Save Link As..." to "Save Linked File As..." >I remember being confused about this when I first started using a web browser; >I'd waver between "Save As" and "Save Link As". I didn't want to save the link >(the blue hyperlinked text)--I wanted to save the file on the other end. I changed the naming of that item to [Save Link Target As...] which is more accurate. >> I found myself wondering why Copy Link Address and Copy Image were not with >> Copy Image Address. >Same here. >If we were to sort by function first, and then by object it would look something >like this: > > * {Open Link | Submit Form} Action > * {Open | Submit} in New Window > > * Copy {Image | Selection} Copy > * Copy Link Address > * Copy Image Address > > * Save Link As ... Save > * Save Image (blarg_01.png) As ... > * File Bookmark for Link ... > > * {Block | Unblock} Image ... Load > * {Load | Reload} Image > > * View Only this Image View > * Link Properties > * Image Properties {and Description} > >So, is that better, or worse? This is definitely something worth considering - shuffling the items based on function.. However what you loose with this method is transference of muscle memory from one menu to the next. Our proposals both seek to maximize association by keeping functions grouped based on context. It depends on how the user view the world - as objects, or as 'things to do'. You could argue either way, however, organization based upon context, or object, offers groupings which become easier to recall over use. ------- Additional Comment #90 From Charles Manske 2001-10-18 10:42 ------- >Context menu click should NOT deselect. That's how I thought most Windows apps >worked; I'm surprised Word doesn't follow that (maybe it's a pref in Word?) right clicking outside of selection would still produce menu pertaining to that selection unless the click were outside the 'horizontal vicinity' (imaginary horizontal bounds) of that selection. then we would deselect, and produce the previous context. this is how it works in ie6, and makes a fair bit of sense since it wouldn't allow user to easily forget he/she selected something when scrolled away from view - if another context were contained within that selection, then right clicking on that element (a form or an image for example) would produce the context menu for that element while keeping the selection. We don't want to loose the selection for a user if he/she is still clicking within the selection region. ------- Additional Comment #142 From Tim Powell 2001-12-19 09:02 ------- >Some specific concerns: I found carrying around the Add Page To Bookmarks, Send >Page, Save Page As, and Print Page items on basically every context menu in >Marlon's to be unnecessary and confusing. This is to provide 'backwards compatability' for ambiguous contexts. for example if user clicks on an image which predominates a page, then how do we determine what they really intend do? which menu should we produce? by providing a scaled-down subset of the content area menu in ambiguous cases, we offer a good balance of menu items for both contexts. >Context menus should not have >submenus, they should have them as a last resort, or only when it makes sense. >and the Frame submenu is especially problematic. It moves the Open >Frame in New Window from being quickly accessable to quite hidden, and >eliminates the View Only this Frame item. frame specific items are quite frankly nothing but problems for most users. Which is why I propose to move them deeper. at the same time it allows user select from a clear division of functions between global and frame specific views. >The mailto: context menu needs a way >to Send email and make it too easy to add to address book. i added default menu items for the 2nd draft spec which should solve that problem. Bugzilla Bug 78338 [RFE] "Character Coding" in context menu in "Message" pane ------- Additional Comment #5 From Matthew Thomas (mpt) 2001-05-03 10:33 ------- A context menu can appear (modulo a bug in XP Toolkit) in any one of four possible places relative to the original position of the cursor, depending on the size of the context menu and how close the cursor is to each edge of the screen: * to the southeast (the default) * to the southwest (if there's not enough room to the right of the cursor) * to the northeast (if there's not enough room below the cursor) * to the northwest (if there's not enough room below *or* to the right of the cursor). For the same reason, if your context menu has a submenu, the submenu can appear in any of 4 * 4 = 16 possible places relative to the original position of the cursor. And if that submenu itself has a submenu -- as the main-menu encoding menu structure currently does -- then the third-level context menu can appear in any of 4 * 4 * 4 = 64 possible places relative to the original position of the cursor. This extreme variability in position makes the quick muscle memory, which context menus are predicated on in the first place, basically useless. It's much quicker just to go to the relevant main menu item instead, rather than using the context menu. For this reason, context menus should never contain submenus. So *if* encoding selection is included in the message pane UI, I think it needs to be a simple `Encoding ...' item which brings up the dialog described in bug 10999. as much as this premise might be valid, the conclusion you have drawn is impractical and too absolute. In a world where all context clicking took place in the 1/8th screen, lower right quadrant, we might have a problem. But i think for most situations, submenus kept to a minimum are fine. A more realistic conclusion might be to say something like - never place tier 1 or tier 2, muscle-memory dependent tasks in a submenu. But to make the statement that no product should ever use submenus would be quite obtuse. there are many variables to consider of course - screen realestate, system font size, and others... the lower-right 1/8th quadrant, and to a lesser degree, the right 1/8th section of the screen, to which your idea mostly applies, is considered the least valuable in terms of information or web page design. Therefore I don't think we should dictate such absolute rules when the conditions under which they apply are uncommon. the purpose of submenus is to bury infrequent items, this supposes that muscle memory *would not even be built*, in order to be relied upon. Bugzilla Bug 10723 [RFE] Context menu item to hide image ---the benefit is outweighed by the effect of adding an extra menu item in the image menu. Bugzilla Bug 27338 [rfe] context menu items should remain in constant position the very premise would suggest that menus should grow out of proportion to their contexts. i feel that the usefulness of the feature lies more in it's ability to 'bring the right tools to the job', rather than facilitating shortcut memorization or any other un-proven hypothesis. Bugzilla Bug 17754 Ability to submit form in a new window answered above - "In what cases would users need to recall form submissions, furthermore, how will they identify stored form submissions???? I do believe a smarter way to accomplish the task described would be to make use of form manager feature. that way you could see (and manage) your form properly edit and identify individual entries." Imagine if you bought something and saved your form submission as a bookmark. Everytime you launched the bookmark it would buy the item again? That's a dangerous proposition. Bugzilla Bug 35130 Control of image loading using context menus (Show Image, Reload Image) although helpful, this would not be useful enough to warrant a spot in the image context menu. it is imparative that the image menu be kept brief as possible, because [image as link] depends on it's brevity. Bugzilla Bug 63054 Use context menu to change encoding of individual frames In my previous comment, i admited that i could not present a good case for the a multi-lingual user's encoding practices. Which is why I was willing to yield to the international authority on the subject, Katsuhiko Momoi . I am now convinced that this could be handled through menus and focus shifting, but that it would be helpful as a shortcut as since it's usefulness has been made apparent here. therefore once we get the implementation fixed, i suggest adding these items to context menus when a proposed Multi-Encoding Bidi support switch is set. This switch may be located either in a pref panel, or in the view menu. I'd support the requirement to hide the charset coding context menu item from Latin-1 users. This could be accomplished e.g. by one or a combination of the following criteria: 1) currently loaded document is encoded in Latin-1 2) browser cache cache does not contain at least one non-Latin-1 document 3) the main charset menu has never been invoked Bugzilla Bug 64749 Add point "Open link" to context menu when right-clicking on a link ---The reason i believe MS is doing this is to accommodate some beginning users which in lab studies seem to not understand or distinguish the difference between right or left clicking. specifically, some users tended to wander around the entire time using the right button to click. Unfortunately, this default menu items do make sense. if we want to follow those guidelines we would add the default action to some menus which required them.. These would include any object such as a link. The other piece to this puzzle lies in the unofficial click and hold behavior that we started doing on the mac. This makes it extremely easy to bring up a contextual menu for any variety of users who's natural behavior seems to include click-hold-and-ponder. Either you embrace what we started and place the default action item under the cursor, or you elminate click and hold, and go with the platform standard. The problem is that now, Netscape, Opera, and IE are doing click and hold, and it would really upset users who depend on it if it were to go missing. So i would have to argue that the default item belongs on the mac as well.. One convention i don't really agree with is placing [help] as the topmost item of every menu. as i am fairly certain it mostly happens in the OS. Bugzilla Bug 72008 Request: make "send link" available when right-clicking on link? we should be skeptical about adding items for "future contexts". for example a more common practice would be to enable user to send the currently viewed the context before while they've deemed it's usefulness. Bugzilla Bug 73322 Automatic image resizing --- Since this feature has not been designed in Mach V, the current spec will not reflect this. Bugzilla Bug 102875 inconsistent bookmark wording and behavior in toolbar and context menus ----Replace [Add Page to Bookmarks] with [Add Page to Bookmarks...] 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 Main Bookmark Menu should have only one Menu item:[Add Page to Bookmarks...] replacing [File Bookmark...] and absent is [Add Bookmark] - the resulting picker dialog will allow user to choose silent bookmarking as a preference. Bugzilla Bug 105580 [FEATURE] Enhanced context menu for selections --- these are good ideas. some of them have been included in my spec revision for context menus. however, some requests such as 'selected as URL or email' offer marginal utility, and don't quite deserve a spot in this context menu, relative to the items that do. "Look up selection in Encylopedia" would be entertaining, but not quite as useful as dictionary for example... Bugzilla Bug 113890 Remove "Edit Link in Composer" context menu item --- I agree that this item wouldn't receive enough frequency by the majority of our users to warrant context menu realestate. |