1565057 - Bring back some features hidden behind meatball menu for commonly used tasks

Status: RESOLVED DUPLICATE of bug 1570792

(Toolkit :: Add-ons Manager, defect)

Description

[Asif Youssuff]

Attachment: Screenshot from 2019-07-10 17-34-31.png

The changes in Bug 1525193 represent a usability regression for users who want to easily access the enable/disable and settings options for extensions.

Feedback on reddit has not been positive: https://www.reddit.com/r/firefox/comments/cbgvdd/extremely_poor_addons_manager_ui_design_in_68/ and the new add-on page is now less usable than the one in Chromium (screenshot attached).

I have seen in other bugs that there is a revamp of the add-ons UI coming, but the direction this seems to be going in today seems to be a step backward, and feels more like form over function, or like a mobile UI where there is no progressive enhancement for people with larger screens.

This isn't even all that touch friendly -- the menus are harder to tap than the previous buttons, and kebabs don't even look like menus at first glance.

Chromium, for example, allows for removal and enabling/disabling without needing a kebab menu.

Even if the add-on details view that appears had disable/enable/remove buttons, that would be a marked improvement over the current UI - why does it need to be hidden behind a kebab menu?

As it is, if a user is trying to test whether some add-ons are causing issues with the browser -- and they know it is likely an add-on because safe mode works -- they must click, then use a menu and click again for each add-on that they want to disable.

Previously, they could simply click once in a disable button that didn't require navigating a menu (not the easiest thing to do if a user has motor control issues, for example).

Has this been tested on users of varying levels of experience? What kind of use cases were tested? It'd be interesting to know whether users who were given a task to disable 4 add-ons preferred the new approach over the old.

Look at the reddit commentary and please reconsider, or provide users with some assurance that the new revamp will take these issues into consideration.

Comment 1

[Tim Nguyen :ntim]

It's a meatball menu not a kebab menu, see https://i.stack.imgur.com/nG8Zu.png

Comment 2

[Asif Youssuff]

Doesn't it depend on how you hold it? ;) Off-topic, I know.

Comment 3

[poperigby]

It would also be nice to be able to right click on the whole box to get also those options. The meatball menu is a little hard to click on.

Comment 4

[BugBot [:suhaib / :marco/ :calixte]]

Bugbug thinks this bug is a defect, but please change it back in case of error.

Comment 7

[janet [:janet]]

This sounds more like an enhancement request (to revert a conscious decision to change the UI) vs an unintentional regression :jimm are these changes from Bug 1525193 a decision you want to reconsider?

Comment 10

[poperigby]

Can you have them accessible via a right-click, instead?

Comment 11

[poperigby]

(In reply to poperigby from comment #10)

Can you have them accessible via a right-click, instead?

If showing them by default doesn't work. That could be a happy medium

Comment 12

[khagaroth]

Can we at least get an explanation why this is the preferred ux design. Preferably a link to the ux discussion that led to this disaster. An WONTFIX without any explanation isn't nice at all.

Comment 13

[Emma Humphries ☕️🎸🧞‍♀️✨ (she/they) [:emceeaich] (Pacific Time) use needinfo]

(In reply to khagaroth from comment #12)

Can we at least get an explanation why this is the preferred ux design. Preferably a link to the ux discussion that led to this disaster. An WONTFIX without any explanation isn't nice at all.

The Firefox mailing list, [e-mail], is the best venue for that discussion.

https://mail.mozilla.org/listinfo/firefox-dev

Please remember that that mailing list, as well as Bugzilla are subject to our Community Participation Guidelines.

Comment 14

[Kyle Ferriter]

This change regresses usability behind what it was, and behind what is available in the Chrome/ium browsers. There is substantial whitespace on the page even before this change, so I don't think the reason could be that this conserves valuable screen real-estate. I've just tested with display sizes 1920x1080 and up (which I would assume covers the vast majority of desktop Firefox users), and more than half of the display is totally empty whitespace. Even on a smaller 1600x900 display, about a third of the page is whitespace.

So given that, I do not understand this change to move addon management buttons into a dropdown menu with a small icon trigger. I understand the Firefox team wishes to make the browser experience 'cleaner' and more user friendly, but presumably when a user navigates to about:addons they wish to do something to the addons, not just see which ones are there. In my opinion the addon management page should show commonly used actions for addon management. I would guess 'Disable' is the most common action performed on that page, so I believe it should be made available directly adjacent to the addon title as it was before.

Comment 15

[poperigby]

I agree that putting the disable button there would be good. That's the only one that needs to be shown. The rest should be hidden behind the meatball menu or a right click.

Comment 16

[Carighan Maconar]

(In reply to Kyle Ferriter from comment #14)

So given that, I do not understand this change to move addon management buttons into a dropdown menu with a small icon trigger. I understand the Firefox team wishes to make the browser experience 'cleaner' and more user friendly, but presumably when a user navigates to about:addons they wish to do something to the addons, not just see which ones are there. In my opinion the addon management page should show commonly used actions for addon management.

I think that is the crux of the issue. A cleaner experience is usually good, but in this case the page was already clean, and is now "without use", in a way. The moved addon options means the first page a user sees doesn't do anything, especially since clicking on an addon does not bring up options.

Comment 17

[Mats Svensson]

(In reply to Carighan Maconar from comment #16)

(In reply to Kyle Ferriter from comment #14)

So given that, I do not understand this change to move addon management buttons into a dropdown menu with a small icon trigger. I understand the Firefox team wishes to make the browser experience 'cleaner' and more user friendly, but presumably when a user navigates to about:addons they wish to do something to the addons, not just see which ones are there. In my opinion the addon management page should show commonly used actions for addon management.

I think that is the crux of the issue. A cleaner experience is usually good, but in this case the page was already clean, and is now "without use", in a way. The moved addon options means the first page a user sees doesn't do anything, especially since clicking on an addon does not bring up options.

(Affirmation pre-deleted)

Just change it back, and move on.
It was a bad decision, and admitting that is not the end of the world.

And maybe next time don't put people who cant stand the sight of controls, in charge of designing pages with controls on them.

Comment 18

[poperigby]

Can we please get this re-opened?

Comment 19

[Dão Gottwald [:dao]]

I don't think Jim was actually involved with this work and I'm guessing he just resolved this based on this being implemented as designed. However I agree we should revisit this. E.g. switching themes in about:addons became rather unintuitive due to these recent changes.

Mark, can you discuss this with UX?

Comment 21

[Mark Striemer [:mstriemer]]

UX is looking into how we might expose some of these options on the card itself.