Closed Bug 1206279 Opened 9 years ago Closed 4 years ago

Experiment with contextual overflow menu, remove disabled options

Categories

(Firefox for Android Graveyard :: General, defect)

All
Android
defect
Not set
normal

Tracking

(Not tracked)

RESOLVED INCOMPLETE

People

(Reporter: antlam, Unassigned)

References

Details

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
(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.
(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.
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.
Status: NEW → RESOLVED
Closed: 4 years ago
Resolution: --- → INCOMPLETE
Product: Firefox for Android → Firefox for Android Graveyard
You need to log in before you can comment on or make changes to this bug.