Closed Bug 1698931 Opened 6 months ago Closed 6 months ago

Rename "Extensions and Themes" app menu entry

Categories

(Firefox :: Menus, enhancement, P1)

enhancement

Tracking

()

VERIFIED FIXED
88 Branch
user-doc-firefox docs-needed
Tracking Status
firefox88 --- verified

People

(Reporter: RT, Assigned: mconley)

References

(Depends on 1 open bug, Blocks 1 open bug)

Details

Attachments

(1 file)

We need to rename this entry to a yet TDB string that includes "Add-Ons" so users retain ability to identify this as the place Add-ons can be accessed.

Priority: -- → P1

I'll note that "Extensions and Themes" is also used in the global menu bar as of bug 1695671, and is currently slated to ride the 88 train, which is very close to soft freeze. If we want to change this string, we need to do so as soon as possible.

Flags: needinfo?(rtestard)

FWIW, in my experience "Add-ons" is the much more confusing term so I would call "Extensions and Themes" an improvement. Chrome uses "Extensions" as well.

Romain, two options:

  1. Retain "Extensions and themes" as label but use the term "add-ons" in a tooltip on this item. I assume this won't satisfy PM requirements and won't be discoverable enough.

  2. Re-label the item as: Add-ons (Extensions and Themes), or Add-ons (Extensions, themes). These are long— will need Flod to review.

We have also been updating "add-ons" to "extensions and themes" in the new modals and panels (and maybe infobars, would need to check). Do we need to pull-through the add-ons term in those instances, too? This may be some ENG re-work? I assume not since those are triggered via an action from the user and may be contextually clearer. I would need to review.

Discussed with Jorge. It is better to just revert to what we had previously rather than introduce a new term. So, the label should be: Add-ons

Romain, is it in scope to add a tooltip to the label? It would read: Extensions and themes

Asa, is there a potential accessibility issue with adding a tooltip to one of the application menu entries? This is sort of a band-aid for our confusing add-ons nomenclature, but I don't want to move ahead with it if it causes usability issues.

Flags: needinfo?(asa)

Discussion is continuing. Cancelling NI for Asa for now.

Flags: needinfo?(rtestard)
Flags: needinfo?(asa)

Flod, with the requirement of including "add-ons" in the label, the clearest label would be: Add-ons and themes

I am concerned that the localization of this label will be too long, causing the menu to break in other locales. I believe German does not localize "Add-ons" so no concerns there. For example, if I compare the French translations of "Add-ons and themes" versus "Extensions and themes" I see that the former is longer. Is it fair to assume that, besides German, "Add-ons" generally becomes a long word when localized and so having the label "Add-ons and themes" is not advised?

Flags: needinfo?(francesco.lodolo)

(In reply to Meridel [:meridel] from comment #7)

I am concerned that the localization of this label will be too long, causing the menu to break in other locales. I believe German does not localize "Add-ons" so no concerns there. For example, if I compare the French translations of "Add-ons and themes" versus "Extensions and themes" I see that the former is longer. Is it fair to assume that, besides German, "Add-ons" generally becomes a long word when localized and so having the label "Add-ons and themes" is not advised?

Yes, the assumption is correct. A couple of example for French and Italian

fr: Modules complémentaires et thèmes
it: Componenti aggiuntivi e temi

You could shorten one of the words, for example Comp. aggiuntivi e temi, but that's not great.

Other locales seem to be relatively short
https://transvision.mozfr.org/string/?entity=browser/browser/menubar.ftl:menu-tools-addons.label&repo=gecko_strings

Flags: needinfo?(francesco.lodolo)

Sorry, forgot one piece of feedback: "Add-ons and themes" might still not be the longest label in that menu. "Customize Toolbar…" is a likely winner
https://transvision.mozfr.org/string/?entity=browser/browser/appmenu.ftl:appmenu-customizetoolbar.label&repo=gecko_strings

To address both clarity and length concerns, we should use “Add-ons and themes” in English and in other locales where it fits in the menu. In locales where it does NOT fit the menu, we should use "Add-ons" and include an l10n note.

Draft l10n note: If localization of "Add-ons and themes" causes the application menu to break, use "Add-ons" as the label.

Flod, please let me know if the note needs to be adjusted, or if you need more information from me. For example, is "causes the application menu to break" specific enough?

Flags: needinfo?(asa)
Flags: needinfo?(asa) → needinfo?(francesco.lodolo)

I don't think that's going to work, or scale. Experience tells that comments are often overlooked.

If we put "Add-ons and themes" in the en-US source, we need to expect locales to translate it as-is, and accept the consequences (ideally, we should make sure the menu doesn't break in the first place).

I think it's also confusing that en-US will have one string, and some locales a translation that looks half-done. Very much like the discussion we had around Troubleshoot menu items.

Also note that this might still not be a source of breakage, because there are wider elements still (e.g. see bug 1698062).

Flags: needinfo?(francesco.lodolo)

Please use either "Add-ons" or "Extensions and Themes" but not "Add-ons and themes". This makes no sense. You can't tell the users in the menu that add-ons and themes are different things and then in the add-ons manager that themes are one category of add-ons. This contradicts itself.

Flod, can you help me understand, based on your last comment ("Also note that this might still not be a source of breakage, because there are wider elements still (e.g. see bug 1698062)") is it that "Add-ons and themes" is no longer a concern in terms of length? If that is the case, then we could proceed with that string in every locale.

Flags: needinfo?(francesco.lodolo)

Correct. I think we should keep one string for all locales, and ignore concerns around length.

Flags: needinfo?(francesco.lodolo)

I'm having trouble following. What values should we update the strings to?

Flags: needinfo?(francesco.lodolo)

UX and product is suggesting "Add-ons and themes" (also, not really the one making the final call here ;-) ).

Flags: needinfo?(francesco.lodolo)

Sounds like "Add-ons and themes" is being selected for both the global menubar and AppMenu items. Patch incoming.

Assignee: nobody → mconley

Yes, we will be moving ahead with the label of "Add-ons and themes" in all locales, in both the global menubar and AppMenu.

UX considered the pros and cons of the label choices of "Add-ons" and "Add-ons and themes." The latter, while not without issues, wins out because:

  1. The addition of “themes” as a secondary term spreads wider net. Users are more likely to see a material distinction between “add-ons”/”Extensions” and “themes.” New users are likely to be looking for “extensions” and for “themes” so we get to include at least one of the common terms.
  2. We view this as a progressive improvement.

When there is time and resourcing, we would like to revisit nomenclature holistically, in and outside of the product.

Settings docs-needed because this is changing a menuitem from "Add-ons" to "Add-ons and Themes", and so SUMO articles might need to get updated.

Pushed by mconley@mozilla.com:
https://hg.mozilla.org/integration/autoland/rev/caf170e17366
Update addons menuitems to be 'Add-ons and Themes'. r=flod,fluent-reviewers

I can only echo comment #12 's sentiment and point out that themes are addons as in .xpi files. Extensions and themes are also hosted on addons.mozilla.org under, well, "Extensions" and "Themes". The shortcut to about:addons in about:preferences is also already labelled as "Extensions & Themes", so I doubt if there are any discoverability issues. If UX thinks there is a perceived distinction between add-ons and themes, it is only because Mozilla dropped support for full themes back in Quantum.

Status: NEW → RESOLVED
Closed: 6 months ago
Resolution: --- → FIXED
Target Milestone: --- → 88 Branch

Hi Meridel,

could you please comment on the concern raised in comment #12? It's really confusing for the user to have a contradicting naming.

I see two options:

a) If there is a plan to change the naming in the add-ons manager (if so - where is the bug?) but it won't happen with Firefox 89 the change in the app menu should be reverted and postponed until the other changes will happen.
b) If it's important to change the label in the app menu in Firefox 89 then the changes in the add-ons manager should happen in Firefox 89 as well.

But overloading one term with different meanings will be confusing for users (and it will also cause headaches for us in the Firefox support). It also means that documentations have to be adjusted multiple times.

Flags: needinfo?(mwalkington)

Extensions are Add-ons.
Themes are Add-ons.
Plug-ins are Add-ons.
Dictionaries are Add-ons.
So writing "Add-ons and Themes" does not make kinda any logical sense.

(In reply to Virtual_ManPL [:Virtual] 🇵🇱 - (please needinfo? me - so I will see your comment/reply/question/etc.) from comment #25)

So writing "Add-ons and Themes" does not make kinda any logical sense.

No one asked for it, but here's my opinion: It's not 100% logical but I think it works well enough. I think what they're trying to convey here is something like "Add-ons, a category which includes themes" so that people who don't know that themes are add-ons (or don't know what add-ons are) have an easier time understanding both. "Add-ons including themes" is kind of cumbersome and I think "Add-ons and themes" gets 99% of that meaning across without being so illogical as to be nonsensical.

Thanks, Asa. Asa's explanation captures the intent of the label change in the app menu.

There are no plans to change the add-ons manager at this time, and I don't see that we would bring that nomenclature to the in-content pages or across the ecosystem. As noted, we recognize the limitations and issues with the label "Add-ons and themes" but maintain that this label, while not 100% technically accurate, will better help users (especially new users) find what they are looking for from this primary access point.

As already stated, when there is time and resourcing, we would like to revisit nomenclature holistically, in and outside of the product, and be able to simplify. In the meantime, including "add-ons" in the label acts as a bridge to existing nomenclature, and adding "themes" helps new users in particular by providing them a word they are likely looking for.

Flags: needinfo?(mwalkington)

I also agree here that we landed on a solution that offers a good compromise between end user understanding, respecting current naming conventions and use of panel space. It's always hard to fulfill everyone's expectations but there was careful consideration of options here and we aligned on the best one.

If it's for easier for other people to transition from other browsers to Firefox, let it be then. Thank you everyone very much for detailed explanation!

If it's for easier for other people to transition from other browsers to Firefox, let it be then.

As i understand it, that is not the reason. Neither Chrome nor Safari or Edge use the term "add-ons", they use the term "extensions". So the string "add-ons and themes" won't help users from other browsers, it's only a known term for existing Firefox users (oh, and Internet Explorer users 😉).

I fully agree, that "Extensions and Themes" was the best compromise. Users don't look that much to Dictionaries or Plugins sections, so they could be omitted as Add-ons in this menu.

Verified - Fixed in Beta 88.0b4 and latest Nightly 89.0a1 (2021-03-29), using Windows 10, Ubuntu 18.04 and MacOS 10.15. "Add-ons and Themes" string is displayed.

Status: RESOLVED → VERIFIED
You need to log in before you can comment on or make changes to this bug.