I remember a CMS implementation I was involved in ten years ago for a major hardware manufacturer. At the time, mobile was just starting to become a "thing" and multi-platform delivery was the new buzzword. People knew that mobile was going to be big, but perhaps they didn’t know how big.

We ended up building a mobile version of that site, and we did so with the leading mobile development technology of the time, the short-lived markup language called WML. Of course that was 2002, five years before the introduction of the single biggest game-changer for the mobile industry.

shutterstock_84437167.jpg The iPhone came along in 2007 with its fully functional web browser, immediately challenging the existing mobile website delivery technologies. After all, why would you develop in WML when a simple HTML page would render just as well? Heck, as the screens on smart phones were getting bigger (think today’s Samsung’s Note and Galaxy S3) it should theoretically become less and less important to have a distinct experience on your handheld and on your laptop.

It looked like it was going to be a golden age for us web developers. You just had to write one webpage, in good old HTML, and it could be seen by anyone, anywhere. Then, in 2008, everything changed again with the introduction of Apple’s AppStore and "native applications." All of a sudden, it wasn’t just about the browser anymore.

The Native Application

Fast-forward to today. I was recently asked to put together a small mobile site for one my clients to publicize the activities of a particular group at the company’s annual kickoff. Flyers with QR Codes were handed out at the event, which, when scanned, navigated individuals to our mobile site.

Surprising to everyone, registration to the site increased by over 300%. Signing up on the phone was obviously more convenient than having to do it on a laptop or desktop computer.

Success breeds interest, and we were immediately asked to take the mobile site to the next level, but this time through native applications. The inevitable conversation regarding mobile platform support (iOS, Android, Blackberry, Windows Mobile, etc.) quickly ensued, ending with:

Me: Why do you want a native application anyway, when the mobile site is already popular and looks really good?”

Client: Because nobody bookmarks pages on their phone’s browser. An app is right there on the main screen. You just have to click on it. It’s much easier for a casual user.”

If you are in the business of writing native applications, the permutations of devices, operating systems and versions quickly spiral out of control. That doesn’t change the fact that my client’s comment is correct. There is something genuinely nice about having a native application, even though it is a pain for us web developers. Welcome back 2002.

Multi-Platform Solutions

All of this probably isn’t news to you. It’s certainly not news to some of the major CMS vendors, including Adobe and Open Text. They’ve known for some time now that the content management system that best supports multi-platform delivery with the least amount of custom code will be poised to be very successful in the future. And to that end, both companies have recently acquired technologies that will help deliver sites built on their platforms to a diverse set of mobile devices.

Nitobi, the creator of the PhoneGap software product, was recently acquired by Adobe. The solution offers a pretty simple concept: create an HTML5 application once and it will take care of turning that application into a native app, compiled and distributed for each of the major permutations of devices, mobile operating systems and OS versions.

OpenText acquired similar technology called the Wave Platform from UK-based company, WeComm. The Wave Platform differs quite a bit from PhoneGap in that it is an entirely web-services based solution. Applications are built using their drag-and-drop GUI interface leveraging components from the native operating systems’ library of components. It doesn’t provide the flexibility that you get from HTML5, but it’s an easy tool to use with almost no learning curve, allowing developers to pump out native apps quickly to any device.

Another offering worth noting is the Titanium platform from Appcelerator, a free toolkit similar to PhoneGap. Build your app with HTML, CSS, JavaScript and with some dynamic bits done in a scripting language like Ruby or Python, and Titanium does the job of making it native. Since last year, Titanium apps built for iOS and Android have increased from 5,000 in number to 50,000.

That doesn’t scratch the surface, though. Multi-platform delivery is a big deal, and other players like trigger.io, Corona and Rho have developed similar offerings.

Getting Back to the Future

It seems obvious to me that the number of devices, screen resolutions and variables are going to be constantly changing as we go forward. This is all the more reason for us web developers to insist on some kind of standardization.

HTML should be that standard, and PhoneGap has the right idea here. If we have to develop the same code in a dozen slightly different ways, then we are taking steps backwards. As HTML becomes more sophisticated, especially with things like conditional CSS, there’s no reason why we can’t build a single website for all platforms. An HTML5 site can be accessible directly or it can be repackaged as a native app and accessed through your OS’s AppStore.

Use some conditional CSS and let the device’s screen resolution take care of the rest. There isn’t even a real need for device detection. A small screen, whether on a tiny netbook or a mobile phone, and a large screen, whether on a tablet or a desktop, should simply show the site in the way most suited for their dimensions.

Check out how about.com’s editor picks manages to cram in more and more articles the wider your browser gets. Here’s another example from alistapart.com that changes the size of their displayed images from full pictures to small icons as the browser’s horizontal resolution gets smaller.

Perhaps my dream of a golden age in which web developers need only support and maintain a single code base for their client’s web content, regardless of platform, might well already be here.

Image courtesy of Angela Waye (Shutterstock).

Editor's Note: You may also be interested in reading: