W3C home > Mailing lists > Public > whatwg@whatwg.org > August 2014

Re: [whatwg] Notifications improvements

From: Andrew Wilson <atwilson@google.com>
Date: Wed, 6 Aug 2014 10:08:25 +0200
Message-ID: <CAArhhivCgsnaZ+BAjokgTLAGE75HN59NBwu8tJvx+WeYQqgu7Q@mail.gmail.com>
To: Jonas Sicking <jonas@sicking.cc>
Cc: WHAT Working Group <whatwg@whatwg.org>
On Tue, Aug 5, 2014 at 11:44 PM, Jonas Sicking <jonas@sicking.cc> wrote:
> On Fri, Jul 11, 2014 at 12:57 AM, Andrew Wilson <atwilson@google.com> wrote:
>>
>> On Fri, Jul 11, 2014 at 2:30 AM, Jonas Sicking <jonas@sicking.cc> wrote:
>>>
>>> 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.
>>
>>
>> I had assumed from the examples you gave that the goal of these new
>> notification types was to have dynamically updating notifications (progress
>> bar, timestamps that update with a countdown to an event, etc), which it
>> wasn't clear could be cleanly implemented across all platform notification
>> systems without significant jank.
>
> For dates the idea is definitely to enable the notifications to be
> dynamically updated by the platform.
>
> For progress bars my expectation was not that it would be
> automatically updated. Instead it would be updated using the exact
> same mechanism that we have for notifications today, i.e. using the
> "tag" mechanism. So the jank would be the same whether OS
> notifications supports rendering progress bars or if they are just
> able to render text.

OK, so the idea is that you'd display a new progress bar notification
with the same tag as an existing progress bar notification, and the
browser would see that they are the same and just update the progress
bar? Or would we pull down and re-display a new progress bar? If we're
just updating the existing progress bar, then I guess for
compatibility, the old notification would still get the normal events
as if it had been replaced?

>
> For lists the idea is not to update them any more or less than for
> plain text content. Just like with text content pages will likely want
> to update them occasionally, but that's not a core aspect of the
> feature.
>
>
>> The intent for things like progress bars
>> would be that they have greater visibility than your typical "5 seconds and
>> then hidden" email notification, which also may not be doable with many
>> notification frameworks.
>
> This is a quite interesting idea. I hadn't thought of that.
>
>> I'm slightly dubious about adding
>> new semantic notification types (I'd still rather give app developers the
>> tools to build their own richer notifications instead of giving them a
>> canned set), but it's definitely worth discussing further.
>
> I'm not sure I understand this argument. If you are concerned about
> having poor fallback on platforms that can't render the UI components
> discussed above, then surely that concern is even greater if we enable
> pages to build their own rich notifications?

I have a couple of concerns:

1) Anything more than plain text + icon notifications won't map well
to native notification platforms. If we're going to build support in
the API for something that isn't well supported by native notification
platforms, then we should get the most bang for our buck and build
something that's flexible enough to meet many use cases.
2) I don't feel like the limitations with the current API are
addressed by adding 3-4 pre-canned notification types. I feel like the
current notification API addresses a broad swath of use cases, and
there's a long tail of unaddressed cases that we can't serve well with
any pre-canned notification types - if we want to try to address those
long-tail cases, then I'd rather have us address them with a flexible
API that gives developers more control over the notification content
rather than cherry-picking individual use cases.

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.

>
> My goal has been two-fold:
> * Don't limit the web to the lowest common denominator of the
> platforms on which it runs.
> * Don't encourage pages that simply don't work unless you use the right OS.
>
> The "pre canned" capabilities enable us to on OSs that have advanced
> capabilities enable web developers to take advantage of those for the
> most commonly requested notification content. While still enabling
> users on OSs that don't have such capabilities to still get a useful
> experience.
>
> / Jonas
Received on Wednesday, 6 August 2014 08:08:49 UTC

This archive was generated by hypermail 2.4.0 : Wednesday, 22 January 2020 17:00:22 UTC