Android Marshmallow and the new runtime permissions – looking for best practices

I’m a long time user of Android phones and only recently installed the new Marshmallow, aka M, update. One of my most anticipated new features in M was runtime permissions which were introduced by Google at Google I/O 2015. After installing the update I wanted to see how apps were managing the change and to learn about best practices before implementing runtime permissions in my app.

Starbucks long list of permissions, presented in the Play Store before download and installation. Why do you need contacts?

The Starbucks app’s long list of permissions, presented in the Play Store before download and installation. Why do you need contacts?

Pre-M apps ask for permissions before the user has downloaded the app, right after the “Install” button is clicked. It’s an all-or-nothing approach: users either accept all permissions and install the app, granting that access in perpetuity, or chose not to install that app. That approach can deter installations even when the permission requested is for a minor feature of the app. For example, Starbucks updated its app a few months ago and added the “contacts” permission. The official reason was that users could send virtual gift cards to friends, clearly a side functionality to finding stores and managing their loyalty program.

M-compatible apps start the download as soon as soon as the “Install” button is pressed. Users are then asked to approve permissions on an ongoing basis, as the app needs that particular access. When an app asks for permission the first time, users can deny or allow the request. The second time a user tries to access the feature that needs the permission, they can deny or allow the request as before, but also tick a “Never ask again” box. In both requests the text is set by Android and says only the app’s name and the permission they are asking for. After denying access, a certain feature may or may not work but the app should continue working. Marshmallow also added a permissions dialog in the phone settings for each app. This is so users can turn permissions on and off in one location, even if they had previously allowed or denied them.

After installing M, I went to look for apps that support it. What I found was a mixed bag. First, while I thought I was late to upgrade to Marshmallow, it seems like some apps, including some popular ones, haven’t released a Marshmallow compatible version yet.  WhatsApp isn’t M-ready while Facebook, WhatsApp’s owner, is. Commerce apps such as Target, Starbucks, Gap and Macy’s aren’t, but Slack and Pinterest are. Many news apps are. That said, it seems that the Marshmallow rollout is taking a long time, so maybe developers aren’t feeling any pressure to release an update.

Regardless, here are two things I learned regarding runtime permissions:

  1. Timing: Ask for permissions when it is relevant for the user, when the benefit is clear. Android recommends asking “for permissions as you need them” but to do so sparingly: “If you confront the user with a lot of requests for permissions at once, you may overwhelm the user and cause them to quit your app.” There are some permissions types that are both essential to the operation of the app and the reason behind the permission request is clear. For example, photo sharing apps clearly need access to the camera. That kind of permission can be requested when first launching the app.
  2. Framing: Android provides its own text in the request dialog, but app developers still need to make sure that the reason for the request is understood by the user. Apps that I found were the best at asking for permissions were good at asking for those permissions not only when the related feature was launched but also used other design elements to explain the request and integrated the request into a logical flow. For example, Slack asked for permission to access contacts in the “Invite” dialog. The request makes perfect sense here as it’s clear that users are to invite their friends and those friends’ emails are probably in their contacts. Slack then added smart hint text that says: “Select or type an email address.” This tells the user that they can type one in themselves but that they could also select an email from their contact. Pinterest also framed the contacts permission smartly by adding a “contacts” choice to the “Find Friends” dialog and making users click a “Connect your address book” button before the permission dialog box pops up. In both cases the flow of the request made that standard request text understandable and reasonable.

This lack of consistency among app developers regarding compatibility with Marshmallow could confuse users who don’t follow every Android release announcement and don’t realize that a quick install means that permissions will be requested later. It’s up to app developers to add the runtime permission requests wisely. Big thanks to Pinterest and Slack for showing us how it’s done.

Slack asks for Contacts permission when inviting friends. Note the helpful hint text: Select or type an email address.

Slack asks for Contacts permission when inviting friends. Note the helpful hint text: Select or type an email address.

Pinterest building up to the request in the flow. Connect your address book on a big, red button.

Pinterest building up to the request in the flow. Connect your address book on a big, red button.

The resulting permission request pops up after users ask to connect their address book.

The resulting permission request pops up after users ask to connect their address book. 

Advertisements

Leave a Reply

Fill in your details below or click an icon to log in:

WordPress.com Logo

You are commenting using your WordPress.com account. Log Out / Change )

Twitter picture

You are commenting using your Twitter account. Log Out / Change )

Facebook photo

You are commenting using your Facebook account. Log Out / Change )

Google+ photo

You are commenting using your Google+ account. Log Out / Change )

Connecting to %s