Re: [whatwg] Notifications improvements

On Thu, Jul 10, 2014 at 1: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.

Actually, given that the UA has a very high degree of semantic
understanding of these properties, I think it should be doable to
implement on top of all existing platform notification systems. In all
of the above cases you can come up with a reasonable string to add to
the end to render the content. This is what pages have to do right now
anyway.

This is different from generic HTML->text conversion I think, since
HTML is very rich and there's a bigger risk of generating unuseful
text.

One thing that we *could* do is to add API for detecting which of
these properties will be rendered "natively", and which ones will use
some form of UA-provided fallback. This way an advanced page could
compensate for lacking capabilities in more advanced ways, whereas
less advanced authors would get reasonably good automatic fallback.

>> 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.

I'm not sure that's true. Notifying that an event is going to happen
in 10 minutes would still be useful even if the user can't "snooze"
that notification.

/ Jonas

Received on Friday, 11 July 2014 00:31:28 UTC