Re: [whatwg] Notifications improvements

On Tue, Aug 5, 2014 at 7:09 AM, Anne van Kesteren <annevk@annevk.nl> wrote:
> On Thu, Jul 10, 2014 at 5:44 AM, Jonas Sicking <jonas@sicking.cc> wrote:
>> I think the most low hanging fruit would be to add the following as
>> data that can be displayed in a notification:
>>
>> * Progress bar
>
> Tracked here: https://github.com/whatwg/notifications/issues/17

Sweet!

>> * Lists of title/body pairs
>
> What exactly is this for?

The place that this has come up in FirefoxOS is when notifying about
incoming emails. We would like to display the sender and the subject
for each newly arrived email.

At first this seemed like a pretty unusual edge case, but after
looking at chrome-apps notification API they had this exact feature.
So it seemed like this has come up elsewhere too.

>> * Date (for things like "event will happen in 10 minutes")
>
> Should this be part of a generic alarm API?

The goal of the Alarm API is to enable a website to do some processing
(and possibly open full UI) at a particular wallclock time. An alarm
clock application is a primary example of this.

The goal of a Date field for notifications is quite different. It's to
enable a notification that's associated with an event that happend, or
is going to happen, at a different time than when the notification API
JS call happened.

For example a calendar application might want to create a
notification. The notification should be created and displayed to the
user 10 minutes before the event is about to happen, but the timestamp
shown next to the notification should at first say "in 10 minutes". As
time passes the timestamp should change to "in 9 minutes" ... "in 5
minutes" ... "now" ... "1 minute ago" ...etc.

The only way you could do that right now is to 10 minutes before the
event happens create a notification which says "CoolMeeting in 10
minutes", then after a minute replace that with "CoolMeeting in 9
minutes" etc. This both has the problem that the application needs to
constantly be running and replace the notification. It would also mean
that the notification would render the platform provided timestamp.
This might look something like "CoolMeeting in 10 minutes. Just now".

Another use case is when creating notifications for text messages (or
other messaging systems). A text message carries the time when it was
created, which might be very different from when the message was
received by the user's device. It would here be nice to immediately
create a notification which says "Message from Anne, 6 minutes ago"
without that again creating the double timestamp like "Message from
Anne, 6 minutes ago. 2 minutes ago".

>> We also need to keep state on the Notification object if the user has
>> clicked the notification or not.
>
> Why is that?

Relying on the application to track this perfectly has two problems.

First off it means that applications has to register a ServiceWorker
handler for all notification objects and run any logic related to
handling a click right away. Rather than simply handle it next time
the application is started, which would save on both CPU and battery.

Second, it's much more error prone to track this in application space
given potential for bugs, crashes and IO errors.

/ Jonas

Received on Tuesday, 5 August 2014 22:17:00 UTC