1113318 - Add-on browser buttons can't be found by users after being removed from toolbar.

Status: UNCONFIRMED

(Firefox :: Toolbars and Customization, defect)

Description

[Kent Brewster]

User Agent: Mozilla/5.0 (Macintosh; Intel Mac OS X 10_9_5) AppleWebKit/600.2.5 (KHTML, like Gecko) Version/7.1.2 Safari/537.85.11

Steps to reproduce:

Install any extension that has a toolbar button.

Right-click the button and select Remove from Toolbar. It's gone.

See here for an expanded Tale of Woe: https://medium.com/@kentbrew/what-to-do-when-your-toolbar-extension-button-disappears-from-firefox-b1059fc216ba



Actual results:

Oh, no. I want it back! Where did it go?

Click the navburger. Is it right there with all the other icons that look like they go on the toolbar? No.

Be sufficiently psychic to know you need to click Customize. Do so.

Note that the window resizes itself (for no apparent reason.) If your browser window is sufficiently small (say 800x600) you won't see everything.

Do you see your toolbar button? No? Be smart enough to know it might be down below the fold, AFTER such indispensable things as "Hello" and "Character Encoding."

Mouse over the area containing the other Additional Tools and Features, and scroll down. (If you're using an OS that has no scrollbars, this is especially hard to know how to do.) Aha, there it is!



Expected results:

When I remove a toolbar icon it should go to the top left slot of the nameless burger-nav-induced customization window, pushing down all other things. I should not have to click Customize to find it, nor should I have to fumble around looking for it in a tiny list.

If I uninstall the extension, Firefox should completely forget that I ever had it, and allow me to have the default experience when I re-install it, and not hide it down at the bottom of the Customize window.

Comment 1

[:Gijs (he/him)]

(In reply to Kent Brewster from comment #0)
> Expected results:
> 
> When I remove a toolbar icon it should go to the top left slot of the
> nameless burger-nav-induced customization window, pushing down all other
> things. 

This doesn't really make sense to most people. That "nameless burger-nav-induced ... window" is essentially the "main menu", as the menu bar is now hidden by default everywhere but on Windows XP (and OS X, because we can't). It can be customized just like the toolbar can, and can't be and shouldn't be the 'dump' where everything goes when it's not in the toolbar. "Remove" doesn't mean "put this in my menu" - that's what "Move to Menu" is for! Remove means, well, remove!

> I should not have to click Customize to find it, nor should I have
> to fumble around looking for it in a tiny list.

... because you made the window really small? What else would you have us do with the list to make it not tiny, when the window doesn't have enough space to make it non-tiny?

What label would you suggest instead of "Customize" to make it clearer that this is where the user should go?

> If I uninstall the extension, Firefox should completely forget that I ever
> had it, and allow me to have the default experience when I re-install it,
> and not hide it down at the bottom of the Customize window.

Your add-on can easily determine that this has happened, and offer the user a choice to restore the button. As it is, we try to protect users from add-ons that have an annoying habit of adding buttons to toolbars where they are completely unnecessary for the add-on to function (adblockplus is a good example), as well as keeping their configuration the same even if they uninstall and immediately reinstall an add-on (which I'd argue is a feature, rather than a bug).



It seems eminently sensible that we should provide more indication that the list scrolls when the OS provides no hints to that effect. Philipp, want to suggest something in order to do that?

Comment 2

[JR Conlin [:jrconlin,:jconlin]]

(In reply to :Gijs Kruitbosch from comment #1)
>> Expected results:
>>
>> When I remove a toolbar icon it should go to the top left slot of the
>> nameless burger-nav-induced customization window, pushing down all other
>> things. 
>
> This doesn't really make sense to most people. That "nameless
> burger-nav-induced ... window" is essentially the "main menu", as the menu bar
> is now hidden by default everywhere but on Windows XP (and OS X, because we
> can't). It can be customized just like the toolbar can, and can't be and
> shouldn't be the 'dump' where everything goes when it's not in the toolbar.
> "Remove" doesn't mean "put this in my menu" - that's what "Move to Menu" is
> for! Remove means, well, remove!

I'd be careful with that set of presumptions about our users. The concept of a centralized menu is still fairly new (less than 2 years old). It's just as easy for me to blame the coder and designer for forcing systems they may be intimately familiar with upon customers who may not share their background.

User blaming doesn't solve problems. Let's instead focus on trying to determine what the root issue is.

In this case, we have two areas, the menu and the not toolbar. (I'll note that I have several "menus" in my version of Nightly, since I opted for the more system traditional app presentation.) Right clicking on a widget presents a menu to "Move to Menu" (which is not the menu bar, but instead the hamburger" menu), or "Remove from Toolbar" (which places the widget in a reasonably inaccessible "Additional Tools and Features" area available only via customization).

>> I should not have to click Customize to find it, nor should I have
>> to fumble around looking for it in a tiny list.
>
> ... because you made the window really small? What else would you have us do
> with the list to make it not tiny, when the window doesn't have enough space to
> make it non-tiny?
>
> What label would you suggest instead of "Customize" to make it clearer that
> this is where the user should go?

I believe the problem may be that there are two levels of "Hidden" storage. When building web-apps, one of the things that's been discovered is that there's a 50% fall off of users for every action requested. This is one of the reasons that retail sites or new user sign up sites tend to have the absolute minimum number of pages. In this case, we have two forms of "Hide this icon",  one that places it in a sub menu, and another which places it on a custom page behind that menu.

It might be worth doing a bit of user testing to see if the "Customize" link is visible enough to users so that they understand what role that button takes. (Remember, many people quickly gloss over instructions if they're not the items they expect to see.)

>
>
>> If I uninstall the extension, Firefox should completely forget that I ever
>> had it, and allow me to have the default experience when I re-install it,
>> and not hide it down at the bottom of the Customize window.
>
> Your add-on can easily determine that this has happened, and offer the user a
> choice to restore the button. As it is, we try to protect users from add-ons
> that have an annoying habit of adding buttons to toolbars where they are
> completely unnecessary for the add-on to function (adblockplus is a good
> example), as well as keeping their configuration the same even if they
> uninstall and immediately reinstall an add-on (which I'd argue is a feature,
> rather than a bug).

If a user reinstalls an app, I believe it may be safe to presume that they are interested in said app. If the app is not being presented to the user directly, I can see some benefit in notifying the user where the app control has been installed. Possibly with a door-hanger or like notification.

Remember, that folks like Kent need to not only understand this behavior, but be able to explain it to their customers, who are of varying technical expertise. If he can't, this leads to a very frustrating experience and may cause companies like Pinterest to point their users to other "easier to understand and use" browsers.

Comment 3

[:Gijs (he/him)]

(In reply to JR Conlin [:jrconlin,:jconlin] from comment #2)
> (In reply to :Gijs Kruitbosch from comment #1)
> > > Expected results:
> > >
> > > When I remove a toolbar icon it should go to the top left slot of the
> > > nameless burger-nav-induced customization window, pushing down all other
> > > things. 
> >
> > This doesn't really make sense to most people. That "nameless
> > burger-nav-induced ... window" is essentially the "main menu", as the menu bar
> > is now hidden by default everywhere but on Windows XP (and OS X, because we
> > can't). It can be customized just like the toolbar can, and can't be and
> > shouldn't be the 'dump' where everything goes when it's not in the toolbar.
> > "Remove" doesn't mean "put this in my menu" - that's what "Move to Menu" is
> > for! Remove means, well, remove!
> 
> I'd be careful with that set of presumptions about our users. The concept of
> a centralized menu is still fairly new (less than 2 years old).

It is considerably older than that on mobile. Less sure about Desktop, but even there I would suggest that your estimate is too low. If, on the other hand, we're talking about Firefox, it is only 8-ish months old as far as release users are concerned.

> It's just as
> easy for me to blame the coder and designer for forcing systems they may be
> intimately familiar with upon customers who may not share their background.
> 
> User blaming doesn't solve problems. Let's instead focus on trying to
> determine what the root issue is.

I'm sorry if this came across as user blaming - my point was, conceptually, the suggestion of removing the additional tools & features pane and putting everything in the menu doesn't really work well. Not least because the menu would get very full, and there would be no way to genuinely get rid of unused things anymore. While I accept that there might be some users who are confused by this (as there will be no matter how we deal with the issue), I disagree that getting rid of the "additional tools & features" section completely is a viable solution, and I assert that the number of people who would be unhappy with that is vastly larger than the number of people who are unhappy because of the current 'system'.

> > > I should not have to click Customize to find it, nor should I have
> > > to fumble around looking for it in a tiny list.
> > What label would you suggest instead of "Customize" to make it clearer that
> > this is where the user should go?
> It might be worth doing a bit of user testing to see if the "Customize" link
> is visible enough to users so that they understand what role that button
> takes.

Why? It is clear, per this bugreport, that for some people it is not clear enough. My question is: how do we make it clearer? You've not really answered that. It's not clear to me how you think that user testing will help with that, rather than just continuing to point out that there is a problem.

> >> If I uninstall the extension, Firefox should completely forget that I ever
> >> had it, and allow me to have the default experience when I re-install it,
> >> and not hide it down at the bottom of the Customize window.
> >
> > Your add-on can easily determine that this has happened, and offer the user a
> > choice to restore the button. As it is, we try to protect users from add-ons
> > that have an annoying habit of adding buttons to toolbars where they are
> > completely unnecessary for the add-on to function (adblockplus is a good
> > example), as well as keeping their configuration the same even if they
> > uninstall and immediately reinstall an add-on (which I'd argue is a feature,
> > rather than a bug).
> 
> If a user reinstalls an app, I believe it may be safe to presume that they
> are interested in said app. If the app is not being presented to the user
> directly, I can see some benefit in notifying the user where the app control
> has been installed. Possibly with a door-hanger or like notification.

The add-on can do that, Firefox cannot - it has no idea which add-on is responsible for which buttons; the APIs here just get opaque calls from arbitrary other JS. Notifying about every new button would require figuring out when it is "new", which isn't a solvable problem on the Firefox end either (because add-ons can and do use their own logic to determine whether to make aforementioned API calls, e.g. behind their own additional prefs). Hence my suggestion that the add-on author implement a solution if this is a frequently recurring problem.

Comment 4

[JR Conlin [:jrconlin,:jconlin]]

(In reply to :Gijs Kruitbosch from comment #3)
> It is considerably older than that on mobile. Less sure about Desktop, but
> even there I would suggest that your estimate is too low. If, on the other
> hand, we're talking about Firefox, it is only 8-ish months old as far as
> release users are concerned.

Since we're talking about an external party and their customers, it's fair to say to say that they're using GA Firefox.

> 
> > It's just as
> > easy for me to blame the coder and designer for forcing systems they may be
> > intimately familiar with upon customers who may not share their background.
> > 
> > User blaming doesn't solve problems. Let's instead focus on trying to
> > determine what the root issue is.
> 
> I'm sorry if this came across as user blaming - my point was, conceptually,
> the suggestion of removing the additional tools & features pane and putting
> everything in the menu doesn't really work well. Not least because the menu
> would get very full, and there would be no way to genuinely get rid of
> unused things anymore. While I accept that there might be some users who are
> confused by this (as there will be no matter how we deal with the issue), I
> disagree that getting rid of the "additional tools & features" section
> completely is a viable solution, and I assert that the number of people who
> would be unhappy with that is vastly larger than the number of people who
> are unhappy because of the current 'system'.

My apologies if I were implying that there was a clear solution. What I am noting is that there are several areas that an extension's widget may go, and (as I understand from previous comments) that widget may be restored to a location that is not immediately evident to the user. I'm a bit confused about your last comment though. 

In terms that the originator could use: I'm creating a Pinterest add-on that has a button widget as it's primary action. (A user clicks this in order to add a page or item of interest to their Pinterest page.) Is it correct to presume:

1) A widget is moved (either by a user directly, by accident, or by a shared computer and someone else's action). Is this revealed to the app so that it might communicate back to the user (e.g. set a flag on the Pinterest site to recommend the widget be returned to the control bar?)

2) When an app is re-installed, is the state of the widget kept (e.g. if the user had the widget in the "Additional Tools" area when they uninstalled the app, it is returned to that location after re-installation)? Is the app made aware of this in some manner so that, again, it can notify the user of this and potentially be returned to the control bar?)

I had presumed that there was some sort of "first run" flag for apps so that they could do things like initialization. If this is not the case, does it make sense to introduce such a concept (say, by passing a state event to the app after installation) to facilitate such behaviors?

My thought on user testing is that when I've participated in that sort of thing, I've often found it very enlightening about a great many elements, including elements often not being directly studied. In this case, it might be useful to increase the font size or weight of the "customize" link, or possibly alter the background color to make it more visible, but I am not a designer nor do I have any form of bucket test result to indicate it's a potential solution.

Comment 5

[:Gijs (he/him)]

(In reply to JR Conlin [:jrconlin,:jconlin] from comment #4)
> In terms that the originator could use: I'm creating a Pinterest add-on that
> has a button widget as it's primary action. (A user clicks this in order to
> add a page or item of interest to their Pinterest page.) Is it correct to
> presume:
> 
> 1) A widget is moved (either by a user directly, by accident, or by a shared
> computer and someone else's action). Is this revealed to the app so that it
> might communicate back to the user (e.g. set a flag on the Pinterest site to
> recommend the widget be returned to the control bar?)

Yes.

> 2) When an app is re-installed, is the state of the widget kept (e.g. if the
> user had the widget in the "Additional Tools" area when they uninstalled the
> app, it is returned to that location after re-installation)?

Yes.

>  Is the app made
> aware of this in some manner so that, 

This is a bit tricky - as far as the customization APIs are concerned, nothing spectactular is happening. It knew about button X, and now button X is back, and so it puts it in the same place it always did. It is not a conscious "oh, let me rummage around and see where this button used to be" thing - it's the same procedure as for a button that was in that place every startup / window open. So there is no specific notifcation for such a thing either, because from the API's perspective, it is indistinguishable from business as usual.

> again, it can notify the user of this
> and potentially be returned to the control bar?)

... however, the app can at any point ask for the location of the button, and move it itself. If it kept track in some way whether it had been installed before (most add-ons set a pref), it could therefore easily do this.

> I had presumed that there was some sort of "first run" flag for apps so that
> they could do things like initialization.

There's an install hook, yes, and the customization APIs basically let buttons specify where they should be by default, and will move them there the first time they see the button (but not after that, so on reinstall, because it's not the first time we see the button, it won't be moved there again - unless the user clicks 'restore defaults' inbetween).

> In this case, it might
> be useful to increase the font size or weight of the "customize" link, or
> possibly alter the background color to make it more visible, but I am not a
> designer nor do I have any form of bucket test result to indicate it's a
> potential solution.

Keeping needinfo on philipp for this (as I am also not a designer :-) )

Comment 6

[:Gijs (he/him)]

(In reply to :Gijs Kruitbosch from comment #5)
> ... however, the app can at any point ask for the location of the button,
> and move it itself. If it kept track in some way whether it had been
> installed before (most add-ons set a pref), it could therefore easily do
> this.

s/app/add-on/

D'oh.

Comment 7

[(Currently slow to respond) Philipp Sackl [:phlsa] (Firefox UX) please use needinfo]

Perhaps a way to deal with this situation would be to provide some kind of an undo mechanism when a button is removed from the toolbar (or any other place, for that matter). I don't know off-hand what that would look like, but I'm thinking of something like what Gmail does when you delete an email.
Figuring out a UI solution for that would warrant a separate UX bug.