HTML5 for HMI

There are some common rules in the design of user interfaces (UI) in embedded systems, such as, “use common dialogs and buttons familiar to your users” or “keep it simple by limiting user activity, as much as possible, within the context of the current function”. The design of these buttons, dialog boxes, help screens and other widgets are not always easy to create in resource-limited embedded systems. What is needed, is an easy and efficient way to create these widgets. HTML5 could help in that.

HTML5 is everywhere right now. And with good reasons it has growing popularity. HTML5 platform can add functionality and capabilities to your device, extending the life cycle of a current product and preparing applications for future platforms. Nowadays idea of building HMI based on HTML5+Websockets has become practical. The graphics and UI tools available via HTML5+CSS3+Javascript are starting be be amazing.

HTML5 is platform agnostic (the main goal is platform independence). Most/all of the UI heavy lifting would be offloaded to the browser on the client size and not using resources on the embedded device. Using web sockets, communication between embedded device and browser would actually be more akin to a peer-to-peer architecture than client-server.

HTML5 and its ancillary technologies (CSS3, JavaScript, AJAX, JSON, etc.) offer an excellent, non-proprietary solution for building rich, device-agnostic HMIs. HTML5 is not very far way. W3C recommendation status for HTML5 is expected in 2014. Many of HTML5 features are already implemented in web browsers today (both on desktop and mobile devices).

Find out how HTML5 affects your current and future products. Here are some pointers to more information:

Understanding HTML5 article attempts to bridge the gap between the musings and the tutorials and present a brief overview of HTML5 that will be useful to people who have technical background but are not already up to their elbows in HTML5. Article also has tip on how to optimize a bit of JavaScript for equalizing audio output.

HTML5 for automotive infotainment: What, why, and how? is a slide set that tells why HTML5 is a hot trend in automotive infotainment.

HTML5 Will Be The Technology Of Choice For In-Vehicle HMIs article tells that in the auto industry, and especially in the design of in-vehicle infotainment systems, the advent of the smart phone has changed everything. HTML5 is a non-proprietary and widely adopted standard that is already proving its worth in a wide range of implementations across a variety of industries, including automotive. If anything can help automakers deliver what their customers want in their in-vehicle infotainment systems at reasonable cost today and tomorrow, it’s HTML5.

QNX Auto Blog has a nice article series on HTML5 in car. Everything you wanted to know about HTML5 in the car, Part I article talks about CSS, cross-platform execution, and asynchronous design. Everything you wanted to know about HTML5 in the car, Part II turn the attention to web servers, native plug-ins, instrument clusters, and display updates. Everything you wanted to know about HTML5 in the car, Part III article turns attention to tools, touch gestures, UI performance, and vehicle resources. 8 steps to building a lean and mean HTML5 application article gives tips on HMI development for the QNX CAR 2 application platform.

PPS messaging connects HTML5 and hardware article tells that Human-Machine Interfaces (HMIs) developed with HTML5 reside in a high-level, virtualized environment, and they work well in this environment. This fact does not preclude their needing to access hardware. Unfortunately, like other high-level HMI technologies, HTML5 doesn’t offer a simple solution for communicating between the HMI layer and the many low-level components found in today’s systems.

Bridging the chasm between HTML5 and the hardware with PPS messaging article tells that writing specific interfaces to communicate between the HMI and each low-level service is a costly—and likely unsustainable—proposal. According to QNX Software Systems a better approach is to use an HMI-agnostic, asynchronous messaging model such as Persistent Publish/Subscribe (PPS): a service for pushing out changes and receiving notifications. PPS promises to provide a simple and effective way for the HMI to communicate with low-level components and the vehicle hardware.

QNX Software Systems has published quite many articles that talks about benefits of PPS. But that PPS must not be the only one choice around. The question is what are the more open alternatives to it? Any recommendations?

Conclusion

HTML5 is fast becoming not just a popular HMI technology, but the preferred environment for delivering rich, flexible user interfaces. HTML is no longer just the standard for presenting web content, but a viable technology for HMIs for all sorts of applications.