Re: Notifications

On Fri, Feb 5, 2010 at 10:36 AM, Anne van Kesteren <annevk@opera.com> wrote:

> On Fri, 05 Feb 2010 19:19:24 +0100, Drew Wilson <atwilson@google.com>
> wrote:
>
>> I've thought about this some more, and I'm not at all convinced that
>> in-tab notification support is the right way to go. It seems that in-tab
>> notifications are a solved problem already (in a few lines of code an app
>> can create a floating div with whatever content it desires) with the
>> advantage that the web app can display that notification in a way that is
>> consistent with the UI in the site (set the notification so as not to
>> interfere with site content, appropriately style the notification so it
>> fits in with the look of the site, etc). I don't quite understand what
>> browser-provided in-tab notifications would provide that would be an
>> improvement over existing functionality.
>>
>
> Allowing them to be displayed there and not having an active permission
> dialog would make it totally opaque to the application whether or not it can
> do system-wide notifications. This seems better for privacy and I also think
> it makes it less likely the user opts into something the user does not want.
>
> I'm not entirely convinced that opacity here is a good thing, especially
since the alternative for apps that want this behavior would be:

if (notifications.checkPermission() == PERMISSION_GRANTED)
  notifications.createNotification(icon, title, body);
else
  jqueryUI.displayInTabNotification(icon, title, body);

Or something similar.

For an example, there is no value for something like a Calendar app to
display in-tab event reminders. The whole point of event reminders is to
notify the user of an upcoming event in a way that is visible when they are
doing other tasks, but in a less-invasive way than an alert() but in-tab
notifications would not provide this.

Opacity here would work against the application's ability to provide the
desired user flow which is to drive the user towards granting desktop
notification permissions. I would rather have the application know that it
can't display desktop notifications rather than silently defaulting to an
unwanted user experience.

I guess in summary, the main goal of having a notification API is to provide
a way for web apps to display notifications to the user when the associated
tab is not active. The application already has ways to display notifications
to the user when the tab *is* active. It seems like the only reason to
default to in-tab notifications is to jump through hoops to avoid an active
permission grant UI (i.e. to have in-tab notifications with passive UI for
making them out-of-tab) - no application actually wants in-tab notification
functionality since they already have that.

So I'm not convinced that avoiding an active permission grant should be a
goal of this API, especially since there are a number of other APIs which
implicitly have active permission grant UIs (geolocation, storage quota,
etc). If a UA wants to avoid displaying active permission grants there are
other ways for them to do it without in-tab notifications (they could
display a "pending notification" icon in the tab chrome, etc) - perhaps
removing requestPermission() would provide the flexibility to allow UAs to
do this if that's what they want?


>
>
>  I'm not convinced we need a permission API and would therefore rather
>>> leave it out to see if we can do without. We do not have an API like this
>>> anymore else.
>>>
>>
>> We do have permissions UI in other parts of HTML5 (geolocation, for
>> example). The difference here is that applications generally would like
>> the user to make a permission grant *before* they actually want to display a
>> notification - actually waiting until it's time to display a calendar
>> reminder before the user is prompted for permission means that the user is
>> likely to miss that first calendar event.
>>
>> One possible alternative to an explicit requestPermission() API would be
>> to instead just have the browser display permissions UI the first time the
>> user calls createNotification(). An application that wants to get permission
>> in advance could just call createNotification(), but then never actually
>> call show() (or, perhaps they could just display a confirmation notification
>> like "Desktop notifications are now enabled for FooMail").
>>
>
> This sounds somewhat better to me.
>
>
>
>  As someone who has
>> integrated notifications into a web app, I have to say that I found the
>> explicit API useful, but I'm not currently using the callback for
>> requestPermission() so an alternate API could work so long as there was
>> some way to initiate a permission grant without actually displaying a
>> notification.
>>
>
> I'm still a little bit afraid of what's going to happen when we get many of
> these APIs that need some kind of user permission. It's going to be too
> confusing I think.
>
>
> I agree and there have been similar concerns expressed about permissions
explosions elsewhere. I suspect the HTML standards community will need to
look at how to bulk-manage permissions at some point. I believe that some
implementors are experimenting in this area as well.


>
> --
> Anne van Kesteren
> http://annevankesteren.nl/
>