Offline Mode: The Elephant in the HTML5 Room

Offline Mode: The Elephant in the HTML5 Room
Digital sovereignty

Disconnected-645x250

There seems to be 3 groups of people involved in the HTML5 discussion:

  • Evangelists, whose role is to push technology adoption.  In most industries they’d be called salespeople but in Tech we like to coin words to make us sound specials so the tech evangelists were born!  They are comprised of both staff from large corporations who have a direct interest in HTML5 getting used as well as members of consulting companies who have a vested interest in the technology taking hold so that they can sell new services to their customers.
  • At the opposite end of the spectrum are the “Natives Protectors”.  This group is comprised of people vested in the development of native apps and seeks to protect their turf.  Between each group the conversation often sounds like a tech version of “mine is better than yours and by the way, you suck”
  • Then, in the middle are the developers.  People like you and me who need to make technology decisions about the roadmap for our software and the technologies we will take to take us there.  And once you are part of this group, you know that there is no single technology that solves all the problems in the world.  You also know that few things are more annoying than hearing people on either side claim that their approach is the “right one”.

So today, while we are heavily vested into HTML5 as a technology for our software, I’d like to share what I see as a major down fall of HTML5 at the moment:  Disconnected State.

By disconnected state I mean, “how on earth is our application supposed to behave once the device is not connected to the internet”

Devices lose connectivity all the time. Just looking at my past few days you can see the fickleness of connectivity:  I had no connection in the train between Germany and France.  Then, at my place, there seems to be a spot that simply gets no coverage.  The Parisian subway is hit or miss, and I am about to board a plane in a few minutes and Air Chance does not offer in-flight wifi.

How bad can it be to not have a connection?  Sometimes it is merely an annoyance, as you cannot properly experience a software or game. For example, try out the following game, both connected and disconnected and you will see how different your experience will be: http://mapdive.weareinstrument.com  (I apologize in advance if this link ends up wasting half your day!)

Sometimes it will lead to a direct lack of productivity.  One of the reasons we do not use Google Docs that heavily in our company is that it is a pain to use without a web connection!

HTML5 is still very much in flux with W3C still discussing which storage and best practice standards should be required for disconnected-app.  As these groups work though the different options, developers need to make some strategic decisions on how software should behave when the device is disconnected.
For example, developers will need to address:

  • Should the software be accessible at all when the device is not connected?
  • Which flavor of local storage (cache, local, DB) should be used in case the application needs to function when the device is disconnected?
  • Are there some features that need to be “turned off”?
  • What about security?  Does the data stored on the device need to be secured in any way? Would it be a problem is the device is stolen?
  • If an app can work in a disconnected state, which rules should be put in place in terms of synching once the device becomes connected again?

Granted, all these concerns are operational and should also be addressed when developing a purely native app. However, the fact that there is no current “official” standard on how to store and secure the data locally via HTML5 forces up to think about the disconnected state more globally.
If you create HTML5 applications that work in a disconnected state, feel free to share your approaches and concerns as well as what you feel is the Elephant in the Room in the world of HTML5.

Photo courtesy of TheNextWeb