Moving beyond the browser: HTML5 as an automotive app environment

If you’ve already visited this blog, you’ll know that we are bullish on HTML5 as a way to implement infotainment system HMIs. Not surprisingly, I’ve spent a fair amount of time searching the Web for facts and opinions on using HTML5 in the car, to see how this idea is catching on.

Overall, people see numerous benefits, such as the ability to leverage mobile app development to keep pace with the consumer demands, the availability of a large pool of knowledgeable developers, and the attractiveness of a truly open specification supported by many possible vendors.

But when it comes to the challenges of making HTML5 a reality in the car, I found a common thread of questions, mostly rooted in the erroneous belief that an HTML5 application environment is “just a browser.” Everyone is familiar with the concept of a browser, so it’s easy to see why people take this point of view.

So what are the key differences between a browser and an HTML5 application environment? Here’s my quick view.

The experience
Everyone is familiar with the browser experience. You navigate to a web site through bookmarks, a search engine, or direct entry of a URL. The browser implements a user interface (aka the chrome) around a rendering engine and provides bookmarks, URL entry, back and forward, scrolling and panning, and other familiar features.

An automotive HMI based on HTML5 provides a different experience — just look at the accompanying screen shots and decide for yourself if they look like a browser. In fact, the user experience of an HTML5-based HMI is similar to that of any other purpose-built HMI. It can consist of a main screen, window management, navigation controls, and other typical user interface widgets.


A radio tuner and a media player from the QNX CAR 2 application platform. Both apps are based on HTML5, but beyond that, they neither act nor look like a web browser.

A system that uses an HTML5-based HMI can include:

• core applications that look and act like native applications
   
• add-on (downloaded and installed) applications that have controlled interfaces to the underlying hardware
   
• “web link” applications that simply link to a cloud-hosted application that can be downloaded on demand and cached

The web link approach makes it easy to update applications: just update the server and the remote client systems will automatically pull the application when needed.

Local resources
Web browsers pull text, images, and other content from the web and render it on the user’s machine. The process of loading this remote content accounts for much of the user’s wait time. This paradigm changes with a local HTML5 application environment — because resources can exist locally, images and other components can load much more quickly.

What’s more, screens and user interfaces can be designed to fit the platform’s display characteristics. There is no need for panning and scrolling, and only limited need for zooming. Resources such as RAM can be optimized for this experience.

Security and sandboxing
Browsers load content and executable JavaScript code dynamically. This really is the power of the web technologies. The problem is, dynamically loaded code represents a threat to an embedded platform.

Browsers are designed to be sandboxed. By default, JavaScript code can execute only in the context of a browser engine, and cannot access the underlying operating system primitives and hardware. This approach changes in an HTML5 application environment. To give JavaScript code the ability to behave like a native application, the environment needs interfaces to the underlying OS through to the hardware. Plugins are used to implement these HTML5-to-OS interfaces.

Nonetheless, access to the underlying platform must be carefully controlled. Hence, a security scheme forms a critical component of the HTML5 application environment.

Application packaging
The app experience has become familiar to anyone who owns a smartphone or tablet. An HTML5 application environment in the car can also support this kind of experience: developers create and sign application packages, and users can download those packages from an application store. In an automotive context, authenticity of the applications and control over what they can or cannot do is critical. Again, a security model that enforces this forms a key part of the HTML5 application environment.

So, how should you think of an HTML5 application environment?
From my perspective, an HTML5 environment is like any other traditional HMI toolkit, but with much more flexibility and with inherent support for connected applications. In an HTML5 application environment, you can find technologies similar to those of any proprietary toolkit, including:

• a rendering engine (HTML5 rendering engine)
• a set of content authoring and packaging tools
• layout specifications (HTML5 and CSS3)
• a programming language (JavaScript)
• an underlying data model (DOM)

The difference is, these components are developed with a web experience in mind. This, to me, is the most significant benefit: the web platform is open, scalable, and well understood by countless developers.

Report from CTIA Wireless: Apps in the Car

You wouldn’t think that CTIA Wireless, a mobile show, would be a good venue for a car guy. But automotive journalist Doug Newcomb put together a set of panels that managed to attract everyone from the automotive industry who attended the show.

I met a good number of friends from a variety of automakers, tier one suppliers, and hardware and software vendors. I also had the distinct pleasure of participating in one of Doug's panels, which was moderated by Damon Lavrinc of WIRED.

The topic was the future of apps in the car, and it generated a spirited discussion. Panel participants included Geoff Snyder from Pandora, Michelle Avary from Toyota, Henry Bzeih from Kia, and Scott Burnell from Ford — all experts on the topic.

Andy speaking on the

apps panel. Videos of all

the panels are now online.

In general, we agreed: apps are coming to the car. They have already arrived in several cases, and it’s only a matter of time before they come to mass-market vehicles. And apps are not for North American alone: it's a worldwide phenomenon.

Mind you, we engaged in lively debate on a number of questions: What role does the mobile app developer play? How to deal with the fragmentation caused by different OEM app platforms? How to deal with driver distraction? And when will the "one man app" ever make it into the car? We all had good and varied opinions on these topics, and the session was very well received by the audience.

Derek Kuhn, QNX vice president of sales and marketing, also participated in a panel session, titled "Can we all just get along… for the consumer's sake?". That panel focused on how the industry as a whole can create a more seamless experience for the consumer. Derek's co-panelists included Mark Harland from GM, Leo McCloskey from Airbiquity, Brian Radloff from Nuance, and Niall Berkery from Telenav.

Did I mention? Videos of all the panels are now on Doug Newcomb's website — check them out!
 

OnStar RemoteLink app comes to BlackBerry smartphones

This just in: The RemoteLink App from OnStar, which allows smartphone owners to remotely start their vehicles, check fuel levels, and lock or unlock their doors, is now available for the BlackBerry Bold 9900 and 9930 phones.

RemoteLink has been available for iPhone and Android phones, but many OnStar subscribers have asked for a BlackBerry version of the app. In response, Onstar wrote a new version for the BlackBerry platform, in HTML5.

“Writing the app using HTML5... positioned us to be more flexible supporting new phone operating systems,” said Steve Schwinke, director of advanced systems development for OnStar.

Opening screen
for RemoteLink
© GM Company 

In 2011, OnStar added navigation to RemoteLink, allowing users to search for a destination on their smartphone and send it directly to their vehicle. Users can then access the route through the QNX-powered OnStar system.

By leveraging OnStar’s connection to the vehicle, the app can report on oil levels, tire pressures, fuel level, and lifetime miles per gallon. It also offers remote commands, such as remote start, door lock/unlock, and horn/light activation.

According to OnStar, a total of 821,000 smartphone owners actively use the RemoteLink app.

To read OnStar's press release, click here. To download the RemoteLink app from BlackBerry App World, click here.

On a related note, here's a conversation between QNX's Andy Gryc and OnStar's Steve Schwinke. The topic: how HTML5 can benefit the auto industry.


 

Sound "bytes" from CTIA Wireless 2012

Several of my colleagues went to CTIA Wireless this week, and yes, they took the connected Porsche with them. No surprise there, of course: we’ve also taken the car to CES, MWC, BBW, and numerous other events. (Sorry, I’m really into acronyms today.) The Porsche, with its QNX-powered mobile connectivity and HD hands-free audio, seems to impress people no matter where it goes, and the reaction at CTIA was no different. In fact, the folks from Black Enterprise were so stoked, they awarded the car a CTIA Best in Show award. How cool is that?

Here’s a snap of the award, sitting on the car’s dash:



Meanwhile, Boonsri Dickinson of BYTE met up with Andy Gryc to ask him about QNX’s vision and technology for the connected car. Here's a video of their conversation — in the Porsche, of course:



Andy didn't spend all of his time in the passenger seat. Both he and Derek Kuhn also participated in connected car panels moderated by automotive journalist Doug Newcomb. The panels included "Apps in Automotive: The Future of In-Car Content" and "Can We All Just Get Along, for the Consumer's Sake?". From what I've heard, both sessions were taped, and I hope to post a link to the videos next week.
 

Rockin' the phone at BlackBerry World

I'm at BlackBerry World 2012 (as you already know if you're following my tweets), and it really is amazing.

In his keynote, RIM's CEO Thorsten Heins provided stats on how the average BlackBerry user isn't just connected, but hyper-connected. BlackBerry users engage in more social media, use more organizational tools, and download more apps per day than other smartphone users. (I wasn't quick enough to type up all the stats, but I'm sure you can find them elsewhere.)

Introducing the BlackBerry
10 dev alpha device

Is the BlackBerry platform an entertainment tool? Productivity tool? Social media hub? All of these, but more than anything else, BlackBerry creates success. The 77 million BlackBerry users worldwide are more agile, productive, competitive, and nimble than their counterparts.

Here are some great factoids I was able to capture:

• Mippin is a worldwide mobile development shop responsible for 50,000 apps on iOS, Android, and BlackBerry. But BlackBerry accounts for 70% of their downloads.
   
• Occipital offers a very cool panorama camera app, which they demo'd this morning. It took them only 7 days to port to BlackBerry 10, and it already performs better than the Android version.
   
• Fishlabs creates mobile games. It took them one day to port Galaxy on Fire to the BlackBerry PlayBook tablet. (And it is one awesome app — I gotta go download it tonight :-)
   
• App World for the PlayBook underwent 240% growth in Q4 2011.
   
• 90% of Fortune 500 companies standardize on BlackBerry.
   

Stay tuned for more pix and reports from what promises to be an awesome show!

HTML5: Bustin' the myths

Did you know you can build HTML5 apps that don't use an Internet connection? Did you know you can run HTML5 apps without a web browser? And did you know HTML5 apps can show snappy performance even on automotive silicon? (As you can well imagine, in-car infotainment systems don't ship with quad-core server-class CPUs.)

If you answered no to any of these questions, you need to stop for a minute and check out this interview with QNX Software Systems' Kerry Johnson. Heck, even if you answered yes to all three questions, you'll probably still appreciate what Kerry has to say — and besides, you'll catch a glimpse of a complete in-car UI coded in HTML5. What could be bad?



While I have you, check out Andy Gryc's Q&A series on HTML5, if you haven't already. You'll find the first two installments here and here.
 

Tech-nimble

After working more than 20 years in high tech, I've settled on a mantra: This too shall pass. (Hey, I didn’t say it was original!) To that end, patience is critical, as is flexibility. And ultimately, success depends less on predicting technology trends and more on responding to them. You've got to be tech-nimble, which requires not only the willingness to change, but the technology to accommodate — and profit from — that change.

Yesterday, Adobe announced a restructuring based on a change in direction, from mobile Flash to HTML5. Some might consider this development as proof that Adobe lost the battle to Steve Jobs. But to my mind, they've simply recognized a trend and responded decisively. Adobe has built a product portfolio based heavily on tooling, including tools for HTML5 development. So they definitely fall into the tech-nimble category.

QNX has an even greater responsibility to remain tech-nimble because so many OEMs use our technology as a platform for their products. Our technology decisions have an impact that ripples throughout companies building in-car infotainment units, patient monitoring systems, industrial terminals, and a host of other devices.

So back to the Flash versus HTML 5 debate. QNX is in a great position because our universal application platform approach enables us to support new technologies quickly, with minimal integration effort. This flexibility derives in part from our underlying architecture, which allows OS services to be cleanly separated from the applications that access them.

Today, our platform supports apps based on technologies such as Flash, HTML5, Qt, native C/C++, and OpenGL ES. More to the point, it allows our customers to seamlessly blend apps from multiple environments into a single, unified user experience.

Now that’s tech-nimble.
 

When will I get apps in my car?

I read the other day that Samsung’s TV application store has surpassed 10 million app downloads. That got me thinking: When will the 10 millionth app download occur in the auto industry as a whole? (Let’s not even consider 10 million apps for a single automaker.)

There’s been much talk about the car as the fourth screen in a person’s connected life, behind the TV, computer, and smartphone. The car rates so high because of the large amount of time people spend in it. While driving to work, you may want to listen to your personal flavor of news, listen to critical email through a safe, text-to-speech email reader, or get up to speed on your daily schedule. When returning home, you likely want to unwind by tapping into your favorite online music service. Given the current norm of using apps to access online content (even if the apps are a thin disguise for a web browser), this begs the question — when can I get apps in my car?

Entune takes a hands-free
approach to accessing apps.

A few automotive examples exist today, such as GM MyLink, Ford Sync, and Toyota Entune. But app deployment to vehicles is still in its infancy. What conditions, then, must exist for apps to flourish in cars? A few stand out:

Cars need to be upgradeable to accept new applications — This is a no-brainer. However, recognizing that the lifespan of a car is 10+ years, it would seem that a thin client application strategy is appropriate.

Established rules and best practices to reduce driver distraction — These must be made available to, and understood by, the development community. Remember that people drive cars at high speeds and cannot fiddle with unintuitive, hard-to-manipulate controls. Apps that consumers can use while driving will become the most popular. Apps that can be used only when the car is stopped will hold little appeal.

A large, unfragmented platform to attract a development community — Developers are more willing to create apps for a platform when they don't have to create multiple variants. That's why Apple maintains a consistent development environment and Google/Android tries to prevent fragmentation. Problem is, fragmentation could occur almost overnight in the automotive industry — imagine 10 different automakers with 10 different brands, each wanting a branded experience. To combat this, a common set of technologies for connected automotive application development (think web technologies) is essential. Current efforts to bring applications into cars all rely on proprietary SDKs, ensuring fragmentation.

Other barriers undoubtedly exist, but these are the most obvious.

By the way, don’t ask me for my prediction of when the 10 millionth app will ship in auto. There’s lots of work to be done first.