W3C home > Mailing lists > Public > whatwg@whatwg.org > September 2014

Re: [whatwg] Notifications and service workers

From: Jonas Sicking <jonas@sicking.cc>
Date: Tue, 23 Sep 2014 18:22:15 -0700
Message-ID: <CA+c2ei8GL_j4krVg+iu2CLZzMRtZufJnUJuV667hy7FT9W01jg@mail.gmail.com>
To: "Tab Atkins Jr." <jackalmage@gmail.com>
Cc: WHATWG <whatwg@whatwg.org>, Jake Archibald <jaffathecake@gmail.com>, Peter Beverloo <beverloo@google.com>
On Tue, Sep 23, 2014 at 5:32 PM, Tab Atkins Jr. <jackalmage@gmail.com> wrote:
> On Tue, Sep 23, 2014 at 5:21 PM, Jonas Sicking <jonas@sicking.cc> wrote:
>> After having talked to our web developers, and having talked to Olli,
>> I've come to the following conclusions:
>> * We should consider the case of persistent notifications separate
>> from notifications that automatically close when a page goes away.
>> * Notifications that close when a page goes away does not seem useful
>> on mobile, but could be useful on desktop to enable minimized
>> applications, or applications whose window is covered by other
>> windows, call attention to themselves.
> Can you provide an example use-case for a persistent notification that
> goes away when the page does?

I'm saying that there are two types of notifications:
* Persistent notifications that stick around even after the user
closes the "app"/webpage.
* Non-persistent (aka transient) notifications which are not.

I'm currently not attaching any particular UX to either. I.e. I'm
leaving out *where* these notifications are displayed.

> I can think of transient notifications,
> and persistent ones that stick around until dismissal, but I can't
> come up with this in-between case with a few minutes thought.

I agree.

>> * Persistent vs. non-persistent doesn't seem like a platform
>> difference, but rather two different types of notifications that
>> content could want to create.
> Yes.  Pandora temporarily spawning a notification showing the song
> title/artist that's playing whenever a new song starts seems useful as
> a non-persistent notification on any platform.  I definitely wouldn't
> want that sort of thing to stack up on a mobile device.

Interesting. It's not something I've actually seen myself, but I don't
tend to listen to music on my mobile.

But it does fit with the general idea that non-persistent
notifications solve the use case of allowing "background" applications
to call attention to themselves.

>> * For persistent notifications, in cases where the application cares
>> about the user clicking on the notification (as opposed to
>> fire-and-forget notifications), we should always send a notification
>> to the service worker. In this scenario it never seems useful to fire
>> an event on the Notification instance since that will just mean
>> multiple codepaths trying to handle the same click. At best that would
>> be wasted performance, at worst it could mean broken UI or application
>> logic.
>> * Same applies to "close" in addition to "click".
>> * For non-persistent notifications, it seems good to not require that
>> a service worker is used.
> I'm not sure persistent vs non-persistent is quite the line to draw
> this on. Fire-and-forget vs responsive seems more correct.  Most
> (all?) persistent notifications are responsive, yes, but transient
> notifications might or might not be.  I think it's appropriate and
> useful for a fire-and-forget notification to be fireable from a normal
> page, without a service worker.

I think we are mainly using different vocabulary. I think my "non
persistent" notification is your "transient" notification.

I guess one question is if it's ever useful to have a persistent
notification which is "fire and forget". I.e. where the application
does not want to run code or display UX when the user clicks the

My gut instinct is that there's likely some such use cases.

/ Jonas
Received on Wednesday, 24 September 2014 01:23:26 UTC

This archive was generated by hypermail 2.4.0 : Wednesday, 22 January 2020 17:00:23 UTC