Alex Payne writes online here.

See also the archive, publications, events.

An individual post follows.

Shortchanging Your Business with User-Hostile Platforms

After yet another Campfire outage this week (albeit a brief one), I went looking for an alternative group chat solution for our distributed team at BankSimple. Griping on Twitter led to a number of suggestions, and we gave the most frequently occurring suggestion a try.

This post isn’t about group chat tools. I didn’t want to call out the service we tried (and ultimately abandoned) because they don’t deserve to be badmouthed. They’ve built a superior product to Campfire, and their team was friendly, gracious, and willing to entertain our suggestions and inquiries. But after posting this, one of the service’s developers told me to name them, so: it’s HipChat. They stand by what they’ve built, and I admire that.

This post is about platforms and doing the right thing by your customers. It’s about the one big thing that I think HipChat and some other great companies are doing wrong.

HipChat can be used in two ways: in a web browser or as an Adobe AIR application. After signing up, you’re pushed pretty hard to use the AIR app. The web interface has a persistent callout to install the AIR app, and some key features are only available in the AIR version.

My team experienced a number of the usual problems one has with AIR applications: lousy performance, odd interface bugs, key combinations and UI elements that didn’t conform to our operating system. AIR apps exist in an uncanny valley between a web application and a desktop application, and the result is unsettling and annoying. Pretty soon, we were itching to go back to Campfire (via the native Mac client Propane), even though HipChat has better features and the promise of improved reliability.

When I asked HipChat’s developers about their use of AIR, the response boiled down to: “we’re a small team, our customers are mostly on Windows, and AIR lets us provide a cross-platform desktop app to the maximum number of customers with the least amount of effort”. It’s a case study for AIR, really: a tiny web shop that’s able to ship a desktop app because AIR reuses their existing skills and knowledge. So what’s the problem?

Mystery Meat

At first, I simply accepted the explanation. But the more I thought about it, the more it bugged me. It seemed like a decision that had everything to do with what’s in the best interests of the business, and little to do with what’s good for their customers.

Imagine a new restaurant that wants to make the most of their burgeoning lunch traffic. They start serving low-quality meat: after all, it’s cheap, plentiful, and requires nothing more than placing a different order with their distributor. For a few weeks, profits are up. But pretty soon, so are customer complaints, and the stars on their Yelp page are rapidly dwindling. The owner doesn’t understand. The meat isn’t great, sure, but it’s perfectly edible, and for a while it seemed like the restaurant was making more money and attracting new customers. What went wrong?

AIR, like the cross-platform widget toolkits and application frameworks that came before it, is the gray mystery meat of client-side software. It gets the job done, but it’s hard to stomach. For anyone who used a computer in the 1990s, AIR probably brings back scarring memories of Java apps: slow, ugly, inconsistent, awkward.

Do People Really Want Native Apps?

It sure seems that way. Five minutes of searching produced this list:

Wherever you see AIR apps, there are support forum threads opened by customers asking for a native alternative, and usually a moderator explaining that they just don’t “have the time” to do native apps for each platform. You see the same thing for popular services that only offer in-browser Flash apps. On Twitter, a significant majority of people seem to hate AIR if sentiment analysis is any indication.

Where developers can, they’ll create unsupported third-party native apps for services that only offer AIR or Flash, even if those apps end up requiring frequent maintenance to stay in sync with the services they talk to. Propane, aforementioned, is one such application. PandoraJam is another, and an interesting case study. Because Pandora doesn’t offer an API, the developers of PandoraJam are forever playing catch-up when the streaming music service changes its design or functionality. Still, PandoraJam’s developers and users suffer through the glitches and updates because they’d rather have a native app. I think that’s telling.

Real Talk

What you’re communicating with a poorly-done AIR app is that your business priorities – namely, saving time and money – are more important than what your customers want.

“We don’t have time” is the common excuse for delivering an AIR app instead of a good native app. Money, though, can buy someone else’s time. For a price, you can find a great contractor to build a native app for any platform under the sun. Yes, you have to spend some time managing the relationship with that contractor. It’s an investment. Eventually, unless you’ve misjudged your market, the investment should pay off.

Humans are gifted with extremely sensitive bullshit detectors. The average computer user may not internalize the difference between an AIR app and a native app, but he knows when something doesn’t feel right or work correctly. Your tech-stunted uncle may not ever request a native application with that terminology, but he’ll sure complain about his computer acting funny when he experiences the oddities of an AIR app.

This isn’t just about AIR, of course. As mobile apps become a mandatory part of doing business, more and more cross-platform mobile frameworks are cropping up. As with every cross-platform framework to date, only one in a pile of the resulting applications might even begin to pass for native. These apps just ain’t right, and people can tell.

Conclusion

Nobody uses AIR because it delivers better-quality desktop apps. Companies build AIR apps because they’re short on time and cash and wary of investing in development and maintenance that’s outside their area of expertise. This is understandable, but shortsighted, and a lot of companies are about to make the same mistake in the mobile arena.

Cross-platform solutions like AIR might be better for your business in the short term, but your customers probably hate it, and you could be shortchanging yourself in the long run. If there’s a market, spend the time and money to build proper native desktop and mobile apps. If you don’t think there’s a market but the demand is there, expose an API to your service, let inspired developers build native apps, and see what happens.

Doing things the right way is hard. People respond to quality, though: they reward it, in no small part because quality such a rarity in the software marketplace. Do right by your customers and they’ll do right by you.

Postscript, January 16 2011

This post generated quite a few responses. Having slept on it and mulled over the responses, I’ve made a few edits, including naming the chat service in question at the developer’s request. I’ve also tried to tone down the fierier bits.

I liked Merlin Mann’s response, and it made me excise a particularly off-the-rails portion of the post. You really do see the “we don’t have time” excuse over and over again if you search around for native app requests, though; I wasn’t trying to set up a straw man. I think a lot of developers genuinely would like to do a native app, but they’re hesitant to make the investment. They’re not all developers on one platform who have stoutly declared that they won’t produce for any other platform like the Mac heavyweights he cites. Still, Merlin’s point is a good one: developers don’t have to build something for a different platform if that’s not what they love doing.

I got an interesting email from the developer of JamCloud who claims that the poor performance of many AIR apps is avoidable by using AS3 and not Flex. I don’t know enough about AIR internals to validate that statement, but an alpha version of JamCloud does indeed perform well on my machine.

I got another email from the developer of REAL Studio who claims that his cross-platform solution produces performant applications with native widgets. I like their Quality Applications page. It’s nice to know that they’re thinking about quality and not just selling the ability to get an app out the door quickly.

I received several emails and comments from ex-AIR developers and businesses that had tried AIR and found that it didn’t meet their needs. But then, I also received some ruffled tweets from current Adobe tools developers who love AIR. Interestingly, I didn’t receive a single tweet, comment, or email from a user of an AIR application who thought that AIR made his favorite application better.

Finally, Ed Finkler has posted a great reply that brings up the fuzzy boundary between native and non-native, and the important point that “native” does not guarantee “well-designed” and vice versa. To his mind, developers can go the extra mile to make cross-platform apps that users will love. I don’t have anything against cross-platform technology itself, so I hope he’s right.