Re: Notifications

Hi, Ian-

No need to apologize... HTML is a little bit more widely adopted than 
SVG (I suspect that there are 10x as many HTML documents as SVG 
documents on the Web).

It may be that only specifying text and HTML notifications is the best 
way forward for now, I just wanted to make sure it was an informed 
decision.  I agree with the simplicity goal.  Fallbacks and defaults 
make a lot of sense to me.  I'll noodle a bit and see if I can come up 
with a simple mechanism, but I'm probably happier reviewing other 
people's proposals.

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

Ian Fette (イアンフェッティ) wrote (on 2/23/10 2:20 PM):
> Doug -
>
> I did not mean to be HTML centric, apologies. I'm currently going
> through a debate in my mind (scary thing) about whether allowing an
> arbitrary mime type and content would be good or bad. My gut sense here
> is that if the UA is capable of displaying it, we should allow it, and
> it will be used or not used (with fallbacks provided) based on the
> support of UAs, with more UAs evolving to support it as user demand
> grows. Ideally we would provide multiple fallbacks, e.g. allow someone
> to specify an ordered list in order of preference, e.g. text/html
> representation followed by image/svg+xml followed by text/plain
> (although perhaps text/plain is better left broken out, so that it's
> more visible and people actually fill it in, as opposed to being some
> option in a list of things you can provide).
>
> e.g.
>
> CreateInteractiveNotification(in DOMString text-fallback, [Optional] in
> DOMString MimeType1, [Optional] in DOMString NotificationFormat1,
> [Optional] in DOMString MimeType2, [Optional] NotificationFormat2, ...)
>
> forgive my broken IDL, I'm sure there's a better way to express it, but
> you get the idea.
>
> At any rate, I'm not opposed to what you propose, just trying to think
> out loud of how to best do that while still ensuring that a text
> fallback is still reasonably simple (and obvious) to specify.
>
> -Ian
>
> Am 23. Februar 2010 10:24 schrieb Doug Schepers <schepers@w3.org
> <mailto:schepers@w3.org>>:
>
>     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>
>         <mailto: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>
>         <mailto: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>
>         <mailto: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 19:43:07 UTC