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

I've had a few conversations about Growl and NotifyOSD, both on- and
off-list, and I think it makes sense to discuss some of the underlying
concerns.

>From these conversations, I've gotten the impression that some of the
objections to HTML notifications are not entirely based in use cases (for
example, it seems like the utility of being able to put markup such as bold
text, or graphics, or links in a notification should be self-evident, even
ignoring the various use cases around direct interaction with
notifications). I haven't heard anyone claim that markup is bad - rather,
the objections seem to boil down to a concern that somehow the mere
existence of HTML notifications would undermine the adoption or use of Growl
and NotifyOSD.

I absolutely agree that Growl and NotifyOSD are important use cases to
support, but I don't think they should be the tail that wags the dog (for
example, I'm not sure that I agree with Henri that they should be treated as
a more important use case than mobile phones, given the disparity in the
size of the installed bases). And I also understand that for the users of
these frameworks, having an application display notifications outside of the
framework (possibly conflicting with those frameworks) would be a real
problem.

One of the suggestions made previously on this thread was to coalesce
createNotification() and createHTMLNotification() into a single API with an
optional HTML parameter - this would allow UAs on systems with
Growl/NotifyOSD to ignore the HTML parameter passed in, and only display the
text + icon information through the appropriate system framework. This also
addresses concerns expressed on WHATWG that platforms that don't support
createHTMLNotification() would break the web because web applications would
fail to check for the existence of HTML support before calling these APIs -
UAs would always have a useful fallback.

I don't think it's in the best interest of developers or users to enforce a
lowest-common-denominator approach to this API (especially since the
currently dominant platform [Windows] doesn't have any native notification
framework and would seem to derive great benefit from notifications with
markup). Is the API change described above sufficient, or are there more
things that we can do from an API standpoint to give UAs the flexibility to
provide the desired user experience under Growl/NotifyOSD, without putting
unnecessary restrictions on UAs running on other platforms?

-atw


>
> 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 think the API for ambient notifications should be designed so that
> browsers can map all ambient notifications to Growl and NotifyOSD. As for
> notifications that require explicit acknowledgement, I think it would be
> worthwhile to collect use cases beyond calendar alarms first and not heading
> right away to generic HTML notifications.
>
> If it turns out that notifications that require explicit acknowledgements
> are virtually always calendar alarms or alarm clock notifications, it might
> make sense to design an API explicitly for those. For example, it could be
> desirable to allow a privileged calendar Web app to schedule such alarms to
> fire on a mobile device without having to keep a browsing context or a
> worker active at the notification time.
>
> --
> Henri Sivonen
> hsivonen@iki.fi
> http://hsivonen.iki.fi/
>
>
>