[whatwg] Notifications: usage feedback

[Jasper St. Pierre]

On Tue, Oct 29, 2013 at 11:26 AM, Anne van Kesteren <annevk at annevk.nl>wrote:

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

What about providing a URL that the user-agent will open? If the
originating tab of the notification is still open, navigate it to there,
otherwise open it in a new tab?

Clients can use the HTML5 navigation APIs to detect this and take an
appropriate action.

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



-- 
  Jasper