Re: [whatwg] Notifications improvements

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

Anyhow, I'm very supportive of any efforts to deal with the whole
notifications-for-closed-windows issue. 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.


>
> This is different from generic HTML->text conversion I think, since
> HTML is very rich and there's a bigger risk of generating unuseful
> text.


> One thing that we *could* do is to add API for detecting which of
> these properties will be rendered "natively", and which ones will use
> some form of UA-provided fallback. This way an advanced page could
> compensate for lacking capabilities in more advanced ways, whereas
> less advanced authors would get reasonably good automatic fallback.
>
> >> Second, we really need to figure out the story around handling user
> >> clicking notifications after the user has closed the original page.
> >>
> >> At the very least we need the ability to send a message to a
> >> ServiceWorker when the user clicks a notification. This way the SW can
> >> decide if UI should be shown, and if so if an existing window can be
> >> reused or not.
> >>
> >> SW integration will require some other changes too.
> >>
> >> We need to change the GC behavior. Right now it seems like if a
> >> Notification object is created, but no event listeners are attached,
> >> because the page is expecting to use the SW event to listen for
> >> clicks, the notification won't be kept alive and so the SW can't get
> >> to any of its data.
> >>
> >> We also need to keep state on the Notification object if the user has
> >> clicked the notification or not.
> >>
> >> We should also consider enabling passing a URL to the Notification
> >> constructor which is opened when the user clicks the notification.
> >> Probably this should attempt to reuse an existing tab with said URL if
> >> one is open.
> >>
> >>
> >> Third, we should look at enabling minimal user input through the
> >> Notification. It's very common for notifications to support having one
> >> or more buttons that the user can click. It would also be good to
> >> enable putting a simple text-input in the notification. This area is
> >> definitely more complex though so happy to put this last.
> >>
> > I think if we want to address the "more complex data type" use cases
> above,
> > then this needs to be part of that proposal - for example, I'm not sure
> how
> > valuable having something like a "Date/Event" notification would be
> without
> > a "Snooze" button.
>
> I'm not sure that's true. Notifying that an event is going to happen
> in 10 minutes would still be useful even if the user can't "snooze"
> that notification.
>
> That's a fair point - I guess I was thinking that these new notification
types were a natural fit for canned new buttons/input elements (i.e.
"snooze" for events, "cancel" for progress bars) but they aren't
necessarily tied together.

One note of caution wrt allowing text-input in the notification - typically
it's hard to tell what the source is for a notification (for example, on
Chrome now it's hidden by default and only exposed if the user right-clicks
on the notification). Allowing text input makes it much easier for someone
to use notifications for phishing.

Received on Friday, 11 July 2014 07:57:50 UTC