[whatwg] Notifications: usage feedback

[Anne van Kesteren]

On Fri, Sep 27, 2013 at 2:15 AM, James Burke <jrburke at gmail.com> wrote:
> 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.

We currently do not have a way to have events out-of-band for the web.


> 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.
>
> 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.

That seems like an implementation detail. Activation could mean
dismissal, but e.g. on Mac OS X activation does not mean dismissal.
It's up to the site/app to dismiss after activation and sometimes they
decide to keep the notification around for a bit.


> 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.

That seems like a UI detail we cannot really say anything about in the
specification.


> 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.
>
> [2] https://bugzilla.mozilla.org/show_bug.cgi?id=912645

I think we should hold off on this until we have more experience with
notifications in the web platform. Still very early days.


-- 
http://annevankesteren.nl/