1253635 - Possibly give each extension an icon in the toolbar

Status: RESOLVED WONTFIX

(Toolkit :: Add-ons Manager, defect)

Description

[Andy McKay]

This tracks the Chrome change as outlined here:

https://groups.google.com/a/chromium.org/forum/#!msg/chromium-extensions/7As9MKhav5E/dNiZDoSCCQAJ

Not sure if this is something we want to do yet, there might be other ways of surfacing this information.

Comment 1

[Mindaugas <LA-MJ>]

see https://bugs.chromium.org/p/chromium/issues/detail?id=578051

Comment 2

[Blake Winton (:bwinton) (:☕️)]

I think I'ld want to see some data on how much of a problem this is for Firefox users before we go ahead and do something like this…  (I also think that we might be able to be a little cleverer, maybe by automatically adding the add-ons button to the menu panel, and switching it to show the list of add-ons as a sub-menu, like bookmarks or history…)

Kev, do you have any data on how much of a problem "too many add-ons" is for Firefox users?  Is that something we're interested in collecting?

Comment 3

[Markus Jaritz [:designakt] (UX)]

As I understand it, the problem is not "too many add-ons", but awareness of add-ons running in the background.
From qualitative user research we have indication that users running add-ons are not necessarily aware of them, let alone understand the impact, and we have seen that many users point to the toolbar when we ask them about where their add-ons are.
Having their installed add-ons be visible to the users is a good step towards more clarity.
(If all page actions need to be visible all the time as chrome intends needs to be explored.)

Comment 4

[Andy McKay]

We've talked about this and don't think we should do it. There's probably better ways to go about this, in which case I'd defer to the UX team to see if there's something they'd like to do. A blind copying of Chrome in this case I don't think is a good idea.

Comment 5

[Markus Jaritz [:designakt] (UX)]

(In reply to Andy McKay [:andym] from comment #4)
> We've talked about this and don't think we should do it.

I would be interested to understand why we shouldn't do this.

From UX side and I guess also from Security, this is a very interesting idea as it forces add-ons to be more visible to the user.


(In reply to Blake Winton (:bwinton) (:☕️) from comment #2)
> Kev, do you have any data on how much of a problem "too many add-ons" is for
> Firefox users?  Is that something we're interested in collecting?

The latest Heartbeat on Add-ons shows that more than 50% of users who stated that they have add-on installed, have more than 8 add-ons installed.
https://docs.google.com/document/d/1594yhacE9QNGzSyLDS0OKbaoci1P12dsH8HjaLbA8EU/edit#

Firefox on my Surface Pro 4, i7 is considerably slowed down by 11 active add-ons, so I would assume that 8 add-ons might well be too much for slower machines.

Comment 6

[Kev Needham [:kev]]

Your comment was:

(In reply to Markus Jaritz [:maritz] (UX) from comment #5)
> (In reply to Andy McKay [:andym] from comment #4)
> > We've talked about this and don't think we should do it.
> 
> I would be interested to understand why we shouldn't do this.

From my vantage point, real-estate, clarity around what the icons mean (addons can be installed in a variety of way), and a clear call to action around when a user should care. We add icons when we add features (e.g. pocket and hello), and it's not clear to me there would be a clear line to the user unless we created a separate space for addons specifically, which is something I had thought we were trying to avoid. 

> From UX side and I guess also from Security, this is a very interesting idea
> as it forces add-ons to be more visible to the user.
 
> The latest Heartbeat on Add-ons shows that more than 50% of users who stated
> that they have add-on installed, have more than 8 add-ons installed.

I'm not sure this particular data point applies. These are people who self-identify as add-ons users, and are considerably more likely to know they have addons installed. 

The case that the chromium developers are covering is to raise awareness of add-ons being installed, and we also have an opportunity to identify when the add-ons are affecting the user experience/performance with the slow add-on work in about performance.

Instead of following the chromium model, I'd be more interested in how we draw user awareness to when an add-on is installed outside the control of the user, and when addons are potentially affecting perf. Having a row of icons doesn't really do that, and I'd like to understand the merits of that vs. a clear notification and call to action that raises awareness.

I don't think Chromium's implementation is helpful for the cases they're trying to address, and would rather spend time on defining how we'd help users understand what's going on while raising awareness of add-ons, about:performance, and the add-ons manager.

Comment 7

[Andy McKay]

One example is that we have an add-on icon in the menu bar. We don't do an awful lot with it, click it and it takes you to about:addons. I haven't seen it do anything else. 

Perhaps it could have a little number showing you the number of add-ons you have installed. Perhaps it could change colour as the number of add-ons grow or slow things down? Perhaps when clicking on it, it shows you slow add-ons. Perhaps if the add-ons need to throw a warning and the add-ons icon isn't shown, the hamburger menu will show something.

Comment 8

[Rob Wu [:robwu]]

Chrome's page-action UX is awful. Please don't copy that to Firefox.

Here is Chrome's bug that tracks the UX of page actions in the always-show-all-extension-buttons world:
https://crbug.com/597657 - "Evaluate page action UX in new toolbar design"

Comment 9

[Stephan Sokolow]

Not to mention that this could be counterproductive.

For example, given that I write extensions for my own use first and foremost, and that I value a minimalist, non-distracting UI, I've already started to shift my efforts for extensions which must support Chrome.

My new designs which must run in Chrome eschew both pageAction and browserAction in favour of:

1. Context menus carefully tuned so no more than one ever appears in the same context menu (to reduce the complexity of the mouse motions needed to acquire and trigger them)

2. Keyboard shortcuts

3. An options page only accessible via the button in the extension listing (because there's no longer a pageAction/browserAction popup to add a gear to)

4. If a page action is really the best way to implement the design, I inject something into the page itself via a content script. (A tactic I'm quite used to, since I've spent over a decade using Greasemonkey/Tampermonkey scripts as my solution for cross-browser extensions and the "User Script Commands" menu is a bit awkward to use as a primary interaction point.)

Comment 10

[:Gijs (he/him)]

Andy, are the webextensions folks still considering this? Could/should this bug move there?

Comment 11

[Andy McKay]

We are working towards getting it clearer to users what add-ons are installed and what they do. Making everything have a browserAction feels a bit like a rather unsubtle way to do it and comment 6 outlined that pretty well.

So it looks like we'll diverge from Chrome on this one.

Moving back to won't fix for this particular use case.