If you are obsessed with organization like I am, you probably use Evernote and its sidekick Skitch. Evernote is, in my opinion one of the best products out there to manage content and Skitch feeds the graphic designer part of me. So why did I uninstall Evernote and Skitch last week from all of my Android devices? Because Evernote released an update to Skitch that changed the permissions of the application and totally failed in communicating with its users.
By this point you devs out there are already shaking your head and calling me a n00b. That is fine by me but please read on because you might learn a thing or two about the end-user experience.
The perception problem
As soon as I saw the permissions changes in the update I asked myself: “Ok, the permissions changed and there is no explanation at all for this to happen in the market”. Then I started to read in the comments and everyone and their dog were complaining about how abusive the new permissions were (“Read sensitive log data” was one of them). So I tried to reach out to the developer and all I got was silence. Everyone complaining started to complain about the lack of response from the developer and the developer was still tweeting away its promotional bullshit and not bothering with replying to legitimate questions. To me this was a deal breaker. At this point I didn’t care if they needed the permissions or not. I was angry at the fact that my questions were not being addressed and this is what happened with lots of users, even premium users, that uninstalled the Evernote +Skitch combo from their devices. Was it worth it?
When not knowing how to communicate makes you the bad guy
This comment clearly shows the overall sentiment regarding the update:
The access to system logs permissions would give access to all activity from all programs. I trust Evernote with the things I tell it, because frankly it’s not really commercially relevant. But I do not trust them with what websites I visit, what books I read, what apps i use, what I buy and where I go. I should be able to opt out of this type of collection and there should be clear stated policies about its use and how long it is kept. I did some reading on ever note forums and they claim that the only time sensitive log data is collected is after a crash. Further, since it is sent in the body of an email, the user can edit the information before it is sent. All things considered this is actually fairly reasonable. Still this practice should be more clearly communicated to us.
While I absolutely believe that when a developer includes certain permissions, in any application, he does so because he needs to, I also believe that every developer has the professional obligation to explain to the end users why he needs those permissions in a way that is understandable by everyone that has no idea how to code and doesn’t know the technical lingo. These people are the 99% of your end users and you should respect that.
Evernote is not alone in this bad practice. Most Android developers think that a mere “Fixed several things” as an update description is enough. Guess what? It isn’t.
Learning how to communicate the changes that you have made in your application will be time-consuming but well worth it, because you are giving users an insight of what you have been doing for the several weeks/months, since the last update. If you really want to do it right, have a blog on your website describing item by item what you are doing, and use social networks to listen and interact with those that laud your product and those that are criticizing you: Don’t assume that everyone is just trolling you and take the time to listen to them.
Final Thoughts
As a developer you can’t afford to have a communication mishap tarnish your hard work. Evernote felt this last week and the company did make a new update available and included a link in the market to their website where they explain why the app needs such permissions. However Evernote’s management totally failed to publicly acknowledge the mistake and say “Sorry, we fucked up” . Sometimes – most of the times – that is all you need to do to stop a chain of events that only can lead to a disaster.
About OutSpin
OutSpin is new weekly column by Fernando Fonseca, here at AndroidSPIN. The opinion articles will focus on analyzing Android related issues from the point of view of a regular user and with a heavy focus on communication. It might include some craft beer related content.
Share This Article....
If you like that, Try these....
![[Rumor] Google Bringing Optional Permission Control To Apps?](http://androidspin.com/wp-content/uploads/2013/04/Google-Play-Store-1-150x150.png)
![[Video] Samsung “el Plato Supreme” teaser featuring Seth Rogan and Paul Rudd](http://androidspin.com/wp-content/uploads/2013/01/Samsung-TheNextBigThing-150x150.png)
About the Author
As a developer, permissions are always a concern for me, for just the reasons you noted. There are 2 issues here you should be aware of. First, I believe Google needs to add a way for developers to list descriptions along with permission requests so users can get an idea of how these may be used, although I understand that it would give the chance for malicious developers to try and explain away dangerous permissions and hide what they’re really using them for. The other issue is that some permissions give access to much more than is needed and may make users uncomfortable, thus decreasing sales. For example, READ_PHONE_STATE is the only way to get unique device identifiers (used for analytics, saving data to a server without creating an account, and blocking malicious clients) but it also gives access to information about a phone, including the phone number, which most developers don’t need and most users don’t want to give out. I’ve encountered this issue with every app I’ve developed professionally, but in many cases there aren’t any complete workarounds. In this case, I’d prefer a unique identifier per device which would remain the same even if you uninstalled and reinstalled the app, but couldn’t be used between apps (i.e. different apps would get different identifiers). Developers can request this functionality, but there are far more consumers, so taking your concerns directly to Google is a good way to motivate change.
Chris,
Thank you for the time you took to write this reply and I will surely follow up on your idea of forwarding this concerns to Google and see what comes out of it. The example you give is really a good one and I am sure that there are many more.
Now I have a question for you: Why do you think that developers don’t take the time to explain this to the end users? Is it a cultural thing? Something else? Really would like to know.