1206279 - Experiment with contextual overflow menu, remove disabled options

Status: RESOLVED INCOMPLETE

(Firefox for Android Graveyard :: General, defect)

Description

[Anthony Lam (:antlam) Find me, @antlam on Slack!]

I noticed we don't hide our disabled options inside our menu. If we did, this might help clean up the clutter that has since accumulated in our overflow menu. Apart from just visual clutter, less options would be less overwhelming and less likely to cause any form of decision paralysis.

For example, in about:home, we would be hiding "Find in page", "Page", and "Report site issue". 

This would also align us more with the new principles [1] of this overflow menu that Google and other newer apps adopt now.

Perhaps this is something we should consider as our menu continues to grow? 

Feature discover-ability is a valid possible draw-back, is there anything else?

[1] https://www.google.com/design/spec/components/menus.html#menus-behavior

Comment 1

[:Margaret Leibovic]

(In reply to Anthony Lam (:antlam) from comment #0)
> I noticed we don't hide our disabled options inside our menu. If we did,
> this might help clean up the clutter that has since accumulated in our
> overflow menu. Apart from just visual clutter, less options would be less
> overwhelming and less likely to cause any form of decision paralysis.
> 
> For example, in about:home, we would be hiding "Find in page", "Page", and
> "Report site issue". 
> 
> This would also align us more with the new principles [1] of this overflow
> menu that Google and other newer apps adopt now.
> 
> Perhaps this is something we should consider as our menu continues to grow? 
> 
> Feature discover-ability is a valid possible draw-back, is there anything
> else?
> 
> [1] https://www.google.com/design/spec/components/menus.html#menus-behavior

Can you help explain where you see this in this document? I see an item that says:

"Displaying actions as disabled, rather than removing them, lets the user know they exist under the right conditions."

https://www.google.com/design/spec/components/menus.html#menus-menu-items

I'm in favor of following the Google design guidelines as much as possible, but I also don't want to confuse users if they don't understand why the menu keeps changing.

Comment 2

[Anthony Lam (:antlam) Find me, @antlam on Slack!]

(In reply to :Margaret Leibovic from comment #1)
> Can you help explain where you see this in this document?

To reiterate, I'm not fully convinced of this either. But, this is one idea to help simplify the menus a bit.

So, fair points about confusion, I still think that's a valid point. But since the user will never really be able to "Page", "Find in page" or "Report site issue" in our about:home panel... and they're not really critical features (?) I could be swayed.

I guess what I took away from:

"Each menu item is a discrete option or action that can affect the app, the view, or selected elements within a view."

...was that items/options that can NOT affect the app, wouldn't be in there (at that point).

and

"Contextual menus dynamically change their available and enabled menu items based on the current state of the application. 

...was that our menu would be more "contextual" than static. E.g. google docs menus in https://www.google.com/design/spec/components/menus.html#menus-usage

> I see an item that
> says:
> 
> "Displaying actions as disabled, rather than removing them, lets the user
> know they exist under the right conditions."
>
> https://www.google.com/design/spec/components/menus.html#menus-menu-items

Although, "Displaying actions as disabled, rather than removing them, lets the user know they exist under the right conditions." still applies to this as we wouldn't be changing anything in our top portion of the menu (forward, back, refresh, add to RL, etc) as we look to have a more dynamic menu by placing those frequently used items along the top.

> I'm in favor of following the Google design guidelines as much as possible,
> but I also don't want to confuse users if they don't understand why the menu
> keeps changing.

Agree. We could also let this simmer for a bit until we develop stronger cases for this. We may learn a thing or two about this in the research we're doing around Settings.

Comment 3

[BMO Automation]

We have completed our launch of our new Firefox on Android. The development of the new versions use GitHub for issue tracking. If the bug report still reproduces in a current version of [Firefox on Android nightly](https://play.google.com/store/apps/details?id=org.mozilla.fenix) an issue can be reported at the [Fenix GitHub project](https://github.com/mozilla-mobile/fenix/). If you want to discuss your report please use [Mozilla's chat](https://wiki.mozilla.org/Matrix#Connect_to_Matrix) server https://chat.mozilla.org and join the [#fenix](https://chat.mozilla.org/#/room/#fenix:mozilla.org) channel.