Uncanny App Valley: Is It Really a Cliff?
In Reto Meier’s 2013 Google I|O presentation, he referred to a concept he called the “uncanny app valley”. While most incarnations of the “uncanny valley” refer to UI, his “uncanny app valley” refers to permissions and general creepiness. Mr. Meier had a slide in his presentation depicting a generalized creepiness chart, complete with a valley representing a creepy app, and with an upslope to the right showing apps that know a lot about you but, in Mr. Meier’s eyes, are not creepy at all. In particular, Google Now was his example of a non-creepy app.
I found that to be a curious example, considering that I went to the level of disabling Google Search on my Galaxy Nexus just to get rid of Google Now, as it is entirely too creepy for my taste.
The truth of the matter is that there is no universal creepiness curve. Different people will have different attitudes towards privacy. Some will not worry a whit about it, aiming for maximum app capability. Others will find Google Now and similar apps to be too invasive.
Branding will have a lot to do with it as well. Apps from brands that users trust will be more likely to escape the “uncanny app valley” than will apps from unrecognized developers or brands that are not trustworthy. So, for example, I am willing to give Evernote a lot of permissions that I do not give out otherwise. At the same time I am still hunting for a decent Twitter client that does not ask for the sun, moon, and stars from a permission standpoint. I have greater trust in Evernote than I do in Twitter, and I have greater trust in Twitter’s own apps than I do closed-source high-permission Twitter clients from other developers.
(Murphy’s Law, of course, suggests that Evernote will get acquired by somebody I distrust at some inopportune moment…)
Hence, while Mr. Meier advocates things like location tracking to help apps deliver “magic”, that may not be in your best interests. Each additional permission that you request serves as a filter, with some percentage of your potential audience electing not to install your app due to that permission. How big that percentage is will vary, based upon permission, branding, available substitute apps, and so forth.
Savvy developers will consider allowing users to “dial in” the amount of privacy they are willing to give up, by delegating privacy-invading permissions to plugins. Since Google has demonstrated no interest in allowing users to control permissions individually per app (and since only so many people run ROM mods that offer this), plugins are a likely approach for keeping your main app light on permissions, yet allowing users to opt into additional functionality with only a bit more work on their part. Cutting the work for developers to support this sort of plugin model is on my ever-popular to-do list…
Certainly, “magic” is an app implementation metaphor of some value. However, if giving your app “magic” means raising privacy and security concerns in prospective users, consider how you can best mitigate those concerns, either by adopting a plugin model, or trying to balance exactly how “magical” your app becomes.
