Web apps are not cross-platform apps.
If the battle is whether Apple’s tools or HTML5 is the best way to write iPhone apps, whether Google’s frameworks or HTML5 is the best way to write Android apps, whether Windows Presentation Foundation or HTML5 is the best way to write Windows apps — my money’s on “native” in any and every case. Some developers aren’t as bothered by oppressive distribution policies as they are by the differences between platforms. They see JavaScript as the new Java — write once, run anywhere — and see generic-but-native-looking HTML5 apps as superior to the native apps they mimic.
The trouble is that users don’t value “consistent across platforms”. Why would they? They expect consistency within a platform. Developers who look at web apps as a “cross-platform solution” because of “HTML5″ do themselves a double disservice: not only do they devalue their own app by making it subtly inconsistent to native iPhone apps, they devalue the foundation they’ve built upon by muddying the web’s unique consistency.
Interestingly enough, it was Apple’s experiments that in large part sparked what we now call HTML5 — even before they tried to pitch web technologies as the iPhone SDK. Their 2004 introduction of Tiger’s new WebKit features, and their use in HTML-based dashboard widgets, was not uncontroversial — especially the debut of the <canvas> element. The controversy was not just about a browser adding this new element ahead of the standards process, but whether its nature fundamentally fit the web.
This wrestling may have been too quickly forgotten when the zeitgeist turned to The Web vs. Flash. Which one did we want in our pockets? Which one would we allow into the App Store? (We know who shot a rather rich mixture of fuel across that flame too!) Cute young <canvas> livened up that party, while the more web-ish SVG kept faithfully raising the children back in her own namespace.
Now APIs for 2-dimensional, and perhaps someday 3-onto-2-dimensional, drawing at such a low level as <canvas> provides is one of the most native-ish things a sandboxed web page could hope to ever do. But what distinguishes <canvas> from Flash? Very little as far as the topic at hand — the user experience may certainly benefit indirectly from an open standard implemented by competing vendors accessible from the same code that manipulates other document content, but its fundamental direct nature is one of a rectangular garden in which every website may try to plant its own reimplementation of superficial patterns and behaviour borrowed from hither and yon.
Like Flash, <canvas> is a useful medium for games. Games are their own platform. There are certain habits in game design; one of these patterns is that every game paints its own interaction. The Web, too, is its own platform!
Should the web platform shun games as one of its many contents? Certainly not! The web is a platform for content — perhaps the platform for content — and I’m beginning to suspect that that is exactly how a web *app* should look and behave as well. And not just any content, but linked content. Hyperlinked hypercontent for hyperconnected hyperhumans.
Raw pixels do have a place in that, as do video and audio and maps and molecule models.
You may recall me puzzling, in my early days of transition from desktop interfaces, at the attraction of building “apps” on what began as the physics paper platform. Just as physics is discovering what a tangled web may lie beneath their spherical cows of uniform density, it’s becoming harder and harder to ignore just how revolutionary “sharing within internationally dispersed teams” was even just for some academic information. And the web was never intended to be limited to a single format, so the idea of applying it — finding applications of it — building web apps for any task that can be turned into information, is not unfounded. Because of the web, any part of our lives that can be turned into content is limited only by the velocity of its light cone and the weight of its incoming links. It’s a powerful, powerful platform.
(The web’s other attraction is not unique to the web: any medium seems to gather a healthy school of builders who may not understand the first thing about foundations but are willing to keep bracing lumber together until they find an arrangement that’s worth tying a rope swing beneath. However, the web platform is actually especially conducive to this; how many of us don’t look back fondly at the first tree forts we built, that were our early homesteads in this great forest?)
So what is “native” to the web? Cloning every desktop and mobile operating system into a least common denominator cross-platform app framework has failed before, and it will fail again. I even see a very low return on investment trying to mimic the design patterns and interaction behaviours of only The Mac (or the iPad, for that matter) with the new tools HTML5 has given. The Macintosh interface was designed for specific hardware and a rather earlier period of transition. Not to mention, its modern implementation has much deeper consistencies and broader features than the different 80% each one of us relies on, which varies whether we’re keyboard people or mouse people, know Emacs meta shortcuts or copy/paste, have a multi-button scroll mouse or prefer a braille display. A web app’s best bet is not to pirate these patterns, like a camcorder snuck into a matinee, but to embrace the medium of hypercontent it’s been given.
That’s really what the web is: important information, flexibly found and presented, easily shareable via links. Since the web is not the world, people need specialized means of integration between their lives and whatever information they care to share by projecting it into existing and still-missing forms of content. Making that better is what web apps are.
]]>
