1. Facebook and HTML5
Last week we briefly touched on the fiasco when Facebook relied too heavily on HTML5, and not enough on Native Mobile Applications. In August of 2012, the Engineering Team at Facebook wrote about the evolution of their iOS app from being a native mobile app to a HTML5 hybrid. They explained that while HTML5 on its own was a good start, users of the larger platforms (iOS and Android) needed something catered more to them: something faster and more reliable.
The hybrid HTML5 and Native Mobile App used allows for Facebook to leave sections of the app in HTML5 where they know they will need to constantly update; this way users will have instant fixes, versus having to wait for a new update to the app.
At the Disrupt SF 2012 convention, Zuckerberg mentioned that Facebook had wasted 2 years working on HTML5 design for Facebook. “The biggest mistake we made was betting too much on HTML5 … but it wasn’t good enough. We realized the only way we could get there was to go native.”
Moral of the story for libraries considering HTML5: For a deeper connection with your customers and patrons’ mobile devices, you should invest in mobile apps.
2. Goko Reboots with a New Mobile Strategy After HTML5 Failure
In August 2012, Goko attempted to release their cross-platform social games Dominion and Catan World. Two days after the release of their games, the games were rolled back from the markets. Why? HTML5 was not ready for the social games at the scale they were released on.
As Dean Takahashi of Venture Beat wrote, HTML5 was not fast enough to support the action games, “it didn’t support audio well, and it didn’t scale with large numbers of users”.
In August 2013, Goko rebooted their strategy, along with the help of Ludei—an HTML5 game developer—and created HTML5-formatted Native Mobile apps that will be released in the near future.
Moral of the story for libraries considering HTML5: If you want speed, audio and want your mobile strategy to scale with large numbers, it might be best to look somewhere other than HMTL5.
3. Wooga’s Pocket Island
Like the others, Wooga, a Berlin-based social game developer, had a run-in with HTML5 that left them wanting.
In May 2011, Wooga made the decision to launch “Magic Land Island”, an HTML5 version of it’s popular Facebook app, Magic Land. The game was launched in the following October. Similar to Goko’s tale, HTML5 was not ready to sustain their game. Wooga cites a “long initial load time, lack of sound on mobile and the reliance on being connected to the internet” as their main problems with the HTML5 game. Another issue they ran into was how players were accessing their game; since it was not a native mobile app, users couldn’t just tap an icon to quickly launch the game. Users had to launch their browser and log back in, which lead to a decrease in usage of the game. To assist with accessing their game, Magic Land—the game’s native app—added a cross-link to help boost installs. After some reworking, “Magic Land Island” was launched into the iOS app store. The HTML5 code is still available, open source, through Pocket Island.
Moral of the story for libraries considering HTML5: Be wary of relying on HTML5 instead of native mobile apps if you are going to need sound, a reliable internet connection and an easy way to access your app that encourages return visits.
4. Security Issues
Ok, so this last section isn’t about a specific site failing with HTML5, but it does highlight a potentially huge flaw of the design.
In March 2013, MXSweep announced that websites using HTML5 have a security loophole, which allows for data to be downloaded onto visitors’ computers, without the visitor noticing. The company has notified web security experts in an attempt to close the loophole.
With local storage being an integral part of the HTML5 protocol, developers have to consider the risks that attackers can retrieve or manipulate data, which can then be re-uploaded to the servers.
Moral of the story for libraries considering HTML5: If your library does choose to go with HTML5, make sure your developers take into account the potential dangers that are associated with HTML5 and adjust their design.
What does this mean for libraries considering HTML5?
Libraries should take into account these four examples of HTML5 failures. As a Library, chances are you won’t need to worry that HTML5 doesn’t fully support audio (although this may change soon with new music and video streaming services); but the security issues and the lack of a straightforward way to return to the site are something to keep in mind.
