On Thu, Jul 10, 2014 at 5:44 AM, Jonas Sicking <jo...@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.

Reply via email to