Adding features to applications is a constant trade-off between opposing forces. Sometimes adding to or changing software can be a hinderance both to the user and the developer in several ways.
[Ego][ego], Garrett Murray’s excellent iPhone application, was blocked by [Google Analytics][ga] yesterday. Since support for GA is one of Ego’s advertised features, paying users are understandably upset. Garrett is a good developer, and I’ve been using his software for years (his application [xPad][xpad] was one of the first non-Apple bits of Mac software I ever purchased) but I think much of the user reaction to this issue was predictable and preventable.
[xpad]: http://getxpad.com/ “xPad”
[ego]: http://ego-app.com/ “Ego”
[ga]: http://www.google.com/analytics/ “Google Analytics”
Unlike many of the other stat-tracking widgets used in Ego, Google Analytics does not have an official API with which developers can retrieve data for use in applications. This means that to get the data at all, Ego has to use what I’d (not at all disdainfully) classify as a “hack”; Getting at useful information in an unsupported way. The problem with this is that the average user has no reason to suspect that Google Analytics portion of his $2 iPhone application may stop working without any prior warning. This is a case of the classic “stopped working for no reason” that developers hear all the time. There is a reason, and it’s a pretty simple one, but the user has no frame of reference for it. What’s more,*the user has absolutely no reason to know the reason*. It’s not their job. They just saw a feature list and clicked buy.
Here’s a screen shot of the features section of the Ego application page on the iTunes store:
You can see here that the Google Analytics feature is listed right next to services with officially supported APIs, such as [Feedburner][feedburner] and Twitter.
[feedburner]: http://code.google.com/apis/feedburner/ “Feedburner API”
What this says to the user is “these features are equal, and just as likely to work” which we now know isn’t the case. A lot of applications do things like this, and the intent isn’t malicious- the average user just genuinely doesn’t know and doesn’t need to know what an API is, or what has one and what doesn’t.
Since there is no “official” way to include Google Analytics data, the GA widget is a trade-off between feature set and usability. Unofficial means that it’s more likely to stop working “for no reason.” Unofficial means that Google can change whatever they like whenever they like, and you just have to eat it, like Garrett is doing now.
He’s is obviously a smart guy, and I’m sure he weighed the pros and cons of including support for Google Analytics in the first place, but I’m also pretty sure he’s second guessing that decision at least a little bit today. This isn’t to say that he made the wrong one- I don’t think he did- but that the way in which application features are presented to users create expectations for those features that may have unintended consequences for developers.
