Re: Allow ... centralized dialog up front

Repetitive permission dialog popups at random UI-flows will not solve the
permission fatique any more than a centralized one does. However a
centralized permission dialog will solve the following things fairly
effectively:

- repeated popup fatique
- extension of trust towards a site regardless of what they ask for (do I
trust that Indie game developer? Yes! Do I trust google? No! or vice versa)
- make it easy for developers not to add UI-flows into their application
leading to things the user didn't want to give (Do we want a menu entry
"save to local storage" if the user checked off the box to allow local
storage? I think not.)
- make it easy for developers to not waste users time by pretending to have
a working application, which requires things the user didn't want to give.
(Do we really want to offer our geolocated, web-camera using chat app to
users who didn't want to give permission to to either? I think not. Do we
want to make him find that out after he's been entering our UI-flow and
been pressing buttons 5 minutes later? I think not.)




On Fri, Feb 1, 2013 at 3:22 PM, Charles McCathie Nevile <
chaals@yandex-team.ru> wrote:

> **
> On Fri, 01 Feb 2013 15:16:04 +0100, Florian Bösch <pyalot@gmail.com>
> wrote:
>
> 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?
>
> The stock answer (and I think it is too glib, and we should be thinking
> harder about this) is
>
> "because those who just want the user to agree to give away their security
> and privacy will be able to rely on permission fatigue. Which they can
> create, by getting sufficient users to download versions of popular stuff
> that requests unreasonably complicated permissions. So consolidating
> everything will make the system effectively useless".
>
> cheers
>
>
> Chaals
>
>
> --
> Charles McCathie Nevile - Consultant (web standards) CTO Office, Yandex
> chaals@yandex-team.ru Find more at http://yandex.com
>