Re: Notifications

On Wed, Feb 10, 2010 at 2:17 AM, Henri Sivonen <hsivonen@iki.fi> wrote:

> On Feb 3, 2010, at 20:54, Drew Wilson wrote:
>
> > Following up on breaking out createHTMLNotification() and
> createNotification() vs combining them into one large API - I believe the
> intent is that a given user agent may not support all types of notifications
> (for example, a mobile phone application may only support text + icon
> notifications, not HTML notifications).
>
> My main concern isn't mobile phones in the abstract but mapping to concrete
> system-wide notification mechanisms: Growl and NotifyOSD on Mac and Ubuntu
> respectively.
>
> So far, the only use case I've seen (on the WHATWG list) for HTML
> notifications that aren't close to the kind of notifications that Growl and
> NotifyOSD support has been a calendar alarm.


> I agree that calendar alarm is a valid use case, but I think HTML vs. not
> HTML isn't the right taxonomy. Rather, it seems to me that there are ambient
> notifications (that dismiss themselves after a moment even if
> unacknowledged) and notifications that are all about interrupting the user
> until explicitly dismissed (calendar alarms).
>

I agree that this is a good distinction, but I think even considering
ambient notifications there is a question of how much interaction should be
supported.  NotifyOSD, for example, does not allow the user to take any
action in response to a notification.

So a very simple use case: email web app wants to alert "you have new mail"
outside the frame, and allow the user to click on that alert and be taken to
the inbox page.  This does not work on NotifyOSD, because they explicitly
don't support that part of the D-bus notifications spec.  However, Growl
would support this.

So this suggested approach reduces us to the least common denominator of
these existing notification providers, which are far from ubiquitous (Growl
is a separate install from the OS, and we haven't yet discussed what Windows
users would see).  Perhaps spec'ing HTML notifications is looking too far
down one particular road, but I'm concerned about being completely
restricted by the current set of frameworks, if that means we can't even
rely on an onclick event.

 -John