Re: Web Notifications: please use public-web-notification [Was: Interacting with notifications]

bcc: public-webapps to take them off the thread.

On Mon, Oct 4, 2010 at 8:57 AM, Arthur Barstow <art.barstow@nokia.com>wrote:

>  Please use the public-web-notification list for the Web Notifications
> spec.
>
> John - I think it would be helpful if you would include a note about
> public-web-notification in the Status of Document section.
>
> -ArtB
>
> -------- Original Message --------  Subject: Interacting with
> notifications  Date: Mon, 4 Oct 2010 14:41:20 +0200  From: ext Jimmy
> Forrester-Fellowes <jimmy@rocketware.org> <jimmy@rocketware.org>  To:
> public-webapps@w3.org <public-webapps@w3.org> <public-webapps@w3.org>
>
> Hi All,
> I've been playing with the webkit notifications API while creating a
> chrome-extension. I wanted to raise my concern that I think non-interactive
> notifications are unintuitive for some/most scenarios. I understand that
> using HTML notifications you can add links/buttons so the user can action a
> notification. I think HTML notifications are a really bad idea as they will
> be inconsistent in both styling and user experience.
>

I think it's a tradeoff - with HTML notifications, it is quite possible that
notifications from different web applications will have different stylings,
much as different web pages have different styles. On the flip side, there
are things that you just can't do with static text + icon notifications
(providing UI to let the user snooze a calendar event, providing a dynamic
countdown to some event, etc). I understand that you feel strongly that
enforcing a consistent style of notification may be more important than
providing extra flexibility to notification authors, but I'd posit that a
similar philosophy undoubtedly let to the NotifyOSD decision not to allow
users to interact with notifications at all - a desire to enforce a single
consistent means of interaction. I'd like to see us err on the side of
providing more flexibility to authors, and applications that abuse this
flexibility will fail in the marketplace when users disable their
notifications.


>
>  I suggest that the notification API should allow users to add actions to
> a notification that would consist of a Title & URL. This would leave the
> browser/OS notification system to deal with the styling & user-experience of
> the notification.
>

I would note that the current version of the notification API allows setting
an onclick handler, so if the underlying notification platform supports it,
the user would be able to click on a notification and the parent web page
could take an appropriate action (bring itself to the foreground via
window.focus(), display a popup, navigate to a URL, etc). I'm not certain
that providing explicit API support for inserting links is feasible, since
many of the underlying notification platforms (growl, notifyosd) would not
support this - it seems better to keep the text + icon notification API as a
lowest-common-denominator, and push more advanced functionality like this
into the HTML API.


>
>  I would urge a reconsideration of the API.
>
>  All the best,
> Jimmy
>
>  p..s as an Ubuntu user I'm constantly frustrated by the fact I can't
> click on chat notifications etc (via NotifyOSD)
>