Would users understand splitting an Android app's functionality by permission?

Question

Say I'm developing an app for Android tablets that supports offline use, such as a mail or Usenet client. As far as I can tell, most tablets are Wi-Fi-only, and the user is likely to be away from Wi-Fi for several minutes to several hours at a time. For example, a user might be a passenger on public transit and not be carrying a smartphone with a tethering plan. How can I please both non-technical users who want functionality and technical users who are sensitive about what apps can do to intrude on their privacy?

In case the reader has been spoiled by always-on Internet connections over the past decade, here's a refresher of how offline functionality works: An offline user might read messages that have already been downloaded and compose new messages that go into an outbox. When an Internet connection becomes available, the user expects the app to "sync": wake up, send all messages in the outbox, and download new messages that have become available. Then the user can go offline again and work with those messages.

Some users want opportunistic sync whenever the device discovers that a connection has become available behavior. But other users might think the ACCESS_NETWORK_STATE permission or especially the READ_CONTACTS permission is too intrusive on the user's privacy and would refuse to download an app that requests this permission.

"Need my address book? [Expletive] off."
--epine

And I'm told permissions can't be made optional in Android prior to Marshmallow; only hardware feature requirements can be made optional. And on Android, network state isn't considered an optional hardware feature.

An answer to "Is it possible to have 'optional' permissions in Android?" recommends splitting an app's functionality into several apps listed on Google Play Store:

• "FooMail" is the core app, with only INTERNET permission. If only this app is installed, the app would still run with its own contacts and let the user request a sync within the app. All features are usable except completing "To" with outside contacts and automatic sync.
• "FooMail: Contacts" uses READ_CONTACTS to query the system-wide contacts to complete the "To:" field in mail.
• "FooMail: Background Sync" creates a background service that uses the ACCESS_NETWORK_STATE permission to discover when the Internet connection has become available and request a sync if background data is enabled system-wide.
• "FooMail: Sync on Device Start" creates a background service that uses the RECEIVE_BOOT_COMPLETED permission to discover when the device has finished starting and request a sync if background data is enabled system-wide. This way, even if the device's battery completely discharges or an OTA system update has been installed, the user is notified that new messages are available for offline reading once the device is turned on again. It might be prudent to combine this plug-in with Background Sync.

Once the apps are installed, all the UI would be in "FooMail", and the "plug-in" apps would act as services that communicate with "FooMail". Privacy-sensitive users would install only "FooMail", and they would sync manually by opening the app and pulling down the list of messages. Users who want additional functionality would install the core app and all plug-ins, and the setting to enable a feature present in a plug-in would direct the user to the plug-in's page on Google Play Store. How easily would users understand an app's functionality being split into several entries on Google Play Store? If not easily, then what's the best way to accommodate both non-technical users and privacy-sensitive users?

Answer 1

Installing 4 apps to do 1 thing is bad UX

App Overload is a real thing and people are more hesitant to put things on their phone in general. If you require multiple app downloads before the user can complete their task at hand then many people won't bother or even worse may download the core app only to find out it doesn't work without 3 other apps at which point they leave a bad review and delete the core app.

I understand all the technical details in your question and the reasons behind them but to the end user none of that matters. The only thing that matters to a smartphone user is how much better will my life be if I put this app on my device?

Google and Facebook have both moved to this model

Google docs is split into multiple apps and Facebook has an app for viewing your feed and another app for messaging which was available for about a year with very few downloads before they insisted all users who wanted to message their Facebook friends would be required to download the messenger app and all hell broke loose.

Splitting up apps into multiple parts is great for companies with multiple teams working on them but not usually received very well by the end user.

Super technical users may understand

The silver lining is that depending on your target audience some people might understand the decision and see what you are doing as a more secure option. Most people will not understand why the app is split into multiple pieces and see it as an advantage where they are in control but there could be a few that can only find the control they are looking for in your partitioned app.

Answer 2

If considering Multiple apps for permissions then optimise structure for realistic User concerns.

Any reasonable* user that permits "INTERNET" access to an app will also permit "ACCESS_NETWORK_STATE".

Thus, if willing to install the core app "FooMail" they would find an option of adding "FooMail: Background Sync" quite peculiar.

Then, at face value "FooMail: Sync on Device Start" sounds useless, because phones almost never get rebooted*, so syncing only then will update email once in a blue moon?

Now a legitimate and broadly understandable concern is access to "Contacts". A broad cross section of Android phone may appreciate ability to fine tune control here.

Note that now with just two remaining options we can now package for a single step install

• FooMail
• FooMail Pro (with Contacts sync)

(* yes, there will always be 1 in 10,000 special case unreasonable user. In short DO NOT design for them.

An essential footnote is that the level of detail expressed in the question may be normal for technical users, but is anomalous for the general population - the book The Inmates Are Running the Asylum: Why High Tech Products Drive Us Crazy and How to Restore the Sanity communicates this well.)

Answer 3

Users might not understand the core vs. utility distinction, but they probably do have experience with the lite vs. pro version distinction. So:

1. Create a separate app, FooMail Background Sync
2. Announce that background sync normally costs $4.99 but right now users of FooMail can download it for only $.99
3. Users who would have been unhappy to download background sync for free will now be happy to pay to download it.

I don't know whether this would really work, but it would be interesting to test.

Answer 4

Application Family Approach

From a users perspective, an application should be able to stand on its own and offer a service to the user. When we think of existing applications which do that, like Facebook's messenger and Google Docs, each of them offer something independently to the end user.

Android M does offer the requirement based permissions model. I am not fully aware of it, but I presume developers would have an understanding of which permission is granted by the user and that module can come to life and work.

Along with Facebook and Google, there are other relatively small companies which are doing the same. Like Any.do which offers productivity tools like task manager and calendar, and both these tools have something individually to offer to the end user as a standalone application. That according to me should be your prime criteria when you want to split your application.

In your example, you might want to develop the contacts module as entirely different contact manager which can be in principle separate from the mail system. Then it makes sense to have two applications offering different functionality for the end user.

Plug-in approach

There are some applications like Dolphin browser, SwiftKey themes which work on plug-in model. The secondary applications or plug ins in these suits have a mandatory requirement to have the primary application installed. This approach is still based on the services it offers to the user. It mostly works as a extension of the basic services. This distinction happens from the functional point of view and not technical limitations/feasibility.

Always remember, for a user, it is important that your application should clearly solve business problems s/he she faces. Your splitting and modularization should only depend on the value add and inter-dependence of those things from the perspective of the user.

Answer 5

Users of Automate understand plug-ins.

Automate by LlamaLab has a plug-in system. The core app requires very few permissions. Enabling a feature requiring the device's location, for example, takes the user to the page of the Automate location plug-in on Google Play Store. This app requires location permissions, and once it's installed, the main Automate app accesses locations through a service provided by the plug-in. LlamaLab's developer page on Google Play Store lists the main app and ten plug-ins, but the user ordinarily would not need to visit the developer page because Automate takes the user directly to the relevant plug-in.

Source: Forum post by an Automate user