URL for updating badge/tag (e.g. number of messages waiting)

[chaals]

In most systems that provide an icon for a webapp, there is a way to get variable information. For example messaging apps provide a count of unread messages waiting, auction apps can provide information about the current highest bid, event apps may provide a countdown timer, etc.

We should add this function to manifest.

Essentially we need a URL for the source of the data, and some standard "shape" to interpret the relevant parts of the response. One possible starting point is the "Feed" part of Yandex' Tableau API http://api.yandex.com/tableau/doc/index.xml#manifesto (which performs exactly this function).

But we're not worried about the specific design as much as enabling the functionality - pretty much everyone already has this in some for, which suggests it is a useful functionality to standardise.

[marcoscaceres]

Although the functionality is useful, this seems outside the scope of the manifest. The manifest is only concerned with metadata about a web application.

What you seem to be describing is more of a "badges" API that would possibly work with background sync and push notifications (independently of the manifest - as the JSON data could be pushed or XHR'ed to the app, and possibly handled by a service worker in the background to update the badge as needed).

A proposal similar to this has been made at Specifiction (with reference to Yandex's use case specifically):
http://discourse.specifiction.org/t/native-numerical-notifications/566

And there was some discussion about this at the WHATWG:
http://lists.w3.org/Archives/Public/public-whatwg-archive/2014Sep/0017.html

I would recommend either pursuing this in public-webapps or in the WebMob IG. However, I would strongly encourage documentation of the use cases independently of the API - we can then work out how best to integrate this into the Web platform once we fully understand the requirements and how this would integrate with the badges provided by native platforms.

[marcoscaceres]

Argh, so seems my emails on this subject to the WHATWG list never made it to that list. Here are my thoughts on the subject - it hopefully shows why this is better suited to be an API, rather than a kind of stream source in the manifest:

To me, badges are a low-priority notification and could probably be handled by the same API - but it would be ok to have two APIs and just have them co-ordinate. Unlike notifications, a badge can only go away when something explicitly happens at the application level (the email is "read"; the reminder is explicitly marked as "done") - simply "clicking" a notification is not enough to remove a badge.

There are also some notifications that don't make sense as badges: for instance, iTunes shows me a notification every time a new track starts playing, but doesn't get added as a badge.

More rarely, some applications don't display numbers, but use colors as badges: For instance, LimeChat on MacOS will display a blue circle when I get a DM, and a red circle when I get mentioned in a channel (this kind of badge sucks tho, because they end up stomping on each other).

So, it would be great to be able to show a notification and also indicate that its "badge-worthy". But at the same time, some badges have to be saved across sessions (if the device is rebooted, badges should be shown after reboot - as iOS does - without needing to relaunch an application).

I'm closing this until we can work out where to best do this work.

[chaals]

I'd like to re-open this. I agree that there is basically a specific API, but I think there should be a hook to it in the manifest.

[marcoscaceres]

My concerns with this feature request are:

1. proposes a solution to an incomplete problems: as we don't have an API for badges, it seems premature to add this.
2. presupposes a standardized format for badges: would it be RSS? JSON? XML?
3. seems limited: badges (and their numbers) are associated with an user taking some action, like reading an email, crossing something off a todo list. It's not clear how one would synchronize these badges with the display.
4. Seems limited: push notifications are more efficient than poling some URL.
5. Privacy: an implementation would need to ping this API every time someone opens a tab. This would allow sites to know every time the user opens a tab.

[chaals]

Thanks for re-opening.

1. No, I'm not presupposing a solution - we need a standard to work from. On the other hand, there are a bunch of solutions to this - pretty much everyone has one - and the thing they have in common is a URL where they get info.
2. As far as I can tell, the syntax everyone uses now is JSON, but that's a problem to deal with in standardising a solution - if it's true that the key for all solutions is a URI where you get the info, it won't matter to the manifest what the transport format is.
3. Most of the common use cases produce a number, but not all. Again, this isn't a problem we need to solve in manifest. The actions are taken "out of band" (e.g. an email arrives at the server, or the latest score in the game is updated from some other source). The badge API itself needs to explain how to interpret whatever you get, so the app can decide what to display.
4. Yes this is a real issue that we need to address - probably in the API for badge info. Today they generally work by polling an URL, but there is no reason to discount a push system. Although push may not need this, a "capability URL to register" isn't an outrageous solution - although I agree that we need to keep the horse before the cart.
5. This is what browsers routinely do today. And opening a tab is not a huge privacy leak - although it potentially notes that a user is online (only potentially because you can automate all this). Nevertheless, this is a serious question we should consider before we actually agree to any solution.

[marcoscaceres]

No, I'm not presupposing a solution - we need a standard to work from.

I think we need to work from proprietary implementations - for which Yandex's use cases and experience are very illustrative and informative as one case. There are others: for instance, we are looking to add something similar in FxOS. https://groups.google.com/forum/#!topic/mozilla.dev.webapi/51bNe3VKaZE

On the other hand, there are a bunch of solutions to this - pretty much everyone has one - and the thing they have in common is a URL where they get info.

This is what I would like to see. I don't have this evidence and would really like to see it first hand.
Can you list which badges APIs are relying on a URL?

As far as I can tell, the syntax everyone uses now is JSON, but that's a problem to deal with in standardising a solution - if it's true that the key for all solutions is a URI where you get the info, it won't matter to the manifest what the transport format is.

Format will matter if we want this to be interoperable. Hear me out: if Yandex uses their own format, but Mozilla uses, says {badges: [title: "foo"]} or whatever, developers won't be able to use a single format and will have to use browser sniffing to know what format to send. That would not be great. This is the current situation with Push, and we know that that is really sad.

Most of the common use cases produce a number, but not all.

Agree. The representation of the badge is independent of what it means/does. - particularly for accessibility purposes.

Again, this isn't a problem we need to solve in manifest. The actions are taken "out of band" (e.g. an email arrives at the server, or the latest score in the game is updated from some other source). The badge API itself needs to explain how to interpret whatever you get, so the app can decide what to display.

Exactly.

Yes this is a real issue that we need to address - probably in the API for badge info. Today they generally work by polling an URL,

Again, need to see proof of this (e.g., this is not the case in iOS, where push notification are used - or where the notifications are actually generated by the app itself).

but there is no reason to discount a push system. Although push may not need this, a "capability URL to register" isn't an outrageous solution - although I agree that we need to keep the horse before the cart.

Again, would be really helpful to have some help gathering the evidence that shows how these things are done in the wild on other platforms.

This is what browsers routinely do today. And opening a tab is not a huge privacy leak - although it potentially notes that a user is online (only potentially because you can automate all this). >Nevertheless, this is a serious question we should consider before we actually agree to any solution.

Firefox, at least, does not leak this data by pinging servers - not even when generating the tiles, as we generate the tiles in Safe Browsing Mode (as to not register the user as being logged into a site and helps anonymize the request to the server from which the thumbnail is generated). We take a screenshot that we use to populate tabs, but we certainly don't ping servers.

Safari, does ping servers in the speed dial tabs (which is not great, as it even seems to send cookies).

Chrome also seems to work as safari does: tho I am unsure if they are taking a screenshot of an open tab or if they are actually pinging a server to generate the thumbnail. In any case, they are using a logged in session to generate the thumbnail.

[marcoscaceres]

Reviewing this again, I am reaching the same conclusion: the manifest is not the right place for this feature. There are other better better suited technologies or ways of addressing this then adding a URL to the manifest.