Re: Notifications

On Thu, Feb 11, 2010 at 7:24 AM, Jonas Sicking <> wrote:

> On Wed, Feb 10, 2010 at 6:29 PM, Drew Wilson <> wrote:
> >
> > On Wed, Feb 10, 2010 at 5:49 PM, Jonas Sicking <> 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

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.


Received on Thursday, 11 February 2010 14:08:00 UTC