W3C home > Mailing lists > Public > public-webapps@w3.org > January to March 2010

Re: Notifications

From: Jeremy Orlow <jorlow@chromium.org>
Date: Thu, 11 Feb 2010 14:07:08 +0000
Message-ID: <5dd9e5c51002110607k5c1afd1fy3c55c88d7ec699dc@mail.gmail.com>
To: Jonas Sicking <jonas@sicking.cc>
Cc: Drew Wilson <atwilson@google.com>, robert@ocallahan.org, Henri Sivonen <hsivonen@iki.fi>, John Gregg <johnnyg@google.com>, Olli@pettay.fi, public-webapps <public-webapps@w3.org>
On Thu, Feb 11, 2010 at 7:24 AM, Jonas Sicking <jonas@sicking.cc> wrote:

> On Wed, Feb 10, 2010 at 6:29 PM, Drew Wilson <atwilson@google.com> wrote:
> >
> > On Wed, Feb 10, 2010 at 5:49 PM, Jonas Sicking <jonas@sicking.cc> wrote:
> >>
> >>
> >> And I think the answer is "yes". Any time someone talks about an
> >> optional web feature I get nervous. Can you give any examples of
> >> successful optional web features that exist today?
> >>
> >
> > I'd suggest Javascript and Images, but you've rejected them because you
> > don't think they are examples of successful optional features (meaning
> that
> > browsers that don't support them are not equally compatible with all web
> > content) - and yet most browsers do support turning them off so there
> must
> > be some value for a subset of users.
>
> Have you ever tried to browse the web with javascript or images turned
> off? It's not an experience most users would say is useful.
>
> > I think there are some potentially conflicting goals for any of the HTML
> > APIs:
> > 1) Providing a single lowest-common-denominator API that we can support
> on
> > every single platform to provide the maximum amount of compatibility. For
> > notifications, pretty much every capable platform can display an icon and
> a
> > single line of text, so if we wanted to be pedantic we could make that
> our
> > API, but the currently proposed "icon + header + body" text is probably
> more
> > reasonable.
> > 2) Providing an API that is flexible enough to take advantage of the
> > capabilities of more advanced platforms.
> > 3) Future proofing the API (as capabilities of platforms grow, the API
> can
> > continue to support them)
>
> I disagree with 2 and 3 being goals. Taking advantage of platform
> capabilities isn't a goal in and of itself, it's just a mean.
> Providing a better user experience is the goal IMHO.
>
> If users that want to use Growl can't get their browser notifications
> through growl because the browser was forced to use some other
> mechanism to implement HTML notifications, then we haven't improved
> that users experience. Even worse, if they don't get *any*
> notifications because the website didn't provide a non-html
> equivalent, then we certainly haven't helped that user.
>

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

I really think this is a silly rathole that we've gotten ourselves into
here.  I'm sure that we can come up with a technical solution that
gracefully degrades for those users who want html notifications to integrate
with growl/etc but provides a robust experience for the rest of users.

J
Received on Thursday, 11 February 2010 14:08:00 GMT

This archive was generated by hypermail 2.3.1 : Tuesday, 26 March 2013 18:49:37 GMT