Mark Zuckerberg had harsh words for HTML5 today on stage at the TechCrunch Disrupt conference, saying that Facebook's big HTML5 bet was "one of the biggest strategic mistakes we made."
But just because it's not right for a high-profile commercial app, that doesn't mean corporate developers should ignore it and go all native.
Zuckerberg said that Facebook bet on HTML5 about 20 months ago -- that puts the decision back in early 2011. The company saw most of its mobile traffic coming through its mobile web sites (Zuckerberg said that's still the case today, with Facebook's mobile web sites driving more traffic than the iOS and Android Facebook apps combined). So rather than going with native code, Facebook decided to use HTML5 across the board -- any change to its web site could be fairly easily replicated in its mobile apps.
"It just wasn't ready," Zuckerberg admitted today. The resulting apps were slow and unreliable, while other mobile apps were offering a much better experience. Eventually the company realized that "good enough is not good enough. We have to get to the highest quality level, and only way we'll get there is to do native."
So a few months ago, Facebook shifted directions 180 degrees and started building native apps for iOS and Android. The iOS app came out a couple weeks ago to mostly strong reviews, and Zuckerberg said that engagement has already gone up.
So HTML5 was a bad choice for Facebook. Does that mean it's a bad idea for enterprise mobile apps as well?
Not necessarily. We spoke with Ojas Rege, the VP of Strategy for mobile device and app management provider MobileIron, and the former head of Yahoo's mobile products.
"He's right, Facebook made a faux pas on that one. They didn’t stop and think about how end users were using the product. The HTML versus native question is not an enterprise or consumer-specific question. It's a user-specific question."
Rege laid out five factors enterprises should consider when thinking of the user experience for corporate apps:
- Connectivity. If the user is operating in areas with poor wireless connectivity, giving them a web-based app won't work. For example, a utility worker reading meters in people's basements all day shouldn't be using an HTML5 app.
- Device variety. In heterogeneous environments with lots of device types, HTML5 might make more sense. But today, iOS dominates corporate environments, at least among the customers MobileIron talk swith. So serving multiple platforms is not as big a concern in the corporate world as it is for a consumer company like Facebook, which has hundreds of millions of users accessing its apps from every conceivable kind of device.
- Data sensitivity. If workers are accessing highly sensitive data, companies might want to favor an HTML5 app that leaves all data on the server, rather than letting employees work with it locally.
- Interaction model. HTML5 is OK for apps that have a fairly simple user experience, like entering data into a form or choosing from a few selections. But for more complicated apps, native is a better choice.
- Integration with on-device functions. Native apps may be able to access more built-in functions on the device, like integrating with the camera to scan information, or integrating with contact lists.
Under those parameters, HTML5 seems like it's not appropriate in very many corporate settings. So we asked Rege to name one.
"Hospitals," he said. "You'll have ubiquitous high speed bandwidth. You'll have sensitive data, so you'll want it to be stored on the server side. Depending on what the application is, some might require lots of complex inteactions, but some are very simple, like dosing applications, or patient rounding applicatons. Those could work very well for HTML5."
The key is not to shoehorn a web app into a mobile device at the expense of user experience, just to save developer time. "If you sacrifice user experience to make your developers' lives easier, the app will just fail."
Facebook learned that lesson the hard way.