HTML5 : carrier grade Alex Rutgers / CTO@Momac / February 2013. Introduction Since HTML5 became mainstream media around April 2010 and I decided to create an overview article on HTML5 in the mobile space, many things have changed. This article provides a compact overview on these changes, mainly focusing on the impact in the mobile space and while doing so it s looking ahead what s next. The standardization process of HTML5 is now much streamlined with even a clear view on a roadmap having the HTML5.0 version available as stable recommendation by the end of 2014 and an HTML 5.1 specification recommendation by the end of 2016. To support the road map Adobe, Google, and Microsoft have provided significant funds to sponsor more complete W3C staff coverage to achieve recommendation Status for HTML5 for 2014. With the significant growth of the smart phone market share (ios & Android) HTML5 support on the mobile internet is now a hard fact, resolving constrains that blocked mobile internet innovations. The thinking behind HTML5, still unchanged, is to offer developers a complete suite of markup and API s that allow them to basically build any rich internet application using HTML5, CSS3 and (fast) Javascript. It was especially this thinking that keeps HTML5 important to the mobile platform and really something you should embrace. So how has HTML5 been used in the last few years in the mobile internet domain, and moreover, what could be a next direction? Changes since 2010 Like software packages the HTML5 specification is now under full version control and since 2010 five update versions have now been released aimed at solving issues and defects like omissions in the specification. While improving the specification the main intend and scope did not change, other than the cancelations of some API proposals like the Calendar API that was depreciated to pursue an alternative API design that is based on the current Web browser security model. More significant the IT market picked up on the HTML5 success, and has been creating comprehensive frameworks that are aimed at helping the technical HTML5 users to facilitate the development of mobile HTML5 applications. The top five mobile (and more screens) frameworks, triggered by HTML5 are Ripple, LungoJS, Joshfire, Sencha and Jo. Sencha was used to create a Facebook App alternative called Fastbook which is a better performing HTML5 Facebook App. While the specification grew more stable and many frameworks have been created another change in the market also happened, device (manufactures) and mainly the browsers on these devices start to really embrace HTML5, even Microsoft.
Device (Browser) support The following timeline on the html5 score tells the story how each mobile device/mobile operating system and mobile browsers continuous have been adding HTML5 support. The score is calculated by testing for the many new features of HTML5. Each feature is worth one or more points. As the score grows, more HTML5 features and APIs are supported within the mobile device and mobile internet browser. Illustration 1: HTML5 test score over the years for several browsers Change of device and browser market HTML5 support certainly does not end on smart phone browsers. Since 2010 the device and browser market has changed where many different tablet and phonlet devices have been released. Where ios & Android dominate market share, the browsers on these devices now have a high score on HTML5 support. In fact, the browser developers seem to fully embrace HTML5 support and implement the
HTML5 specification in browsers for even more devices such as game pads, consoles and smart TV. Because of this wide range of support, HTML5 has become a great multi screen technology. Responsive design and fluid rendering While the HTML5 specification matured, devices and browsers went multi screen. The early ideas on how to support 'any kind of screen format could finally materialize with HTML5 and especial CSS3 s media query support. Multi screen design had to become adaptive as the layout needs to be automatically adjusted to fit all display resolutions and devices.css3 with media query support made this really much easier. The impact of this development is that a single created HMTL5 web page can adjust itself to almost any type of device ranging from a smart phone, phonlet, tablet, laptop, PC, game console, and smart TV delivering true multi (touch) screen support. While this achievement is really a great improvement, at the same time we need to realize that the type of applications used on any of these screens is different screen by screen, where the information density that can be provided differs. As a consequence modern responsive designs include the concept of supporting multiple dynamic layouts that can be presented depending on the actual device and browser the page that is rendered. A well equipped CMS would be able to produce the right layout based on the device as used by the end user to visit the HTML5 page, providing true multi screen support. Mobile First approaches supported by HTML5 Since 2010 the approach towards mobile of several players in the internet/web market is changing. This change is facilitated by HTML5. Some over the top players, media companies but also carriers and affiliates now see mobile internet as their primary market domain, and when a new development is started, the mobile first approach is chosen with HTML5. This approach puts the smart phone and tablet support first and asserts that the new service is fully tested and tailored to run on most modern mobile devices, while support for larger screens like fixed PC or Smart TV is put second or limited. Mobile Self care in HTML5 A concrete example of a new mobile first approach, aided by HTML5 technology, is in the domain of the carriers and the way they deliver care to their subscribers. Traditional carriers embraced the standard PC web technology and provided additional channels like a call helpdesk and IVR, and never seriously considered the mobile devices they were selling as a potential channel to deliver efficient care to their subscribers. This attitude has been changed almost a 180 degrees. Recent developments have placed the user and the mobile device in the center where mobile self care is now fully possible on device. With sophisticated HTML5 applications subscribers can track their data and voice usage, change their subscription settings like their roaming profile, and get internet boosts when needed. HTML5 technology such as the versatile canvas element has lead to a range graphical libraries (like Rgraph or OCanvas) allowing developers of HTML5 pages to quickly insert a gauge or graph that represents the subscriber usage data together with their current service level. Illustration 2: 2: monly compact spending overview of montly usage of a subscriber overview 1
Within the mobile service domain, carriers also start use the on device approach as a viable marketing channel to push & advertise their existing and new services as the mobile subscriber is now a returning visitor in the self care space. Network type detection, handling and profiling in HTML5 HTML5 technology also allows browser clients to detect and collect information on the service level of the network they are connected with. Trough the HTML5 System/Networking API information can be collected on the Network type. For example if the device is connected to the 3G or wifi network the device is connected via 3G or Wifi network or check the actual connection speed via the HTML5 navigator.connection.bandwidth DOM attribute. With this information a HTML5 page can not only respond on the device properties such as the screen dimensions and the number of pixels in it, but also adjust the user experience by using the collected network information, where lower bandwidths may lead to reduced page and media size tailored to a slower performing network. Illustration 3: A performance dashboard Not only the responsiveness of the user interface can be controlled via these API s. With the network status information it is also possible to switch to another connection that may be available on a congested 3G network in a football stadium. The HTML5 application could switch to a carrier defined wifi offload network so e.g. replay video s of the current game can still be viewed on the mobile device. With these API s the carrier is also able to collect real time network performance from each individual device, enriched either with GPS or mobile cell information, providing fine grained insight in the actual performance of the carrier network. Native versus HTML5 Applications Since the start of HTML5 many articles discussed native versus HTML5 application development. The discussion is still going on where HTML5 is getting more terrain that proves some of the claimed arguments are true. Mainly the once develop and deploy easy cost argument plays a role in areas where many commodity applications don t reach the top 10 attraction in itunes or Google Play but still need development, maintenance and support. Also the choice native versus HTML5 doesn t have to be so black-and-white where a new way of thinking emerged allowing to use the benefits of both worlds: the hybrid approach.
Hybrid HTML5 applications Today native application developers can choose to implement an app in 100% Native OS code, or include a (thin client) browser component that supports HTML5 within the native application to render the markup that is provided through a web server. This flexibility is depicted in the following diagram. The Y-axis represent the amount of native or HTML code used. Illustration 4: a code comparison between 100% native and hybrid application Typical the native code in a hybrid environment would implement the features that prove still to be difficult within a pure HTML5 browser based application, for example creating a native menu, and access device specific information, like SIM card settings or collect specific device information like cpu load. Fragment Application Caching One of the main recurring arguments in the native versus HTML5 discussions is the performance that can be achieved using HTML5. Where Apple s ios delays the rendering of markup in a native application this argument is valid. With the HTML5 Application Cache API it is possible to optimize the rendering performance of the HTML5 markup. The HTML5 page and the web server would have to support fragment caching that allows the client and the web server to exchange information on what elements in a page have changed and which not. The unchanged fragments can then be pulled from the local storage trough the HTML5 Application Cache API, resulting in native behavior. HTML5.next HTML5 will continue to develop into versions like HMLT5.1 and on. W3C & WHATG are adding new features to the specification like the support for the <template> element. This element could reduce communication overhead and increase rendering performance due to re-use principles. Most
professional multi screen CMS systems also have the option to define templates so this proposed HTML5 feature is a smart improvement which aligns great with existing technology. With HTML5.next, W3C is also collecting new ideas and suggestions on the development of HTML5 such as the <decompress> element to integrate files from ZIP folders into web pages directly or the responsive image handling that simplifies issues with retina displays like different Dots Per Inch (DPI s), slower networks, zooming and cropping. Conclusion Since 2010 the implementation of the HTML5 standard is becoming a commodity feature for a device with a browser component. The support is ubiquitous which implies that HTML5 is a standard carriers really can and must rely on. HTML5 continues to enable and facilitate web developers to build a breed of mark-up applications which would not have been possible with this standard and will keep evolving adding more features as new type of applications will require this. Besides the evolving HTML5 markup standard it may be a good time also to take a closer look at all the web (server/ backend) API s that are used to implement HTML5 applications. At technical API level (REST, XML, JSON) standardization works. However the industry still suffers from lack of use of business API standards at their back-end system which is impeding the integration value chain. While extensive business API standardization exists in many forms and shapes (like IEEE, OAuth, OpenID, BizTalk, NGN Open API, Parlay X and TMForum) there could be a fundamental issue why business API standards are not being applied on a large scale and with success like HTML5. Perhaps a similar success HTML5 pattern could be re-used where a new special interest group would take the lead on a new business integration API standard that could inspire more efficient mobile (application) development. Alex Rutgers is the Chief Technology Officer with www.momac.net. Momac specializes in partnering with media companies and mobile operators to create powerful mobile internet sites and profitable mobile operator portals. Follow Momac on Twitter #momac