Re: Notifications

Hi, Ian-

I generally agree with you, and certainly with your sentiment.  Not to 
go all SVG on you, but why "*HTMLNotification"?  I understand that HTML 
is really common, and that increasingly SVG can be used as part of HTML, 
but there are lots of devices out there (TVs, mobiles, set-top boxes) 
that use SVG rather than HTML, which would benefit from these 
interactive notifications... shouldn't we define a more generic 
"CreateWebNotification" and pass an optional MIME Type parameter that 
defaults to "text/html" (or some similar mechanism)?

I strongly agree with the sentiment that we should design for the 
future, in any case, and not limit ourselves to simple text notifications.

Regards-
-Doug Schepers
W3C Team Contact, SVG and WebApps WGs


Ian Fette (イアンフェッティ) wrote (on 2/23/10 1:06 PM):
> 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
> <mailto:johnnyg@google.com>>:
>
>
>     On Fri, Feb 12, 2010 at 10:14 AM, Drew Wilson <atwilson@google.com
>     <mailto:atwilson@google.com>> wrote:
>
>         On Fri, Feb 12, 2010 at 5:06 AM, Henri Sivonen <hsivonen@iki.fi
>         <mailto: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
>
>

--

Received on Tuesday, 23 February 2010 18:24:44 UTC