1254301 - Change "Extensions" to "Add-ons" and "Appearance" to "Themes" in about:addons

Status: RESOLVED DUPLICATE of bug 1355788

(Toolkit :: Add-ons Manager, defect, P4)

Description

[Philip [:pwalm]]

Attachment: Screen Shot 2016-03-07 at 2.02.40 PM.png

We currently use incorrect terms when referring to Add-ons and Themes in the L-hand side nav of about:addons. This is confusing to users.

"Extensions" -> "Add-ons"
"Appearance" -> "Themes"

Comment 1

[:Gijs (he/him)]

(In reply to Philip [:pwalm] from comment #0)
> Created attachment 8727601 [details]
> Screen Shot 2016-03-07 at 2.02.40 PM.png
> 
> We currently use incorrect terms when referring to Add-ons and Themes in the
> L-hand side nav of about:addons. This is confusing to users.
> 
> "Extensions" -> "Add-ons"
> "Appearance" -> "Themes"

When did these terms become incorrect? "Add-ons" has, AFAIK, always been a collective term that refers to extensions, themes, locale packs, and pretty much anything that we stick in a .xpi or .jar file and install into Firefox. addons.mozilla.org also calls them "Extensions".

I could be convinced we should call the "Appearance" section "Themes", but I don't know the history there (ni Dave), and the first item in your list is very confusing.

Either way, this is not a Fx::Theme bug.

Comment 2

[Andy McKay]

Our terms might be correct, but probably rather confusing to most people who don't have the knowledge that we might have. For example, I get an Add-on, but it appears under Extension. As part of the overhaul of add-ons we are hoping to simplify all this. 

pwalm, I'm wondering if we should make this change when we haven't changed the rest of our infrastructure, eg. addons.mozilla.org and it should be part of that bigger overhaul.

Comment 3

[:Gijs (he/him)]

(In reply to Andy McKay [:andym] from comment #2)
> Our terms might be correct, but probably rather confusing to most people who
> don't have the knowledge that we might have. For example, I get an Add-on,
> but it appears under Extension.

But you don't get an add-on, you get an extension. That's what addons.mozilla.org calls them, too...

I don't understand how the terminology is confusing right now, and I also don't understand why changing it to make it confusing for developers like me who do understand the distinction is in any way an improvement.

Comment 4

[Philip [:pwalm]]

Alright, let's put it this way: We need to pick one. Either extension, or add-on. I'm not super invested in either term (but the company as a whole seems to have picked "add-on" as the desired choice), but having two leads to confusion. Look at the two other major browsers with this same feature: Safari calls them extensions, as does Chrome. But they don't have two terms for what is the same package of software, we do.

"...and I also don't understand why changing it to make it confusing for developers like me who do understand the distinction is in any way an improvement."
- Fair point, but take a second to think of the (possibly millions) of users who don't understand that distinction. That's why we're bringing this change up. Smart devs like yourself get it, but there is a not-insignificant part of our user base that doesn't. We have some recent research that backs this claim up:
https://docs.google.com/presentation/d/1fatoDoEjWJFMsI2S4eCbanX71_ps15K4tUXJifktoH0/edit#slide=id.gbf3108ea0_0_27

It all boils down to reducing friction around the whole Add-ons ecosystem for everyone involved, devs and users. This is just a small part of that.

andym: Not too fussed when this happens, I just filed it so it's on people's radar.

Comment 5

[:Gijs (he/him)]

(In reply to Philip [:pwalm] from comment #4)
> Alright, let's put it this way: We need to pick one. Either extension, or
> add-on. I'm not super invested in either term (but the company as a whole
> seems to have picked "add-on" as the desired choice), but having two leads
> to confusion. Look at the two other major browsers with this same feature:
> Safari calls them extensions, as does Chrome. But they don't have two terms
> for what is the same package of software, we do.

I'm confused about which "same package of software" you are referring to.

There are two distinct concepts for different things:
- add-ons. This is the supercategory of pretty much anything you or someone else installs into Firefox that modifies the browser in some way. Maybe it changes the available spellcheck languages, or changes the appearance of the browser, or offers you extra toolbar buttons, or lets you use Firefox's UI in Klingon. All of these are add-ons.
- extensions. This is a subcategory of the above - "extensions are a type of add-on" - and strictly refers to the "here's some extra functionality" type, not to
a) styling changes
b) language changes
c) npapi plugins

etc.

I don't know of anywhere where we use the phrase "add-ons" when we really mean "extensions", and I do know of places (like AMO, like the add-on manager) that use the phrase "extensions" and really only mean that, and not themes or langpacks or dictionaries or plugins - because those get separate categories. Making one of those categories be labeled "add-ons" is confusing because then the "parent" category shows up as a "sub" category, which makes no sense.

> "...and I also don't understand why changing it to make it confusing for
> developers like me who do understand the distinction is in any way an
> improvement."
> - Fair point, but take a second to think of the (possibly millions) of users
> who don't understand that distinction. That's why we're bringing this change
> up. Smart devs like yourself get it, but there is a not-insignificant part
> of our user base that doesn't. We have some recent research that backs this
> claim up:
> https://docs.google.com/presentation/d/
> 1fatoDoEjWJFMsI2S4eCbanX71_ps15K4tUXJifktoH0/edit#slide=id.gbf3108ea0_0_27
> 
> It all boils down to reducing friction around the whole Add-ons ecosystem
> for everyone involved, devs and users. This is just a small part of that.

Sure. I am not disputing that the fact that we have several categories is confusing for users; I am disputing that your suggested change would be an improvement, and I am further asserting that it would make things strictly worse for technical users.

Calling extensions "add-ons" would be wrong because that category would still not include other add-ons like langpacks, plugins, themes, etc.

The problem for "ordinary" users is that we have categories to begin with, and that the distinction between those categories is unclear. We can relabel them as much as we like but it's really never ever going to be clear to users, and I think your suggestion makes things worse because of the reason I gave in the previous paragraph - you're swapping a confusing name for a name that is simply wrong.

Taking a step back here - from a technical perspective it makes total sense that you have this category of NPAPI plugins as a separate thing.
If you try to articulate what NPAPI plugins do, however (ie come up with a description that a non-technical user can actually understand) it boils down to something like "render, convert or use some parts of a web page, in that web page" (at least, that covers silverlight, flash, adobe reader, google talk, the EME stuff we ship, etc., and I would be hard-pushed to find a more sensible description that could potentially understood by users)

But there is actually no reason from a "what does this do" perspective that that category wouldn't include things like ad blockers.

You could also try to describe it as "functionality in Firefox provided by external programs", which is also true for most of those (although gtalk and EME are a bit iffy), but then you get things like anti-virus programs and input device manufacturers (hi logitech) that ship Firefox extensions (not plugins).

What I'm getting at is: there are technical distinctions between those categories. There are distinctions to how they can and can't affect Firefox. We have, both in terms of policy and in terms of actual security (signing!), made actual, real differences between items that go in the different categories. So fine, they go in separate categories.

However, those technical constraints seem arbitrary from a user perspective. Why is Norton's thing in "extensions" and gtalk under "plugins", but skype under "extensions" ? That's just dumb!

At that point, trying to label them with a single word and making the distinction clear for non-technical users becomes literally impossible.

As such, I can only see downsides to this proposal and no upsides. I think we should take a different lesson from that user study, namely that the division here is arbitrary, as far as users are concerned. Lump them all together, and start treating the currently-privileged categories of langpacks, themes and services with the same security constraints as other types of add-ons.

Comment 6

[Justin Dolske [:Dolske]]

(In reply to :Gijs Kruitbosch from comment #5)

> At that point, trying to label them with a single word and making the
> distinction clear for non-technical users becomes literally impossible.

I think the point is that it's not clear there's actually significant benefit from trying to make the distinction clear.

NPAPI Plugins are arguably worth keeping separate (otherwise it's hard to talk about their severe security and stability problems, and that we're deprecating them), but this problem will go away by the end of the year when we drop support for plugins other than Flash. And part of why I say "arguably" is that plugins-vs-extensions is probably the biggest difference in things under the "addons" umbrella, and many users still don't get it.

But I think it's fair that before we change naming, that we should be comfortable with what it means for some of the annoying details, and are consistent across product, website, and perhaps even browsers.

> As such, I can only see downsides to this proposal and no upsides. I think
> we should take a different lesson from that user study, namely that the
> division here is arbitrary, as far as users are concerned. Lump them all
> together, and start treating the currently-privileged categories of
> langpacks, themes and services with the same security constraints as other
> types of add-ons.

I'm... Not sure what you're arguing about here. I get the sense you and Philip are in violent agreement.

Comment 7

[:Gijs (he/him)]

(In reply to Justin Dolske [:Dolske] from comment #6)
> > As such, I can only see downsides to this proposal and no upsides. I think
> > we should take a different lesson from that user study, namely that the
> > division here is arbitrary, as far as users are concerned. Lump them all
> > together, and start treating the currently-privileged categories of
> > langpacks, themes and services with the same security constraints as other
> > types of add-ons.
> 
> I'm... Not sure what you're arguing about here. I get the sense you and
> Philip are in violent agreement.

Well, comment #0 proposes relabeling the "Extensions" category to "Add-ons", and I'm saying that I think that's a bad idea, so I'm not sure how that qualifies as agreement...

I'm instead suggesting that, if we care about the user confusion here, we should get rid of the categories in the add-on manager altogether (and provide alternative UI for switching themes, or switching languages/dictionaries), and lump plugins, themes, extensions and services into the same container/list.

Comment 8

[Markus Jaritz [:designakt] (UX)]

We seam to agree that "apperance" should be changed to "themes" in about:addons. Can we do that for 48 as we then will do an add-on discovery in onboarding which will feature many themes and might therefor get some people to find there themes again in the add-on manager.


And thanks for all that input on addons & extensions. Resolving this discussion will be difficult and not ready for 48. It has to work for devs (logically sound) and has to make sense for other users (easy to understand). Not an easy one, but we are working on it. And currently most agreement seams to be around conflating the terms add-ons and extensions. So everything would still be an add-ons, but some are grouped in sub-categories like themes... So what we now call "extension" is then an add-on that does not fall in any of the sub-categories.

Work and discussion on this re-structuring of all add-on naming currently takes place here:
https://docs.google.com/document/d/1PZlljYzlE-UvavXiCU3WI77Ofmy6t8T3O95URrsdiy8/edit#heading=h.95ehhf8mwyyp
(I will make sure to consider the arguments brought up here.)

Comment 9

[:shell escalante]

tagging these as "amo refresh" this is part of the much bigger re-do.

Comment 10

[Markus Jaritz [:designakt] (UX)]

We should change "Appearance" to "Themes" now as we will direct more people to that page when we start with the new discovery. And as far as I have seen here, that part is not disputed as we call them Themes everywhere else already.
The other part is a clear case for the bigger re-do.

Comment 11

[:shell escalante]

this is PM choice on naming - so passing to PM =]

Comment 12

[Jorge Villalobos [:jorgev] (he/him)]

I'm okay changing Appearance to Themes.

Comment 13

[Kev Needham [:kev]]

Appearance to Themes makes sense. Changing Extensions to Add-ons doesn't, because plugins mostly go away, search has its own UI separate from AoM.