Re: static permission functions on Notification (was Feedback from Safari on Web Notifications)

On Sat, Mar 24, 2012 at 12:38 AM, Rich Tibbett <rich.tibbett@gmail.com>wrote:

> On Thu, Mar 15, 2012 at 2:46 AM, Jon Lee <jonlee@apple.com> wrote:
> > There are currently three different permissioning models used by Web
> APIs:
> > implicit (drag-and-drop), on-demand (geolocation), and explicitly
> requested
> > (notifications). Explicit permissioning is the least desirable of these
> > three models, and we should discourage it whenever possible.
>

BTW, is the objection to explicit permissioning solely around the existence
of a "grantPermission()" API? Let's say we had some other sort of
permission model (e.g. on-demand, triggered by the display of a superfluous
notification generated when a page first loads) - we'd still want to be
able to query the state of the current permission so we could avoid
generating a superfluous notification. Would having the ability to query
for a prior grant of a permission be just as objectionable as the ability
to explicitly request permission?


> I'd argue there is a fourth permissioning model: the 'in-flow implicit
> authorisation' you provide when you using <input type=file>. The file
> picker is just a part of the work flow of uploading a file and isn't
> even considered an authorisation dialog. This is an excellent design
> IMO and its subtly is often overlooked as an excellent workflow-based
> permissioning mechanism.
>

This is a great point. I don't necessarily think this model is a good fit
for notifications (see below) but I agree that for some cases it provides a
very natural permissioning flow.


>
> > By only providing a generic API for explicit permissioning, we implicitly
> > elevate that model to be the preferred approach for the whole Web
> platform.
> > Thus far, the lack of a common API for *any* of the Web's permissioning
> > models has forced spec authors to think hard about how permissioning
> should
> > work in each case.
>
> I've been thinking a lot about if we could enable an 'in-flow'
> authorisations for Web Notifications. Any web page is free to call the
> Web Notification method and notifications appear tab-modal - that is,
> they appear automatically but only in the originating tab (or across
> all currently open tabs at a UA level pending more UX
> experimentation). The user is then able to simply elevate that
> notification to the system level via a native control available in
> each displayed tab-modal notification which then enables subsequent
> notifications to appear at the system level. In this model each
> notification gets displayed but the user gets to decide what they want
> or need to notify them at a system level.
>
> Those settings would likely be maintained until the user clears their
> private data at which point we would forget the authorized web
> notifications and/or the user could drill in to individual
> notification elevation permissions via an in-UA preferences panel.
>

I can only speak to the gmail use case here, but we found that it's a poor
user experience in general to display things like chat and new mail
notifications to the user while gmail was the focused tab, since there is
already affordance for exposing these events to the user within the
existing UI - additional notifications only get in the way and annoy the
user. The whole point of using notifications is specifically so our app can
notify the user when they are not the focused window.

The flow you describe above would require us to display in-tab
notifications to the user when gmail is the focused window, which IMO is no
better than displaying an infobar - if anything, it's worse, because at
least in the case of gmail I am able to display an infobar immediately upon
the user enabling the feature, rather than waiting for the next new mail to
arrive (or, worse, displaying a notification for no other purpose than to
display the text "click the little arrow button to pop out gmail
notifications").


> > In another part of this thread, you said—and I agree—that providing the
> > pattern to follow for explicit permissions is vitally important. We
> should
> > consider writing a Note discussing the different permissioning models of
> Web
> > APIs and the trade-offs among them. Spec authors could then refer to this
> > Note when designing features requiring permissioning.
>
> We discussed the need to document some best practices wrt to
> permissioning systems for the web at our recent Device APIs F2F
> meeting. We've come a long way on this topic and there are a lot of
> lessons learned, since we've made all of these mistakes (and more) in
> that group from a lot of APIs we've been experimenting with over the
> last couple of years.
>
> My hope is that this is an action that the W3C DAP would be able to
> pick up and I'm sure they'd be interested to know that the Web
> Notifications group is requesting some input here.
>
> HTH, Rich
>
>