 |
|
Mary Brittain-White |
The hype around HTML5 is loud and bountiful. At face value you would believe that HTML5 answers 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 freedom from the pesky corporate security issues raised by iOS and Android.
But is this idea too good to be true?
Absolutely. While HTML5 is a great answer to many mobility environments, specifically if you have many customers who need immediate access your services, such as apps that allow users to reserve airline tickets, hotel rooms or rental cars via mobile.
If the mobile experience is a bit slow, or fails, we as consumers have been taught to start again, the convenience is worth the frustrations that we sometimes meet.
In contrast, let's imagine a business service delivery environment. A repairman comes to your home to fix your washing machine, and he plans to use an HTML5-based app. The coverage in your laundry room from his telco provider is inadequate. 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. The repairman returns and fixes the washing machine, but in order 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 to get to a finalization screen. Unfortunately going back to his van his app fails, and he must start again.
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. However, an iPad-only app would be constrained to only iOS, 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? Consider HTML5 hybrid and cross-platform toolkits.
Hybrid apps commonly use HTML5 code for the screen and basic description but have an additional envelope of code that gives the app features that HTML5 cannot do: take a GPS reading, read input from a barcode, have and manage a database, etc.
So now the repairman can get the data and work offline in your laundry. However, we have lost the independence of being able to work in 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 read 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. 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. A slow, difficult and complex procedure.
HTML5 Hybrid apps lack data synchronization capabilities.
Data synchronization capabilities have dominated mobile business app development for the past decade. This technology means that data transfers are specific to and from the end user in the field and are changes rather than 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 file. Similarly, synchronization tracks what work orders a technician 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 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 platforms. However, with Windows Mobile 7, Microsoft effectively left the business mobile platform market and their synchronization technology came to a dead end. Most mobile application vendors had nowhere to go easily so HTML beckoned with its device agnostic marketing. That data synchronization was abandoned was fundamental to capability, but it has never been raised by IT analysts or in the press.
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 would not be an issue. The app would also be native and thus would be faster and more intuitive to the device than HTML5. Cross-platform environments allow app generation to all mainstream operating systems and devices. However, he would still need a data synchronization capability to address the recovery scenario of a failed device.
Therefore, a native app with data synchronization 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.
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. All great for IT. However, it is not great for the end user: they give up reliability, ease of recovery and the intuitiveness and speed of a native app. So who wins? IT may currently dominate the conversation, but the winner is always the end user.
If people don't like the app, they won't use it and will turn to your competitors or other consumer smartphone apps. Internal sponsors will withdraw their support, and all the IT arguments and prejudices fade to black.
The answer: the end user rules.
Mary Brittain-White is the founder and CEO of Retriever Communications.