941436 - Hard to detect which button has its own submenu in the menu panel on Australis

Status: RESOLVED WONTFIX

(Firefox :: Toolbars and Customization, defect)

Description

[YUKI "Piro" Hiroshi]

Actual:
Currently there are two type buttons in the menu panel: widget-type="button" and widget-type="view" (including the "Help" item), however they are shown with just same appearance. There is no visual feedback for buttons which have its own submenu. It is painful for users to distinguish them. (Actually, on the first time I couldn't find out the way to go to "About" screen from the menu panel. It exists in the submenu of the "Help" item.)

Expected:
Buttons with its submenu should have different style (for example, ">>" mark and so on.)

This can be related to the bug 940307.

Comment 1

[Tetsuharu OHZEKI [:tetsuharu] (UTC+9)]

Attachment: WindowsPhone homescreen

At Windows Phone homescreen, it provides the arrow indicator icon which inform the expand area to user. (See screenshot right-bottom)

Comment 2

[Jared Wein [:jaws] (please needinfo? me)]

UI-on-hover is generally a bad idea, so showing a chevron when the user hovers a button probably isn't what we want here, but my other ideas don't seem much better.

Some ideas:
- UI-on-hover chevron that is shown on the right side of the button ">" to show that this will open a panel.
- A badge in one of the corners of the button with a subview icon
- A glow on the end of the button when hovered

Alternatively, should there be some visual notice when a button *doesn't* open a subview? Really, buttons can have an unbounded amount of outcomes, so labeling only one of them seems like the wrong idea.

It's probably best to just close this bug out, as fixing it won't solve a particular problem that users are facing.

Comment 4

[(Currently slow to respond) Philipp Sackl [:phlsa] (Firefox UX) please use needinfo]

The question here is: What do we need to indicate?
In classic menus, the ellipses indicates items that do not lead to direct action, but require some further interaction (though we are not really consistent about it because e.g. Find has no ellipses but it does require more input).
This means that we'd have to have indicators on all items that:
- Open a subview
- Lead to a dialog box
- Show additional UI before leading to results (e.g. Find)

I think it makes sense to only have one kind of indicator that is universal for all those cases. While I can't come up with a good one from the top of my head, I'll keep an eye on this issue.