QuirksBlog - HTML5 apps
Part of Mobile.
Yesterday Horace Dediu tweeted:
A browser is an infinitely flexible interface, but is it the best interface for everything? Apps allow experiments in new interaction models
The browser is not the most advanced interface there is. It’s too easy to build the wrong features into something as flexible as a browser, and once a badly-designed feature gains traction it’s impossible to get rid of it. (See HTML5 drag and drop.)
Cameron Moll is worried about a future in which we’ll all write Objective-C for the iPhone OS instead of writing web standards for the mobile web.
At one point in time, J2ME (now Java ME) and WAP were the starting points for a discussion on mobile strategy and the web. Then, for a brief period of time, you talked about HTML/CSS. Now, for a growing majority of mobile strategies that don’t require a global presence on widely varying devices, the discussion begins with iPhone.
Emphasis mine. Strategy and presence are the clue, and they’re the reasons I think the situation will not be quite as bad as Cameron fears.
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.
Yesterday evening I returned from my fourth foreign trip this year. This time I went to
the Mobile World Congress,
the annual Barcelona-based get-together of the mobile industry, and I can tell you, it’s
This post gives an overview of announcements by mobile players that might be of interest
to web developers. There’s an incredible lot of it, too, because every single major mobile
player except Apple feels that MWC is the ultimate forum for major announcements.
If you know of more news, or have links to additional information, please leave a comment.
I was there because Vodafone had invited me to sit on a
panel in a technical “embedded
conference” about W3C Widgets and related technologies.
The concept can use some fine-tuning; I’m hoping to do some of that in the future.
I was there mainly to stress that the mobile browser situation is not as simple as it looks. THERE
IS NO WEBKIT ON MOBILE!
While I was at it I also invented guerilla browser testing.
Since my attempts at capturing web developers’ hearts and minds by
have failed miserably but my thirst for attention continues unabated,
today I will once more shout at iPhone developers. That’s
proven to work.
More specifically, today I will shout at web developers who think that delicately inserting an
iPhone up their ass is the same as mobile web development.
Before we start, a little thought experiment. Suppose I proposed the following:
- IE6 is today’s most advanced browser. (Note: this was actually
true back in 2000. Please bear with me.)
- IE6’s market share is about 80%.
- The other browsers are way worse than IE6, and developing for them is a pain;
something we’re not interested in and are a bit afraid of.
- Therefore we will develop websites exclusively for IE6.
Would you agree with those sentiments, even if we’re back in 2000 and IE6 is really
the best browser we have?
Or would you reply that our sites should work as well as they can in all browsers
through the use of web standards, progressive enhancement, and all the rest
of the best practices we’ve been preaching for the past ten years?
I distinctly remember a time when we web developers cared about such concepts.
But those times are long gone.
In his “Apple’s mistake” essay Paul Graham makes an unwarranted assumption; an assumption everybody who’s currently involved in the Great App Store Debate seems to be making.
The fundamental problem on the iPhone is not Apple’s App Store approval policies, but the iPhone developers’ arrogant disdain for Web technologies.
It was only last Friday I told a roomful of Web developers that Apple is evil, and a spontaneous applause erupted. Since then, however, I have changed my mind completely. The Web developers and I were wrong.
Apple is not evil. iPhone developers are stupid. Their problems with the App Store approval process are entirely their own fault and they deserve no commiseration.
I hope the App Store approval process sticks around for a loooooooong time.
Update: I was wrong about Web apps being able to replace native apps right now. I was wrong about the iPhone developers’ mindset. They aren’t stupid. Read my follow-up post.
As I said before, I’m currently working for Vodafone on mobile browser compatibility and W3C Widgets. I’ve discussed some mobile browser problems, and you can look over my shoulder while I’m at work dissecting their odd behaviours. If you want the latest scoops on my mobile adventures, you can follow me on Twitter.
The time has come to talk about the W3C Widgets part of my job. Exactly what is a widget, how do you create one, why would you want to, and which systems support them?
Personally I firmly believe that widgets are the future of the mobile web. They are easy to create, they’re based on open standards, they save the end user quite a bit of network traffic, and many people around the world already know how to create them.
In contrast to other recent publications about widgets, I’ll tell you the whole story — or rather, a condensed version thereof.