Where Does HTML5 Fit into the Mobile User Experience?
May 9, 2013 Leave a comment
- Emerging Web browser standards such as HTML5 promise mobile Web apps the features they and we so richly deserve.
- But have high powered browsers leveled the playing field between desktop and device as well as between native and mobile code? Not according to Facebook.
Software development is expensive, but it is especially costly in the realm of mobility. Developers must contend with the big three (iOS, Android and Windows 8/Mobile/RT) and maybe even BlackBerry, WebOS and others. For each target platform, they must often employ vastly different languages and authoring systems.
Part of the trouble, as I see it, is the slow-paced and conflicted standards process itself. Including the December 2012 candidate recommendation, there have been 13 major W3C draft releases of the HTML5 standard itself, dating back to 2008. And of course, the standard itself is being overseen, authored and edited by all of the major browser vendors, Google, Microsoft and Apple. In other words, HTML5 is very much still a slow moving target authored by developers with highly conflicting interests.
Despite this, at the end of the day (at least for today, May 9th, 2013) what we have is some very rich browser functionality that’s pretty well standardized across all of the major browsers. Of course, as with native client development, words like “pretty well” still spell incompatibility and additional cost. When it comes to nitty-gritty areas such as graphics rendering, microdata capabilities, codec support, basic form fields, sound generation, feature deprecation and the like, browser development still looks an awful lot like native development – except with a larger stable of players including IE, Firefox, Chrome, Opera, Safari, Silk, Android, BlackBerry etc.
Were such micro-complexities the reason Facebook decided to let go of its much maligned Web-based efforts and rally around a fully native client app, Facebook Home? Certainly those complexities slowed development and elevated costs. On a more macro level, however, I think Facebook’s objective (at least for the Android platform) was to capture the entire user experience by running as an Android Launcher. That’s the key, and it’s something a browser-based experience will never touch.
Though it is likely that the browser as an app platform will reach feature parity with native applications, is the browser really the answer, as Google would have you think with Chrome and the Chromium OS? This is the case with Google’s Chromebook, where the browser is quite literally the operating system – and that’s the point. Users expect a highly unified mobile environment, where the services provided by an application are literally one with the operating system, forming a single user experience covering the niceties like interactive notifications, customized home screens/widgets and icons, not to mention the unified view of all native device hardware (camera, sensors, phone, etc.).
So should enterprise IT professionals turn away from HTML5 and demand native-only mobile apps and apps that meld the operating system, as with Android Launchers and Lock Screen widgets (as with DashClock)? Certainly not – mobile apps will likely always provide a much deeper, more unified mobile experience. But HTML5 will play a very important role in that experience. After all, what could be better than a single, cross-device content rendering engine nestled inside a native app. What’s most important is the user experience itself. Now if only HTML5 were complete and consistent across browser apps.