On Fri, Feb 1, 2013 at 3:02 PM, Adrienne Porter Felt <adriennefelt@gmail.com > wrote: > My user research on Android found that people have a hard time connecting > upfront permission requests to the application feature that needs the > permission. This meant that people have no real basis by which to allow or > deny the request, except for their own supposition. IMO, this implies that > the better plan is to temporally tie the permission request to the feature > so that the user can connect the two. > In some circumstances this works, in others, it does not. Consider that not every capability has a UI-flow, and that some UI flows are fairly obscure. More often than not a page will initiate a flurry of permission dialogs up front to get it out of the way. Some of the UI-flows to use a capability happen deep inside an application activity and can be severely distracting, or crippling to the application. If a developer wants to use the blow-by-blow popup dialogs, he can still do so by simply not calling an API to get done with the business up front. But for those who know their application will not work without features X, Y, Z, A, B and C there is no point. They already know their app is not going to work. They already know they would have to pester the user 6 times with successive popups. They already know that they will severely distract the user or cripple themselves by making the user click trough 6 popups whenver it becomes necessary. They already know that 80% of their users will quit their page after the 3rd popup asking random questions. Why should there not be a way to prevent all that from happening?
Received on Friday, 1 February 2013 14:16:31 UTC