Closed Bug 1366074 Opened 7 years ago Closed 7 years ago

Make it so menu sub-panels open via hover.

Categories

(Firefox :: Toolbars and Customization, defect)

defect
Not set
normal

Tracking

()

RESOLVED WONTFIX

People

(Reporter: bbell, Unassigned)

References

(Blocks 1 open bug)

Details

Attachments

(1 file)

491.13 KB, video/quicktime
Details
Users expect menu items with a ">" character on the right to open on click and or hover, as the often do on Mac and Windows File Menus. Some users are expecting this same behavior in our new menus, and because it's not there, they are reacting to it poorly. 

Augment the current click to open with and open on hover. 

Opening-on-hover needs to have a slight delay of a 1/2 of a second.

https://mozilla.invisionapp.com/share/24BS7S8ZH#/229252106_Menus
Whiteboard: [photon-structure]
While in the "delay" before opening the sub-panel, The hover state should blink twice before opening.
Summary: Make it so menu sub-panels to open via hover. → Make it so menu sub-panels open via hover.
Flags: qe-verify?
Priority: -- → P2
Do you mean that hovering would cause the current panel to be replaced with the sub-panel?

If so, it sounds like we'd be replacing one unfamiliar behavior with another.
This would mean that people would get into the sub-menu without clicking, but would need to move the mouse and click the back button in order to get back to the main panel. Compare that to the native behavior, where hovering is non-destructive since it doesn't replace the current panel.
Flags: needinfo?(bbell)
Attached video Hover to open.mov
I'm proposing the same rules and visual indication that users get while dragging and dropping. 

Example Video: https://cl.ly/442Z0q3M401p

This affordance would satiate any user that assumes this menu works like traditional "File Menus" with their auto opening flyout panels.
Flags: needinfo?(bbell)
(In reply to bbell from comment #0)
> Users expect menu items with a ">" character on the right to open on click
> and or hover, as the often do on Mac and Windows File Menus. Some users are
> expecting this same behavior in our new menus, and because it's not there,
> they are reacting to it poorly. 
Folders open on hover only if you are dragging something into them because it's not 'possible' to click. Opening a sub menu and dragging and dropping an item into a folder are two different actions and such difference is highlighted in their interaction. 

> Some users are expecting this same behavior in our new menus
Is it possible to drag items into our new menu? If yes, opening a sub item while hovering should be possible but only if the user is dragging something into it. Otherwise the two actions should maintain their different behavior. Offering the same interaction for different actions (opening a sub menu and dragging something into a sub menu) leads to different users expectations.

> This affordance would satiate any user that assumes this menu works like traditional "File Menus" with their auto opening flyout panels.
I wasn't able to open a sub menu only while hovering on macOS. Do you have a specific example?
Flags: needinfo?(bbell)
(In reply to Amin Al Hazwani [:amin] (Firefox UX) from comment #4)

> I wasn't able to open a sub menu only while hovering on macOS. Do you have a
> specific example?

All Mac Sub menus open on a hover Example: https://cl.ly/0x0M3y3k3T13

We just can't do the same because if we did people would lose their place since we can only show one thing at a time.

The proposal to open sub-menus on a delayed hover is only designed to help people who have an ingrained sense that hovering over menu items would reveal their content.
Flags: needinfo?(bbell)
I talked with Stephen last week and he had some ideas on how we could fix this with some lightweight icon changes.

Even if the slide action is delayed, it still creates the issue of changing state through a non-deliberate action. In other words, it creates a minefield of places where you can and cannot linger with the mouse pointer. As Bryan mentions, sub menus also trigger on hover, but they a) don't replace the current content and b) are also closed automatically when moving the mouse further.

Let's close this issue and see if we can come up with something more lightweight to address the original concern.
Status: NEW → RESOLVED
Closed: 7 years ago
Resolution: --- → WONTFIX
Flags: qe-verify?
Priority: P2 → --
Whiteboard: [photon-structure]
You need to log in before you can comment on or make changes to this bug.

Attachment

General

Creator:
Created:
Updated:
Size: