WAP v HTML5 v Native
WAP, A language from the past
I’ve been having many conversations in the last few weeks about mobile browsing, reminiscing about WAP (Wireless Access Protocol) and how for a short while we were led to believe that this was the language that we (developers) needed to use to get our content onto mobile devices.
Part of the problem with WAP was the lack of standardisation from device manufacturers. For many years, (cue Scooby Doo style wavy lines…) Nokia decided that all their devices would ignore @media queries targeting type=”mobile” which meant that Nokia devices forced the same content upon mobile users that desktop ‘screens’ did. ‘Screen’ media was meant to indicate that you were looking at a large (desktop) screen, and whilst they might have had grandiose opinions that their devices were somehow ahead of the game and could accurately replicate the desktop experience, those opinions were far from reality. What this actually meant was that developers were unable to truly target mobile devices as the proposed standards of the time intended – mobile web browsing on Nokia devices was an awful experience which was a shame as the rest of their device experience was mostly rather lovely.
Whether Nokia were alone in this misconception I don’t recall, but that was the experience that I had. It was frustrating. This was a time when developers were struggling against bloated content management systems for the implementation of semantic structure – clients were demanding splash screens and spinning logos, designers were clinging to print methodologies, trying to apply them to the screen when browser technology just wasn’t capable of delivering the creative concepts we were coming up with.
Web developers were faced with 2 options. Jump down the WAP route degrading the visual experience forcing developers to solve the problem with server side delivery, or decide to strip away any visual formatting using CSS @import methods so that raw yet semantically correct content was delivered to the mobile browser. I decided to opt for the latter. It seemed to me at the time that mobile devices were being updated and upgraded at a faster rate than the languages we were using to code our sites – consumer mobile contracts were 12 months and you could be pretty much guaranteed that you’d get a new handset within that time, the thought was that software development would accelerate faster than hardware. We were almost right. Some mobile operators even tried to create their own WAP specifications, but these quickly became obsolete as mobile browsers became more capable.
It’s not the first time we’ve turned round to a language or framework and decided that we don’t need it anymore and it’s oftentimes the toughest decision to make. Many of us had invested effort, time and money into learning the nuances of WAP implementation and hacking it’s structure to perform the tasks we required of it, but it was definitely time to let it go, it had become obsolete. I enjoyed it’s simplicity and uncomplicated deployment, but not as much as I now enjoy fuller and richer mobile experiences. My brief flirtation with WAP is not one that I regret.
HTML5 vs Native
Now, back in 2011 we are now faced with 2 options. Use the native language of the platform or go with HTML5. Later this year Microsoft will release the Mango update for Windows Phone 7, part of this update deploys IE9 onto Windows phones. We will then no longer have to make do with sub-optimal experiences on our mobile devices and across WP7, Android and iOS, developers can build for the screen and assume that the HTML and JavaScript they’re writing for the desktop is replicated pretty accurately on the devices in our pockets – in some instances, the increased resolution on modern mobile devices can deliver a visually superior experience.
But as consumers, developers and designers we would much rather consume content through applications that are native to the devices we use. Using a native app means there is less chance of anything going wrong. To quote Dean Hachamovitch from MIX11 “Every library, every layer, every abstraction between your site and the device challenge performance, reliability and the overall experience.” He was referring to HTML5 in IE9 on Windows but the same can be applied to mobile app experiences.
There will always be a consideration for native applications. Silverlight and XNA on Windows Phone 7 can provide superior experiences in some applications (see 3D seating plan on the British Airways WP7 app) but HTML5 threatens to give us a better experience as developers building applications across all mobile operating systems. Yes, I expect we will have to tweak for some devices but the re-use of code and logic is going to save us a great deal of time.
HTML5 is here, you can use it today and to quote Bruce Lawson ‘”it wants you to go to the pub”. I for one intend to be there enjoying a Guinness with him and I hope you’re all coming along. The reason it wants you to go to the pub is that it makes developer’s lives easier. By simplifying and standardising the creation of common consumer needs and developer tasks it is less likely to break and therefore quicker for you to implement and test – giving you back time. Guinness for Bruce, continental fizzy lager beer for me please.
Where do you want to go from here?
The world wide web is never going to go away. And if it does, hopefully the last thing on anyone’s mind is going to be, ‘where’s Spooner? I need to tell him he was wrong’. Our life styles and cycles have changed so much in the last 10 years that we will never be able to go back to the disconnected lives that we used to lead unless dictated by a phenomenal global change to humankind. I shudder at the actual realisation of peak oil, but when it comes, we will have solved the issue by other means or be too busy quarrelling for any of this to be any longer meaningful.
My call to arms to you, as developers is to try and future proof your application. The data. The logic. Place trust in the cloud and grow to accept that everything is always going to be always on – you can’t turn off the cloud. Gather your pitchforks, gather your lanterns and we’ll meet at the bottom of Client Hill and together we will march their applications and data to the cloud.
We. Are. Developers.
And the future of the web will be our idea.