HTML5 apps

Right now nobody’s interested in a mobile solution that does not contain the words “iPhone” and “app” and that is not submitted to a closed environment where it competes with approximately 2,437 similar mobile solutions.

Compared to the current crop of mobile clients and developers, lemmings marching off a cliff follow a solid, sensible strategy. Startling them out of this obsession requires nothing short of a new buzzword.

Therefore I’d like to re-brand standards-based mobile websites and applications, definitely including W3C Widgets, as “HTML5 apps.” People outside our little technical circle are already aware of the existence of HTML5, and I don’t think it needs much of an effort to elevate it to full buzzwordiness.

Technically, HTML5 apps would encompass all websites as well as all the myriads of (usually locally installed) web-standards-based application systems on mobile. The guiding principle would be to write and maintain one single core application that uses web standards, as well as a mechanism that deploys that core application across a wide range of platforms.

What are HTML5 apps?

HTML5 apps

have one single core application; are written with web standards, primarily HTML, CSS, and JavaScript; and are deployed on more than one mobile platform.

Thus, normal websites are HTML5 apps. They are written with web standards, have one single core application (the website) and are deployed on more than one mobile platform (all of them, in fact).

Although I’m concentrating on the mobile web here, there’s no reason why a normal website meant primarily for desktop couldn’t also become an HTML5 app, as long as it also works on at least two mobile platforms (most likely iPhone and Android).

In addition to websites, local applications written with web standards, including but not restricted to W3C Widgets, would also qualify as HTML5 apps, as long as they share one core application.

The fact that we’re dealing with one single core application means that it’s fairly easy to update the HTML5 app. The fact that we’re using web technologies to deploy it means that there is no need to go through 27 app stores’ worth of approval processes. We just have to update the core files, redeploy the app, and it works everywhere.

Still, the problem lies in the deployment. In the short-term we probably have to use several systems in order the HTML5 app working on more than one platform. The market situation is chaotic, and we have to adapt — for now. I’ll get back to the technical details in a bit.

A new name

From a technical perspective all this makes solid sense, but there’s no real need for a new name. Still, I believe this scheme will fail without calling the resulting applications “HTML5 apps.”

There’s some justification for the “HTML” and “app” bits. HTML5 apps are all about applications (web-based or locally installed) that are squarely based on web standards, symbolised by HTML.

Of course the “5” makes no sense from a technical perspective. It’s quite possible to write an HTML5 app that does not use any actual HTML5 features.

From a marketing perspective this new name is exactly what we need, though. If we include the “5,” mobile web standards can hitch a ride on HTML5’s increasing popularity as a buzzword.

It’s just a marketing ploy. I hope Hixie doesn’t mind.

The problem

I am convinced that the HTML5 app route is the best one for a fat slice of the non-game iPhone apps currently out there, especially those that are simple and face stiff competition. Increased interoperability will help them more than a relative lack of eye candy will hinder them.

The problem is convincing clients of that.

Friends of mine have a two-year old daughter. Clients remind me of her. Picture her in her high chair. Picture her wanting something.

Portrait of the client as a two-year old, take 1

Client [points at iPhone] Want iPhone app. Me That’ll only work on the iPhone, and about 80% of smartphone users have another phone. Interoperability is critical for a simple social media client facing stiff competition. Eye candy isn’t. Client Want! iPhone! App! Me [tries to hand non-iPhone device to client] Take this one, for instance. It’s very popular. An iPhone app won’t work on it, but a [website | web app | W3C Widget] would. Client [pushes non-iPhone device away] Don’t want that one. Want iPhone app! Me [shoves non-iPhone device into client’s hands] You need [website | web app | W3C Widget]! Client [throws non-iPhone device to ground] WANT IPHONE APP! [cries] IPHONE!

...

APP! non-iPhone device [sad] Bleep.

The solution

Instead of going against the grain and explaining that what they ask for is not actually what’s good for them, why not try to get clients to want a web-based solution? That, basically, is why we need a new buzzword.

Clients are very buzzword-sensitive because they don’t know better. They’re shielded from reality by a business logic layer of consultants who use a continuous stream of buzzwords to explain their high hourly rates.

Thus we’d have to insert a new buzzword into this stream: “HTML5 app.” The HTML5 bit helps a lot because it is a proto-buzzword with quite a bit of potential right now. Witness:

The Morgan Stanley mobile report (48M PDF) states on p. 142: “Products with best HTML5 browsers gain share.” Nobody bothers to define “HTML5 browsers,” but that doesn’t matter. We’re talking buzzwords here. See also pages 162-4.

“Developers [are] defecting from App Store to HTML5” according to ZDNet.

The Google Mobile blog already described the Google Voice application for iPhone and Palm as an “HTML5 application.” If we just get rid of the “lication” bit we’re in business.

Better, clients and even consultants know that HTML has something to do with the web. The new buzzword will point them in the right direction, while terms like “W3C Widgets” might conceivably cause confusion.

So let’s try to make “HTML5 apps” bloom into full buzzwordiness as the worthy successor to “iPhone app.” Who knows, it might even work.

Portrait of the client as a two-year old, take 2

Client [points at iPhone] Want iPhone app. Me That’ll only work on the iPhone, and about 80% of smartphone users have another phone. Interoperability is critical for a simple social media client facing stiff competition. Eye candy isn’t. Client Want! iPhone! App! Me [gives non-iPhone device to client] Take this one, for instance. It’s very popular. An iPhone app won’t work on it, but an HTML5 app would. Client [pays real attention for the first time] ... HTML5 app? Me You want an HTML5 app? Client [swings legs happily] HTML5 app! Want HTML5 app! Me [takes HTML5 app from pocket and installs it on non-iPhone device] Look what we’ve got for you here? Client [clasps device ecstatically] HTML5 app! [Shows it to me] Look, HTML5 app! non-iPhone device [happy] Bleep!

Selling HTML5 apps

So how do we sell the HTML5 app concept? In the short run we won’t be able to avoid a comparison to iPhone apps. (A mid-range goal would be to get rid of this comparison.)

Right now I think we should try to sell it as “an iPhone app that works on several other platforms, too, and doesn’t have to go through the app store approval process.”

Of course it’ll also be less advanced in eye candy, but that’s something we should conveniently neglect to mention if it’s in our client’s interest.

What you can do

Supposing you think all this is a good idea, there are several things you can do.

First of all, take actual business cases from actual clients and see whether they’d be served by an HTML5 app. The reasons for choosing an HTML5 app over a native app need more study.

You could even try to sell the concept to the client right now, but I think we need the buzzword to become better known before you can really have success in that arena.

More importantly, you could start to use the term “HTML5 app” with artful carelessness whenever it’s appropriate (and even when it isn’t), all the while projecting the assumption that obviously everybody knows what you’re talking about. That’s how a buzzword starts its life.

I have no idea if this is actually going to work, but it would be worth a shot. I myself am definitely going to try it.

Technical details

Still, selling HTML5 apps also means solving a few tricky technical problems. They fall apart in browser compatibility problems, for which progressive enhancement is the solution, and deployment problems, for which there is the beginning of a solution that has no name yet.

Progressive enhancement

If an HTML5 app must run on a plethora of browsers you have to test it in those browsers (or at least a good subset of them) and solve CSS and JavaScript issues.

This is going to be a problem, but it’s nothing fundamentally new. Although we’ll have to discover and solve a lot of brand-new compatibility problems, our mindset and tools are fundamentally the correct ones for the job ahead.

By far the most important tool is progressive enhancement. Where on the desktop progressive enhancement means not much more than daringly leaving out the rounded corners in IE6 and 7, the mobile space calls for a significant upgrade of the concept.

“If it doesn’t work, leave it out.” That’s the fundamental rule. For instance, the BlackBerry browser is totally lousy when it comes to JavaScript performance. If the problems get too hard, just switch off the script for BlackBerry and use a plain HTML/CSS version of the HTML5 app.

(RIM, the Blackberry vendor, is fully aware of these problems, by the way, and is working on a wholly new WebKit-based browser. Of course this browser will be different from all other WebKit-based browsers, but I expect it to be good.)

On the other side of the spectrum there’s the advanced CSS transformations and animations that Safari iPhone and Android WebKit support. It’s perfectly fine to use those, as long as you make sure your HTML5 app also works without them.

And don’t believe the silly nonsense that these advanced effects somehow must work in order for your HTML5 app to be a success. They don’t. They’re just eye candy. Use them when possible, but leave them out when necessary. (That’ll happen automatically anyway, because other browsers just won’t react to the transformation and animation CSS. There is no technical problem here, only a mindset problem.)

In order to create HTML5 apps we must use progressive enhancement as it’s really meant, and not as a theoretical construct that makes for a nice conference discussion topic but is shelved as soon as the client whispers “IE6.” On mobile there is no other way to deliver an HTML5 app on time and keep your sanity.

(Oh, and remember, IE doesn’t matter on mobile! Microsoft may make it matter by vastly improving its standards support, but mobile web developers aren’t required spend 30% of their time squashing IE bugs. Windows Mobile has only a 6% market share, and many Windows Mobile devices already use Opera as default browser. The ball is in Microsoft’s court here. Let’s see what the Windows Phone will bring.)

Deployment

Once we’ve solved the browser issues by applying progressive enhancement we need to deploy our HTML5 app to as many platforms as possible.

The simplest deployment mechanism is already in place and is called the World Wide Web. All smartphones, and even a goodly part of the feature phones, contain a browser, so all their users can visit your website.

Still, sometimes a local HTML5 app makes more sense, particularly when the app uses quite large JavaScript files. Avoiding a reload of those files every time the user starts up the app is well worth the effort. Besides, a local app can also function when the user has no connectivity at all.

If we want to offer our HTML5 app as a local application, we need a deployment mechanism that’s considerably more complicated than the WWW. Still, this is not an impossible task.

In fact, Uxebu has done some ground-breaking work by deploying an HTML5 app in pretty much the way described below. It wasn’t always easy, but it works. And now that we start to understand the basics it it will only get easier.

For local HTML5 apps W3C Widget packaging and configuration is the deployment mechanism of choice. It will become the worldwide standard because it’s already there, it makes sense, and it’s close to becoming a formal specification. Besides, many vendors are already hard at work implementing it.

W3C Widgets work on Vodafone S60 and Samsung phones, Opera desktop and mobile on any platform, the Bolt browser (a thin-client solution like Opera Mini), and Windows Mobile 6.5, while BlackBerry also supports them, though right now they need a special Java wrapper as an interface to the BlackBerry OS. There’s no reason to assume that the W3C Widget march will stop here.

Still, W3C Widgets are not enough for now. They don’t work on several platforms, most notably iPhone and Android, and that’s where the Phonegap library enters the picture. As a stop-gap measure it would become a deployment tool to make HTML5 apps available for the iPhone, Android, and BlackBerry platforms. Its creators consider Phonegap to be temporary; eventually all phones will have to support this sort of thing natively. For now we need a library, though.

Apple Dashboard widgets and their close cousins the Nokia Widgets would also count as HTML5 apps. They’re nearly the same as W3C Widgets except that they require an info.plist instead of a config.xml . Adding that file is of course trivial. Besides, Nokia will switch to true W3C Widgets in the not-too-distant future.

On the iPhone (and probably on other platforms, too) a native app can contain a Safari instance. Thus you can create a native app that still downloads its data from the Web, and combine some of the advantages of a native app with most of the advantages of an HTML5 app.

Then we need to study Palm’s webOS, the appcache technique that works on iPhone, maybe the NetFront widget manager, as well as any way of getting HTML5 apps to work on Moblin and LiMo devices.

Yes, it’s going to be complicated. It’s going to take time and effort. It’s also going to take automation.

I expect that in the not-too-distant future a clever web developer will create a site that gives people a way of uploading a core HTML5 app and automatically convert it to a W3C Widget, Phonegap-based native iPhone, Android, and BlackBerry apps, a Dashboard widget, a Palm webOS native app, plus any other platform-specific solution that is necessary.

Conclusion

Concluding, deployment is by far the most tricky problem that early HTML5 apps will run in to, and even there we have the beginnings of a solution. Other than that there aren’t that many arguments against HTML5 apps. As far as I’m concerned the new buzzword will force all relevant parties in the mobile space to firmly opt for web standards, and that’s what we all want, don’t we?

Comments are closed.