[notifications] what are the requirements? [Was: Re: Notifications]

Hi All,

After seeing Jeremy's response below, I wondered about this spec's  
requirements so I scanned the latest ED and did not notice any:

  http://dev.w3.org/2006/webapi/WebNotifications/publish/

Perhaps it would be helpful to get agreement on the use cases and  
requirements now. Agreed requirements are needed to advance the  
document to Last Call Working Draft.

-Art Barstow

On Feb 11, 2010, at 9:07 AM, ext Jeremy Orlow wrote:

> 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 17:35:39 UTC