Last Comment Bug 1373966 - Sub menu should behave like sub menu, otherwise it shouldn't imitate sub menu.
: Sub menu should behave like sub menu, otherwise it shouldn't imitate sub menu.
Status: REOPENED
: ux-consistency
Product: Firefox
Classification: Client Software
Component: Toolbars and Customization (show other bugs)
: unspecified
: Unspecified Unspecified
-- normal with 2 votes (vote)
: ---
Assigned To: Nobody; OK to take it and work on it
:
: :Gijs
Mentors:
Depends on:
Blocks:
  Show dependency treegraph
 
Reported: 2017-06-17 10:39 PDT by Tooru Fujisawa [:arai]
Modified: 2017-07-08 03:41 PDT (History)
7 users (show)
See Also:
Crash Signature:
(edit)
QA Whiteboard:
Iteration: ---
Points: ---
Has Regression Range: ---
Has STR: ---


Attachments
comparison between sub menus (108.45 KB, image/png)
2017-06-17 10:39 PDT, Tooru Fujisawa [:arai]
no flags Details

Description User image Tooru Fujisawa [:arai] 2017-06-17 10:39:07 PDT
Created attachment 8878803 [details]
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 User image :Gijs 2017-06-17 12:59:13 PDT
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 User image Tooru Fujisawa [:arai] 2017-06-17 13:01:48 PDT
(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 User image :Gijs 2017-06-17 13:12:43 PDT
(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 User image Aaron Benson 2017-06-19 14:16:30 PDT
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 User image Tooru Fujisawa [:arai] 2017-06-19 14:18:44 PDT
that doesn't answer the consistency issue...
Comment 6 User image Aaron Benson 2017-06-19 14:28:12 PDT
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 User image Tooru Fujisawa [:arai] 2017-06-19 14:32:40 PDT
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 User image Tooru Fujisawa [:arai] 2017-06-19 14:43:27 PDT
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 User image Aaron Benson 2017-06-19 14:49:30 PDT
Yes. All of the toolbar menus will behave as sliding menus.
Comment 10 User image Tooru Fujisawa [:arai] 2017-06-19 14:51:05 PDT
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 User image Aaron Benson 2017-06-19 14:53:43 PDT
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 User image Tooru Fujisawa [:arai] 2017-06-19 14:55:28 PDT
so, it means that the consistency within Firefox is not achievable if you go with sliding menu.
Comment 13 User image Aaron Benson 2017-06-19 15:01:54 PDT
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 User image Tooru Fujisawa [:arai] 2017-06-19 15:19:59 PDT
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 User image YUKI "Piro" Hiroshi 2017-06-19 18:18:04 PDT
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 User image Tooru Fujisawa [:arai] 2017-06-20 04:26:18 PDT
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 User image Tooru Fujisawa [:arai] 2017-06-20 04:27:32 PDT
> bug 1366074 comment #c5
I meant bug 1366074 comment #5
Comment 18 User image Tooru Fujisawa [:arai] 2017-07-08 03:41:51 PDT
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.

Note You need to log in before you can comment on or make changes to this bug.