The HTML5 Myth

- By:

Courtesy of Retriever Communications

The hype around HTML5 is loud, bountiful and at face value it appears to provide answers to all the key dilemmas in the mobility app market – independence from the operating system, a coding environment that is already a common programming skill and it steps around those pesky corporate security issues raised by iOS and Android.

Too good to be true? Absolutely.
HTML5 is actually a great answer to many mobility environments, specifically if you have lots of customers who need to access your services now and then – like the mobile purchase of an airline ticket or hotel or a consumer rental reservation for cars, for example. If the mobile experience is a bit slow, or if it fails, we as consumers have been taught to start again, the convenience is worth the frustrations that we sometimes meet.

By contrast, lets imagine a business service delivery environment: a service technician calls at your home to fix your washing machine and is using an HTML5 app. The coverage in your laundry by his telco provider is inadequate, i.e. no coverage. He needs to look up your machine’s serial number to ensure you are under warranty, however for his app to work he must go outside to the road and get verification. He comes back in and fixes the washing machine problem but to do his paperwork – a safety check to ensure his insurance coverage, actions taken, parts used, time taken – he has to go back into the street to upload what he has entered and get to a finalisation screen.

Unfortunately, on the way back to his van, the app fails and he must start again. As this example clearly illustrates, HTML5 lacks the robustness required in a business scenario.

Had our technician’s company developed a native app, say just for the iPad then this lack of coverage would not have been an issue as they work out of coverage, however the app would be constrained to only working on the Apple operating system and in a world of Bring Your Own Device and sub-contractors that is not a commercially workable solution.

So are there other mobility design approaches that would help our technician? Well there are HTML5 hybrid and cross platform toolkits to consider.

Hybrid apps commonly have HTML5 code for the screen and basic description but have an additional envelope of code that gives the app all the things that HTML5 cannot do: take a GPS reading, read input from a barcode, have and manage a database. So now, the technician can get the data and work offline in your laundry room. However, we have lost the independence of being able just to work in just any browser; we are now limited to the browser supported by the hybrid platform supplier under specified operating systems. Nevertheless, the technician is now happy that he can use his barcode reader to take in the serial number, activate a GPS marker for proof of presence or take a photo if the damage to the machine was going to cause a warranty debate later. So the story is good until we have a device failure on the way back to the van. HTML5 hybrid models cannot take the technician back to his last contact with the service, it cannot track the technician’s data activity and reference file updates at an individual level, so recovery means having to ask the back office accounting system what parts the technician had in his van and what jobs he had left to do today. This is a slow, difficult and complex procedure.

HTML5 Hybrid apps are very much back to the future as they are missing data synchronisation capability. This technology dominated mobile business app development for the past decade; it means that data transfers are specific to and from the end user in the field and are changes only, not whole files. The benefit is that a sync can update a technician’s parts list with new parts available, or delete discontinued ones, rather than having to resend the whole parts file. Similarly, synchronisation tracks what work orders a tech has, which ones are completed, pending etc. so if his device fails in some way it can be reconstructed immediately over the air from the mobile server without reference to back office systems. Is this important? It is if you want field workers up and running quickly after device issues, or if you want to lower your wireless data traffic for cost or speed issues. Historically, most mobile application vendors achieved this by using the embedded sync technology from Microsoft rather than developing it within their own platform. However, with Windows Mobile 7 Microsoft effectively left the business mobile platform market and their synchronisation technology came to a dead end. Most mobile application vendors had nowhere to go easily so HTML5 beckoned with its device agnostic marketing. That data synchronisation was abandoned and was fundamental to capability but it has never been raised by IT analysts or in the press. Odd?

So how would a cross platform toolkit with a native app work for our technician still stuck in the laundry? His app would be able to address barcodes, cameras and GPS capabilities – all good – and he would have a local database so coverage is not an issue. The app would also be native and so more than likely faster and more intuitive to the device than HTML5. Cross platform environments allow app generation to all mainstream operating systems and devices so good there too. However, he still needs a data synchronisation capability to address the recovery scenario of a failed device.

So a native app with data synchronisation and an ability to move cross platform would seem to be the answer for core business applications with HTML5 only for transient customer or consumer apps.

So why is there the HTML5 tunnel vision in the market today?
Perhaps it is because HTML5, like any web based environment, is the answer to the IT department’s prayers: easy to distribute, no version control issues. This is all great for IT. However, as shown above it is not great for the end user: they give up reliability, ease of recovery and the intuitiveness and speed of the app. So who wins? The conversation may be currently dominated by IT but the winner is always the end user. If people don’t like the app they won’t use it, they will then suggest that your competitors or even their other consumer smartphone apps work better so why should they co-operate. Internal sponsors withdraw support and all the IT arguments and prejudices fade to black.

Customer comments

No comments were found for The HTML5 Myth. Be the first to comment!