Manifest: Add (optional) "category" member

[RobDolinMS]

Many app stores including Apple, Google, and Microsoft ask developers to choose a "category" for their app. This would be a good (optional) field to enable web app developers to suggest which category their app should be listed in.

  "category": "sports",

FAQ:
Q: These stores (and others) don't have the same categories. How would you align?
A: Actually, they have many (9) of the exact same categories: Business, Education, Entertainment, Health & Fitness, Lifestyle, Medical, Productivity, Shopping, and Sports
A: And many (14) categories that are very similar:

• Book-like categories: Books, Books & Reference, Books + reference
• Food-like categories: Food & Drink, Food + dining
• Magazines and Newspapers categories: Magazines & Newspapers, News & Magazines,
• Music-like categories: Music, Music & Audio
• Navigation-like categories: Navigation, Maps & Navigation, Navigation + maps
  A: The Manifest spec COULD define a canonical set of categories (or include this as informational in a related wiki page)

Q: What about sub-categories?
A: Similar to the old "font" tag, web app developers could list desired categories in descending specificity.
For example: "category": "Hotels, Travel, Lifestyle"

Q: What about non-English strings?
A: Just as other enumerations in the Manifest use English strings, these categories would use English strings.
However, there would be nothing preventing a developer from listing non-English strings.
For example: "category": "Libros, Books, Reference"

[aarongustafson]

I think this makes a lot of sense and I’m inclined to have the spec define the canonical list. Then it would be up to the individual app stores to map those standard categories to their specific ones internally (rather than putting the onus on the developer to track all of the various categories run by each app store—and any new ones that crop up). So, for simplicity:

• Business
• Books
• Education
• Entertainment
• Food
• Health
• Lifestyle
• Maps
• Medical
• Music
• News
• Productivity
• Shopping
• Sports

I’m also fine with authors being able to define additional sub-categories if they want. Direction doesn’t really matter to me much. Font families go one way (cascading backwards until a match is made), the original concept of class-ification started general and grew more specific (BEM and similar classification schemes echo this as well). I don’t really have a preference, but I do think the order should be defined rather than random. From a processing standpoint, its 6-of-one: shift() or pop().

I also think non-English categories provide a nice option as long as the canonical category is included in the appropriate position.

[marcoscaceres]

@aarongustafson could you please provide an example of how you see the multiple categories and refinement working - particularly with localized categories?

[ghost]

This is a great idea! I've made https://outweb.io and a hint in the manifest about the category of an app would be very helpful. I support the idea of an array with a list of strings (all chars lowercase and spaces replaced by an underscore like "music_and_audio"). Then the algorithm can search through this list until a match or the end of the list. If there's no match it doesn't matter, because the category list was optional.

[kenchris]

I guess they should be case insensitive, so the parsing algorithm will just ignore case.

Adding new parsing rules, like use , or now ; is confusing to devs and leads to interoperability issues - the viewport meta tag had such issues for long. This is JSON anyway, so why not just use an array?

category: [ "sports", "food and dining" ]

The categories that we define should preferable be single words (less chance of people using it wrong)

[aarongustafson]

@marcoscaceres Sure!

{
  "name": "Gojiro",
  "description": "Gojiro, a freak mutation with a cynical worldview, suffers the pain of solitude as well as several maladies experienced by entertainers, including drug abuse and suicidal tendencies.",
  "icons": [{
    "src": "images/icon.png",
    "sizes": "192x192"
  }],
  "category": ["books", "fiction", "science fiction & fantasy", "kaiju", "怪獣"]
}

[RobDolinMS]

I’m inclined to have the spec define the canonical list

From the analysis I did of categories from the Apple, Google, and Microsoft stores, here is a relatively canonical list of one-word categories:

• books
• business
• education
• entertainment
• finance
• food
• games
• health & fitness (all three stores used both words)
• kids
• lifestyle
• magazines
• medical
• music
• navigation
• news
• personalization
• photo
• productivity
• shopping
• social
• travel
• utilities
• weather

If folks think this is a reasonable direction, please comment and I'll draft a PR.

[chaals]

I like the idea of having the item, but I really dislike the idea of putting some canonical categories into the spec.

1. Naming things really is one of the 3 hard problems.
2. Creating a canonical registry of names really is an invitation for trouble in a decade or so when someone asks you to deal with the things that turned out to be only relevant for a little while.
3. Naming things is hard.

[aarongustafson]

@chaals Agreed, naming is hard. Thankfully the app stores have shouldered this task already and have seem to have come to similar conclusions.

I think the CSS spec’s handling of media types is a good reference here ("handheld" notwithstanding). In particular:

• The names chosen reflect commonly used categories used to describe apps. In the following list of category names of media types are normative, but the descriptions are informative. …
• Category names are case-insensitive.
• Category names are mutually exclusive in the sense that a user agent (is this what we wanna call a manifest parser?) can only support one media type when parsing a Web App Manifest and importing an app.
• Note. Future updates of the web app manifest may extend the list of categories. Authors should not rely on category names that are not yet defined by a Web App Manifest specification.

[FluorescentHallucinogen]

From the spec it's not quite clear whether categories member an array or a string?

The following text confuses me:

The algorithm takes a sequence<USVString> categories as an argument. This algorithm returns an Array<USVString>.

What is a sequence? :-/

Should I use "category": "business, navigation" or "category": ["business", "navigation"]?

If categories member is the array, it wouldn't be better to change

The categories member describes the expected application categories to which the web application belongs.

to

The categories member is an array of USVStrings, describing the expected application categories to which the web application belongs.

in the spec to avoid confusing?

[kenchris]

sequence means an array here but I think it is fine to clarify

[marcoscaceres]

We should probably link "sequence" to the IDL spec in prose. Irrespective, the spec clearly states: "This algorithm returns an Array<USVString>".

[kenchris]

Yes, we should also link things like "for each" etc to the infra spec. I think I fixed some of these before, but from looking at the Generic Sensor spec, it seems we can do better :)

[aarongustafson]

@FluorescentHallucinogen Based on your question, it’s JSON, which would require the latter approach

"categories": ["business", "navigation"]

AFAIK, the comma-separated string would not be valid. Also, note that the key is categories, not category.

[FluorescentHallucinogen]

@aarongustafson

Also, note that the key is categories, not category.

Thanks for your note!