HTML5, the latest, all-encompassing trend that seems to permeate every app launch in the blogosphere. Google has even discontinued their Google Gears product to throw their support behind the HTML5 specification which is, technically, still in draft status.

This will be a two-part series discussing HTML5's suitability for the enabling your mobile enterprise. Today, I'll focus on creating the mobile extension of your enterprise applications and a few key capabilities of HTML5. Next week, I'll focus on security and compatibility concerns that should be considered when reviewing HTML5 as an option.


HTML5 is the fifth major revision to the HTML specification aimed at reducing the need for plug-in's. It's the first major revision to the specification in almost ten years due in part to a decision by the W3C to stop evolving HTML and focus its' efforts on XHTML. Because of the W3Cs decision to focus on XHTML, HTML5 was primarily driven by Apple, Mozilla and Opera under the "Web Hypertext Application Technology Working Group" (WHATWG) until the W3C decided they did, in fact, want to participate in ~2006. HTML5 was originally created under the moniker "Web Applications 1.0".

Some features we will discuss are actually their own W3C specifications that are bundled with "HTML5" for discussion purposes. I'll try to point out when the topic being discussed is its' own specification.

Mobile Web Strategy

The development options available to you in modern mobile browsers are tremendous. Mobile browsers have evolved into powerful programs capable of displaying full versions of websites (minus Flash...on the iPhone/iPad). However, just because they can display a standard site, doesn't mean they should.

The driving force behind a typical enterprise mobile initiative boils down, in some way, to productivity gains (access to information, support the sales process, etc) realized by either your workforce or your end customers. It's difficult to augment productivity if users are constantly zooming-in, zooming-out and clicking the back button because they "fat-fingered" a link.

Keep these points in mind when preparing for your mobile initiative:

  • Design for mobile devices: First and foremost, the mobile app should not be a copy of your existing portal or web application, it should be an extension of it. Identify the key features to be used and make them incredibly easy to access and execute (i.e. enter lead, retrieve customer information, reserve a desk in the office, access credit card rewards information, pay a bill, etc).
  • Design for mobile connections: Yes, 3G can be fast and 4G sounds promising (while a ways off, yet), but you are still on a mobile for it. The storage options available in HTML5 can be powerful - explore them. Preload and cache frequently accessed data, use HTML5 form enhancements such as datalists (i.e. validations, new input types) to reduce calls to the server. These aren't without their own potential issues but, if implemented properly, can be powerful.
  • Design for the platform: Design and build web applications that mimic native platform applications. There are dozens of frameworks available on the web (especially for the iPhone) that can be easily implemented and turn your web app into a native looking app with a little Javascript and CSS. While this increases complexity and could increase load time, it will reduce adoption time and increase usability and user satisfaction allowing you to realize benefits earlier.

Benefits / Features

Now, with that long-winded primer over, let's jump into things. As I've said, HTML5 was initially created with web applications in mind ("Web Applications 1.0") so you'll notice that most of the new features lend themselves to that end.

  • Structured Client-side Storage: There are two interfaces that can be used for storing information on the client-side in a structured manner - web storage and web database. The current recommendation is that browsers limit storage to 5MB per domain. This is subject to change as feedback on the specification is received but it can also, usually, be changed at a domain level by the user (client-side storage can also be disabled in most cases so include proper checks...).
    • Web Storage: the web storage object allows you to store information in key/value pairs using a common set of get and set methods. Web storage is it's own specification and allows for two levels of persistence:
      • Session Storage: like it sounds, this object is used for storing session information. When you're done (close the tab, window, etc) the information is gone.
      • Local Storage: allows you to save data locally that persists beyond a single session. This could be used for storing a 'bookmark' of where the user last was, a count of the times a page was viewed, lite shopping cart, etc.
    • Web Database: also it's own specification, Web Database allows you to create a lite SQL database on the client-side. I'm sure you can imagine the possibilities (including for abuse - more on that next week) that this presents. Shopping carts, phonebook contact information, preloading of data in preparation for 'offline' mode are all easily within reach. Web Database has full query support, transaction support, and schema versioning. The possibilities are endless provided you understand the risks.
  • Offline Access (AppCache): AppCache is one of the features I get most excited about. AppCache allows you to make all, or portions, of your web application available to users without a network connection (airplane, subway, dropped connection, etc). Specifically, AppCache works by allowing the developer to create a manifest file and linking it in the root file (index.html) with an attribute in the HTML element. When the page is loaded it reads the manifest and cache's the files (html, js, css, etc) listed for use offline. The combination of AppCache and Web Database presents some powerful opportunities, especially for mobile applications.
  • Canvas: Canvas is another new element that was initially created by Apple for the Mac OS X Dashboard. The canvas element allows you to draw graphics in the browser, typically with JavaScript. The canvas element can be interactive and presents an incredible opportunity, executive dashboards quickly come to mind. Getting started with the canvas element is pretty simple but its' complexity scales with you as you work up the learning curve - a couple Google engineers even ported Quake 2 to the web using the canvas and audio elements, local storage and Web Sockets.
  • Video: Mobile video delivery is already HUGE and the new screens/devices (e.g. iPad) being introduced are only going to increase demand. I won't get into specifics of implementing, but the video element, quite simply, allows you to deliver video to mobile devices without the need for plug-in's (e.g. Flash). From an enterprise perspective, this could be an opportunity to deliver company presentations or training to executives on the run.
  • Geolocation: The Geolocation API is technically its' own specification and allows you to pinpoints the devices location. More specifically, the API uses a combination of GPS, user input, and information inferred from network signals such as IP, and WiFi and Bluetooth MAC addresses to get that location. The API uses latitude and longitude coordinates to communicate and is designed to handle one-time location requests and continual location updates. Accuracy is not guaranteed so keep that in mind when designing your app - turn-by-turn directions may not be a good idea at this time.
  • Forms: As you might imagine, web applications often require user input (user input = forms, forms = important). Understandably so, forms are a major focus area in the HTML5 specification. The creation of new input types (tel, email, date/time (renders a calendar in some browsers), etc), the addition of input element attributes 'required' and 'autofocus', and the datalist element make mobile forms more user-friendly and powerful. While the enhancements I just mentioned can improve user experience, they also improve our ability to complete client-side validation (don't forget to validate on the server side as well) which ultimately results in fewer round-trips to the server.

While not a comprehensive review of every change included in HTML5, this covers some of the core improvements that make HTML5 relevant to the enterprise. Tune in next week when I discuss security and compatibility concerns that should be considered. In the mean time, if you have questions, feel free to contact me.