Re: Notifications

This thread seems to have languished, and I'm trying to figure out how to
move forward here.

My understanding, grossly simplified, of the current state of the world is
this:

1. Some people have a desire to show HTML / interactive notifications, to
support use cases like "remind me of this calendar event again in 5 minutes"
or "Answer this call / hang up this call."
2. Some people have a concern that the proposed way to achieve 1, namely
allowing HTML, will result in certain platform notification systems (Growl,
NotifyOSD etc) not to be used.

I will disclose my biases up front and say that I do believe the use cases
that 1) tries to support are important. (I want to be able to interact with
a calendar notification to say "remind me again" or "take me to the full
details of the event," for instance). I also am of the belief regarding #2,
being unable to find any actual data on how many users have and use growl,
that the user base falls into roughly two camps. There's the people who have
gone out and downloaded Growl (or another notification service) because they
want everything coalesced, and then there's the people who don't really
care, and if mail.app wants to tell them something vs their browser wants to
tell them something, they don't really think much of it.

I think that initially, we can do a lot more for this second group in terms
of functionality that we can provide, and would find it unfortunate if we
held up forward progress because of a current implementation detail. If that
functionality proves to be useful and desired by a number of users, I
believe that platforms like Growl and NotifyOSD will find a way to make it
work. In the meantime though, I think there are relatively simple things we
can do to not leave these users in the dark.

1, for the CreateHTMLNotification call, we could still allow a text version
of the notification to be provided. If there's a significant number of users
whose platforms don't support HTML Notifications, I think there's a
reasonable chance that would be filled out. If 20% of users didn't see
images, alt= text would be more prevalent.
2. For the case where there is no text alternative provided by the website
for the HTML notification, the UA can make a best effort at transforming the
HTML notification to a text notification, optionally with whatever markup
the UA provides for text notifications (bold, links, etc). Obviously things
may not be perfect and it would be preferable if the author of the page
provided a notification, but the world is not perfect.
3. Let the user decide which notification mechanism they prefer. If the user
prefers HTML notifications, then they get whatever the UA implements. If the
user has an alternate notification provider they prefer, then they live with
the constraints of that notification system, but either way it's a tradeoff
that the user can make. And yes, in the near term some of this may be
prohibitive on mobile devices, but so are many things (try as they might,
mobile browsers still aren't a pleasure to work with when it comes to
viewing large complex sites or sites that use flash, etc).

I strongly believe that web applications are increasing in number, in scope,
and are becoming an integral part of people's lives. As web applications
expand, I don't think it is unreasonable to believe that support for HTML in
the platform (e.g. HTML in notification providers) will happen some day.
It's not going to be immediate, and so I have outlined some ideas that I
hope may get us moving in the meanwhile, but I don't want us to fall victim
to the argument of "well, right now it's hard so let's not do it."

My $0.02.

Am 12. Februar 2010 12:50 schrieb John Gregg <johnnyg@google.com>:

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