View source for Talk:Menu cleanup

[https://bugzilla.mozilla.org/show_bug.cgi?id=322736 Bug 322736] (Reorder menus and options to promote tabs more) should be taken into account when planning this for Firefox 4.

-- Frank, 2010.03.17

The Page menu is missing 'View page source code', and 'View page info' or maybe 'Page media'. That's kind-of a big deal to me.

Slightly off topic, it would be swell for the functionality of the 'Media' tab in 'Page info' to be more prominent and support downloading streaming flash media like DownloadHelper for example.

--[[User:Daghead|Daghead]] 01:33, 15 January 2010 (UTC)

regarding the location of "character encoding": please consider the importance of quick encoding switching for international users, as discussed in Bug 70830 and Bug 240301. the major use case in my experience being webmail. 

-- eyal gruss 2009-09-18

Per the "already in the UI" argument, we could remove Cut, Copy, and Paste from the Edit menu and the new Page menu, since they're available from the context menu. We should display the keyboard shortcuts in the context menu though.

-- Steffen 2009-09-15

Yes, but not everyone uses the context menu, so Cut/Copy/Paste is something we can't really kill off. I guess it would be more correct to say "kill off anything that is in the UI and not hidden in a context menu". For the other examples, there are dedicated buttons to do those operations in the UI already, which is why we want to remove them.

— Alex Limi, 2009-09-15

: Alex: I am not as sure that so few people use the context menu. Jensen Harris found [http://blogs.msdn.com/jensenh/archive/2005/09/16/468365.aspx the reverse to be true]: that even novices nowadays use it. Perhaps a user study should be dedicated to this question. If contextual menus are, in fact, commonly used, it would have powerful ramifications for the re-design. Instead of cramming contextual actions into the Page menu, they could be left in the contextual menus—and only there. The result would be a big Hick’s Law win: the Page menu now has fewer items to choose from, and each action can now be found in one and only one location.
: This would also allow a cleaner and more logical separation between menus (as I have [[Talk:Firefox/4.0_Windows_Theme_Mockups#Menus_.C3.97_3|previously described]]): the Application menu (whatever it’s called) shows items contextual to the whole Application, the Page menu shows items contextual to the page as a whole, and the context menu shows items contextual to objects under the pointer (selections, images, links, toolbar buttons, etc.).
: —[[User:David Regev|David Regev]] 06:51, 16 September 2009 (UTC)

I know about the Jensen Harris study (and I quote from it all the time too ;), but it doesn't mean that everyone uses the context menu, just that it's the first thing people try on the Windows platform when they don't know what to do, since a lot of the UI design there encourages that behavior.

Think about naïve Mac users — their computers have had one button since the very beginning, and still does — even though they support right-clicking with their new mice and trackpads, it's not the default.

If we're going to make it only appear on the context menu, it would probably only be that way on Windows. I definitely think it's worth considering, but it's also a very risky thing to remove, since it's so commonly used. 

The same talk from Jensen Harris also explains why the paste button is so big in Office — it's the most used function by orders of magnitude. :)

— Alex Limi, 2009-09-15

: Alex, that’s a ''great'' talk. I think the biggest problem with right-clicking in general is that you never know where anything goes. There is too much duplication of functionality, and too little logical separation between where anything ''should'' go. And it doesn’t help that the right mouse button isn’t labelled. So, for example, Firefox’s menu for any empty area in the page shows things like Back and Forward and several other items that apply to the page as a whole. It also contains much of the Edit menu but not all of it. This, naturally, leads to a lot of hunting through menus and never having a good idea of where to guess. If a logical separation were strictly enforced, finding the right command would not be as difficult. I think this would be worth exploring solely for the comfort of having real organization. As for Mac users, as you point out, relying on right-click is not a good idea. It would be nice if there were a way to enforce this order there too; perhaps a ‘Selection’ menu could be added in the menu bar.
: —[[User:David Regev|David Regev]] 07:37, 16 September 2009 (UTC)

Items on the context menu cannot displace the existence of menu items on a menubar because malicious or otherwise ill-behaved websites can disrupt or break the right-click context menu process, such as with alert() on right-click.

The trend away from menubars is somewhat disturbing. I for one don't use Chrome in part because it has very little functionality, and what little of it there is is hard to access owing to lack of a menubar. The trend away from menubars is a triumph of style over functionality, and I believe the fad will fade over time. A quick Google of "office 2007 menus" indicates that the predominant sentiment is <b>not</b> positive, on the contrary, the overwhelming reaction is antipathy. I do not think FF should make the same mistake as Vista / Win7 / Office 2007.

[[User:Barrkel|Barrkel]] 15:02, 23 September 2009 (UTC)

: First, most keyboards have a Menu button. Second, the ability of sites to block right-clicking is a bug that needs to be dealt with somehow. (Aside: Regarding the Office 2007 ribbon, I would recommend you watch [http://blogs.msdn.com/jensenh/archive/2008/03/12/the-story-of-the-ribbon.aspx the talk] to which Alex alluded earlier.) —[[User:David Regev|David Regev]] 16:19, 23 September 2009 (UTC)

I think you should provide the copy-paste-toolset only in the context menu, 'cause duplicate content is bad, always. Never have I seen someone using the Edit-menu to copy something. Most people use Ctrl-C and the rest does use the context menu. The only problem is, as mentioned above, that the context menu may be hidden using JS (and HTML 5 provides the possibility even in markup: [http://www.whatwg.org/specs/web-apps/current-work/multipage/interactive-elements.html#context-menus context-menus]). Solving this problem will be quite complicated: Blocking oncontextmenu fully, as some browsers do, isn't standarts-conformant (bad...). The HTML5 context menu can easily be included in the browsers context menu as described in the spec, but I dunno what to do with the oncontextmenu-Event. Maybe you should provide a message, that the website wants to replace the context menu using the new [http://people.mozilla.com/~faaborg/files/20090821-notification/newNotification-i1.png ideas for notifications]. If the user accepts it the page can manipulate the context menu, but the user still has access to it using the Page-button. (Submenu: "Context-menu" or something like that)

[[User:Nikic|Nikic]] 19:16, 26 October 2009 (UTC)