Re: [whatwg] Notifications improvements

Hi Andrew,

On Wed, Aug 6, 2014 at 12:59 PM, Andrew Wilson <atwilson@google.com> wrote:

> 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 find myself being in favor of the semantic types.

The primary reason for this is that it allows us to provide a much more
consistent user experience, especially on platforms where we don't control
rendering of the notification, compared to HTML notifications. On Chrome
for Android we want to provide for a consistent user experience, where
notifications should be visually indistinguishable (aside from clarifying
the origin) from those created by native apps. The proposed semantic types
would get us there.

Furthermore, support for HTML notifications will be much more difficult to
implement across the board. Some mobile OSes, notably Firefox OS and iOS,
wouldn't support this at all. Others, such as Android, theoretically could
support it, but won't because it means creating an entire WebView --
causing very significant memory pressure on already resource constrained
devices.

Implementation wise, Chrome recently switched to rendering Notifications
using a new message center implementation, which already supports rich data
such as progress bars, timestamps, lists and buttons. On Android many of
these features will come down to calling an extra method on the Java
Notification.Builder.

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)?
>

I would argue that this is a feature that should be defined by the UA or
platform. I'm not sure whether using a counting notification is the right
way to implement a count-down -- I would expect normal, foreground UI
displaying a counter, and a notification if that UI was moved to the
background and the counter expired.

The timestamp doesn't necessarily need to be in the future either.

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

The notification wouldn't visually re-announce itself on every update.

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

I think the benefit of being able to closely match the UI and UX of native
notifications on the platforms is something that's enabled by using
declarative properties, whereas that would be near impossible to do with
HTML notifications. As long as advanced features, especially more
compatible ones (say, buttons or timestamps) can be feature detected by
developers so that they can provide a fallback when they're not available,
I would be in favor of extending the future set with Jonas' declarative
proposals.

Thanks,
Peter

Received on Friday, 8 August 2014 12:48:42 UTC