Making Better Permission Requests

This is a minor piece on UX and asking for permission for notifications, the microphone or other things on the web. I consider it the bare minimum that someone should implement when requesting permissions.

You’ve probably seen it; you go on a website and before you can even browse the content you’re bombarded with different requests. This news site wants to send you notifications. It also needs to inform you that it has cookies and uses them appropriately. Perhaps its of vital importance that you know that its GDPR compliant, also we never, ever use your data inappropriately, we promise.*

I considered putting in a gif of being bombarded by prompts, but this frankly seemed more pleasing. (Designed by lifeforstock / Freepik)

Popup spam for the modern age

Do you look at these? Do you read them? Most likely not. With some perhaps its not within the developer’s control — we’re obliged to ask about Cookies and Data compliance (although I don’t know if it has to be so obnoxious), but with other things we’ve made the web worse. Its spam. And we shouldn’t add to it.

The context for this is our new Web API. At Intrasonics we’ve developed an SDK that listens for encoded media and allows a developer to create interactive content online, implemented in Javascript.

That’s great! However, to do this we need to explicitly ask for permission for the microphone.

If we do this without thinking and naively initialise the SDK once the website has loaded fully, the user will load the page and be immediately be prompted to allow access to the microphone. This prompt is handled by the browser.

Two problems:

1) As mentioned before it immediately fires the prompt which is annoying, especially if several such things are fired.

2) It does not give any context as to why you need to use the microphone.

This is bad, not just because its obnoxious but because we need to be trusted in our microphone use. Users are rightly more concerned about privacy. A website that asks, without any justification for microphone or webcam access will be rightly judged with suspicion.

Compounding this, changing these permissions on a mobile phone is not particularly simple. Desktop browsers have gotten better at making this easy to change, but once a user has denied permission once on a mobile, you’re probably not going to get them to change their mind, purely because it’s not convenient (even having a few additional steps in a tucked away menu can make this inconvenient and by then you’ve lost your user).

Context and Control are King

So what do you do? Simply put you need to provide context and justification for what you’re doing. Making a permission request is best saved for those times when a user can actually evaluate what you’re asking of them and make an informed decision, and not simply confirm or deny out of frustration.

Permission requests for access to the microphone or the webcam are things that are handled by the browser. They trigger automatically as soon you attempt to use the functionality in question. In our case, attempting to use the microphone will prompt the user for permission.

Ideally, you stagger when the permission is asked for with an explicit button, where that button starts the functionality in question. You give additional text explaining what you intend to do with the functionality you’re asking for.

For Intrasonics, we need to explain that the microphone is used to enable interactivity:

A bit of explanation and a start button. Simple.

I’d suggest against putting this in a modal that pops up once the site has loaded, because while you’re providing more context, you’re still obnoxiously bombarding a user with things at the beginning of their experience.

The permissions API has been defined so that a website cannot repeatedly ask for access for the same thing once it has been denied. This means there isn’t a controllable mechanism to continuously trigger prompts. This is fine if the prompt being triggered is tucked away behind a button or some other controllable mechanism. However, some prompts, such as the one to install a PWA, trigger immediately.

To deal with these you defer when the prompt shows. You may need to use preventDefault() to cover Chrome 67 and earlier versions from triggering automatically.

Putting some contextual information, letting the user control when to receive the prompt — it makes a lot of difference to the User’s experience.

*So long as you don’t look too closely at the terms and conditions…