Re: [whatwg] Notifications improvements

On Wed, Aug 6, 2014 at 12:48 PM, Anne van Kesteren <annevk@annevk.nl> wrote:
> On Wed, Aug 6, 2014 at 10:08 AM, Andrew Wilson <atwilson@google.com> wrote:
>> I understand your concern that is driving this proposal: you don't
>> want to provide rich APIs that can't be well implemented on every
>> platform, and thereby fragment the web platform. I just don't want to
>> see us go down this path of adding these new notification types that
>> are so limited in ability that people will just keep using general
>> notifications anyway - I'd rather just stick with the existing API.
>
> Are you unenthusiastic about any of the proposed additions (what about
> those already added?) or is this more about the more "complex"
> features such as indication of progress?

I'm (somewhat) unenthusiastic about the new semantic types, because
I'm not sure they'd get enough uptake to be worth the effort to
implement (note that this is just my personal opinion - I'm no longer
as heavily involved in the notification work within Chromium, so Peter
B's opinion carries much more weight than mine when it comes to
determining what we'd implement).

I am quite enthusiastic about adding support in the API around
allowing users to interact with notifications after the parent page
has closed, however.

>
> Having a new field timestamp that carries a particular point in time
> related to the message seems quite useful for instance and not very
> intrusive.

Perhaps I'm not understanding how this would be used. What would such
a notification look like for (say) a calendar event ("Your 1PM meeting
starts in 5 minutes") versus a countdown timer ("In 73 seconds, your
hard boiled egg will be done cooking")? Would we have to provide a
format string so the UA knows where to inject the time remaining, or
would it always have to be put at the end? Do we need to specify
granularity of updates (i.e. if I have a stopwatch app, I probably
want to update every second, but for a calendar app, updating every 5
minutes is probably sufficient, until we get down to the last 5
minutes)?

At least for me, a calendar notification that is constantly updating
its countdown every minute but has no snooze functionality is actually
a mis-feature, because it's distracting.

Again, I don't want to be overly negative about this - maybe there are
use cases like list notifications where the new API would be really
useful, but as soon as I start thinking about more complex display
scenarios, I immediately want to start having more control over the
formatting of the text being displayed, and i wouldn't get that with
this proposal.

Received on Wednesday, 6 August 2014 12:00:17 UTC