[RFE] make pref. for page-navigation options on all context menus.

VERIFIED WONTFIX

Status

SeaMonkey
UI Design
--
enhancement
VERIFIED WONTFIX
16 years ago
9 years ago

People

(Reporter: Matthew Miller, Assigned: Blake Ross)

Tracking

Firefox Tracking Flags

(Not tracked)

Details

(Reporter)

Description

16 years ago
Recently, the right-click (context) menus have been streamlined, in many cases
removing options that a lot of us found very useful. Particularly, the "Back"
and "Forward" options (as well as other page-navigation choices "Reload" and
"Stop") were taken out.

This bug asks for a pref. which, when enabled, makes "Back", "Forward",
"Reload", and "Stop" -- or at least just "Back and "Forward" -- appear at the
top of *all* right-click menus, regardless of which particular item happened to
be clicked on.

Further discussion can be found in bug #135331, but in summary: Some people say
the navigation options are always "in context" for all sub-items on a page, so
they should always be there, particularly because they're so very useful. (Note:
pages with lots of images, transparent spacer-gifs, muscle memory, etc.) Others
say that this makes the menu too long, and that context menus should always be
limited to only the tightest possible set of applicable contexts. 

Making this an option may seem like bloat, but this is a UI preference upon
which reasonable people can and obviously do disagree. Giving a choice is
clearly the best thing to do.
(Reporter)

Comment 1

16 years ago
Currently, this bug is an enhancement for those of us who miss the Back option.

Of course, if bug #135331 is actually reopened and resolved, this switches and
becomes an enhancement for those who want shorter context menus. Either way. :)
Depends on: 135331
(Reporter)

Updated

16 years ago
No longer depends on: 135331
(Reporter)

Updated

16 years ago
Blocks: 135841

Comment 2

16 years ago
Confirming. This is needed. The default should be off/disabled.
No longer blocks: 135841
Status: UNCONFIRMED → NEW
Ever confirmed: true
Keywords: mozilla1.0.1

Comment 3

16 years ago
qa --> sairuh@netscape.com
QA Contact: paw → sairuh

Comment 4

16 years ago
Totally agree. Adding preferences for these page navigation context menu items
is the best option. So everybody can be happy.

Comment 5

16 years ago
All right click menus?  even the ones in the sidebar, PT and URL bar? how bout
mail?  Yes, I'm being silly, but anyways I assume you mean everywhere inside the
page view?
(Reporter)

Comment 6

16 years ago
Yes, I suppose I do. Got a good suggestion for a better yet still succinct Summary?

Comment 7

16 years ago
No matter how annoying Mozilla's shortcut menus are, a pref like this one would 
be an incredibly bad idea. It is completely unfair to shove Mozilla's design 
troubles onto the user like this.
(Reporter)

Comment 8

16 years ago
As a user, I feel more like the design troubles are being shoved on me when good
UI features suddenly vanish, allegedly in the name of making the UI better.
Giving people the option to have things the way they want doesn't feel like
shoving -- it feels like I'm given back power and choices. That's a good thing!
(Reporter)

Comment 9

16 years ago
Whoo, I've been tagged as "trivial" in mpt's weblog (http://mpt.phrasewise.com/). 

In seriousness, there are a lot of good points there which I respect. My
strongest preference is for bug #135331 to be fixed -- Back/Forward restored
always. That would solve the complaint about too many confusing "trivial" options. 

But failing that, this preference is *non*-trivial, because having these options
makes the interface *significantly* better. (ref: making the product better than
Apple's or Microsoft's.) Unlike point #9, the new design takes away significant
efficiency -- it's not a case of people who have become accustomed to a bad old
design, but rather people who are accustomed to a *really good thing*.

Comment 10

16 years ago
In comment 7, he said this would be "unfair." How could it be both unfair and
trivial? 

(Reporter)

Comment 11

16 years ago
I think he's saying that it's unfair to have a bunch of trivial options. That's
fair. :)

Comment 12

16 years ago
Well, if the change is really trivial, then it wouldn't be "unfair" or
"incredibly bad." 

Comment 13

16 years ago
MPT: It isn't "unfair" to enable an option to turn a missed feature on in an
Advanced panel somewhere in the prefs. Any option we kill in Mozilla should be
an option somewhere in an "Advanced" button somewhere. Normal users won't go to
"Advanced" at all, and so adding options to "Advanced", IMHO, does not create
any chaos at all w/ normal users.

Comment 14

16 years ago
You have many choices.  If you want to get commands for an image, right click on
an image.  If you want commands for navigation, right click elsewhere. Limiting
the number of items makes each item much easier to choose. Basing the command
choices on the context is also quite powerful, in that the choices can be
extended cleanly for any context.  Having each context bear the weight of all
possible commands for its container hierarchy would yield context menus that
increase power at the expense of convenience, their primary reason for being. I
suspect the ultimate power-user context menu would just popup a command line,
and let you enter whatever code had not yet been added, if anything is still
missing. ;-)
(Reporter)

Comment 15

16 years ago
Peter -- as has been rehashed plenty in bug #135331, there are several serious
issues with that. The primary one is that it's not always apparent whether what
you're clicking on is an image or not -- much of the web consists of images of
text (ugh), and there's clear spacer images everywhere.

Conceptually, an image is *no different* from any other page element in terms of
whether navigation options should apply or not. Why is text any more part of a
page than an image? Once this bug and #135331 have been worked out, the
navigation options should be removed from the right-click menus for text -- an
inconsist UI is the worst of all. (I hope we can all agree on that, at least.)
IMHO, a pref like this is stupid.

Maybe this is one of those features which should result in a different browser
for different users, as described by hyatt in 
   http://mozillian.blogspot.com/2002_04_07_mozillian_archive.html#75279564

(Reporter)

Comment 17

16 years ago
Calling this stupid, humble opinion or no, is not constructive.

Hyatt's call for many different browsers is an interesting idea, but
realistically, I don't think it'll work out that way. Diversity is good and all,
but on the other hand there is a strength in shared culture. If I visit my
family or a friend's house, I don't want to have to install a whole new web
browser to surf comfortably -- and, if a friend asks for a browser
recommendation, I want to be able to say "use Mozilla -- it rocks" (which I do
and will continue to do unless _all_ of the nice UI is eventually backed out.
*grin*). 

And of course, it's nice to avoid duplicating work.

Although Mozilla is nominally targetted at developers, it's going to be 
extremely popular with end users. It's already one of the dominant web browsers
on Linux (where I do most of my work). I really like the mainstream Mozilla as
an end-user myself, and don't want to have to run off to something else just
because one aspect of the UI got broken. 

I think fixing bug #135331 would make for the best all-around user interface for
everyone, but since that apparently isn't going to happen, this + bug #137655
seems like an acceptable compromise. 
Based on comments from mpt in this bug, marlon's comments in bug 135331, and
blake's comments on IRC, RESOLVED WONTFIX. If you wish to push for this change
despite the wishes of the two most prominent UI designers working on Mozilla as
well as the implementor of the menu code, please contact drivers@mozilla.org.

If the UI of this Mozilla web browser is not satisfactory for all users, we
should not be surprised -- but we shouldn't simply add more prefs to make the
browser one-size-fits-all. The users who wish to add these features to the
Mozilla browser are encouraged to make their own Mozilla-based browser with a
different target audience.
Status: NEW → RESOLVED
Last Resolved: 16 years ago
Resolution: --- → WONTFIX

Comment 19

16 years ago
Having now read mpt's top ten usability problems in Mozilla along with the
comments on Dave Hyatt's blog, I will concur that a user pref for this would be
counter-ideal, and Mozilla would be better off without it.
(Reporter)

Comment 20

16 years ago
I'm not going to argue about this anymore. I wasn't being a pain just for the
sake of it, and I'm willing to let it drop. If there's no chance of it being
changed, so be it.
(Reporter)

Comment 21

16 years ago
Ok, Havoc Pennington's musings on this have convinced me that I'm wrong and 
that there shouldn't be a UI preference.

(see http://www106.pair.com/rhp/free-software-ui.html)

Therefore, I'll remove my vote for this and go back to asking that the problem 
be fixed.
mass-verifying Wontfix bugs.

mail filter string for bugspam: Tursiopstruncatus
Status: RESOLVED → VERIFIED
Product: Core → Mozilla Application Suite

Updated

9 years ago
Component: XP Apps: GUI Features → UI Design
You need to log in before you can comment on or make changes to this bug.