Re: Notifications

On Fri, Feb 12, 2010 at 10:14 AM, Drew Wilson <atwilson@google.com> wrote:

> 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).
>
>
In terms of how I wrote the current draft, HTML vs Text+Icon has nothing to
do with notifications being ambient or persistent.  It is really just about
the content of the notification.  It would completely acceptable to me to
have HTML notifications which are always ambient: they show up for a few
seconds, then they go away, but if the user wants to interact with the
dynamic content during those seconds it's possible.

The problem is that none of the popular ambient notification providers
support HTML, so the assumption is that HTML = another new window or HTML =
mandatory acknowledgement.  However that's not necessarily true.


> 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 :)
>
> Nothing in the current draft spec requires a UA to make Web Notifications
of either type persistent - a UA which only supports ambient (self-closing)
notifications could already be conforming, as long as clicks that do happen
are passed back to the web page.

 -John