464621 - Allow get add-ons to search specific categories

Status: RESOLVED INVALID

(Toolkit :: Add-ons Manager, enhancement)

Description

[Bryan Clark (DevTools PM) [:clarkbw]]

Attachment: quick menulist addition mockup

For Thunderbird there is a lot more browsing of add-ons required from within the add-ons manager than Firefox.  I'd like to add a menulist beside the search that offers the categories of add-ons available.  

The menulist should be populated with available categories and query the list of the add-ons available for each category as changed; similar to search.  If searching with a category (other than 'All Categories') selected I would assume that only results within that category are returned.  If the user changes categories with a search term in the search field we could keep the search term and re-query against the new category chosen.

Of course this menulist might not make sense for the add-ons manager inside firefox so it makes perfect sense to require that someone pass in additional parameters to invoke this categories element. 

We also would like to be able to call the add-ons manager from other areas of the interface, opening it to a specific category.  See design below:  
http://clarkbw.net/designs/inline-get-add-ons/account-settings-add-ons.png

If this sounds feasible I'd assume that we need to add in the menulist item to the window with the proper options checking such that the menulist is shown only when needed.  At the same time we need the API of a.m.o to offer the categories, if it doesn't already.

Thanks!

Comment 1

[Dave Townsend [:mossop]]

This doesn't seem like too bad an idea, I'm not quite sure how well it fits in with the requests to allow searching only themes/extensions f.e.

We'd require the AMO API to be updated first of course and likely we'd need an API to periodically pull the AMO categories list since we don't want to hardcode that into the app.

Comment 2

[Bryan Clark (DevTools PM) [:clarkbw]]

Filed bug 465251 for the AMO API change needed.  Marking this as wanted-thunderbird3

Comment 3

[Dave Townsend [:mossop]]

Why does this bug block bug 107884?

Comment 4

[Dave Townsend [:mossop]]

(In reply to comment #2)
> Filed bug 465251 for the AMO API change needed.  Marking this as
> wanted-thunderbird3

That is not the only API change necessary, there would also be UI required for this.

I'm not sure what Gecko Thunderbird 3 will be released with but this certainly won't be in Gecko 1.9.1

Comment 5

[Wayne Mery (:wsmwk)]

(In reply to comment #3)
> Why does this bug block bug 107884?

Because Bryan in bug 107884 comment 99 states this is highly desirable for implementing the finding of Thunderbird extensions, for example solutions of bug 107884. Should bug 465251 be the blocker instead of this bug?

Comment 6

[Dave Townsend [:mossop]]

(In reply to comment #5)
> (In reply to comment #3)
> > Why does this bug block bug 107884?
> 
> Because Bryan in bug 107884 comment 99 states this is highly desirable for
> implementing the finding of Thunderbird extensions, for example solutions of
> bug 107884. Should bug 465251 be the blocker instead of this bug?

No, neither. This bug is about making finding extensions to install easier within the product. It has nothing to do with fixing that bug except by virtue of the fact it appears you expect it to be fixed by extensions.

Comment 7

[Dave Townsend [:mossop]]

The way I see this is that we probably only have the option of implementing this or bug 414570. Otherwise I think we would just have too much UI for what the get add-ons pane is meant to be, simple. My inclination is that this is a better option however there are some issues I see.

It requires AMO to have a single category list for extensions and themes. They don't appear to currently. AMO has one apparent category list on the front page but in reality this selects categories and add-on types. It might be possible to fake this in the same way but that is something I'd probably expect to be API side not client side.

Laura, do you have any thoughts here?

Boriss, so you have any quick ideas of how we might fit something like this into the existing UI or whether bug 414570 might be the better choice after all?

Comment 8

[Bryan Clark (DevTools PM) [:clarkbw]]

Just to make a couple more notes here.  We (thunderb) just need a small list of 'top' extensions to appear for each category, plus a way to search inside a category; again only showing the top few results.

I think it could be possible to allow for extension / theme searching by including them in the drop down list, perhaps with a separator.  i.e.

.--------------.
| Category 1   |
| Category 2   |
|--------------|
| Themes       |
'--------------'

I'm not really keen on this as I think that could create some consistency issues with the theme tab area; however it's an option.

Comment 9

[Bryan Clark (DevTools PM) [:clarkbw]]

with the landing of bug 516776, this bug and it's blocker bug 465251 are likely unnecessary or at least much less important to us as we'll be more likely taking the route described in bug 517498 to hook into AMO in the future.