Re: Allow ... centralized dialog up front

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.

With that being said, I agree that it's a bad idea to constantly barrage
the user with pop-ups, particularly identical-looking generic pop-ups. If
different permission dialogs can be made visually distinct from each other
and engaging in some way, some of the concerns of having a billion
identical "Do you want to grant X?" would go away.

On Fri, Feb 1, 2013 at 5:37 AM, Florian Bösch <pyalot@gmail.com> wrote:

> On Fri, Feb 1, 2013 at 2:29 PM, Charles McCathie Nevile <
> chaals@yandex-team.ru> wrote:
>
>> **
>> Right now vendors look at a page and can often heurisitically generate a
>> permission request that is either consolidated, or depends on actual usage.
>>
> A heuristic is fine but, it only goes so far. First of all the incidence
> of APIs with restricted use is climbing (due to the ever present fetish of
> preventing fingerprinting and other security hazards). And second, the
> heuristic can only capture APIs that would be simultaneously initiated
> (like pointerlock and fullscreen). Sometimes the necessity of an API (clear
> at page start) and the actual use (considerably later) do give a heuristic
> no chance.
>
>
>>  One of the patterns clear with Android apps (which use a central
>> dialogue like you are proposing) is applications that request a massive
>> number of permissions that are irrelevant to their main purpose, and which
>> effectively train users to ignore the whole question and click yes. :(
>>
> And popups solve that problem how? What exactly makes a user less inclined
> to just madly mash "yes yes yes" to a series of poups?
>