Closed Bug 596594 Opened 14 years ago Closed 14 years ago

allow browsing of more addons in add-ons manager

Categories

(Firefox for Android Graveyard :: General, defect)

Fennec 1.1
x86
macOS
defect
Not set
normal

Tracking

(fennec2.0b3+)

VERIFIED FIXED
Tracking Status
fennec 2.0b3+ ---

People

(Reporter: madhava, Assigned: mfinkle)

Details

(Keywords: polish)

Attachments

(2 files)

Right now, a user can see a set of recommended add-ons in the add-ons manager, but otherwise, to browse more, he or she must search (requiring knowing what he or she is looking for) or must use the AMO website, which is not yet mobile-friendly.

Sketch of new design: http://www.flickr.com/photos/madhava_work/4993317270/sizes/o/

This design revises the current default (not searching) display in two ways.

1. It replaces the currently displayed set of just recommended add-ons with a list of recommended and non-recommended add-ons, in high-ratings order (i.e. recommended first, and then others in order of their ratings).

2. It adds a row or button (depending on which of the two design alternatives is picked) to show more add-ons.  By default (in 1.) we show only 10, but by pressing this option, the manager will load and show another 10.  The button/row to press to see yet more will then sit at the bottom of the newly enlarged set.

While the extra set of 10 is loading, we should show "[throbber] loading" under the already loaded set, as we do when a search is in progress.

After a search, which will replace the set of add-ons listed, the display will revert to just 10 add-ons displayed.
blocking2.0: --- → ?
blocking2.0: ? → ---
tracking-fennec: --- → ?
Bug 594795 has a patch that implements the basics of Design #1. We can tweak that code after it lands.
tracking-fennec: ? → 2.0b2+
Assignee: nobody → mark.finkle
Some notes:
* AMO doesn't support a "paging" style API to retrieve add-ons, so I think we'll still pull a big list down all at once.
* Since we have all the add-ons from a single fetch, we might not need a "[throbber] loading"
* Since the the list is enlarged (#2 in comment 0), I wanted to ask if we even need this system if say 100 add-ons are fetched and shown?

Panning through more than 100 add-ons seems like a job for "search"
tracking-fennec: 2.0b2+ → 2.0+
I wouldn't want to dump 100 add-ons in front of the user, especially if there's a row that's useful ("browse site") at the very end.

Some options
- fake paging!
- not have a useful row at the end, and then just show a lot (maybe not 100 though)

If we wanted to get rid of the row at the end, we _could_ try combining the Browse All Add-ons ( Go to page) row and the Learn More section into one, at the top...

Screenshot of the current situation here, for reference: http://www.flickr.com/photos/madhava_work/5118116285/
tracking-fennec: 2.0+ → 2.0b3+
Keywords: polish
So - faking it!

I think what we're going to do is put the two buttons in the last row, as per the design.  The API gives us 50 add-ons, of which we're already showing 10.  When the user hits "See more add-ons" button, we'll show another 10, with the button row still being at the bottom.  We'll keep doing this, additively, until we're out of the 50.  At that point, the "See more add-ons" button will grey out.  If a user wants to see more, he or she can still hit the "Browse Site" button.
will need tests if this work lands.
Flags: in-testsuite?
Flags: in-litmus?
(In reply to comment #4)
 
> I think what we're going to do is put the two buttons in the last row, as per
> the design.

Where "as per design", I mean as in http://www.flickr.com/photos/madhava_work/4993317270/sizes/o/

so, a row at the bottom with the blue gradient background, as now, but with two buttons.

------------------------------------
[ico] Add-on Name              ***oo  <-- add-on #10
      descrioption
------------------------------------

[Browse site]     [See more add-ons]  <---- row at end 

------------------------------------
Attached patch patch (strings)Splinter Review
This is a string only patch. I can try to get a more functional patch ASAP, but the strings could land now.
Attachment #490206 - Flags: review?(mbrubeck)
Attachment #490206 - Flags: review?(mbrubeck) → review+
Attached patch patch (feature)Splinter Review
This patch adds the paging feature. We pull down al the popular add-ons, as is current behavior, but we only show 5 initially. If there are more than 5 recommended add-ons we show zero popular add-ons initially.

We display the "Browser Site" and "Show More Add-ons" buttons in the bottom row. "Browse Site" goes to AMO. "Show More Add-ons" will display 5 more add-ons at a time.

If there are no more add-ons to show, we hide the "Show More Add-ons" button.
Attachment #491557 - Flags: review?(mbrubeck)
Comment on attachment 491557 [details] [diff] [review]
patch (feature)

>+++ b/chrome/content/bindings/extensions.xml

>+    this.appendSearchResults(aBrowseAddons, true, (aRecommendedAddons.length >= 5 ? 0 : 5));

Replace "5" with a named constant.
Attachment #491557 - Flags: review?(mbrubeck) → review+
added a named constant

pushed:
http://hg.mozilla.org/mobile-browser/rev/ae862433094d
Status: NEW → RESOLVED
Closed: 14 years ago
Resolution: --- → FIXED
https://litmus.mozilla.org/show_test.cgi?id=15185
Flags: in-litmus? → in-litmus?(ioana.chiorean)
Flags: in-litmus?(ioana.chiorean) → in-litmus+
VERIFIED FIXED on:
Build ID: Mozilla /5.0 (Android;Linux armv7l;rv:2.0b13pre) Gecko/20110315
Firefox/4.0b13pre Fennec /4.0b6pre
Device: HTC Desire

This feature is working on latest trunk but "Show More Add-ons" button is not displaying 5 more add-ons at a time because we don't know if there are so many add-ons for a nightly build. If the problem still occurs please file a new bug.
Status: RESOLVED → VERIFIED
You need to log in before you can comment on or make changes to this bug.

Attachment

General

Created:
Updated:
Size: