Addons-frontend: Add support for all promoted types to AMO

[bobsilverberg]

9579 replaces the logic for Recommended add-ons on AMO to use the new promoted field from the API response, but only supports Recommended add-ons and keeps all other logic the same. In order to support the line and verified categories, we need to update more logic.

Some other things that need to be considered:

1. We currently restrict the logic for Recommended add-on badging to apply only to extensions (i.e., we exclude themes via code). Are we going to keep that restriction? If so, will that apply to all promoted categories?

2. We are recording the application(s) for which a promoted category applies in the database. The API returns this information to frontend. We currently ignore that information for Recommended add-ons, as it is new and was never used previously. How do we want to use this information for promoted add-ons going forward?

3. Currently we exclude all Recommended badging from the android site, but do nothing in terms of user agent. I.e., if someone visits the firefox site with a non-desktop browser they will see the Recommended badge.
4. If we are going to use this application information to control badging on the frontend, should it be based on clientApp (which is the android site vs the firefox site), or based on user agent sniffing?
5. Further to the above, do we know what we want to do with the android site wrt to Fenix?
6. Also further to the above, do we want to/need to differentiate between Fennec and Fenix wrt promotional badging?

Pinging @jvillalobos about all of the above questions.

[jvillalobos]

We currently restrict the logic for Recommended add-on badging to apply only to extensions (i.e., we exclude themes via code). Are we going to keep that restriction? If so, will that apply to all promoted categories?

Limiting promoted badging to extensions should be okay for now. I don't expect us to do anything for themes in the near future. We do have Recommended Themes, but those are based on a collection, and that shouldn't change.

We are recording the application(s) for which a promoted category applies in the database. The API returns this information to frontend. We currently ignore that information for Recommended add-ons, as it is new and was never used previously. How do we want to use this information for promoted add-ons going forward?

All promoted categories should be application-agnostic except for Recommended. We plan to have independent Recommended sets for Desktop and for Android, and the plan is to implement that in Q4. Badges other than Recommended should appear on the mobile site.

If we are going to use this application information to control badging on the frontend, should it be based on clientApp (which is the android site vs the firefox site), or based on user agent sniffing?

One thing I would like us to tackle in Q4 is to use agent sniffing to decide what to show, instead of the platform in the URL. I don't know how much work that is, though. For the time being, we should stay consistent and use the URL.

Further to the above, do we know what we want to do with the android site wrt to Fenix?

Beyond what I've mentioned above, there are details in this PRD.

Also further to the above, do we want to/need to differentiate between Fennec and Fenix wrt promotional badging?

Fennec and Fenix can be treated the same as far as badging goes.

[bobsilverberg]

We are recording the application(s) for which a promoted category applies in the database. The API returns this information to frontend. We currently ignore that information for Recommended add-ons, as it is new and was never used previously. How do we want to use this information for promoted add-ons going forward?

All promoted categories should be application-agnostic except for Recommended. We plan to have independent Recommended sets for Desktop and for Android, and the plan is to implement that in Q4. Badges other than Recommended should appear on the mobile site.

I take it from this that administrators will not be assigning applications for promoted add-ons other than Recommended. If no application is assigned, the system assumes that means "all applications", and the API in fact returns info indicating that the add-on is compatible with all applications.

Given this, I think it makes sense to have AMO set up so that all promoted categories are treated the same, using the application data returned by the API to determine whether an add-on should have a badge appear or not. We then would not have to introduce special casing just to deal with Recommended add-ons, and if a requirement should appear in the future to pay attention to applications for other promoted categories, the code would already be in place.

WDYT @jvillalobos and @diox?

[jvillalobos]

sgtm

[bobsilverberg]

One more point about this: Although I feel this approach is the best one to take, it does mean that if an administrator specifically lists only one application (e.g., firefox) for a promoted add-on, then that add-on will not be badged for the other application (in this case android). This is exactly what we want for Recommended add-ons, but not what we want for other categories (i.e., line and verified). Note that this would only happen if an administrator went out of their way to specify only one application, and if noticed it could be fixed by an administrator via the admin page, so I don't think it should be a blocker, but I did want to point out that it would be possible for this case to arise.

[bobsilverberg]

I don't think we've addressed the question of how we should replicate the fact that Recommended badges are currently excluded from the android site. We are currently doing it explicitly in code, but I'd rather use the information that is in apps in the promoted property returned to us by the API. That would mean that all recommended add-ons should be updated in the database to specify that firefox is the only valid application for them. Perhaps that has already been done (I seem to recall seeing something about that)?

@jvillalobos Are you okay with taking that approach, and rather than have special code in frontend for Recommended add-ons to exclude badges for android, we would use the application information from the database?

This would place the burden on the administrators to make sure that Recommended add-ons specify firefox as their application and that any other promoted add-ons do not specify an application, which is effectively the same thing as saying "All applications", but I think that ultimately that is how we want it to work.

[jvillalobos]

I don't think we have a good way to configure the application for that state other than the django Admin tools. Since Scott can add or remove add-ons from it at any time, I'd rather not have to worry about keeping it in sync.

However, I also don't think it's worth having special code just to hide the badges on mobile. It should be okay for them to show up temporarily, while we implement proper support for mobile.

[bobsilverberg]

@jvillalobos As I'm working on this, I'd like to update the code for the InstallWarning to deal with the various categories. Looking at https://docs.google.com/spreadsheets/d/1ENbv1CuLDd25Sk0XAwgbWTl9is5rV12OxJD6g1kUi48/edit#gid=1788006942, it looks like we should not show the warning for any promoted category other than "Strategic". Is that accurate?

[bobsilverberg]

@jvillalobos Another question: We currently do not display the Recommended badge for add-ons displayed on shelves (e.g., Home page shelves, Extensions page shelves) because it is considered redundant as only Recommended add-ons can appear on those. Should we extend this rule for any promoted badge? I.e., we will not show any promoted badge for add-ons that appear on those shelves? Or does it make sense to keep this limitation specific to Recommended add-ons? The former would be a bit simpler to implement, and I don't know that we expect anything other than Recommended extensions to appear on those shelves.

What about the new Promoted shelf on the home page? Do we want the promoted badge to appear next to those add-ons?

[jvillalobos]

it looks like we should not show the warning for any promoted category other than "Strategic". Is that accurate?

Yes.

Should we extend this rule for any promoted badge? I.e., we will not show any promoted badge for add-ons that appear on those shelves? Or does it make sense to keep this limitation specific to Recommended add-ons?

We don't need to show badges on shelves. The expected behavior is that all of these extensions are recommended, with the only exception being the Sponsored shelf, which is labeled clearly to point that out.

What about the new Promoted shelf on the home page? Do we want the promoted badge to appear next to those add-ons?

No, the title of the shelf should be enough.

[ioanarusiczki]

@bobsilverberg I am going to take a look at the badges on Fennec/Fenix.
Many parts from this conversation have been verified/covered by the issues from https://github.com/mozilla/addons-frontend/pull/9614

I did notice that the conversation says that themes are not in focus (such as they remain in the recommended collection).
Right now other badges can be added to themes to, I hope that's fine. An example:
https://addons-dev.allizom.org/en-US/firefox/addon/green-spring/?utm_source=addons.mozilla.org&utm_medium=referral&utm_content=featured

[ioanarusiczki]

@bobsilverberg I also verified on Fenix (80.1.3) on android 9.0:

• not too many extensions available for the shelves on AMO dev because the addons were migrated to firefox. So what I did on dev is to add at least 2 add-ons from admin to be Firefox for Android .

AMO stage does not have android extensions on shelves since all addons were migrated to Firefox:

• right now the recommended badge is available on android too for both extensions and themes in the See more URLs, in search results, autocomplete. I'm thinking that is a change caused by the request of making the other badges available too and it wouldn't make sense to hide the recommended anymore.

[bobsilverberg]

@bobsilverberg I am going to take a look at the badges on Fennec/Fenix.
Many parts from this conversation have been verified/covered by the issues from #9614

I did notice that the conversation says that themes are not in focus (such as they remain in the recommended collection).
Right now other badges can be added to themes to, I hope that's fine. An example:
addons-dev.allizom.org/en-US/firefox/addon/green-spring/?utm_source=addons.mozilla.org&utm_medium=referral&utm_content=featured

If one marks a theme as promoted using the admin, yes, badges will appear for it. I believe the intent is to just not mark any themes as promoted.

[bobsilverberg]

@bobsilverberg I also verified on Fenix (80.1.3) on android 9.0:

• not too many extensions available for the shelves on AMO dev because the addons were migrated to firefox. So what I did on dev is to add at least 2 add-ons from admin to be Firefox for Android .

I'm not sure if this is a question awaiting a response, or just some information.

AMO stage does not have android extensions on shelves since all addons were migrated to Firefox:

Again, is this a question, or just information?

• right now the recommended badge is available on android too for both extensions and themes in the See more URLs, in search results, autocomplete. I'm thinking that is a change caused by the request of making the other badges available too and it wouldn't make sense to hide the recommended anymore.

Yes, we are no longer hiding badges by default for Android. The assumption is that promoted extensions will be marked in the admin as promoted for Firefox only, and therefore the badge will not appear for Android, but if an extension is promoted for Android, or for All Applications, then the badge will appear for Android.

[ioanarusiczki]

@bobsilverberg It is information but also to address a question: if the same thing happens on prod, is the admin going to add some addons using the admin? Or that is not needed since there's a recommended collection, probably shown on all the other shelves (meaning for top rated or trending extensions).

[bobsilverberg]

@bobsilverberg It is information but also to address a question: if the same thing happens on prod, is the admin going to add some addons using the admin? Or that is not needed since there's a recommended collection, probably shown on all the other shelves (meaning for top rated or trending extensions).

This is a good question. Thanks for pointing it out. Let me do some investigation.

[bobsilverberg]

Thanks for bringing this issue to our attention, @ioanarusiczki! We are making sure the data is updated in production so those add-ons that are compatible with Fenix will be returned when we request recommended add-ons, so there should be some data for these shelves in prod after the push.