Re: [whatwg] Notifications and service workers

On Fri, Sep 26, 2014 at 7:36 AM, Peter Beverloo <beverloo@google.com> wrote:
> Let me reply to a few points mentioned in this thread -- it's quite
> overloaded :-).
>
> I've also added Andrew, who might know some historical reasons for the
> events. (Andrew: most of this is in context of persistent notifications.)
>
> * Life-time of existing notifications.
>
> Chrome currently treats Web Notifications as "persistent" ones. When the
> page goes away, the notification stays. Interaction with the notification is
> not going to trigger anything anymore. While I'm in favor of changing this,
> we have to be very cautious to not break user expectations of existing users
> of the Web Notification API, for example in calendar applications.

The current situation feels pretty broken in that the API was designed
for, and only really works for, non-persistent notifications, however
all implementations implement persistent notifications, presumably
because that's what the most urgent need was.

I think we might need some form of transition period to transition to
whatever API we decide is the right one.

> * Dropping the close event.
>
> I've been wondering myself whether it's valuable to support this. Like Tab,
> I'm not aware of any messaging application actually using the close event as
> an indication that the message has been read. There is the "dismiss all"
> button on most platforms, which definitely does not imply having read the
> message. It's actually an interesting privacy question as well, for example,
> if a user dismisses a Facebook notification in their notification center
> without actually starting the app, should the sender be informed about them
> having at least looked at their phone?
>
> Synchronizing closing of the notification on all the user's devices is an
> interesting one, but opt-in would be sufficient for this.

Ah, that's the best use case I've heard so far. Though, do you really
want to close a given notification on all devices just because the
user pressed "clear all" on one device?

Or is it better to close the notification on all devices once the user
engages with the relevant part of the app, for example by clicking the
notification.

> Given the cost of starting up a Service Worker, I'm interested in exploring
> opt-in. One potential optimization a UA could do is detect the events bound
> on a Service Worker's global when it starts, and check whether
> "notificationclose" is part of this for future invocations.

Yeah. Though I think interest in "did this notification close" will
vary with notification. Which means that if you are interested in
close events for one type of notifications in your app, suddenly you
pay the price for all of them.

> * Supporting non-persistent notifications in Service Workers.
>
> I'd prefer not to, especially if we would auto-close the notifications.
> There seems to be little point beyond indicating to the user that the
> Service Worker is running, which feels more like a UA thing if they choose
> to do so.

The main use case I can think of is if we enable playing audio from a
SW, in which case you might want to notify about change in songs.

But I'm fine with leaving this unsupported for now. As long as
whatever syntax we use doesn't preclude it from being added later
should the need arise.

> * Supporting non-persistent notifications in Shared and Dedicated Workers.
>
> As long as we continue to support non-persistent notifications, I see no
> reason not to do this. The globals of both kinds of workers have well
> defined lifetimes, making the notifications as reliable as in-page ones,
> most notably on desktop.

I'm a bit skeptical about tying even non-persistent notifications to
the lifetime of a global of any sort. Either window or worker.

If the use case of non-persistent notifications is to give
"background" apps some temporary screen real estate where they can
inform the user about a change, then shouldn't that generally
disappear after a short timeout?

I believe (but am not sure) that Android and iOS have the concept of
non-persistent notifications that are displayed at the top of the
screen for a few seconds. These do not go into the notification
center.

OSX is somewhat different in that it displays an on-screen
non-persistent notification. But it also adds the notification to a
notification center. Though this notification center is more of a
"log" than "stuff that happened since you last looked at your device".
I.e. stuff on this list doesn't go away when you click it, and
applications don't remove items from here when you interact with the
app.

Most importantly, I don't know of any types of notifications on any
platform that go away when you close the app.

While I agree that we generally should leave UI up to UAs, we need to
have some model of what type of interaction authors can expect when
using various APIs. Leaving UI too undefined is part of what has
gotten us into the current somewhat messy state (though the lack of SW
certainly didn't help).

So all that said, I'm fine with allowing non-persistent notifications
to be created from workers, as well as windows. But I think we should
define that authors should only expect that they are displayed on
screen for a short period of time.

Which incidentally also means that I don't think they need to have a
.close() function.

> * "Extra-persistent" notifications (non-removable ones)
>
> Let's have a separate thread about this. I think it's a loaded subject given
> that it's incredibly easy to badly annoy the user when using these, and we
> have to make some careful considerations here.

Agreed.

/ Jonas

Received on Friday, 26 September 2014 17:09:15 UTC