Context menu on Mac OS X

[Dominic Mazzoni]

If you don't care about Mac-specific UI design issues, you can ignore this message.

When you right-click in a Chrome tab on any platform, you get a context menu. While some of the items in this menu are redundant, many can only be accessed via this menu, including options that have been added by an extension. This presents a couple of problems on Mac OS X that aren't an issue on other platforms:

* Apple's interface guidelines strongly discourages including anything in a context menu that can't be accessed some other way. Mac users never expect to find something in a context menu that isn't available somewhere more discoverable as well.

* It's a minor accessibility problem, as there's no way to pop up the context menu at the current keyboard-focused location. On Windows and Linux, you can press the context menu key on your keyboard, or Shift+F10, to do this.

To help with the accessibility problem, we could add support for a Mac keyboard shortcut that's the equivalent of Shift+F10. Do you think many would use it?

As a potentially better solution, why not dynamically add items that would normally go in the context menu to the top menu bar? Mac is the only platform that has a complete top menu bar, and compared to the Wrench menu it's not very crowded. As an extremely simple straw-man proposal, we could just add a "Context" item to the Edit menu with a submenu containing all of the context menu items that aren't easily found somewhere else. This would solve both the discoverability problem and the accessibility problem.

- Dominic

[Mike Pinkerton]

Can you give a concrete example of what might go in this menu?

> --
> Chromium Developers mailing list: chromi...@chromium.org
> View archives, change email options, or unsubscribe:
> http://groups.google.com/a/chromium.org/group/chromium-dev

--
Mike Pinkerton
Mac Weenie
pink...@google.com

[Nico Weber]

Instead of adding UI, could we try removing UI instead? The menu items
not accessible otherwise are: Duplicate, Pin Tab, Close Other Tabs,
Close Tabs to the Right. For the ones that are being used according to
metrics (probably "Pin Tab"), we could try to find "real" places them
to the normal menu. The others (probably the rest), we could remove
from the context menu as well.

Nico

[Dominic Mazzoni]

On Mon, Mar 12, 2012 at 4:42 AM, Mike Pinkerton <pink...@chromium.org> wrote:

Can you give a concrete example of what might go in this menu?

1. Any context menu items added by an extension, for example I have an extension installed that lets me select text and then "Blog Selected Text".

2. When in a text area: spelling suggestions, and the Writing Direction submenu. I couldn't figure out how to get to Writing Direction any other way.

3. Inpsect Element, View Frame Source and View Frame Info - would apply to the element or frame containing cursor focus, though this sounds much less useful than the first two.

- Dominic

[Sam Kerner]

On Mon, Mar 12, 2012 at 4:10 AM, Dominic Mazzoni <dmaz...@chromium.org> wrote:
> As a potentially better solution, why not dynamically add items that would
> normally go in the context menu to the top menu bar? Mac is the only
> platform that has a complete top menu bar, and compared to the Wrench menu
> it's not very crowded. As an extremely simple straw-man proposal, we could
> just add a "Context" item to the Edit menu with a submenu containing all of
> the context menu items that aren't easily found somewhere else. This would
> solve both the discoverability problem and the accessibility problem.

The context menu's contents depend on what was clicked. For
extensions, he type of item being clicked on the page (image, link,
form, etc) is passed to the extension. If we put the context menu
items in the menu bar, how do we know what element on the page the
user intended to act on?

Sam

[Dominic Mazzoni]

4. When focused on a link: Open Link in New Tab, Open Link in New Window, Save Link As... - these can all be activated by the keyboard alone on Windows and Linux, but not on Mac.

[Dominic Mazzoni]

On Mon, Mar 12, 2012 at 9:46 AM, Sam Kerner <ske...@google.com> wrote:

The context menu's contents depend on what was clicked.  For

extensions, he type of item being clicked on the page (image, link,
form, etc) is passed to the extension.  If we put the context menu
items in the menu bar, how do we know what element on the page the
user intended to act on?

Same as on Windows or Linux, it's whatever's selected or has keyboard focus at the time when you open the menu. Try it now on Windows or Linux - open an editable text area, move the cursor to a misspelled word and press Shift+F10.

- Dominic

[Evan Martin]

(At least on my Linux machine, shift-f10 didn't work but the "menu"
button to the right of my spacebar did.)

[Chris Palmer]

On Mon, Mar 12, 2012 at 8:10 AM, Nico Weber <tha...@chromium.org> wrote:

> Instead of adding UI, could we try removing UI instead? The menu items
> not accessible otherwise are: Duplicate, Pin Tab, Close Other Tabs,
> Close Tabs to the Right. For the ones that are being used according to
> metrics (probably "Pin Tab"), we could try to find "real" places them
> to the normal menu. The others (probably the rest), we could remove
> from the context menu as well.

On Linux, Reopen Closed Tab (Ctrl-Shift-T) is not available anywhere
else. I only heard of it at random on some web forum; it is not
discoverable.

I agree with Nico that we should try removing UI. I'd try getting rid
of the context menu on tabs, and move Reopen Closed Tab to the Wrench
menu (and its appropriate place in the Mac menubar, whatever that is.
File, perhaps? Should be right near New Tab and New Window, as in the
Wrench menu.).

I am strongly against the Easter Egg School of UX Design. The tab
context menu feels too much like an easter egg, especially since you
can't get what it has any other way. It would be less of an easter egg
if it merely duplicated functionality found elsewhere. The title
bar/tab bar context menu is somewhat less easter eggy in that way
(given that e.g. Task Manager is available in Wrench -> Tools).

[Dominic Mazzoni]

On Mon, Mar 12, 2012 at 10:44 AM, Chris Palmer <pal...@google.com> wrote:

I agree with Nico that we should try removing UI. I'd try getting rid

of the context menu on tabs,

I was apparently unclear in my original email - I was actually talking about the context menu inside each tab contents (i.e. in the web contents), not for the tab strip itself.

But FWIW, I also agree that commands that are currently only found by right-clicking in the tab strip should be discoverable some other way, *especially* on Mac OS X where hiding things in context menus goes so strongly against the native platform guidelines.

- Dominic