Open Bug 137901 Opened 22 years ago Updated 3 years ago

Context menus: Swap page and frame related options.

Categories

(SeaMonkey :: UI Design, defect)

Product:
SeaMonkey
Component:
UI Design
Type:
defect
Priority:
Not set
Severity:
normal

Tracking

(Not tracked)

People

(Reporter: nick, Assigned: marlon.bishop)

References

Details

In the new scheme, the page related options are right there e.g ("reload page").
And all the frame specific options are into a submenu (e.g "reload frame").

But:
 * If I want to reload a page, I already have a direct button to do it.
 * All browsers I've checked reload the frame in the frame's context menu.
 * According to rationale I've read, the context menu should show options about
the target object. Here the frame is nearer than the page to what the user has
choosen.

I've focused on reload, but the similar things can be said about "view source"
or "show only this frame" (I've loved the quick access to that option :/ ).

This should block meta bug 135841. Thanks.
to marlon
Assignee: mpt → marlon
Blocks: 135481
Status: UNCONFIRMED → NEW
Ever confirmed: true
the frame related items are exceptional and are located in a flyout for
different reasons. please read the rationale given in, "a note about frames in
context menus":

http://mozilla.org/projects/ui/communicator/framework/contextmenus/digest.html
*** Bug 138291 has been marked as a duplicate of this bug. ***
Blocks: 135841
No longer blocks: 135481
Hmm.  I read marlon's rationale, and it keeps going on about these mythical
users who apparently don't care about the difference between frames and pages. 
I get the idea for "Bookmark", but not for other commands like "View Frame
Source", "View Frame Info" and "Reload" (which I use all the time).  When I
right click on a frame (ie a bunch of content) then it seems pretty obvious I
would want to use the Frame versions of these commands (even if didn't know it
was a frame).  

The other argument is that "most users" are not going to be using these commands
in a *context menu* anyway!  (They're in the main menus already)
*** Bug 148347 has been marked as a duplicate of this bug. ***
I only can support Martin Dougiamas!!! I have exactly the same problems with it.
Please see my remarks in Bug 148347 that was marked as dupe of this (sorry, did
not find this bug).

Robert
*** Bug 153058 has been marked as a duplicate of this bug. ***
I don't.

Here you are looking at this site: http://www.amoa.org/

You click the right mouse button.

Your first expectation is to see a menu for:

a. a web page or,
b. a frame?
As a technical person using the non-obvious, technical method (right-clicking),
I expect to see a context menu for what that example actually IS - a frame.  I
know what a frame is.  I develop web sites.  I right-click on web stuff all the
time to access hidden options, and get cheesed off at least once a day with this
particular bug (as do the people filing these duplicates).

A less technical person would use the existing obvious main menu items such as
"Bookmarks -> Bookmark this Page",  or "File -> Save Page as...".  If they
somehow were to right-click and discover frame options - hey, the real world is
educational!

In addition, Hogarth's example is quite unusual in that the frames aren't
immediately obvious - the vast majority of framed pages are much more obvious
than that.
If I right-click a page to bookmark it, I would certainly want the entire page
bookmarked, not just a single frame.
There are FOUR other methods to bookmark a page: *TWO* menus, drag and drop and
CTRL-D.  There are NO other methods to bookmark a frame other than the context menu.
The average user doesn't understand the concept of frames. If a user is used to
bookmark pages from the context menu, changing the behavior of a familiar menu
item to suddenly only bookmark part of the page would be *very* confusing.
Second time, that I have to totally agree with Martin Dougiamas! ;-) In 
addition to that, majority of users is used to that the right-mb-menu is relate 
to the frame-content, not the page-content (see e.g. IE, NS 4.x, ...).

For a certain page (waslos.de) I already prefer to use IE due to this "nice" 
menu. There is a small pager line you sometimes have to reload manually. With 
IE it is in done in a second. With Mozilla it is hell because e.g. a loose of 
the focus (be e.g. a messenger-popup-window) closes the menu immediately and I 
need a couple of seconds to handle the menu and find the reload-statement.

Well, the bookmark-problem is not really a problem, I'd say! ;-) Name 
it 'Bookmark this frame' and users that are able to read will see the 
difference. And if this is not enough, also add a line 'bookmark this page'. 
And at least then, they will start to think about... ;-)

People are not that stupid as you might think! And they will learn by their 
mistakes...
>Additional Comment #9 From Martin Dougiamas  2002-08-22 05:06 -------
>
>As a technical person using the non-obvious, technical method (right-clicking),
>I expect to see a context menu for what that example actually IS - a frame.  I
>know what a frame is

you're assumption about right-clicking as a technical method for technical
people, could not be further from the truth.  As we've seen in our own studies
as well as from outside reports, there has been a growing trend for beginners
and intermediates to rely on right-clicking more than anyone had ever expected.
 Which is why the context menu design we have now supports a more general use
set of features.  Making the distinction between frames and page is still not
something casual web surfers care, or know to do.

This may be the reason Microsoft guidelines have added in some cases the
'default action' to the topmost position of context menus: apparently many new
computer users were sometimes not aware of a difference between right clicking
and left clicking!

it's an eye-opening experience to know who you're designing for..
Well, maybe we should see this "problem" from a more logical point of view.

Considering the left-mouse-button, you expect that the closest operation to the 
position you are pointing ist performed. E.g. if you are over a link, you 
expect that the link is clicked. You do NOT expect, that e.g. the window is 
activated. Logical, isn't it?

And with the right-mb, for me it is exactly the same. I expect the menu-
content/context as close as to the object I am pointing to. And if I am not 
really over an object, I want to have the next object in hirarchy. If I am on a 
blank/text-part of page, this is the FRAME, NOT THE PAGE. The next object in 
hirarchy from the frame is the page - IMHO!

So it is a quiet unlogical and confusing thing to have a logical working left-
mb and an arbitrary right-mb-menu.

Even InternetExplorer uses a logical right-mb-menu. And people are used to 
think logical and will complain (as many do!!!) about such unlogical things. In 
addition to that, it slows me down in working with Mozilla.
Blocks: advocacybugs
Marlon, if you're going to call on Microsoft as a higher authority then you
should probably notice that right-clicking on a frame in IE brings up
frame-related options.
this issue is more-or-less the sole downside of my recent mozilla upgrade.

i can't count the times this bug has cost me extra time, **** me off, and at
times caused serious data loss (reloading the page rather than the frame).

now, i'm not claiming to be a usability expert, but i would like to think i'm a
reasonably typical mozilla user. 

(as an aside; in usability circles i think people underestimate users. i don't
think that these mythical ingenues whose views are often speculated about
actually exist. and in the end, second-guessing their thought processes is just
that - guesswork)
Component: User Interface Design → XP Apps: GUI Features
Product: Core → Mozilla Application Suite
Component: XP Apps: GUI Features → UI Design
MASS-CHANGE:
This bug report is registered in the SeaMonkey product, but has been without a comment since the inception of the SeaMonkey project. This means that it was logged against the old Mozilla suite and we cannot determine that it's still valid for the current SeaMonkey suite. Because of this, we are setting it to an UNCONFIRMED state.

If you can confirm that this report still applies to current SeaMonkey 2.x nightly builds, please set it back to the NEW state along with a comment on how you reproduced it on what Build ID, or if it's an enhancement request, why it's still worth implementing and in what way.
If you can confirm that the report doesn't apply to current SeaMonkey 2.x nightly builds, please set it to the appropriate RESOLVED state (WORKSFORME, INVALID, WONTFIX, or similar).
If no action happens within the next few months, we move this bug report to an EXPIRED state.

Query tag for this change: mass-UNCONFIRM-20090614
Status: NEW → UNCONFIRMED
Status: UNCONFIRMED → NEW
Ever confirmed: true

          You need to log in
          before you can comment on or make changes to this bug.