Re: [whatwg] Notifications improvements

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 08:05:09 UTC