Re: Notifications: usage feedback

[This is a draft WG reply to James's last call comments. Comments on the proposed resolution are welcome; if no one objects in a week’s time, this will be the WG’s official response to his comment. -Jon]

On Oct 3, 2013, at 9:59 AM, James Burke <jrburke@gmail.com> wrote:

> 1) Ability to pass data with the Notification
> 
> Right now, we URL-encode some args to the iconURL to pass data to the
> handler function that is registered via
> navigator.mozSetMessageHandler('notification', function(){}) [1].
> 
> It would be better if I could just pass a JSON-friendly data object to
> Notification instance and then have access to that data in the
> notification callbacks that are triggered.
> 
> We cannot depend on notification.onclick to work since the app can be
> closed after the notification is fired. It also seemed very unreliable
> to depend on it, given garbage collection possibilities. So we cannot
> reliably capture state using a function closure.

The API targets several different notification platforms, not all of which allow associating data with notifications, nor allow delivered notifications to persist once the browser has been closed. But this is an interesting feature request. When we have more experience deploying the current API on different platforms, we should consider this feature request for v2 of the API.

> 2) General notification callback entry point
> 
> We are avoiding use of notification.onclick/onclose and would prefer
> to have a generic entry point to receive notification events. Right
> now we use navigator.mozSetMessageHandler('notification',
> function(){}).
> 
> but I would prefer to see a more official entry point in the spec. I
> would go so far as to want to deprecate the .onclick and .onclose as
> in practice they are not reliable, given that the app may be closed
> down after firing the Notification but before it is clicked.

The existence of the on{show,click,close} events are consistent with the rest of the platform. Replacing semantically named and defined events with a generic, string-based callback makes coding to the API more confusing for Web developers.

Moreover, both the existing API and the proposed API are equally "unreliable" in scenarios where the tab has been closed or the browser quit. How the notification platform re-launches the browser or causes a navigation back to the originating page is out of scope for this API.

> 3) onclick fires onclose too?
> 
> It seemed a bit unclear in the spec, but right now FirefoxOS fires
> onclose too for onclick actions, as the onclick pathway removes the
> notification from the list of notifications.
> 
> This seems counterintuitive to me, I would have only expected one
> event. Perhaps clarifying the onclick behavior would be good.

Yes, this is unclear. The WHATWG's spec has been changed (in [1]) to clarify this. I think we should take that change. (This is an editorial change, so it won’t cause us to go back to Last Call.) What do others think?

> I would prefer to just see one event fired in this case, if
> onclick/onclose are kept around. If the general notification callback
> entry point is established, then just firing it once with the
> event.clicked property set to true for the clicked route.

Some notification platforms support the concept of activating a notification, while others do not. This is why the spec currently states "In general, the event model for notifications is best-effort; while the Notification object offers a click event, applications may enhance their functionality by listening for that event, but cannot depend on receiving it, in case the underlying notification platform does not provide that capability." These events should remain separate.

> 4) onclick does not bring web app to front
> 
> This may be part of just further defining the steps for the "click"
> pathway in the spec, but at least in FirefoxOS right now, the
> notification onclick pathway does not bring the app to the visible
> front in all cases. The email app has to do some extra document.hidden
> checking and try to bring itself to the front.
> 
> What I would rather see is by default the web page is brought to the
> visible front, and then perhaps allow the app a way to cancel that
> behavior perhaps via a preventDefault() type of mechanism on any
> notification click event.
> 
> This would also reduce the need for an API that the app could call to
> bring itself "to the visible front". Right now, there is an
> app.launch() API in FirefoxOS for this, but there are concerns that
> giving apps the ability to launch themselves to the front could lead
> to an abuse of that API.

How or even whether a notification platform exposes clicks to the Web Notification API is undefined. FirefoxOS's notification service is free per spec to adopt the behavior requested.

> 5) Ability to set notification modes.
> 
> This one is a bit less defined. I would rather this one is discarded
> than spending too much time on it if it meant losing track of the
> points above:
> 
> For email notifications, we did not necessarily want the phone to
> light up the screen on every notification and make a sound or vibrate
> (particularly at night), but rather just register the notification and
> have it show up in the notification count and listing.
> 
> While ideally there is UI for the user to control notification
> behavior for all web apps, I can also see the case for allowing
> notifications the ability to opt in to the notification modes it
> prefers.
> 
> Any user settings would override the modes specified in the
> notification, but for apps that did want to be nice, it would be a way
> to avoid a very annoying first notification behavior, in the case of
> email, not disturbing the user unless they did an explicit override.
> 
> This may be too tricky to specify, but I started a bugzilla bug for
> FirefoxOS for this[2]. One suggestion was listing the preferred modes
> in the web app manifest, but I can see an app may have different types
> of notifications, so it would be more flexible to set per Notification
> instance.

Notification platforms like iOS only provide per-app or per-device equivalents to the requested per-notification feature. If platforms with per-notification granularity of such settings become more prevalent, we should consider exposing that in the Web Notification API. That said, prematurely exposing such a feature may overconstrain our API's ability to match future platform APIs well. Also, as you note, this seems really moble-centric; if we were to add an API, it should probably be more generic (e.g. priority numbers).

==

Please let us know promptly whether this response satisfies your comments and suggestions.

Jon

[1] http://lists.w3.org/Archives/Public/public-web-notification/2013Oct/0003.html

Received on Tuesday, 3 December 2013 02:18:13 UTC