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? -Sam
_______________________________________________ webkit-dev mailing list webkit-dev@lists.webkit.org http://lists.webkit.org/mailman/listinfo.cgi/webkit-dev