1373966 - Sub menu should behave like sub menu, otherwise it shouldn't imitate sub menu.

Status: REOPENED

(Firefox :: Toolbars and Customization, defect, P5)

Description

[Tooru Fujisawa [:arai]]

Attachment: comparison between sub menus

Steps to reproduce:
  1. open Nightly 56.0a1 (2017-06-17) (64-bit) on OSX
  2. click hamburger button
  3. hover on "Web Developer >" menu item
  4. click "Web Developer"
  5. click "Tools" in the menu at the top of the screen
  6. hover on "Web Developer >" menu item

Actual result:
  3. nothing happens
  4. the content slides to sub menu and the original menu disappears

  6. sub menu opens next to the menu item

Expected result:
  those 2 menu items should behave in the same way
  it's not intuitive to have 2 similar things on the screen that behave differently.
  the behavior at the step 6 is how sub menu behaves, that should be consistent across applications on the same OS

  so, at the step 3, sub menu should open next to the menu

Comment 1

[:Gijs (he/him)]

We won't do this (see also bug 1366074). This is also not really a change from before - we have had these sliding subviews in the main hamburger panel for a while, as well as in the downloads panel and identity popup.

Comment 2

[Tooru Fujisawa [:arai]]

(In reply to :Gijs from comment #1)
> We won't do this (see also bug 1366074). This is also not really a change
> from before - we have had these sliding subviews in the main hamburger panel
> for a while, as well as in the downloads panel and identity popup.

but now the panel looks like a menu, that is different from before.

previously the panel looks totally different from a standard menu, so different behavior doesn't matter,
but now the panel looks almost like a standard menu.
if we imitate a menu, we shouldn't do different thing.

Comment 3

[:Gijs (he/him)]

(In reply to Tooru Fujisawa [:arai] from comment #2)
> (In reply to :Gijs from comment #1)
> > We won't do this (see also bug 1366074). This is also not really a change
> > from before - we have had these sliding subviews in the main hamburger panel
> > for a while, as well as in the downloads panel and identity popup.
> 
> but now the panel looks like a menu, that is different from before.
> 
> previously the panel looks totally different from a standard menu, so
> different behavior doesn't matter,
> but now the panel looks almost like a standard menu.
> if we imitate a menu, we shouldn't do different thing.

So, schedule-wise, this is going to be almost impossible to implement for 57 at this point. It would require rewiring everything. I'm also not sure how easy menus with custom styling (e.g. for the zoom/edit controls). But maybe Bryan or Aaron can explain the thinking here for posterity, and/or make a decision about whether we want to do this long-term.

Comment 4

[Aaron Benson]

The submenus work as designed to allow for greater depth of navigation. The flyout menu approach becomes difficult to manage once you get more than 2 layers deep in a hierarchy.

Comment 5

[Tooru Fujisawa [:arai]]

that doesn't answer the consistency issue...

Comment 6

[Aaron Benson]

The menus aren't consistent with macOS but they don't necessarily have to be. It's more important that the menus within Firefox are consistent with each other, which is why we've adopted this approach.

Comment 7

[Tooru Fujisawa [:arai]]

if the UIs are not consistent across applications, how users can operate on it without failing several times?

also, 2 menus in https://bug1373966.bmoattachments.org/attachment.cgi?id=8878803 are both Firefox's, so currently it's not consistent even within Firefox.

Comment 8

[Tooru Fujisawa [:arai]]

also, there are so many places that uses standard sub menu (flyout one) all around Firefox UI, like bookmark toolbar, context menu, etc.
is there any plan to replace all of them with the sliding style?

Comment 9

[Aaron Benson]

Yes. All of the toolbar menus will behave as sliding menus.

Comment 10

[Tooru Fujisawa [:arai]]

only toolbar menus?

how about context menu or the menu at the top of the screen, or menu at somewhere else than toolbar?

Comment 11

[Aaron Benson]

The context menus and the one at the top of the screen (Menu Bar) are driven by the operating system and can't be modified.

Comment 12

[Tooru Fujisawa [:arai]]

so, it means that the consistency within Firefox is not achievable if you go with sliding menu.

Comment 13

[Aaron Benson]

Yeah, solid point. I shouldn't have phrased it that way. What I meant was the menus in the toolbar are designed with the sliding menu.

Comment 14

[Tooru Fujisawa [:arai]]

okay, so the reasoning behind using sliding menu is only to manage deeply layered hierarchy easily, right?
if flyout submenu cannot be used for that reason (I'm not yet sure why it needs to be only single pane at once tho), I'd suggest to stop imitating the standard menu styling (especially ">" mark) and make it clear it's different UI component that needs different operation.

Comment 15

[YUKI "Piro" Hiroshi]

I'm one of people who is confused from this styling.

(In reply to Tooru Fujisawa [:arai] from comment #14)
> if flyout submenu cannot be used for that reason (I'm not yet sure why it
> needs to be only single pane at once tho), I'd suggest to stop imitating the
> standard menu styling (especially ">" mark) and make it clear it's different
> UI component that needs different operation.

I also think so. Actually I'm living with Firefox, but I'm also living with other applications - Adobe Illustrator, LibreOffice, and others. When I switch my task between these applications, current (sliding with submenu-like appearance) design confuses me every time.

Comment 16

[Tooru Fujisawa [:arai]]

also, I think the following points should also be reconsidered:
  1. are there so many deeply layered sub menus?
     (IMO, 2 or 3 layered sub menus with flyout style won't become a trouble)
  2. is it worth addressing operability about deeply layered sub menus even with introducing difficulty for single or a few layered sub menus?
     (with current way, user needs to click, that doesn't match to OS and other places inside Firefox, and also just requiring extra click is also bad)
  3. why are we showing only one pane at a time? (bug 1366074 comment #c5 points out that that's the source of the issue there)


then, to be clear, what I propose here is doing either:
  A. use flyout submenu that opens by hovering (that matches to standard menu)
  B. make it distinct from standard menu, and make it look like a button or something that deserves a click to activate

A is the best way, and B is alternative way that may require less change.

Comment 17

[Tooru Fujisawa [:arai]]

> bug 1366074 comment #c5
I meant bug 1366074 comment #5

Comment 18

[Tooru Fujisawa [:arai]]

this bug should be kept opened, even if it cannot be fixed before firefox 57.
there's no good reasoning about inconsistency inside application and across applications.

Comment 19

[Bill his name]

https://bugzilla.mozilla.org/show_bug.cgi?id=1402384