Re: Notifications

I can't help but think the Growl issue is way overblown. I am the user who
uses Growl and also a GoogleTalkLabsEdition for Mac that pop ups nice
notifications about upcoming meetings, email and chat. Growl is connected to
IRC and something else (don't even remember). They both use top-right corner
of the screen to pop up their balloons and co-exist just fine. I don't
remember having them ever overlap (or that being a problem). And snooze on
meeting popups is great.

As for less-capable devices like phones, a few years ago even having a real
HTML displayed on them was out of the question. There are still successful
companies out there that provide a service of translating any given HTML
page into dumbed-down version for a particular cellphone model - for a fee
per-translation. Sites that are serious about mobile internet on wide
variety of currently-deployed devices often use this stuff to serve pages,
it's easier then to build up expertise on all the variants of crippled
'browsers' out there. The progress in this field in a last few years is
phenomenal and fast. It wouldn't be surprising if 'regular' HTML
notifications were totally possible on those devices by the time the spec
and implementations gain some maturity. There is no reason why user of a
cell phone can not have a nice meeting reminder with a snooze button, or a
chat invite with 'reply now', without the need for a native app.

Dmitry

On Thu, Feb 11, 2010 at 6:07 AM, Jeremy Orlow <jorlow@chromium.org> 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
>