Re: Allow ... centralized dialog up front

I do not particularly care what research you will find to support the
UI-flow that the existence of a requestAPIs API will eventually give rise
to. I do say simply this, the research presented, and pretty much common
sense as well easily shows that the current course is foolhardy and ungainy
on both user and developer.


On Sat, Feb 2, 2013 at 3:37 AM, Charles McCathie Nevile <
chaals@yandex-team.ru> wrote:

> **
> On Fri, 01 Feb 2013 15:29:16 +0100, Florian Bösch <pyalot@gmail.com>
> wrote:
>
> 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
>
>
> Sure. And that is valuable in principle.
>
> - 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)
>
>
> I don't think so. As Adrienne said, as I have experienced myself, without
> understanding what the permission is for trust can be reduced as easily as
> increased.
>
>  - 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.)
>
> These are not so clear. As a user, I *do* want to have applications to
> which I will give, and revoke, at my discretion, certain rights. Twitter
> leaps to mind as something that wants access to geolocation, something I
> occasionally grant. for specific requests but blanket refuse in general.
> The hypothetical example you offer is something that in general it seems
> people are happy to offer to a user who has turned off both capabilities.
>
> I think the ability for a page to declare permission requests in a
> standard way, the same as applications and extensions, is worth pursuing,
> because there are now a number of vendors using stuff that seems to only
> differ by syntax.
>
> The user agent presentation is a more complex question. I believe there is
> more research done and being done than you seem to credit, and as Hallvord
> said, I think this is an area where users evolve too.
>
> For the reasons outlined already in the thread I don't think an
> Android-style "here are all the requests" is as good a solution in practice
> as it seems, and there is a need for continued research as well as
> implementations we can test.
>
> cheers
>
> Chaals
>
>
>
>
>
> 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
>>
>
>
>
>
> --
> Charles McCathie Nevile - Consultant (web standards) CTO Office, Yandex
> chaals@yandex-team.ru Find more at http://yandex.com
>