[webkit-dev] Notifications API

Sam Weinig sam.weinig at gmail.com
Tue May 26 20:57:31 PDT 2009

On Tue, May 26, 2009 at 5:04 PM, Drew Wilson <atwilson at google.com> wrote:

> On Tue, May 26, 2009 at 4:43 PM, Sam Weinig <sam.weinig at gmail.com> wrote:
>> On Tue, May 26, 2009 at 4:20 PM, Drew Wilson <atwilson at google.com> wrote:
>>> To give the list some insight into the discussions we've had with the
>>> Chrome UX folks:
>>> 1) We want to associate some set of enhanced permissions with a given
>>> origin (e.g. https://mail.yahoo.com), and we want the user to be
>>> presented with a single "do you want to grant permissions to
>>> https://mail.yahoo.com" dialog, rather peppering the user with a bunch
>>> of individual permission dialogs for each feature ("Yes, please allow
>>> mail.yahoo.com to use 100MB of local storage", "Yes, allow
>>> mail.yahoo.com to display notifications", "Yes, allow mail.yahoo.com to
>>> run in the background").
>> It seems like a bad idea to give all or nothing trust, and not along the
>> lines of how APIs have managed choices in the past (quotas are increased
>> when the limit is hit).  I am not even sure how a UA would present such a
>> choice to a user in a meaningful manner.  I think a workflow such as the one
>> quoted above by Maciej is a good direction, that gives a user a better
>> chance of understanding the choice they are making.
> I thought that maciej suggested the same thing we suggested - an explicit
> javascript API to request permissions. In our case, we want to ask for
> permissions in bulk up front, rather than peppering the user with
> permissions on an ad-hoc basis - in your example (prompting for more quota
> when the quota is hit) will break things like background sync in persistent
> workers, as the user may not be around when that background sync occurs.

It is similar, but I am concerned with how to present a dialog to a user
that states that by clicking "grant" they are completely trusting you.

>>> 2) We want the timing of the permission grant UI to be under application
>>> control (as part of some kind of application user flow). So just visiting
>>> mail.yahoo.com would not suddenly popup an unexpected dialog - instead
>>> the application would have some UI along the lines of "Turn on desktop
>>> notifications" which would drive some app-specific UI flow, a part of which
>>> would involve the permission grant.
>> Can you please elaborate on this, perhaps with a concrete example.
> One example of a similar flow is Gmail Offline feature, where the user
> clicks on a "Offline" link, which drives the user through some
> app-controlled UI, culminating in a Gears permission-grant dialog. Here's
> another example:
> Remember The Milk rolls out a new feature: desktop reminder notifications.
> This is implemented by having a persistent worker which tracks changes on
> the server, determines when it's appropriate to display a reminder for a
> task, and displays a desktop notification.
> When a user logs into Remember The Milk, he sees a link: "New feature:
> desktop reminders!". He clicks on this link, and is taken to an HTML page in
> Remember The Milk which describes what the feature is and asks the user if
> he wants to turn on these reminders. The application invokes getTrusted() to
> see if the domain is already trusted - if it isn't, then the UI may include
> some language to prepare the user for the upcoming permission grant dialog
> by telling him what to expect.
> When the user clicks "yes, turn on this feature", the application calls
> requestTrust() - this brings up the UserAgent-specific permission grant
> dialog. When the user clicks the appropriate UI to grant this permission,
> then the application has the ability to create persistent workers and
> notifications (if we don't allow this kind of bulk permission grant, then
> the user is subjected to multiple dialogs for each feature - persistent
> workers and notifications - which is a crummy user experience).

I would argue it is much more confusing to a user to have to grant complete
trust (for some undetermined list of things to trust a origin with).  Should
that include geolocation data?  I don't really want Remember The Milk to
know where I am, does that mean I can't have notifications?  How can a user
make an informed decision?

-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.webkit.org/pipermail/webkit-dev/attachments/20090526/b0532b23/attachment.html>

More information about the webkit-dev mailing list