27338 - context menu items should remain in constant position

Status: NEW

(SeaMonkey :: UI Design, enhancement, P3)

Description

[sarnold]

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! :)

Comment 1

[Sean Richardson]

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.

Comment 2

[sarnold]

*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

Comment 3

[Eli Goldberg]

QA Assigning non-confidential New/Assigned User Interface: Design Feedback bugs 
to Matthew Thomas ([e-mail]).

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 [e-mail].)

Comment 4

[Matthew T (active 1999-2002)]

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.

Comment 5

[Jesse Ruderman]

mpt, i posted that rfe as bug 37596.

Comment 6

[Brian]

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...)

Comment 7

[Matthew T (active 1999-2002)]

*** Bug 42275 has been marked as a duplicate of this bug. ***

Comment 8

[Matthew T (active 1999-2002)]

Attachment: How 4.x's context menu looks immediately after you open it

Comment 9

[Sean Richardson]

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).

Comment 10

[Sean Richardson]

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.

Comment 11

[Matthew T (active 1999-2002)]

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.

Comment 12

[Jesse Ruderman]

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?

Comment 13

[sarnold]

(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. :)

Comment 14

[Jesse Ruderman]

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?)

Comment 15

[Matthew T (active 1999-2002)]

Attachment: Yes, it *is* still the same simple, memorizable gesture, even if you click at the bottom of the screen. :-)

Comment 16

[Brian]

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.

Comment 17

[sairuh (rarely reading bugmail)]

shuang is no longer at netscape, so over to paul the default owner for triage...

Comment 18

[hangas]

German, you choose and then send to Browser if change desired.

Comment 19

[Matthew T (active 1999-2002)]

*** Bug 54699 has been marked as a duplicate of this bug. ***

Comment 20

[Andrew Pimlott]

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.

Comment 21

[german]

mass-moving UI:Design Feedback bugs to hangas

Comment 22

[NilsE]

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 :-)

Comment 23

[timeless]

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.

Comment 24

[NilsE]

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 ...

Comment 25

[timeless]

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?

Comment 26

[Brian]

> 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.

Comment 27

[timeless]

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.

Comment 28

[Jesse Ruderman]

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.

Comment 29

[NilsE]

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" ;-)

Comment 30

[Andrew Pimlott]

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?

Comment 31

[Zach Lipton [:zach]]

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...

Comment 32

[Asa Dotzler [:asa]]

updating to new owner. sorry for the spam.

Comment 33

[AriB]

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

Comment 34

[Ashley Bischoff (blog at handcoding.com)]

*** Bug 92207 has been marked as a duplicate of this bug. ***

Comment 35

[Hogarth]

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 :)

Comment 36

[Hogarth]

Attachment: A small illustration of why the back button should remain on top. Are you looking at a page or a fram (or set of frames?)

Comment 37

[bugzilla]

Attachment: tiny patch to keep back at the top of the context menu

Comment 38

[Asa Dotzler [:asa]]

restoring dependency (probably) lost because of bug 108175. 

Comment 39

[marlon bishop]

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

Comment 40

[Michael Lefevre]

*** Bug 119892 has been marked as a duplicate of this bug. ***

Comment 41

[Jonas Jørgensen]

.

Comment 42

[Alfonso Martinez]

*** Bug 200249 has been marked as a duplicate of this bug. ***

Comment 43

[Blake Ross]

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.

Comment 44

[Serge Gautherie (:sgautherie)]

Filter "spam" on "guifeatures-nobody-20080610".

Comment 45

[BMO Automation]

Attachment: [mozilla-mobile/fenix] For #27338 - Update summary text for preferences from settings screen (#28207)

Comment 46

[Frank-Rainer Grahl (:frg)]

Comment on attachment 9308453 [details] [review]
[mozilla-mobile/fenix] For #27338 - Update summary text for preferences from settings screen (#28207)

wrong bug