Mile
Zero

Last week, at the Gov 2.0 conference in Washington, D.C., I sat through a session on mobile application design by an aspiring middleware provider. Like most "cross-platform" mobile SDKs these days, it consisted of a thin native wrapper around an on-device web page, scripted in some language (Ruby, in this case), with hooks into some of the native services. As usual with this kind of approach, performance was awful and the look-and-feel was crude at best, but those can be fixed. What struck me about the presentation, as always, was the simple question: if I already have to code my application in Ruby/HTML/JavaScript, with all their attendant headaches, why don't I just write a web service? Why bother with a "native" application, except for the buzzword compliance?

This is not just snark, but an honest query. Because to be honest, the fervor around "apps" is wearing me out--in no small part, because it's been the new Product X panacea for journalists for a while now, and I'm tired of hearing about it. More importantly, it drives me crazy, as someone who works hard to present journalism in the most appropriate format (whatever that may be), that we've taken the rich array of documents and media available to us and reduced it to "there's an app for that." This is not the way you build a solid, future-proof media system, people.

For one thing, it's a giant kludge that misses the point of general-purpose computing in the first place, which is that we can separate code from its data. Imagine if you were sent text wrapped in individual .exe files (or their platform equivalent). You'd think the author was insane--why on earth didn't they send it as a standard document that you could open in your favorite editor/reader? And yet that's exactly what the "app" fad has companies doing. Sure, this was originally due to sandboxing restrictions on some mobile platforms, but that's no excuse for solving the problem the wrong way in the first place--the Web didn't vanish overnight.

Worse, people have the nerve to applaud this proliferation of single-purpose app clutter! Wired predictably oversells a "digital magazine" that's essentially a collection of loosely-exported JPG files, and Boing Boing talks about 'a dazzling, living book' for something that's a glorified periodic table with some pretty movies added. It's a ridiculous level of hyperbole for something that sets interactive content presentation back by a good decade, both in terms of how we consume it and the time required to create it. Indeed, it's a good way to spend a fortune every few years rewriting your presentation framework from scratch when a new hardware iteration rolls around.

The content app is spiritual child of Encarta. Plenty of people have noticed that creating native, proprietary applications to present basic hypertext is a lot like the bad old days of multimedia CD-ROMs. Remember that? My family got a copy of Encarta with our 486-era Gateway, and like most people I spent fifteen minutes listening to sound clips, watched some grainy film clips, and then never touched it again. Cue these new publication apps: to my eye, they have the same dull sheen of presentation--one that's rigid, hard to update, and doesn't interoperate with anything else--and possibly the same usage pattern. I'm not a real Web 2.0 partisan, and I generally dislike HTML/CSS, but you have to admit that it got one thing right: a flexible, extensible document format for combining text with images, audio, and video on a range of platforms (not to mention a diverse range of users). And the connectivity of a browser also means that it has the potential to surprise: where does that link go? What's new with this story? You can, given time, run out of encyclopedia, but you never run out of Internet.

That's perhaps the part that grated most about the middleware presentation at Gov 2.0. A substantial chunk of it was devoted to a synchronization framework, allowing developers to update their application from the server. Seriously? I have to write a web page and then update it manually? Thing is, if I write an actual web application, I can update it for everyone automatically. I can even cache information locally, using HTML5, for times when there's no connectivity. Building "native" applications from HTML is making life more complicated than it needs to be, by using the worst possible tools for UI and then taking away the platform's one advantage.

I'm not arguing that there's no place for native applications--far from it. There are lots of reasons to write something in native code: access to platform-specific APIs, speed, or certain UI paradigms, maybe. But it all comes back to choosing appropriate technology and appropriate tools. For a great many content providers, and particularly many news organizations, the right tool is HTML/CSS: it's cheaper, easier, and widely supported. It's easily translated into AJAX, sent in response to thin client requests, or parsed into other formats when a new platform emerges in the market. Most importantly, it leaves you at the mercy of no-one but yourself. No, it doesn't get you a clever advertising tagline or a spot at a device manufacturer keynote, and you won't feel that keen neo-hipster glow at industry events. But as a sustainable, future-proof business approach? Ditch the apps. Go back to the browser, where your content truly belongs.