Corvus Consulting

Last week Garrett Murray’s commentary on the state reviewing culture on the iTunes App Store reviews circulated through the the blogaverse, catching my eye by way of Lachlan’s Pool Room.

Garrett’s application, Ego (iTunes Link), lets iPhone users check in on their Google Analytics stats on the go. A snafu with Analytics caused his app to be blocked, but in true web spirit Google and Garrett worked out the problem, and an update to Ego was submitted into the App Store’s approval process, which takes about a week.

Meanwhile, on the App Store and Get Satisfaction, Ego customers reacted badly, giving rise to the Garrett’s two core grievances on how commenting on the App Store and elsewhere works:

• Reviewers can be quick to criticize and don’t read every detail before doing so.
• The App Store doesn’t give developers a way to respond to specific comments, or comments in general.

These are fair criticisms, one rooted in problematic human-computer expectations (and if we acronymize that to HCE, we can go on speaking tour), and the other in the design of the interface at the App Store. Along with people commenting on Ego’s problem, we have Google Analytics and the App Store not coming off very well. But there’s a fourth leg in this interaction dance, which is how the Ego app itself handled the unexpected use case of being blocked by Google. Here’s the use case that needed to be accommodated: Google Analytics responds and has not reported invalid user credentials, but does not answer requests for data. At this point the application would display an error indicating that Google Analytics is reachable but isn’t cooperating for unknown reasons. The message can be extended to prompt users to check the developer’s blog, a separate page for the Ego app status, or a support email.

This isn’t to pick on what Garrett did or didn’t do when writing Ego, but his experience is a pointer to a broader need that any application designed to work with third party services needs to meet. When we make apps that provide windows into data managed by other services, we’re acting as a concierge or host for the experience facilitated by using that data. As such, we need to be good hosts, anticipating and explaining on behalf of those we partner with, even when they screw up in ways we can’t control.

The relationships in integrating with a third-party service used to just go three ways: app maker, app customer and the external service. As the gateway to what I think of as a managed environment, the App Store adds even more spin for developers to deal with. It makes things more complicated (yet predictable).

And then there’s the people factor. No matter what the technical relationship is between an application and the services it uses to assemble the data it presents, the user experience focusses on the app. If they love it, their love focus on that app and say nothing about the third-party services that play a critical role. If they are upset with it, their vitriol will focus on that app and say nothing… you probably see where I’m going here. If you put on the clothes of the concierge, be prepared to account for what you can’t control, both in the software itself and in customer feedback.

It’s the new reality, but it’s not an impossible one to deal with. Just remember that if you want to carry your water in a four-legged dance, bring lots of paper towels and a smile to clean up the spills.