Closed Bug 941436 Opened 7 years ago Closed 7 years ago

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

Categories

(Firefox :: Toolbars and Customization, defect)

defect
Not set
normal

Tracking

()

RESOLVED WONTFIX

People

(Reporter: yuki, Unassigned)

References

(Blocks 1 open bug)

Details

(Whiteboard: [Australis:P5])

Attachments

(1 file)

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.
Blocks: australis-cust
No longer blocks: australis-merge
Whiteboard: [Australis:P5]
Attached image WindowsPhone homescreen
At Windows Phone homescreen, it provides the arrow indicator icon which inform the expand area to user. (See screenshot right-bottom)
Attachment #8344343 - Attachment description: ss.png → WindowsPhone homescreen
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.
Status: NEW → RESOLVED
Closed: 7 years ago
Resolution: --- → WONTFIX
Duplicate of this bug: 971857
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.
You need to log in before you can comment on or make changes to this bug.