‘www.buynow.com wants to use your device’s location’ Block is what comes instantly to mind, right? Yes, some people might allow, but again there are a host of factors involved. This is just a glimpse of the permission request on the web.
But the story is same everywhere- users view permission requests as a nuisance. Although Google revamped its permissions modal design with Chrome 63, still the web community hasn’t paid much heed to it. We are in dire need of making changes in the way Chrome asks for permission from viewers for sensitive details like a phone’s location, access to a camera, or control to send push notifications.
In fact, stats reveal that 90% of Chrome permission prompts are either rejected or ignored. That means users aren’t making a decision if they want to share their location or not. They simply resort to X to close the window or click elsewhere on the screen to dismiss the modal.
Enhancing user experience isn’t a challenge these days. We can create an edge through powerful browser APIs to track users’ location, send them notifications regardless of the site being opened or not, engage with MIDI devihttp://www.thinkinnovationsconsultancy.com/thinkcms/blog/posts/edit/11/#ces and various other means. But, honestly, when it comes to permissions, we need to buck up. Those pesky pages which ask you to install their mobile apps are rated really high on the annoyance scale. It is high time we make some changes to our website as it will ultimately lead to terrible UX. Users turning a blind eye to prompts can pose two issues-
- By not making a choice about the prompt, the user will be disturbed time and again by the website.
- If people opt for blocking requests, website authors might modify how they ask for permission. As it is human nature to ignore permissions, website authors are least particular when it comes to prompts. Surprisingly, many websites ask for encroaching permissions on the first-page load itself.
Remember APIs aren’t the root cause; it is our execution that sucks! Let’s learn how we can improve and take a leap-
The Need
Yes, UX is of utmost priority but asking someone immediately about their location creates a negative impression and is a big turn off. A permission request bothers your user and he, in turn, doubts the credibility of your site. From authentic content to conversions, it is all a game of trust on the web.
Prompts aren’t helping you to achieve anything as it is users are rejecting them. Actually, they are doing more harm than good. For instance, you might want to send notifications to lower down drop-offs and make them come back to your site. But it could make users flee even before they read a single article. Further, Chrome 63 sets the trap. Requests are posted like models before the content and users can’t discard the prompt without making a choice.
This, as a result, also lessens the number of repeat requests as people can no longer ignore. Thus it motivates the sites to enhance their UX. Users will not tolerate websites enforcing such a modal on top of HTML modals, banners and irritating ads displayed on the page on load. So, what will be browsers course of action if we don’t mend our ways? They will hinder access to these APIs by default. Users would then have to approve by going to their browser settings.
If browsers want to give advantage they might display a small icon nearby which would able the prompt on selection. Disabling by default option would be an extreme measure, nevertheless, Google has removed the notification center stating lack of usage and it would definitely please people.
Gradual Approach
Don’t request access to APIs mindlessly. If you are experimenting with your personal site or creating an API demo, it’s okay, but if you have users, have some mercy. Step into your user’s shoes. If you ask them straight away because it is crucial for your app, re-consider your motives. Will your site or app come to a halt without it?
Absolutely not. Or else get ready to block people those who react negatively to the prompts from using your app. If you want access urgently, go for the context. Look at the door. Be clear that the user knows what your site or app is about. How will they be familiar if they are immediately attacked with a request to track their location? Give some value points to the user. Work on the trust factor. Ask only when there is an actual need.
Avoid asking them their location until they approach your store locator. Enquire if they would like to get notifications of latest articles only after users have gone through a couple of write-ups. Innovations are not meant to be misused. If the user’s browser supports a unique feature that doesn’t imply you should jump into it immediately. Experiences can’t be mastered in a day. It is a process and must happen gradually.
Double Request Game
Okay, if you are adamant to disrupt the user then at least make sure that the rate of acceptance increases. There is only one chance. Remember ‘Block’ is something that is permanent in Google Chrome unless the user decides and manually adjusts it in your Chrome’s settings. Other browsers contain ‘remember this choice’ option which leads on the same path.
This is where the double request feature from the mobile world comes handy. Give a glimpse of fake UI i.e. HTML. If the user shows some approval then put forward the native permissions request. If it’s dismissed or ignored, then leave it. There isn’t any condition on the number of attempts, so you can ask the users again whenever you feel like. Act vigilant, don’t annoy the user. Notice their reaction again after some visits or create a smart algorithm. Out of context requests have 40% fewer chances of being accepted. While using this fake prompt, tell why the permission is important, how the user will gain from it, what will be the effects if they accept it, etc.
If you want to prompt with notifications, the notifications will be regarding what? What will be the frequency? Here a good example can be new Google Calendar’s fake notification request. Till now, you were looking at a fake popup but still, a better way would be to hide the feature in your app’s settings. Permitting the user to choose like that surely guarantees a high success rate.
Permissions API Advantage
One issue with using fake UI is the confusion of whether or not the user has accepted the permission. It is not reasonable to show the popup every time and if it depends on app setting, make sure it looks enabled. Some APIs give a solution to this problem. Notifications, for instance; notification. permission will either be labeled granted, denied or prompt.
This differs API to API and even there are some APIs in which this feature is totally absent. Like in the case of geolocation API; we have no method to verify if the user has previously approved access to their location without sending the request again. This is the time where Permissions API comes into use. It enables you to query the status of any permission with the help of a single interface, including the geolocation API.
What is tough is that the Permissions API is at present only enabled in Chrome (43+) and Firefox (46+). When a request is allowed or denied you can save that information in localStorage or wherever you want for future confirmation. Then you can verify the permission’s status instead of querying it up using the Permissions API. The Mozilla Developer Network also provides such ways for requesting and canceling permissions. No browser is compatible with the former and the latter is only workable in Firefox (47+).
Reward the User
To motivate the user to exert their choice, you could tell them that they will be given an incentive in some way or the other. You can give anything you want as a reward. Another way can be gamification. Like, you can display an on-boarding list somewhere in your app, consisting of ‘enable notifications’ and anything else according to your preference.
Just by displaying the number of completed items or completion rate to the user will be sufficient to get their approval on notifications. Don’t resort to blackmailing users; don’t restrict their use on certain features unless they have given permission or signed up for your newsletter or something of this sort.
On Rejection
There are fewer chances of the native request being rejected but still, there could be a possibility once the native prompt pops up. If this is the case, you must go in for some feedback and elaborate on how to manually enable the request through browser settings.
Just don’t wish by crossing your fingers. When the user comes in contact with your fake UI and you are about to play on native prompt, you can help to give them some clarity. It could be in the form of an overlay that is spread across the entire page. With this, you can gather more attention towards the prompt; make sure it is not ignored. Go for some text.
A classic example can be when Google Chrome first gained popularity, some sites would use an arrow pointing at the download bar just after the download finished. It was raw but it worked. It is better to keep this overlay simple and clear. Don’t assume the position of native prompt, browser-sniff or put in too much code to complicate things.
Reason it out
What will you do once people grant permission? Well, that is another ball game altogether. Firstly, you should try to relieve them if possible. For notifications, in particular, don’t strain the users much.
Remember there is no spam filter for notifications. Further settings can be brought in action to tweak how requests can be put to use. Some apps also have a feature that even though notification is sent for every message initially but once you become comfortable with the app, it suggests minimizing your notification level, so that you get notified only when you are tagged. Beware of sending multiple notifications for the same thing to the user again and again.
Even if the app is open in 20 tabs, still there should be one notification for an event. This can be done through the ‘tag’ option in the notification API. If multiple notifications are generated on the same tag, the user will be sent only one.
Be Practical
You don’t need all this trouble. Figure out the importance of the permission to your site. The web-scale will improve if everyone applied this logic. For each request, study the response and rate of acceptance, also, how much users can tolerate before dismissing any permission. This is just like a conversion funnel. Ultimately, you can maneuver and A/B test it.
Browsers in Support
Changes are always welcomed to enhance the experience of users and keep abuse at bay. To be just, browsers stop the requests after three dismissals of permission. Google Chrome permits the requests again after a period of a week. Yes, this is of support, but more can be done in this regard. To think of it, browsers can be of help if they could give some text along with the native prompt to add some clarity to the context for the user.
This way you won’t be sloppily asking for user’s microphone access. Another way can be a callback with an icon, link or button to explain the reason for the request. There are some security measures which do exist at present. One is the Bluetooth API which doesn’t permit a device request unless there is a user gesture such as a touch or click.
Chrome restricts notifications from iFrames, unsafe origins and even cautions you if you pass notifications that aren’t in response to a user gesture. Chrome’s rules for using persistent storage aren’t a cakewalk; Chrome automatically allows persistence request if the site is bookmarked, has a high rate of interaction, has been saved to the home screen and has push notifications on. If it fails on these conditions, the permission is automatically rejected. No rule can be labeled good or bad, but browsers, in general, should set some rules to adhere to permissions requests.
AskBlocker on Guard
AskBlocker is an extension for Chrome, Firefox, and Brave which keeps a watch on permissions requests. Permissions requests can’t come into play unless you have been engaged with the page. However, there are few exceptions- when the permission has been previously sent and accepted, if the domain is localhost or if you are shifted to the present page from another page on the same domain.
This will stop immediate requests to activate notifications the first time you visit a site. As it is open-source, you can even see the requests in line and whitelist them. Note that there aren’t any extensions for other browsers as of now as they aren’t compatible with Permissions API.
Wrap Up
Once your permission requests are blocked, there is no scope to enter the game again. You lose once and for all. Yes, there is a steep price to pay if you don’t improve your permission prompts. Websites must consider carefully before they jump the gun. Don’t forget; requests when done correct works else irks.
