Re: [whatwg] Notifications improvements

In principle I agree that the specification should be implementable by all
major platforms. However, I also think that there is an important trade-off
to make here, since they are an increasingly important part of the user
experience offered by an applications -- most notably when applications can
have background activities.

Windows 8's Toast Notifications are the most basic ones, exactly matching
what the Web Notification API provides today. Both iOS and Android have
various features on top of this, with Android's notifications being much
richer than most other platforms'. Some desktop user agents implement their
own rendering, and therefore have much more freedom than having to defer to
an operating system.

I would love to be able to expose a reasonable subset of those features to
users, but we'll have to be very conscious about the impact this can have
in terms of interoperability. I don't think we should strictly hold back
because of platforms which choose to be conservative in the Notification
features they offer, as long as (1) developers can feature detect the
differences, and (2) they can degrade gracefully.

Perhaps we can start with investigating buttons? iOS 8's interactive
notifications will introduce support for them.

On Thu, Jul 10, 2014 at 4:44 AM, Jonas Sicking <jonas@sicking.cc> wrote:
>
> Second, we really need to figure out the story around handling user
> clicking notifications after the user has closed the original page.
>
> At the very least we need the ability to send a message to a
> ServiceWorker when the user clicks a notification. This way the SW can
> decide if UI should be shown, and if so if an existing window can be
> reused or not.


Yes. See my e-mail about this in May; we should continue discussing Service
Worker integration there. Anne has yet to make the changes.

http://lists.whatwg.org/pipermail/whatwg-whatwg.org/2014-May/296806.html

On Thu, Jul 10, 2014 at 4:44 AM, Jonas Sicking <jonas@sicking.cc> wrote:
>
> We need to change the GC behavior. Right now it seems like if a
> Notification object is created, but no event listeners are attached,
> because the page is expecting to use the SW event to listen for
> clicks, the notification won't be kept alive and so the SW can't get
> to any of its data.
>
> We also need to keep state on the Notification object if the user has
> clicked the notification or not.
>
> We should also consider enabling passing a URL to the Notification
> constructor which is opened when the user clicks the notification.
> Probably this should attempt to reuse an existing tab with said URL if
> one is open.


Notifications should just be serialized and re-created on demand, since
they can outlive both pages and workers.

If a page creates a notification, events for which should be delivered to a
Service Worker, then won't be able to re-use the existing object anyway. We
can't rely on a SW to stay alive between [creating a notification,
interacting with the notification] either. Since the |data| property
exists, developers can use that (or the notification's title) instead of
using the equality operator.

I believe we had some discussion about a launch URL earlier on. There are
various race conditions: what if the user presses twice on the notification
in quick succession - will we open the page twice? What is a page with that
URL has already been opened? What if there are two? Deferring to a Service
Workers solves these. The |notificationclick| event could be allowed to
open windows, too.

Thanks,
Peter



On Thu, Jul 10, 2014 at 9:04 AM, Andrew Wilson <atwilson@google.com> wrote:

> On Thu, Jul 10, 2014 at 5:44 AM, Jonas Sicking <jonas@sicking.cc> wrote:
>
> > Hi All,
> >
> > We've on and off discussed various features added to notifications.
> > It'd be great to move forward with some of these improvements.
> >
> > I think the most low hanging fruit would be to add the following as
> > data that can be displayed in a notification:
> >
> > * Progress bar
> > * Lists of title/body pairs
> > * Date (for things like "event will happen in 10 minutes")
> >
> >
> So, many of these cases were what the original HTMLNotification API was
> supposed to address. This was eventually shot down for a number of (good)
> reasons: too much complexity on the implementation side, and more
> importantly, the fact that these more complex notifications aren't
> compatible with various platform notification frameworks and so this would
> be a source of platform/UA incompatibility. It's not clear to me that
> re-adding support for these use cases one at a time as distinct
> notification types is really a good path forward, or that it's necessarily
> "low-hanging fruit" unless we have a good idea for how to deal with the
> platform-compatibility issue.
>
>
> >
> > Second, we really need to figure out the story around handling user
> > clicking notifications after the user has closed the original page.
> >
> > At the very least we need the ability to send a message to a
> > ServiceWorker when the user clicks a notification. This way the SW can
> > decide if UI should be shown, and if so if an existing window can be
> > reused or not.
> >
> > SW integration will require some other changes too.
> >
> > We need to change the GC behavior. Right now it seems like if a
> > Notification object is created, but no event listeners are attached,
> > because the page is expecting to use the SW event to listen for
> > clicks, the notification won't be kept alive and so the SW can't get
> > to any of its data.
> >
> > We also need to keep state on the Notification object if the user has
> > clicked the notification or not.
> >
> > We should also consider enabling passing a URL to the Notification
> > constructor which is opened when the user clicks the notification.
> > Probably this should attempt to reuse an existing tab with said URL if
> > one is open.
> >
> >
> > Third, we should look at enabling minimal user input through the
> > Notification. It's very common for notifications to support having one
> > or more buttons that the user can click. It would also be good to
> > enable putting a simple text-input in the notification. This area is
> > definitely more complex though so happy to put this last.
> >
> > I think if we want to address the "more complex data type" use cases
> above, then this needs to be part of that proposal - for example, I'm not
> sure how valuable having something like a "Date/Event" notification would
> be without a "Snooze" button.
>

Received on Thursday, 10 July 2014 15:01:35 UTC