Re: [whatwg] Notifications improvements

On Mon, Aug 11, 2014 at 9:27 AM, Andrew Wilson <atwilson@google.com> wrote:

> On Fri, Aug 8, 2014 at 2:48 PM, Peter Beverloo <beverloo@google.com>
> wrote:
> > 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.
>
> To be clear, I'm not arguing for HTML notifications - as I said in my
> original post to this thread, HTML notifications were removed from the
> spec for various good reasons. But I think it's a mistake to just bake
> in canned notification types. What if a developer wants a progress bar
> with a cancel button? A progress bar with a timestamp? A list
> notification that contains an event with timestamp? Or some other
> different notification that doesn't specifically match one of your
> curated templates, but could easily be built if you gave him a
> lower-level set of primitives?


You raise an interesting question. Given the following notification:

var notification = new Notification('Title', {
    body: 'Hello, world!',
    icon: '/my-icon.png',
    items: [
        { title: 'Message 1', body: 'Contents of message 1' },
        { title: 'Message 2', body: 'Contents of message 2' },
        { title: 'Message 3', body: 'Contents of message 3' }
    ],
    buttons: [
        'Reply',
        'Reply to all',
        'Forward'
    ],
    date: new Date('2014-08-11T16:35:00'),
    progress: 40
});

What do we expect to be displayed?

I *think* Android can mix and match some of those, but expect at least
progress bars and lists of items to be mutually exclusive. I don't have a
good answer for this right now. UAs rendering their own notifications could
support this more easily, but it will still raise interesting UX questions.

Thanks,
Peter

Received on Monday, 11 August 2014 15:39:19 UTC