Re: Notifications

On Fri, Feb 12, 2010 at 5:06 AM, Henri Sivonen <hsivonen@iki.fi> wrote:


>
> On Feb 11, 2010, at 16:07, Jeremy Orlow wrote:
>
> > As has been brought up repeatedly, growl and the other notification
> engines are used by a SMALL FRACTION of all web users.  I suspect a fraction
> of a percent.  Why are we bending over backwards to make this system work on
> those platforms?
>
> More seriously though: Virtually every user of an up-to-date Ubuntu
> installation has the notification engine installed. As for Growl, the kind
> of users who install Growl are presumably the kind of users who care about
> notifications of multiple concurrent things the most. Furthermore, it seems
> that notifications are becoming more a part of operating system platfroms.
> For example, it looks like Windows 7 has a system API for displaying
> notifications:
> http://msdn.microsoft.com/en-us/library/ee330740%28VS.85%29.aspx
>
> This is a useful data point. It does seem like the major platforms are
conforming to a simple icon + title + text interface for ambient
notifications. The microsoft API seems more aligned with NotifyOSD
(non-interactable notifications with a transient status tray icon provided
to allow the user to click). I suspect a UA on those platforms (NotifyOSD
and Microsoft) would display an icon with each notification to give the user
the ability to register a click on and/or dismiss the notification.



> > Are there other examples where we've dumbed down an API to the least
> common denominator for a small fraction of users?  Especially when there's
> no technical reason why these providers could not be made more advanced (for
> example, embed webkit to display fully functional notifications)?
>
> It's not a given that it's an advancement in user experience terms not to
> force all ambient notifications into a consistent form.
>

I think this is a reasonable point also. I also want to reiterate that your
distinction between ambient and interactive notifications is an interesting
one - most of the system notification frameworks are geared towards ambient
notifications (it's why NotifyOSD does not support the DBUS "actions" array,
I'm assuming). Their core use cases are things like "your printer is out of
paper", not "You have an incoming voice call from Bob. Answer the call?
Yes/No".

I think the challenge here is framing our API in a way to allow developers
to specify their intent (interactive vs ambient), with more restrictions on
ambient content. The current spec makes one cut at this via
"createNotification" vs "createHTMLNotification", but it's not at all clear
that HTML notifications are intended to be interactive rather than just
pretty versions of ambient notifications (hence, Jonas' concern that
developers will just create HTML notifications when what they really want is
an ambient notification).

One solution is only to support ambient notifications (which is essentially
the thrust of the "no HTML" argument), but I'd be opposed to any API that
does not allow for interactive notifications. I suppose that's a discussion
for the requirements thread, though :)

-atw