1253240 - [TV] Adding "Category" feature for TV Web Apps Discovery Portal

Status: RESOLVED WONTFIX

(Firefox OS Graveyard :: Gaia::TV, defect)

Comment 1

[Josh Cheng [:josh]]

Hi Michael,
Could you provide more information about how Joseph can query category info from content on backend?
Thanks!

Comment 2

[Michael Ellis]

@ David Durst to assist here, as he is more familiar with the under-the-hood workings of Marketplace

Comment 3

[David Durst [:ddurst]]

This is a more complicated question.

First, note that the categories associated with a particular app are currently returned with the rest of the data from the API. That tells you what categories are relevant to the content.

However, that doesn't necessarily tell you *all* of the categories that are in Marketplace.

More importantly, there aren't that many endpoints for TV: http://firefox-marketplace-api.readthedocs.org/en/latest/topics/tv.html. Because the endpoints were created for the specified UI -- which was one request: a list of content -- getting a separate list of categories wasn't necessary. So if a discrete list of categories is what's needed, getting that for TV requires more work.

That said, I'm not entirely clear on what the goal is.

Comment 4

[Joseph Yeh [:joseph]]

We can use api with query parameters to get apps in specified category.

e.g. https://marketplace.firefox.com/api/v2/tv/multi-search/?cat=music

Comment 5

[Joe Cheng [:jcheng] (please needinfo)]

(In reply to David Durst [:ddurst] from comment #3)
> This is a more complicated question.
> 
> First, note that the categories associated with a particular app are
> currently returned with the rest of the data from the API. That tells you
> what categories are relevant to the content.
> 
> However, that doesn't necessarily tell you *all* of the categories that are
> in Marketplace.
> 
> More importantly, there aren't that many endpoints for TV:
> http://firefox-marketplace-api.readthedocs.org/en/latest/topics/tv.html.
> Because the endpoints were created for the specified UI -- which was one
> request: a list of content -- getting a separate list of categories wasn't
> necessary. So if a discrete list of categories is what's needed, getting
> that for TV requires more work.
> 
> That said, I'm not entirely clear on what the goal is.


Hi David,

The goal is to make sure users are having a better experience as we have more contents in the Web Apps for TV. It is a single list for now since there are only a handful of Web Apps. As more contents are listed, having categories is one way to help users find what they are looking for in a easy way. So having categories is what we plan to do in 2.6

However, if there is a way to find out how out *all* of the categories that are in Marketplace, then the front-end design can probably be flexible enough so that as more contents / categories are added, the UI is presented in a proper way to the users without changing code on front-end/back-end, as long as the data is entered properly in the backend. 

Does it answer your question, David?

Thanks 
Joe

Comment 6

[David Durst [:ddurst]]

It does.

The categories in Marketplace are found here: https://github.com/mozilla/zamboni/blob/master/mkt/constants/categories.py#L4

As for querying them, Joseph is correct in #c4.

I imagine that TV would/could use a more streamlined category set. You can see in the github link that we did a similar mapping for Tarako; I would assume TV could benefit from something similar.

Comment 7

[Josh Cheng [:josh]]

Hi Jack, Hi Tori,
Could you check comment 6 for category issues?

Comment 8

[Tori Chen [:tori]]

Based on David's suggestion and previous work on studying different TV app stores(https://docs.google.com/document/d/1s6i8wxajP6gieBfI2eVIXGrG7K9y9HKLH8gXcFn703Q/edit), here is the proposal. 5 categories which cover 25 categories from phone marketplace. As media consumption and entertainment are the major use on smart TV, these will be emphasized on TV marketplace.

The five categories are: 
I. Movies & TV
II. Games
III. Entertainment:
IV. Utilities
V. Lifestyle

and below is how it correspond to all categories of current phone markpetplace

I. Movies & TV
   14.news
   16.photo-video
   22.sports

II. Games
   7.games

III. Entertainment: 
   1.books-comics
   4.entertainment
   6.kids
   9.humor
   13.music
   21.social

IV. Utilities:
   2.business
   3.education
   10.internet
   12.maps-navigation
   15.personalization
   17.productivity
   18.reference
   19.science-tech
   24.utilities
   25.weather

V. Lifestyle:
   5.food-drink
   8.health-fitness
   11.lifestyle
   20.shopping
   23.travel

--------------------------------------------------------

Comment and feedback welcome! 

Hi David, do you know what is the mechanism/logic of "popular" and "new" inside marketplace for phone? and can we apply that to TV marketplace easily?

Hi Joe, could you take a look on the proposal or forward the ni to relevant people?

Comment 9

[David Durst [:ddurst]]

Here's a useful link that I was sent: search in marketplace for ':help' and it will explain a variety of things.

From that you can see that 

- popular: is essentially a sort by downloads
- new: is essentially a sort by the "reviewed" field (so, date reviewed)

A little more info:
- popular: sorts by download data from the last 90 days (via monolith: install data is triggered from marketplace's front-end to Google Analytics and then brought back into Marketplace's back-end -- there's more data than just installs, but install is an easy count that's brought back in and updated in the catalog)

"Popularity" is problematic in two ways:
1) it was never established for websites. Because that content type did not gain traction, we never tracked anything more than clicks (or "opens", since there was no concept of "install" -- you can see this here: https://github.com/mozilla/fireplace/blob/master/src/media/js/tracking_events.js). So you may be able to sort things by "installs" for websites, I'm not certain that that's fully implemented the same way it is for webapps, so I'm not certain if you can apply that one easily. Or if it's meaningful; prior to TV, websites were mixed with webapps, and in order to not skew the results for the UI (that was at the time mixing webapps and websites), the import of website data set arbitrary 'popularity' levels for newly-imported websites (see: https://github.com/mozilla/zamboni/blob/a199cd52b0d586077f5f5dda44fbef9c97d17ece/mkt/websites/management/commands/import_websites_from_csv.py#L256) -- with the intention to update once we added more content and had more user data over time.

2) Since that did not happen, we didn't move forward with that data -- and in fact if you look at the import script for TV content (websites), it doesn't account for popularity at all.

That said, if you are tracking "click" (or "open" or whatever analogous) on the TV implementation, then *that* is the data you should use to determine popularity (new is probably OK as it is). But to do that, you'd either need to write a cron job that takes that data and updates zamboni daily (similar to: https://github.com/mozilla/zamboni/blob/a199cd52b0d586077f5f5dda44fbef9c97d17ece/mkt/webapps/cron.py#L109), or filter your API responses through some middle layer that adjusts that data based on what FxOS says about popularity.

Comment 10

[Josh Cheng [:josh]]

Descoped from TV 2.6