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

  1. have one single core application;
  2. are written with web standards, primarily HTML, CSS, and JavaScript;
  3. 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:

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?

This is the blog of Peter-Paul Koch, web developer, consultant, and trainer. You can also follow him on Twitter or Mastodon.
Atom RSS

If you like this blog, why not donate a little bit of money to help me pay my bills?

Categories:

Comments

Comments are closed.

1 Posted by Simon St.Laurent on 8 March 2010 | Permalink

I agree with this on pretty much every level, though I have doubts about one point.

"Avoiding the app store" is a good idea for many projects, but not so much for people who want to sell their apps directly. There's a large group of people out there with a specifically financial motivation who might not find this approach as appealing.

But they're certainly not everyone!

2 Posted by ppk on 8 March 2010 | Permalink

@simon: Basically we have to stop charging for the app and start charging for the content. That will pretty much solve the problem.

I've deliberately left payments out of this article, though, because it's a complicated subject and I need to get some more information first.

3 Posted by Nikolai Onken on 8 March 2010 | Permalink

@simon - there are working models starting to emerge where people charge for apps even though the app store is entirely web-based. Yes you don't have the benefit of paying through for instance Apples payment gateway (I don't really see that as a good thing), from a usability perspective it is as easy as you would want it to be.

4 Posted by Baldur Bjarnason on 8 March 2010 | Permalink

What's the story on deploying updates? I get the impression from the Vodafone 360 docs and the Opera docs is that their processes are roughly similar to iTunes Connect (you submit the update through a web interface).

When you're deploying updates to the same app across dozens of different devices, platforms and distribution channels you need to be able to automate the update process both on the developer and the user side and if any of the widget platforms you mention offer that, they're doing a crap job of documenting it.

HTML5 Apps are a very interesting concept and W3C widgets show promise. But the decision to deploy/sell/distribute an app to a platform isn't just based on cross-device/platform compatibility, if the distribution platforms suck, all that potential dies in the cradle.

5 Posted by AlastairC on 8 March 2010 | Permalink

Payments is unfortunately a key piece of the puzzle.

The iTunes store has a massive advantage as they've essentially implemented micro-payments (well, mini-payments) for apps, and have millions of accounts with credit cards.

To compete across the board (rather than just in free apps), HTML5 apps would need a payment mechanism. Something that's easy to browser, download and buy from.

I could see someone like Paypal doing this well, but it's more likely that phone providers will try, and do it badly.

Remember the Milk has an interesting approach, where the web-app is free, and the iPhone app is free for 30 days. After 30 days you need a pro-account. That works for things where you use them across devices.

However, for general acceptance, you don't want to give every app provider your credit card details.

Who do you think could do a good HTML5 App store properly?

6 Posted by erik swedberg on 8 March 2010 | Permalink

Thanks for the thoughts. Developers need more ammunition like this when trying to convince clients that, when trying to bring their web service to mobile, focusing on one (or two) noncompatible platforms isn't a "mobile strategy".

As far as micropayments for bits of native code, let's hope this giant step backwards in the evolution of the web passes quickly.

7 Posted by Eric Anderson on 8 March 2010 | Permalink

Regarding progressive enhancement I disagree we have the tools available.

I can develop a web app with little cost as the servers, web browsers, etc are all free. So entry is low and this helps ensure websites follow standards, achieve compatibility and implement progressive enhancements.

The mobile environment it is MUCH worse. Developing for one platform is pretty easy as I have just the cost of getting tools and actual phones for one platform. But to make an app that works on 20 devices we are talking about a serious investment of time, resources, tools and hardware. The high entry will make people to just say "fuck it, lets just make a iPhone app".

Some platforms the costs is fairly low. For example, WebOS has a SDK that runs the entire phone on a virtual machine. The SDK is free and you can run it on any platform.

On the other hand, the iPhone is much worse as you have to buy into the entire Mac eco-system to run an iPhone dev environment.

So the platforms that are easy and cheap to test on (like WebOS) and the popular platforms (iPhone, Android) there will be compatibility/progressive enhancement. The other platforms will just be ignored as the tools are not available to do progressive enhancement.

8 Posted by John Foliot on 8 March 2010 | Permalink

Another possible strategy to look at (that I am contemplating working more at as time permits) is creating Open Social gadgets [http://code.google.com/apis/opensocial/ ] and deploying them via Drupal [http://drupal.org/project/opensocial ], and then using Drupal's Mobile Module [http://groups.drupal.org/mobile ] for mobile platform delivery. Want fancier? See jQTouch [http://www.jqtouch.com ] - just go build them already...

PPK, we need HTML5 apps t-shirts!

9 Posted by Marc Friederich on 8 March 2010 | Permalink

We're facing those clients who WANT an iPhone app and we think that the good compromise is to build an html5 app. Testing in the whole devices browsers and building a webview app especialy for iPhone. As far as I'm concerned win win here it is :-).

We are talking about safari mobile features (successfully testied on Android)
http://www.slideshare.net/antistatique/safari-mobile

10 Posted by Mayel on 8 March 2010 | Permalink

Great initiative ! I hope this will help standards-based apps become more accepted.

Have you seen this example http://voicecentral.riverturn.com/ of a pretty powerful HTML5 app (this one tries to mimic a native iPhone as much as possible) ?
It seems to have solved the financial aspect by offering a premium version with a subscription ($6 yearly via PayPal or Google Checkout).

11 Posted by Liza Daly on 9 March 2010 | Permalink

We just traipsed through the happy fun land of HTML5 with http://ibisreader.com. Due to time constraints we were only able to launch with Android 2/iPhone support -- webOS didn't "just work." We're likely to improve the mobile, non-HTML5 experience across the board before we return to webOS again.

For our particular application, performance still needs improving, but having a single codebase that runs on traditional web, mobile web, and HTML5 with offline and local storage is pretty great.

12 Posted by Delan Azabani on 9 March 2010 | Permalink

I'd like to start off by saying that your blog's insightful posts bring me back all the time. Anyway, I think that this buzzword concept will really capture the public's mindset if it isn't overused, but some of the problems with HTML 5 apps aren't just the specifics that you mentioned, but also include things like speed and implementation. We need to look back on how browser wars and severe incompatibilities of the 'dark ages' of the Web hampered development ten years ago and learn from that.

13 Posted by Belen on 10 March 2010 | Permalink

I think we defenders of the mighty HTML5 apps have to take our share of the blame. Clients are not like children, we just suck at selling the right solution.

If we are convinced that a HTML5 app is the right way to go for a client, we should be able to prove it with hard facts, numbers and unequivocal evidence. Building the case in terms of reach and development costs could help.

But the first step is to determine that a HTML5 app is indeed what serves the client's needs best. How you decide which mobile platform is the right platform is something we need to study a bit more, I believe.

14 Posted by Alex Gibson on 11 March 2010 | Permalink

I quite like the term 'HTML5 app', will be interesting to see if people begin to adopt it.

I started a pet-project this year developing mobile web apps at http://miniapps.co.uk/

So far, I have released a checklist application that runs on iPhone OS, Android 2.0, WebOS and Firefox Mobile. It also runs on the latest versions of most desktop browsers.

I have also released a card game that makes use of CSS 3D transforms. So far, this currently runs on iPhone OS only, although I am looking into how to make the game work on other devices that do not yet support 3D transforms.

15 Posted by stelt on 13 March 2010 | Permalink

-"HTML5 App?"
- "Yes, a Scalable App.
Scales to the capabilities of the device."

16 Posted by Alex Curylo on 13 March 2010 | Permalink

I think you're missing the real point -- people want, rightly or not, to be in the App Store. I *routinely* go through this variation on your conversation.

CLIENT: Want iPhone App!

ME: There's no technical reason this needs to be a native app. You could do it as an HTML5 offline app cheaper, without paying Apple a penny, and without any approval process.

CLIENT: Will it be in the App Store?

ME: Well, no. But they just have to hit 'Bookmark' in Safari, and it'll be installed and act indistinguishably from a normal app. And you can set up a payment process where you keep all the money, not just 70%.

CLIENT: So it won't be in the App Store?

ME: No. No, it will not.

CLIENT: WANT IPHONE APP!

...

17 Posted by David Ciccarelli on 13 March 2010 | Permalink

Thanks for the well-researched point-of-view. We just finished the launch of our mobile app, found at http://m.voices.com after reading the Morgan Stanley Mobile Report. Clearly, iPhone Apps are catchy, but when it comes to updates and quick iterations, waiting for approval by the App Store support staff is problematic.

18 Posted by ESN on 14 March 2010 | Permalink

I am all for web apps to native apps. In fact, I have only ever built iPhone web apps. However, I have to admit when it comes to marketing and selling apps, native apps have a lot more advantages. When people want an app for something, they go to apple (or android etc) app store to search for it, they don't go to google. It would be good if there is a single marketplace/store (much like Apple Store) where people could search for apps by device type and purchase them.

19 Posted by c69 on 14 March 2010 | Permalink

It sounds stupid, but maybe it is a way to go.. look at ajax, nobody used the tech until it got a fancy name ;)

20 Posted by Scott on 17 March 2010 | Permalink

I am anxiously awaiting flash builder cs5 with iPhone packager so I can write an app in flash, release it as a native app, then I can use the same code and resources on other devices/platforms!
info here - http://labs.adobe.com/technologies/flashcs5/appsfor_iphone/

21 Posted by Tunde on 20 March 2010 | Permalink

Awesome article! I can relate especially to the Me/Client exchange. Clients are Buzz word minded.

22 Posted by Olivier Thereaux on 25 March 2010 | Permalink

Excellent article, with one minor flaw: thinking we can make it easy to deploy apps outside of app stores won't solve the revenue question.

Users paying for content? Yeah, right. Ads? There is a ton of controversy (see Pinch media's “appstores secrets” study) as to whether it is profitable. Not to mention Apple and others aren't too friendly with apps not installed through their store.

That said, systems like phonegap, titanium and others do help in deploying html5 apps to the stores.

In other words, I fully agree that html5 apps (a decent buzzword indeed) are a good thing (TM) and the future of development of multi-platform apps, but we'll have to smuggle them into "native" app stores for the time to come.

23 Posted by Brent on 28 March 2010 | Permalink

Interesting post. I agree with your take on HTML5 apps as well.

I myself have been working on some things in that space lately. From my experience some platforms such as JIL (or BONDI) seem poised (with perhaps a little push) to provide some great native functionality to Mobile Widgets (aka HTML5 apps) on numerous and widespread supported devices. (such as Vodafone 360 devices being one of the first JIL enabled devices).

The future will be interesting indeed!