Re: Notifications

This seems like a balance and all around reasonable way to move forward.

2010/2/23 Ian Fette (イアンフェッティ) <ifette@google.com>

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