[Klathmon]

It's not about being surprised, it's about not reading the dialogue at all.

I make a barcode scanning app in the browser. Our users know that the app scans barcodes using the camera, they receive training on the app before using it, and yet about ~15%~ (Edit: it's closer to 8% now) of our users click "no" when asked to allow camera permissions to scan barcodes. It was causing so many support calls that we ended up doing a 2-stage permissions prompt. First we display a javascript dialog telling the user that they need to click "yes" for the app to work, then we show the native permissions request after they have clicked yes, because if the user selects "no" the first time, we can't ask again, and 99% of users don't know how to go into the settings and re-enable it (hell, even I don't know where it is from memory, and would need to hunt around to find where it is)

And it doesn't create an incentive not to ask at all. At worst the website is where they would be if they didn't ask, at best they are able to display notifications, play audio, play video, get location, etc...

It's a no-lose situation in 99% of cases for the website owner, unless they actually really need that permission to function, then they have a LOT to lose. It's a situation where the incentives are misaligned terribly.

And don't get me wrong, i'm also very VERY happy that I can prevent notifications or location access, but I also think that more could be done to prevent spamming of the permissions prompt itself.

[ameister14]

Yeah, clearly they read the dialogue if by adding more dialogue you change their action.

The problem may have been that simply asking for permission to use the camera in general and not stating when and how you would use that permission, people thought about the fact that they didn't really want to give the app blanket permission to use their camera.

The solution to that problem is to point out what you are using it for and tell them it is necessary, which is what you did.

[Klathmon]

>Yeah, clearly they read the dialogue if by adding more dialogue you change their action.

No, because with our first-stage dialog we can just keep showing it until they click yes, but with the native dialog we only get one chance, and if they click "no" we might not even get a callback that they clicked anything at all on some browsers (which I honestly kind of like from a privacy standpoint).

But to be clear, i'm not happy with the 2-stage dialog. It feels condescending to ask for permission to ask, and for non-business applications it just slows down the "thing" that you are asking for permission for even more. But thus far it's the only thing that has consistently worked for us.

>The problem may have been that simply asking for permission to use the camera in general and not stating when and how you would use that permission

Our app is a business-oriented application that is running on dedicated company-owned phones in most cases. Users are trained on how to use it, how to set it up, how to create accounts and more.

About 8% of our new users still click no on average 2-3 times spending less than a second on the dialog according to some analytics I have on it. It dropped from 15% with the change from 1-step to 2-step permissions, but that's still a LOT of users that instinctively click "no".

[ameister14]

So are you saying that you don't allow them to say no to the first-stage, and have it pop up immediately after, or that you pop it up every time they open the app?

I don't think it's innately condescending to ask someone for permission and outline exactly what you need the permission for, but I don't know the copy you are using.

I know that in context it makes sense, but people read things and don't think about them in larger context all the time. They think about them individually - do I want to give this thing permission to use my camera? No. Do I want to give it permission to use my camera so that it can do this thing I want it to do? Yes.

That's why outlining the purpose as in the second case makes it more likely for people to say yes.

Have you tried putting the reasoning on the second dialogue or is this a native one that is uneditable? You might be right if they are spending less than a second, but I've found with websites that a surprising number of people read everything. It'd be an interesting test if it's possible.

[Klathmon]

>So are you saying that you don't allow them to say no to the first-stage, and have it pop up immediately after, or that you pop it up every time they open the app?

Basically we lock them from going further in the app by repeatedly showing the dialog immediately after a "no" answer, because at that point they need to scan barcodes and if they can't then the entire app is completely useless anyway.

>I don't think it's innately condescending to ask someone for permission and outline exactly what you need the permission for, but I don't know the copy you are using.

It just feels like it to me. We found it difficult to explain how you MUST say "yes" to the next prompt, it's for barcode scanning (which explaining this alone feels condescending, the app is called "x barcode scanning" FFS), the app cannot function without it. Just asking to ask alone feels wrong. I want my applications to be as easy to use and straightforward as possible, and doing stuff "automatically" rather than making the user manually do it is like 40% of my job, so it feels really wrong when I need to make it worse in that way.

>Have you tried putting the reasoning on the second dialogue or is this a native one that is uneditable?

Yeah it's the native one, so you can't change what it says.

It's tough, i can understand not wanting to allow websites to spam notifications constantly, but the "you only get one chance" really sucks.