Re: [WebNotifications] omnibus feedback reply, new draft

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

-atw