Closed Bug 136665 Opened 18 years ago Closed 18 years ago
[RFE] make pref
. for page-navigation options on all context menus .
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.
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
Confirming. This is needed. The default should be off/disabled.
qa --> firstname.lastname@example.org
QA Contact: paw → sairuh
Totally agree. Adding preferences for these page navigation context menu items is the best option. So everybody can be happy.
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?
Yes, I suppose I do. Got a good suggestion for a better yet still succinct Summary?
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.
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!
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*.
In comment 7, he said this would be "unfair." How could it be both unfair and trivial?
I think he's saying that it's unfair to have a bunch of trivial options. That's fair. :)
Well, if the change is really trivial, then it wouldn't be "unfair" or "incredibly bad."
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.
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. ;-)
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
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 email@example.com. 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
Closed: 18 years ago
Resolution: --- → WONTFIX
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.
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.
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
You need to log in before you can comment on or make changes to this bug.