[webkit-dev] Notifications API

[David Levin]

On Tue, May 26, 2009 at 8:57 PM, Sam Weinig <sam.weinig at gmail.com> wrote:

>
>
> 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?
>

I'm not in the chrome ux discussion... but I'll add my 2 cents.

If you think of the clients of webkit that expose it as a browser to third
parties.  Here's a few that come to mind.

   - Safari on OSX
   - Dashboard on OSX
   - Safari on iPhone
   - The browser on Andriod
   - Google Chrome

When I think of Andriod, I know that installing apps gives me a list of
permissions being requested.  I would expect that any web item that wanted
permissions would have to be similar on that platform.

For iPhone, I don't know what the install looks like (sorry).

For dashboard, it just asks if you want to install it.

For chrome, it is tbd.

It looks like there is a mix of models in this small set.  An internal api
which is granular (areNotificationsAllowed(securityOrigin)) can support a
blanket uber permission as well so it seems like that is the more flexible
model which would cover the needs of the many webkit hosts better.




> -Sam
>
>
> _______________________________________________
> webkit-dev mailing list
> webkit-dev at lists.webkit.org
> http://lists.webkit.org/mailman/listinfo.cgi/webkit-dev
>
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.webkit.org/pipermail/webkit-dev/attachments/20090526/4ec47c10/attachment.html>