Re: [WebNotifications] omnibus feedback reply, new draft

On Thu, Apr 22, 2010 at 1:05 PM, Drew Wilson <atwilson@google.com> wrote:
> On Thu, Apr 22, 2010 at 12:28 PM, Tab Atkins Jr. <jackalmage@gmail.com>
> wrote:
>>
>> I'm happy about this, as it also opens up a number of other use-cases
>> for free.  For example, a webapp may want to use notifications for
>> events that are "bursty" and can sometimes come in fast enough that it
>> would be annoying to pop a notification for each one.  Integrating the
>> time into the replaceId, perhaps truncated to every 10 seconds or
>> every minute as appropriate for the app, provides virtually free
>> assurance that the user won't accidentally be swamped with alerts, a
>> task which otherwise requires manual tracking of the "last update"
>> time.
>>
>> ~TJ
>>
>
> As another data point from an app developer, I am in the process of adding
> notification functionality to gmail (staggered notifications of new emails,
> which may arrive in batches), using the current experimental
> webkitNotifications API in Chrome.
>
> I'm manually mimicking the replaceId functionality (by tracking the current
> notification and closing it before opening a new mail notification). If the
> user gets several emails at once, the behavior I'm trying to achieve is:
>
> 1) Only one email notification will ever be displayed on screen at once
>
> 2) Each individual email notification is displayed for some reasonable
> period of time (a few seconds) so the user has a chance to process it before
> it is replaced by the next one
>
> 3) Manually dismissing a notification displays the next one in the queue (or
> maybe clears the queue - I haven't decided yet)
>
> I'm writing my own queueing logic in gmail to achieve this as functionality
> like this isn't provided by the API (and I don't think it should be since
> it's easy enough for applications to do this themselves).
>
> It sounds like Tab is suggesting different behavior than my #2 above - by
> integrating a granular timestamp into the replace ID, an application that
> got a flood of events would end up rapidly replacing notifications, leaving
> the most recent one visible (this is probably desirable behavior for some
> applications, where subsequent notifications are intended to obsolete
> previous ones).

Indeed, I'm suggesting what you say, replacing rather than queuing,
and I think it's what John is suggesting as well as the behavior of
notifications with identical replaceIds.

Queueing is interesting and sounds useful.  This might be useful
enough to be the default behavior.  Alternately, it could just be the
behavior of the actual notification system.

~TJ

Received on Thursday, 22 April 2010 20:19:58 UTC