625477 - The "Default" option should be removed in add-ons manager descriptive view

Status: RESOLVED INACTIVE

(Toolkit :: Add-ons Manager, defect)

Description

[Jennifer Morrow [:Boriss] (UX)]

Attachment: Mockup: Removing the default option, for the love of all that is good in this world

In the add-on manager's description view, the user can change the updating of an add-on from automatic to manual.  This is a good expert feature for users who want to individually manage some of their add-ons.

However, currently the options for automatic updates are "on," "off," and "default."  Default should absolutely not be an option.  Instead, marking on and off should change the behavior of only that particular add-on to update automatically or not to.

There's a few reasons why having a "Default" option makes no sense.  The most glaring is that "Default" begs the question - it tells the user nothing about whether the open add-on is automatically or manually updated.  What exactly is the default?  Who knows!  Will marking an add-on "on" or "off" change the mysterious default?  Who knows!  It's an implementation detail that is essentially useless without more information.  Even if what the current "default" was were stated on the UI, it would be completely superfluous.  On and off are all that the user should care about, because they are all that matter.  

The fact that there even exists a "default" is simply so we could have some way for users to go from global to individual to global notification again if they chose to.  Who does this?  Extremely few people.   The option is there to let expert users go crazy with updates if they want, but it's hidden under the "advanced" menu because the number of people who will do this is miniscule.  To reveal what is essentially an implementation detail that is invisible and undocumented to users would be as crazy as automatically putting users into offline mode.  Oh wait.

The intended functionality is this:

- In descriptive view, the options for automatic updates are "on" and "off"
- Marking an add-on's automatic updates "on" and "off" changes the updating for only that add-on
- In the advanced menu, clicking "Reset add-ons to update automatically" changes all add-ons to update automatically, no matter what they were set to before.  If any add-ons are marked "off" at that point, all of a sudden they are marked "on."  
- Unchecking "Update automatically" in the advanced menu makes all add-ons update manually

Comment 1

[Dave Townsend [:mossop]]

We've gone through changing the update selection UI at least twice already and each time come across problems we never thought of when we started. This is too risky to take at this late stage.

Comment 2

[Henrik Skupin [:whimboo][⌚️UTC+1]]

Also "default" was definitely not the right wording. You are right that it doesn't tell anything to the user. Instead it should have been named something like "Global", which expresses the global settings.

Personally I really like the current feature. It allows me to specify add-ons which should never update automatically, but it gives me the possibility to switch between automatic and manual update whenever I want. If we would remove this option, users will loose this capability. And AFAIR this setting was one of the key reasons why it has been added.

Comment 3

[Blair McBride [:Unfocused] (UNAVAILABLE)]

I really *really* think we need to keep that option (see comment 2, and the discussions in bug 586574). But I agree the wording could be better (its a bit late to change for 4.0 though). Maybe "Use global default" ?

Comment 4

[Blair McBride [:Unfocused] (UNAVAILABLE)]

Pretty sure Dave meant to remove this with comment 1 (can't be a softblocker if its not blocking).

Comment 5

[Jennifer Morrow [:Boriss] (UX)]

(In reply to comment #1)
> We've gone through changing the update selection UI at least twice already and
> each time come across problems we never thought of when we started. This is too
> risky to take at this late stage.

We've talked about this before, but never did this default option on this page come up to my knowledge.  

(In reply to comment #2)
> Also "default" was definitely not the right wording. You are right that it
> doesn't tell anything to the user. Instead it should have been named something
> like "Global", which expresses the global settings.
> 
> Personally I really like the current feature. It allows me to specify add-ons
> which should never update automatically, but it gives me the possibility to
> switch between automatic and manual update whenever I want. If we would remove
> this option, users will loose this capability. And AFAIR this setting was one
> of the key reasons why it has been added.

The capability you're talking about would be useful to those who already, in their head, know what the "default" or "global" option is.  I pose that the only users who would are those, like us, who know how the system works already.  For users not familiar with the backend, we need to give understandable information.  With "yes" and "no" as the only options, the only way the user will ever change that particular add-on's update system without clicking on the details screen would be to use the advanced menu.

(In reply to comment #3)
> I really *really* think we need to keep that option (see comment 2, and the
> discussions in bug 586574). But I agree the wording could be better (its a bit
> late to change for 4.0 though). Maybe "Use global default" ?

Changing the name of the option really doesn't get ride of the fundamental problem, which is that the term is meaningless as long as users don't know the invisible default.  The default is invisible because users are never meant to know it.

Comment 6

[Wes Kocher (:KWierso) (Not reading bugmail; email directly if needed)]

So nothing would be selected on a specific addon until the user selects one?

After a user selects "On" or "Off", how would the user be able to revert that decision so that the addon follows the global/default setting? (I realize that you, the user, could change On/Off to match whatever the global setting is, but that still wouldn't have the addon follow the global setting.) (You, still the user, could also probably toggle the global setting to get everything to follow the setting, but that seems suboptimal for just wanting to restore a single addon's behavior.)

Comment 7

[Dave Townsend [:mossop]]

Really I think we just took the customisation bit too far and have tried to support too many use cases. I think we only need to care about the following ones:

* Support turning off background updates entirely.
* Support turning off background updates for individual add-ons.

Boriss's suggestion matches this, some clarification on what I think would happen:

By default add-ons will show "On" for automatically applying updates until the user chooses "Off". This whole choice would probably be greyed out with an explanation if the user has globally disabled automatic updates.

I'm not totally sure even having a reset option is necessary, we could just flag add-ons not being automatically updated with warnings or something.

I disagree that this is polish because it really involves a decent amount of behavioural change

Comment 8

[Adam]

Attachment: Adds a "Restore to Default" button to the add-ons manager's descriptive view.

Comment 7 outlines a better path, so this patch may be moot.  It adds a "Restore to Default" button to the right side of "Automatic updates."  If the option is already default, the button is disabled.  If the user clicks either radio button, the button becomes enabled.

This allows the user to customize the value while having an indication that it's not the default, as well as letting them know when it is already the default (if the button is disabled).

One problem it introduces is the need for localization of the button, but if there's a way, it could reuse the localization from the browser/locales/chrome/browser/preferences/main.dtd.  For now I have just added a new definition for it (en-US locale) to the extensions.dtd.  It is also based on the location of the "Automatic updates" row prior to the resolution of bug 627274.

Comment 9

[Jennifer Morrow [:Boriss] (UX)]

Attachment: Diagram: how updating add-ons works in Firefox 5

(In reply to comment #8)
> Created attachment 507613 [details] [diff] [review]
> Adds a "Restore to Default" button to the add-ons manager's descriptive view.
> 
> Comment 7 outlines a better path, so this patch may be moot.  It adds a
> "Restore to Default" button to the right side of "Automatic updates."  If the
> option is already default, the button is disabled.  If the user clicks either
> radio button, the button becomes enabled.
> 
> This allows the user to customize the value while having an indication that
> it's not the default, as well as letting them know when it is already the
> default (if the button is disabled).
> 
> One problem it introduces is the need for localization of the button, but if
> there's a way, it could reuse the localization from the
> browser/locales/chrome/browser/preferences/main.dtd.  For now I have just added
> a new definition for it (en-US locale) to the extensions.dtd.  It is also based
> on the location of the "Automatic updates" row prior to the resolution of bug
> 627274.

Thank you for this patch, Adam, but this isn't the behavior that's going to fix the problem.  The problem here isn't how we describe the default, but that we describe it at all.  The concept of a default should play no part in the add-ons manager, because to the user it has no meaning.

I'm afraid I've been a bit unclear, and have been thinking about this bug a lot oately.I'd like to back up and outline the intention behind the bug and how we fix it, both partially in Firefox 4 and completely in Firefox 5.

I'm describing two fixes:

Fix 1 will make Firefox 4 massively more understandable and help users understand how their add-ons are being updated.

Fix 2 will make Firefox 5's UI much more usable for add-ons users that want more fine-grained control over their add-on upating.

Fix 1 - high priority for Firefox 4

Get rid of the "defualt" option in the detail pane, leaving only "yes" and "no."  Which one is marked reflects the actual state of that add-on's update method.  If the user switches between yes and no, they change only that particular add-on's update settings.  This eliminates the *big* problem that I've been pointing to in this bug - that the concept of a "default" option in the detailed pane carries no information and does not tell the user anything about how the add-on is actually being updated.

Fix 2 - make manual control easy in Firefox 5 for those that want it

In Firefox 5, I'm proposing supporting the following cases:

* 1. Automatically updating all add-ons (default)
* 2. Choosing to manually update all add-ons (via advanced menu)
* 3. Switching between #1 and #2 easily
* 4. Creating one-off exceptions to whatever the user's updating preference is

All add-ons, in their detailed pane, will still reflect their update setting.  Changing that setting changes the updating of that one, particular add-on.  In the advanced menu, only one option is presented for switching settings.  The menu item either saids "Switch to Manual Updates" or "Switch to Automatic Updates."  These options switch ALL add-ons to that state, not some add-ons.

The only case that isn't supported in Fix 2 that if a user has made several "one-off" decisions (marking a few add-ons to update manually or automatically) and then switches their global option via the advanced menu, that data about which ones where switched is lost.  This is *fine*.  It's at the very worst a few extra clicks to recreate a few one-off exceptions and effects very few users and very few moments.  This design support manually setting all add-ons' options, and going as far as to preserve one-off states at the expense of quite a bit of simplicity is an easy trade-off to make.

The attached diagram shows a diagram of how Fix 2 would feel in Firefox 5.

Comment 10

[Adam]

Attachment: WIP: Removes the default radio button from detailed view; updates tests

This patch implements the removal of the "default" radio button.

The tests that this adds at browser_details.js:482-3 (lines 164-165 in the patch) fail.  I believe this is a timing issue, as it works when I test manually.  The test is whether the correct radio is selected when the addon has not had a value selected (ie, follows default) and the default preference changes.  

If test changes are needed (rather than implementation changes that eliminate the timing issue), then the tests around 337-349 (117-134 in the patch) will need to be changed as well, though they currently pass.

Comment 11

[BMO Automation]

Per policy at https://wiki.mozilla.org/Bug_Triage/Projects/Bug_Handling/Bug_Husbandry#Inactive_Bugs. If this bug is not an enhancement request or a bug not present in a supported release of Firefox, then it may be reopened.