Open Bug 27338 Opened 25 years ago Updated 2 years ago

context menu items should remain in constant position

Categories

(SeaMonkey :: UI Design, enhancement, P3)

enhancement

Tracking

(Not tracked)

People

(Reporter: sarnold, Unassigned)

References

()

Details

Attachments

(4 files, 1 obsolete file)

Netscape communicator 4.7 always has the "back" menu item occupying the top position on context sensitive menus. I have become addicted to this placement, and I feel disoriented with "Open Frame in New Window" as the top menu item on the context menus while browsing a site with frames. I would like the "back" and "forward" menu items to be held in constant placement on the context sensitive menus, similar to communicator. Thanks! :)
This one's going to get disagreement no matter what. In earlier versions of Communicator, Back and Forward were always at the top of the context menu. With NN 4.7 (going back to 4.5 methinks), Open Link in New Window and Open Link in Composer got added on top iff the right-click was over a link, and Open Frame in New Window iff the right-click was onto a frame. Mozilla is mirroring what NN 4.7 is doing, so in that sense already has 4xp. Personally, I open in new windows all the time with the context menu, and tend to use the toolbar button or ALT-rightarrow, depending on where my mousing hand is, to go back, so I'd prefer not to have Back at the top of the menu. But I suspect that this is in a spec, and the spec will win over personal preferences.
Keywords: 4xp
*sigh* of course I forgot about how links are handled. I do enjoy the Open Link In New Window on the context menu --- and would miss it if it weren't the top of the menu. (Heheh, however, once mozilla supports navigator's middle-click to open the link in the new windows, I am going to be using the context menu much less often. :) Thanks
Summary: [rfe] [4.xp] context menu items should remain in constant position → [rfe] context menu items should remain in constant position
QA Assigning non-confidential New/Assigned User Interface: Design Feedback bugs to Matthew Thomas (mpt@mailandnews.com). Matthew Thomas is now the QA owner for the User Interface: Design Feedback component. (Bugs that involve UI issues in the Netscape-branded Mozilla browser should continue be QA assigned to elig@netscape.com.)
QA Contact: elig → mpt
I think there should be a distinction between the top item in the context menu, and the *default* item in the context menu. That is, sometimes the context menu should pop up in such a position that an item other then the first item is right next to the mouse pointer. For example, the context menu for a link could still have `Back' and `Forward' at the top; but the default item (further down in the context menu) could be `Open link', immediately followed by `Open link in new window'. Since context menus are currently done by Mozilla rather than by the OS, this could be implemented XP fairly easily.
mpt, i posted that rfe as bug 37596.
consistancy is the key here. the user, after using the browser for a while, should be able to navigate with his/her eyes closed. In N4, I have the navigation bar closed, I navigate with the mouse. I know that when I want to go back all i have to do is right-click and move the mouse a tiny bit down and right. to stop, it's just a bit more down. the important thing is that it's in the same spot *every time*. If you want to change the position of the items, you might as well place them in the menu randomly, it'd be just as easy to use. the way N4 puts open in new window at the top when you're in a frame annoys me to no end. I have to make a concious effort to change my behavior simply because the page is in a frame. The number 1 reason I don't use IE is because I never know what's going to be in the menu when I right-click. it would be a shame to see mozilla do the same thing. The best solution imho is to put the navigation items at the top no matter where you click, followed by context-specific stuff, then have things no one uses at the very bottom (view source, add bookmark, etc...)
*** Bug 42275 has been marked as a duplicate of this bug. ***
More Mac-Windows fun. Checking NN 4.x and a current Mozilla build on Windows, the context menu for a link includes "Open in New Window" and "Open Link in Composer", but not "Open this link". That's not consistent with Windows Explorer and IE, which always put the default action at the top of the context menu (re-ordering it depending on what actions are possible), but it is consistent with usage: since a single click will always traverse an http or ftp link in the same window (assuming no target), right-clicking to invoking a context menu to do the same is about the least likely use of a context menu. (Note that those for whom using a mouse is difficult would just press [Enter] once the link they wish to traverse has focus.) From the discussion in bug 42275, I'm guessing that on a Mac, once a context menu has appeared after 0.5 seconds of hovering over a link, it is easier to use it than to dismiss it and click on the link again, and thus "Open this Link" *should* be the default action. (I'm especially thinking of the usage style of many who tend to hover over a UI element while deciding whether to invoke its action , rather than think about whether to do a UI action first, and having decided, do it unhesitatingly.) Given that, Matthew's suggestion of distinguishing between the default and top item on a context menu makes sense, and at least on Windows, Jesse's suggestion of showing the default by bolding it makes sense, but making "Open this Link" default XP for all links would remove existing (and 4xp) ease-of-use functionality from Windows builds. There is no reason that the "Open this Link" item should not be on the Windows context menu in a constant position iff the top item were not always the default, and iff, on Windows, "Open in New Window" were the default. (As it is, opening a link in a new window is a very easy gesture: Right-click, hold, move pointer a few px, let button up) An aside: Neither "Open this Link" (Mac, from attachment) nor "Open in New Window" (Windows, from testing on Mozilla) is a very good synonym for "Compose Message" on context menus for mailto: links -- but that would be another RFE. (Worse, Mozilla *does* create a new browser window as well as a Message Compose window; NN 4.x suppresses "Open in New Window" on the context menu for mailto: links, probably to work around that).
Hmm, it seems like the mailto: contex menu items problem is the subject of bug 32358, "changes to context menu for mailtos", M21. Matthew, if my reasoning about having the same default item on a context menu as the normal default action on a Mac is correct, you may want to speak up there -- the current proposal is to have *only* a "copy email address" item.
Ok. I think Back and Forward should still be at the top of the context menu, even in a frame, and even over a link, because: * it makes the structure of the context menus more stable; * soon we're going to get `Open Frame in Whole Window', which -- if grouped at the top with the other `Open' commands -- would push Back and Forward even lower; * Windows users can now (like X users) middle-click to open in a new window -- decreasing (but not eliminating) the proportion of users who miss having `Open in New Window' as a *quick* context menu item. * Mac users will have 4xp behavior when bug 37596 is fixed. But it's Shuang's call.
Re "memorizable gesture" and "constant position": Having something near the top of the context menu doesn't guarantee that it's a simple, memorizable gesture. For example, what if you right-click a link near the bottom of the screen? What if you right-click on a flash applet (bug 38482, v. invalid)? (risking stating the obvious) What people want here seems to depend mostly on what they use the mouse for. A "mouse person" is likely to want to have navigation items readily available on the context menu, because the navigation toolbar buttons are usually far away and not ridiculously big. I'm a "keyboard person", so I use the keyboard for navigation and the mouse for doing things with links and frames. I expect to be able to do things like "open frame in new window" and "open link in new window" quickly, and don't care that the "back" option isn't always in the same place. But being a "keyboard person" also means that I'm more frustrated that Mozilla almost completely lacks keyboard shortcuts (bug 22529) than that items aren't where I want them on the context menu. Would it make sense for middle-clicking in an empty area of a frame to open the frame in a new window?
(wow, I never expected this to become so long... :) In direct response to only the latest person asking about middle-clicking in an open area of a frame to open the frame in a new window: I don't think I like that particularly -- middle-click, when something is in the clipboard, will open that something in the current window. I like the feature, but don't use it every day. However, I would be sad to see it go in favor of opening a frame in a new window... (I guess pleasing everyone is going to be impossible. :)
Oh, I wasn't aware of that functionality. Ignore that part of my comment :) (What happens if you middle-click in a frame? Does it open the clipboarded URL in the whole window or in the frame?)
perhaps we can make it like this (when right-clicking a link): +-------------+ |Composer | |New Window | ->|-------------+ |Back | |Forward | |Stop | +-------------+ |View Source | | ... | +-------------+ That way the navigation items are always in the same relative spot, right and down a bit. The context-specific stuff are also in the same spot, right and up a bit. The lesser-used stuff are at the very bottom. It seems to be the solution to make everyone happy. Mousers get the navigation stuff in the same spot every time, and keyboarders get the stuff they want close to the mouse.
shuang is no longer at netscape, so over to paul the default owner for triage...
Assignee: shuang → hangas
German, you choose and then send to Browser if change desired.
Assignee: hangas → german
Blocks: 36866
*** Bug 54699 has been marked as a duplicate of this bug. ***
I submitted a duplicate of this bug (54699, sorry), and have a few new comments. First, people have mentioned that Netscape 4.7 has the mozilla behavior. This may be true for some platforms, but every version of Netscape for Linux I have used has the "Back" button at the top, always. I am honestly surprised to learn that this was changed on other platforms. Second, the claim that the current behavior is better for "keyboard people" doesn't make sense to me. Even a keyboard person has to use the mouse frequently (well, doesn't _have_ to, but ...), and during these times, right-click-back is faster than clicking the back button or switching to the keyboard. Also, there is already the middle-click shortcut. Third, the point that the "back gesture" not working at the bottom of the screen is weak because one can easily learn to avoid it, and most people keep their mouse in the middle of the screen anyway. I don't recall ever having made a mistake because of this. Basically, back is such a frequent and fundamental function that it deserves a convenient, consistent idiom. If you give users a convenient idiom that works most, but not all, of the time (ie, current Mozilla), many will get used to that idiom and become confused when it doesn't work (especially since when they want to go back, they won't even notice whether they are over a link). Due to the first point, I argue for back on top at least for Unix, but preferably for all platforms.
mass-moving UI:Design Feedback bugs to hangas
Assignee: german → hangas
Is there anything still going on regarding this topic? In user interface design, consistency is one of the foremost design principles, and that is violated here. Other than than, I have nothing to add in favour of a change as everything has been said already. In particular, I'd like to support Andrew Pimlott's statement and would like to see this thing done :-)
andrew's comments are probably worth ignoring. touchpad manufacturers solved the problem by adding back/forward regions. ms and other rodent manufacturers added buttons (we have bugs for supporting these events). if i finish my cs projects early, i'll publish my bindings which will surely not gather support from andrew.
timeless: you're slightly missing the point. ;-) Of course, if you have special hardware you can provide other means of navigation. But that fact is unrelated to making the existing means easy to use. And every HCI book tells you that a user interface has to be consistent in order to be easy to use ...
hci books are young and ever hci developer will tell you that they haven't decided whether an advanced mode is a good or bad thing. hci is a young field and like all psyc fields not everything published is worth following. provide a patch that makes me happy and i'll work on getting it in. otherwise stop complaining, all sides have spoken enough. context menus don't work when you have multiple contexts concurrently. explorer tends to reduce the number of options shown when you have objects of different types selected, but that probably violates your consistency view. context menus are supposed to be contextual, normal menus are suppposed to support this stupid hard wiring. if you right click a piece of paper a stone, and a pitri dish filled w/ water do you want to have the same menus for all three objects?
> if you right click a piece of paper a stone, > and a pitri dish filled w/ water do you want to have the same menus for all > three objects? I would like to have "global" menu items in the same place (relative to the cursor) for all 3 items, especially if they all are on the same table and all look very similar (which is often the case with things like transparent backgrounds and CSS to make links look like regular text. Then there's the case when the page is in a frame...) Having to go, "let's see.. what's my pointer over? hmm.. looks like it could be an image, that means I'll have to move my cursor this much." is lame. Having to read the menu every time it comes up is even lamer.
to be clear i'm talking about physical objects, so i hope you're talking about a physical table. Suppose [Sp] you are disabled and have to use a computer to manipulate objects. You sucessfully manipulate a pointer to a region of space that contains 5 objects. Now you tell the computer you want to manipulate it. Does the computer give you a list of actions you can do [sorted based on what is typically done {by you, for objects, by you for these objects, for the most prominent object}] and then how does the computer indicate that you failed to indicate exactly one object? If i'm this user, i'd want the computer to give me a list of objects and allow me to indicate that i want to act on a specific one. as for the pref of what to put first, a semi sane implementation follows |most prominent object| although that's probably the wrong description. In web browsers i use that to mean the item which i could most easily have missed and therefore in not missing am most likely to have wanted to implicate.
Mozilla already leaves the navigation items at the top of the context menu when you right-click on an image, since you can't always tell when you're over an image. You can usually tell when you're over a link, though, so it would be a waste to put them at the top of the link context menu (since we want the link and image+link context menus to not be too long, and since many users want fast mouse-only access to Open Link in New Window). I like Mozilla's current behavior here.
Jesse: following your argument about noting that you are over a link and can then expect a different context menu - I often don't realize (or realize too late or don't care) that a new page is actually framed, in which case currently the topmost item is "open frame in new window" instead of the navigational items. Then I end up having created a new window when I just wanted to get back. This is the very reason I'm so annoyed by this "bug"... :-/ Maybe we can reach an agreement to leave the nevigational items at the top in case when the user can't be very sure about the context (e.g., over an image, in a frame), but if you so desire then put some other important stuff at the top when the user in fact can be sure (e.g., over a link). Would that be OK? timeless: regarding your comment that I provide a comment or stop complaining - I see this as a design issue, not a coding issue. Once the design has been agreed upon the coding is probably simple. Therefore, before we don't have an agreement on the design I won't be wasting my time to produce a patch that won't get included because you "don't like it" ;-)
Three additions, even if debate is nominally closed: 1) New pointer designs notwithstanding, the great majority of users currently do not have special-purpose back/forward controls. 2) timeless makes interesting points about the UI difficulty caused by layered contexts, but I think misses the fundamental point that, regardless of what objects happen to be on the page, the browser context is usually predominant to the user. Put differently, I bet that a user executes 1000 "generic" browser operations for every one "special" operation on a particular object. If this is true (and it is obviously only speculation, as I have not scientifically surveyed browsing habits), then if "special" objects (eg images) occupy just 1% of the screen, every time I right-click on such an object, I am still 10 times more likely to want a "generic" browser operation than a "special-object-specific" operation. To refer to timeless's own model, I would argue that the web browser is (almost) always the "most prominent object". 3) timeless argues that the context menu should emphasize the "item which I could most easily have missed". This doesn't make sense to me (and evokes the humorous image of a user right clicking all around the screen, to see whether there's anything he missed). If you right clicked and weren't looking for "generic" browser operations, surely you were already aware of what object you were clicking on. Can you explain what you meant?
Chaning the qa contact on these bugs to me. MPT will be moving to the owner of this component shortly. I would like to thank him for all his hard work as he moves roles in mozilla.org...Yada, Yada, Yada...
QA Contact: mpt → zach
updating to new owner. sorry for the spam.
Assignee: hangas → mpt
Depends on: 75338
No longer blocks: 36866
I would be very happy if Back was always on top especially when I'm in a page that happens to have frames. Thank you
*** Bug 92207 has been marked as a duplicate of this bug. ***
I think we are getting too deeply into this. To me this is a simple issue. When I am looking at the site that I go to, do I see a frame or a page? What is it that I am affecting when I click on a space that is not an image or a link? To me it's the page. The entirety of it. I may be travelling within a frame of that page but it's the whole thing that i sbefore me and so the back button should be first in the list. If I click on a link then I can see that it is the liunk that I am acting on. If on an image then similar (though this gets a wee bit messie with bg images but lets not go into this overly deeply again). Now. I tried to think of a page with frames in it and I got the one in the attachment I am about to leave from a friend. When you look at it, do you see a frame or a page? Does the fact that you're in a frame become instantly apparent to you? If you got someone else who did not know what the image is there to represent to tell you, what would they say? (I tried this with someone else and they said 'page'). Anyhow, attachment coming up. I hope this puts things more on track again as this has annoyed me many a time now. (it is -really- weird and disorienting using the right mouse button to go back and have a window pop up on you). (oh. and the dupe above is mine also :)
No longer depends on: 75338
restoring dependency (probably) lost because of bug 108175.
Blocks: 75338
the very premise of this would suggest that menus should grow out of proportion to their contexts. i feel that the usefulness of context menus 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. i have posted the 2nd draft to the Context Menu Revision 2 document located: http://mozilla.org/projects/ui/communicator/framework/contextmenus/cmrev2-2.html
*** Bug 119892 has been marked as a duplicate of this bug. ***
.
Assignee: mpt → blaker
Component: User Interface Design → XP Apps: GUI Features
QA Contact: zach → paw
Summary: [rfe] context menu items should remain in constant position → context menu items should remain in constant position
*** Bug 200249 has been marked as a duplicate of this bug. ***
Reassigning obsolete bugs to their respective Seamonkey owners (i.e. nobody). If you want this fixed for Firefox, change the Product and Component accordingly and reassign back to me.
Assignee: firefox → guifeatures
Product: Core → Mozilla Application Suite
Filter "spam" on "guifeatures-nobody-20080610".
Assignee: guifeatures → nobody
QA Contact: pawyskoczka → guifeatures
Component: XP Apps: GUI Features → UI Design
You need to log in before you can comment on or make changes to this bug.

Attachment

General

Created:
Updated:
Size: