So without further ado, here is the first of my "FAQs" on HTML5 in the car. If you have a question and you don’t see it answered here, leave a comment and let me know! I’ll try my best to answer it in a future post.
How can you create multiple in-vehicle user interfaces using a single HTML5 code base?
The key to achieving this is the Cascading Style Sheets language, or CSS.
CSS controls the look and feel of web pages, but it can also be used to control the look and feel of a vehicle head unit. By changing a single CSS file, you can, for example, change all the fonts and background colors in a website (or head unit) from Arial and white to Verdana and black.
Mind you, CSS does much more than that. It also lets you specify how individual tags in HTML documents are displayed: layout, margins, sizes, colors, behavioral characteristics, events, and so on. Consider, for example, a phone app accessed through the vehicle head unit. If that app provides an HTML5-based user interface, each OEM could provide a default CSS that controls how the app looks on the head unit, adapting the app to meet in-vehicle usability standards and, of course, branding it.
A sample app from the QNX CAR 2 application platform, created with HTML5 |
Keep in mind, though, that CSS can’t solve different OEM input philosophies, such as touch, hardkey, softkey and so on. You could use CSS to change the appearance for different inputs, but you would still need to have JavaScript hooking things up underneath.
You mentioned that cross-platform execution is a key benefit of HTML5. Do you have any recommendations on how to implement it?
Cross-platform execution is definitely something you want to keep in mind when designing software for vehicle head units. If you’re careful to ensure your app avoids features specific to the embedded environment, you can use mobile and embedded apps with the same HTML5 code base. It shouldn’t be difficult to make sure your app runs in both environments, but it’s better to plan for this going into design. That way, you can avoid using anything that prohibits cross-platform execution.
Could HTML5 replace the current HMI systems in head units that support multiple applications, and still be event driven and asynchronous in nature?
Definitely. JavaScript in HTML5 supports the concept of separate threads, called workers, that can handle events asynchronously. Although workers have some restrictions, such as the inability to modify the Document Object Model (DOM) or access globals, they should still be able to handle most asynchronous events. Maximum flexibility may require additional support from the HTML5 engine. To that end, QNX Software Systems has invested a lot of time in improving WebKit to allow code to run in separate engine web views, in different threads, in different processes, and even in completely independent HTML5 engine instances.
Stay tuned for Part II, where I plan to tackle questions on web browsers, web servers, and instrument clusters.
No comments:
Post a Comment