On Tue, May 26, 2009 at 8:57 PM, Sam Weinig <sam.wei...@gmail.com> wrote:
> > > On Tue, May 26, 2009 at 5:04 PM, Drew Wilson <atwil...@google.com> wrote: > >> >> >> On Tue, May 26, 2009 at 4:43 PM, Sam Weinig <sam.wei...@gmail.com> wrote: >> >>> >>> >>> On Tue, May 26, 2009 at 4:20 PM, Drew Wilson <atwil...@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@lists.webkit.org > http://lists.webkit.org/mailman/listinfo.cgi/webkit-dev > >
_______________________________________________ webkit-dev mailing list webkit-dev@lists.webkit.org http://lists.webkit.org/mailman/listinfo.cgi/webkit-dev
