HTML

HTML5 or Native?

Facebook CEO Mark Zuckerberg has gone down on record as stating that developing with HTML5 was “one of the biggest strategic mistakes we made.” Does that mean you should not use it in a corporate environment? Far from it.

Facebook CEO Mark Zuckerberg has gone down on record as stating that developing with HTML5 was “one of the biggest strategic mistakes we made.” Does that mean you should not use it in a corporate environment? Far from it.

Keep in mind that Facebook started to switch to HTML 5 nearly two years ago, when the standard was far less mature. The apps produced with it ran slowly and unreliably, at a time when other mobile applications offered a much better user experience. As a result, Facebook was forced to backtrack and create mobile applications on iOS and Android. As Zuckerberg explained, “good enough is not good enough. We have to get the highest quality level, and the only way we'll get that is to do native.”

What does that mean for developers in corporate environments who want to build apps? Is HTML5 still an option? According to Ojas Rege, the former head of Yahoo's mobile products, “The HTML versus native question is not an enterprise- or consumer-specific question. It's a user-specific question.” Before you decide how you will create the app, then, you need to consider how its end users will use it. According to Rege, enterprises need to consider five factors that will affect the user experience for corporate apps.

First, look at your end user's connectivity situation. Will the app be used in an area with poor wireless Internet access? Then you should not create a web-based application to fulfill that purpose. For example, a cross-country truck driver probably should not be using an HTML 5 app. Such apps may also be unsuitable for workers in remote or rural areas.

The second point you should consider is the variety of devices that will be utilized. If your app will accessed in a heterogeneous environment by a whole range of different devices, you may want to use HTML 5. But if one particular system truly dominates, you may want to cater to users of that platform and go native; you'll give them a better experience.

The third matter to take into consideration is the sensitivity of your data. Will users of your app be accessing and working with highly sensitive data, such as proprietary information or sales figures? In that case, you might want to go with an HTML 5 app. With that kind of application, you can make sure that all of the data remains on the server, and not permit employees to hold it on their local machines.

The fourth item to consider when choosing between going with an HTML 5 or a native app is how your user will interact with the data. I know, all of these points have covered that issue from different angles, but this one is more a matter of how the user will interact with the application itself. If they will be filling out a form or engaging in a similarly simple activity, HTML5 will work just fine. If they need to do something more complicated, however, you may want to go with a native application.

Finally, you'll need to think about how important it is for the application to be able to access functions on a specific device. Native applications can usually reach and utilize more functions on their own devices. For example, if you're building a warehouse app that will use a device's camera to scan bar codes or QC symbols, you may want to go native.

Choosing between using HTML5 and going native to build your corporate applications should not be done lightly. You must keep the user experience in mind, or your app will fail. Hopefully these five points will help you make the right decisions for your environment. Good luck!

DISCLAIMER: The content provided in this article is not warranted or guaranteed by Developer Shed, Inc. The content provided is intended for entertainment and/or educational purposes in order to introduce to the reader key ideas, concepts, and/or product reviews. As such it is incumbent upon the reader to employ real-world tactics for security and implementation of best practices. We are not liable for any negative consequences that may result from implementing any information covered in our articles or tutorials. If this is a hardware review, it is not recommended to open and/or modify your hardware.