Open Bug 904286 Opened 7 years ago Updated 1 year ago

[meta] Improve add-ons discoverability

Categories

(Firefox for Android :: Add-on Manager, defect)

ARM
Android
defect
Not set

Tracking

()

People

(Reporter: Margaret, Unassigned)

References

(Depends on 1 open bug)

Details

(Keywords: meta)

See the mockup here:
https://bug891115.bugzilla.mozilla.org/attachment.cgi?id=772318

For bug 892125, we can start by making the "Browse Firefox Add-ons" item open a link to AMO, but in the long term we'd like to be able to browse add-ons in our settings UI. As a first step for that, we could just use a hardcoded list of add-ons (similar to the featured add-ons we currently show in about:home), but a more generic solution would involve getting this data from AMO somehow.

Karen, could you help us coordinate with AMO about building some sort of API to get this add-on data? This feels like something we may need to push to a v2 of this add-ons in settings feature, but I want to get the conversation started.
Flags: needinfo?(krudnitski)
Actually, I just noticed that desktop already does this, so there may already be APIs we can use. Maybe Blair knows about how this works.
Flags: needinfo?(bmcbride)
(In reply to :Margaret Leibovic from comment #1)
> Actually, I just noticed that desktop already does this, so there may
> already be APIs we can use. Maybe Blair knows about how this works.

You mean the "Get Add-ons" tab in about:addons? That just loads an AMO page:
https://services.addons.mozilla.org/en-US/firefox/discovery/pane/26.0a1/WINNT/normal

Although AMO goes have an API for recommended add-ons (I *think* this is the same as featured), accessible via AddonRepository.retrieveRecommendedAddons().
Flags: needinfo?(bmcbride)
Oh, I think what I was seeing was the search results list, which looked like it was getting data from AMO to populate a list in the browser chrome.

Also, when clicking on one of these search results, I got an add-on detail page that looks like it has all the data we would want for the add-on detail page in ibarlow's mockup:
http://cl.ly/image/3C3O171M2R20

This is XUL, so we this isn't a webpage.

Looking through the mockups, I suppose the APIs we need are:

* List of featured add-ons (sounds like that exists already)
* List of new add-ons
* List of top-rated add-ons
* List of themes
* Search results (looks like that exists using desktop about:addons)
* Details about a given add-on (also looks like this exists)
Thanks, Margaret - this is a great breakdown list and I'll speak to AMO stakeholders to see what can be done and in what timeframe.
Flags: needinfo?(krudnitski)
(In reply to :Margaret Leibovic from comment #3)

> Looking through the mockups, I suppose the APIs we need are:
> 
> * List of featured add-ons (sounds like that exists already)
> * List of new add-ons
> * List of top-rated add-ons
> * List of themes
> * Search results (looks like that exists using desktop about:addons)
> * Details about a given add-on (also looks like this exists)

The good news is: We already did most, if not all, of this when Fennec was written in XUL! \o/

* Display add-ons based on a search:
  http://mxr.mozilla.org/mobile-browser/source/chrome/content/extensions.js#538

* Display recommended add-ons:
  http://mxr.mozilla.org/mobile-browser/source/chrome/content/extensions.js#542

* Display the top popular add-ons (it uses an empty search term):
  http://mxr.mozilla.org/mobile-browser/source/chrome/content/extensions.js#868

I don't think AMO has a way to filter on themes or recent add-ons.
Robin, since you've been doing add-ons work recently, what do you think of the "Browse Add-ons" mocks on in comment #1? I think this is a good place to start improving our Add-ons experience, so I just want to make sure you think these mocks seem up to date!
Assignee: nobody → liuche
Flags: needinfo?(randersen)
I think we should morph this bug to be about promoting add-ons in the current add-on manager, since I wouldn't want this to block on creating a native settings UI for add-ons.
(In reply to :Margaret Leibovic from comment #7)
> I think we should morph this bug to be about promoting add-ons in the
> current add-on manager, since I wouldn't want this to block on creating a
> native settings UI for add-ons.

Maybe even in other places in the UI too. We shouldn't force people to discover the Add-on Manager to discover add-ons. We can lead people to the Add-on Manager though.
(In reply to Mark Finkle (:mfinkle) from comment #8)
> (In reply to :Margaret Leibovic from comment #7)
> > I think we should morph this bug to be about promoting add-ons in the
> > current add-on manager, since I wouldn't want this to block on creating a
> > native settings UI for add-ons.
> 
> Maybe even in other places in the UI too. We shouldn't force people to
> discover the Add-on Manager to discover add-ons. We can lead people to the
> Add-on Manager though.

This sounds like a perfect snippet. I think we even have snippets in the rotation that do promote add-ons.

But it could be nice to promote different add-on categories in different places. For example, in the developer tools menu on desktop, there's a link to "Get More Tools", which takes you to the developer tools section of AMO.
Morphing this bug to be about improving add-on discoverability.
No longer blocks: 892125
Summary: Create "Browse Firefox Add-ons" settings page → [meta] Improve add-ons discoverability
Duplicate of this bug: 1000439
Flags: needinfo?(randersen)
Unassiging since this is on the back-burner for now.
Assignee: liuche → nobody
Depends on: 1160604
Keywords: meta
You need to log in before you can comment on or make changes to this bug.