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!
 

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!

Autonomous cars? Surely, you're joking

No, I'm not. And stop calling me Shirley.

Five years ago, I would have called someone nuts if they said cars would soon be driving themselves. But next week, I'm going to say just that. On Monday I'm headed to Detroit for the 2012 SAE World Congress, and the rise of driver-less cars is one of the points I'm going to make as part of a panel on the future of telematics.

Saying that cars could or should drive themselves might get some people up in arms.  Am I advocating taking away the driver's rights? What happened to The Ultimate Driving Experience? What about Fahrvergnügen?

I enjoy driving as much as anyone. And yes, generally, I want to be in control of my car. But I see the writing on the wall, and it comes from three things:

Elderly boomers
My grandfather told me once a couple years before his death that drivers today were so rude

—they were always giving him the finger. I sympathized, until I took a ride with him. I white-knuckled it the whole way as he drove 40 mph in a 70 zone, straddling two lanes of traffic and getting plenty of hand gestures all the way. He didn't drive for much longer after that, fortunately for him and everyone else on the roadway.

My dad is still a good driver, but slowly and surely, my parents are getting there. What happens when all the boomers lose their ability to drive safely? Especially in North America, where distances are so long and independence is a given?

Gen AO
Otherwise called Generation Always On, this group includes anyone who picks their car based on their phone, rather than the other way around. There's a whole generation of people whose need to connect and socialize is far stronger than their need to drive. I'd argue this narrow generational definition could be extended to almost all of us at one time or another.

How many of us (not asking for hands) have been guilty of glancing at their phone while driving? Okay, now how many of us have seen other drivers drift a little too far out of their lane (looking at their phones, presumably) and then all of a sudden snap back to their lane? Right, me too.

Google
It's not just Google; it's also a bunch of very smart and driven (pun intended) people at lots of universities and high-tech companies. Google has motive: it can generate a lot more ad revenue if people are searching, and people can search a lot more if they're not driving. University researchers also have motive: Driver-less cars pose a very challenging problem that would be prestigious to solve. What's more, Google's proven it can be done—on real roads—with their driverless car. Enough that they convinced Nevada to pass a law allowing autonomous cars, with other states soon to follow.

Add those three things together, and what do you get? Yep—driverless cars, sooner than you might think. If I get to the point where I'm endangering others, I'll willingly let my car drive, rather than give up mobility. And wouldn't we all be a little safer if cars came with a cruise-control-like automatic pilot? Yes, I'm sure we would. This is the one thing that could permanently solve any form of distracted driving: a human not driving. I was never was much for Knight Rider, but KITT? Bring it on.
 

Everything you wanted to know about HTML5 in the car, Part III

Welcome to the third installment in my Q&A series on HTML5 in the car. In Part II, we looked at web servers, native plug-ins, instrument clusters, and display updates. This week, we turn our attention to tools, touch gestures, UI performance, and vehicle resources.

Are there any HTML5 HMI builder tools available?
Most of the well-known IDEs, including Eclipse, Dreamweaver, and Netbeans, support some flavor of HTML5 in their latest release. Adobe Edge, a new tool now available in preview, also lets you create animated HTML5 content. I suggest you check out the HTML5 Tools site, which publishes up-to-date tool reviews.

Often, automotive customers will ask system designers to make an infotainment system work "like an iPhone,” with the popular gesture controls. Does HTML5 support "inertial" menus and two-finger zoom?
Multi-touch is handled at the app level; here’s an example. Pinch zooming at the browser level is browser-dependent — the QNX browser handles it, but not every browser does. As for physics-based scrolling, HTML5 doesn’t support it “out of the box”; it needs to be added. Frameworks like Sencha Touch provide these types of controls.

Will the performance of HTML and JavaScript be adequate for critical user interface components or computations, such as safety-related notifications?
This has to be tested on a case-by-case basis. For the UI elements, yes, the performance should be adequate. Our testing indicates you can build HMIs that are surprisingly responsive. Also, our WebKit port lets you do things things like run JavaScript code in other tabs, threads, or processes to ensure those ocmponents aren’t being thread-blocked by something less critical.

I do get a little gun-shy recommending HTML5 for safety-critical components, because JavaScript isn't inherently real-time. If you wouldn't feel comfortable using Java for a critical coding task, you shouldn't use HTML5 either. If you want predictable, real-time performance for a lower-level computation that cannot tolerate any delay, the code should execute in a non virtual-machine environment. Most code doesn’t really fit that description, so most of the time JavaScript should work just fine.

How do you call vehicle resources — vehicle HMI, vehicle diagnostics information, etc. — on a HTML web app in the car? What's the process in plain words?
In plain words, it’s kinda hard. :-) But here’s my best take on this question: we solve this by creating a vehicle-bus driver that exports data through a publish/subscribe mechanism. The HTML5 layer talks to that piece through a JavaScript interface.
 

Everything you wanted to know about HTML5 in the car, Part II

Welcome to the second installment in my Q&A series on HTML5 in the car. Last week, we looked at CSS, cross-platform execution, and asynchronous design. This week, we turn our attention to web servers, native plug-ins, instrument clusters, and display updates.

If I don’t use a web server in my infotainment system, will I miss out on some features of HTML5?

A web server isn’t strictly necessary, but there are two very good reasons for including one. First, it lets you export a user interface to devices outside the car, thereby allowing mobile phones or tablets to run apps that are hosted on the vehicle head unit. Second, it lets you export internal car resources, as a URL, to HMI software running in the head unit. For instance, the web server could provide the HMI with access to static vehicle-configuration data (through an xml file) or to a back-up camera (through a video stream).

Will using native code plug-ins compromise my ability to leverage HTML5?

This is tricky, because a lot of things you want to do may require native code. So, yes, use native code, but do it judiciously. The more native code you use, the more it will limit the cross-platform capability of the HTML5 code that relies on it. The good news is that with HTML5 gaining so much functionality, plug-ins are needed far less than ever before.

A sample climate control app from the
QNX CAR 2 platform, created with HTML5.

Would you consider HTML5 as an option for cluster instruments: speedometers, tachometers, etc.?

At this point, I’d say no. HTML5 makes a lot of sense for in-vehicle infotainment, but it doesn’t provide the response needed for a vehicle cluster and it won't ensure safety-critical certification. Plus, the instrument cluster isn’t where you realize a lot of HTML5’s value: downloadable apps, connectivity to mobile devices, and so on. If the cluster and the infotainment system eventually merge into one big screen, then it’s more likely you could use HTML5 for both — but that’s still a few years out.

What’s a good way to get responsive display updates (10Hz update) into HTML5? Websockets?

If you need to deliver high-speed updates to your head unit, Websockets is one way to go. Make sure, however, that you don’t stall the rest of the JavaScript engine while your main thread is blocked on tasks. If you create another thread to monitor for changes, you can do it just as effectively (and probably with less work) with a JNEXT or NPAPI call into native code.
 

Everything you wanted to know about HTML5 in the car, Part I

My HTML5 webinar generated a lot of interesting dialog about what HTML5 means for in-vehicle systems. People asked questions about everything from security and performance to WebGL and cross-platform execution. Many of the same questions come up with when I speak with customers and analysts, which got me to thinking: Why not address them in this blog?

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

Let’s say your phone has an HTML5 navigation app that you want to run in your Audi today and your Chevy tomorrow. Although the phone serves up the app content identically in both cases, the Audi system can use a CSS to ensure that the app looks ‘Audi-like’, with that distinctive black and silver coloring, and the Chevy system can use a CSS that gives it the app the look-and-feel of OnStar. In effect, CSS can give the OEM more control over brought-in applications than other types of ‘screen replication’ technologies, like MirrorLink or iPod Out.

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.
 

HTML5 Hackathon

Learn how to put together HTML5 apps at the HTML5 Hackathon. You'll get hands-on experience with WebWorks, which is the BlackBerry tool for building applications with HTML5.

That'll get you primed for building HTML5 apps for the QNX CAR 2 application platform!

The Coolest Cars at NAIAS

Here's the Cliff Notes version of North American International Auto Show industry preview. (Cole's notes for my Canadian followers.)

The show was a great one, especially compared to last year. Industry people were there from across the globe, and most of the exhibits were packed. (The pictures below that were absent of people required patience, timing, and retakes.)  NAIAS was strong, despite some debate about how it may be losing relevance with Europeans or Asians. Jaguar LandRover was missing this year. But it's still the show where the big three pulls out all the stops; very few other major automakers want to risk being absent.  Cobo hall was filled with absolutely massive displays of new models, concept cars, and interactive displays from Audi, BMW, Chrysler, Daimler, Fiat, Ford, GM, Hyundia, Kia, Toyota, Volkswagen, and many others.

There was a lot to see.  Unfortunately due to my other show duties, I didn't get a lot of time on the show floor.  What I saw was pretty darn cool, and here are the highlights.

Smart Art





Not your father's Mercedes




Honda Fit - an Insightful design



The ultimate jacked suspension on a Ford Raptor

F-150 King Ranch.  Sweet! (Except I don't do leather)

Chevy Miray concept.  Holy gull-wing, Batman!

Miray from the back looks just as wicked

TRU 40S — another very cool GM concept.  Love the white satin  finish

Lexus LF-LC.  Concept based on Lexus LFA.  Looks fast (that's why it's blurry).

LF-LC from the rear.  This is the view you'll normally have, but far smaller.

Nothin' but sliver Porsches.  Drool.

VW Bugster.  Combination bug and roadster.  Huh.

Via.  Don't know what it is, but it sho' looks cool.

Audi R8GT.  Nice side vents to cool off those brakes.

I just liked this mini hung up on the wall.  Looked cute — want one in my den.

BMW concept car.  Tron, anyone?

BMW Active Hybrid; a little more practical than the above pic

Audi e-tron

Audi RS 5 Coupe -- aggressive grille!

Another Smart concept car--perfect for the city (bikes in the back)

Chrysler 700C.  Now this is a minivan any man would agree to

Another view of the 700C

300SRT8.  Didn't know SRT made normal cars

SRT Challenger

SRT Yellow Jacket - Starsky

SRT Super Bee - Hutch

Next week: CES, CTS, AT&T, NAIAS. Phew!

It has been a hectic week back from Christmas vacation trying to get all the last minute preparations ready for the Consumer Electronics Show (CES), the Consumer Telematics Show (CTS) in Las Vegas and the North American International Automotive Show (NAIAS) in Detroit.

CES has become a  "must attend" show for automotive, due to the continued convergence between the consumer and automotive industries. (Yes, that's an intentional pun, and SAE Convergence is this year, but thankfully not until October.) Our CES QNX booth is tucked right behind the RIM booth #30326 in the main hall. We'll have some really cool new demos that you'll definitely want to check out! I can't give you details until next week, but trust me they are worth the wait.

We've got QNX representatives speaking both at CTS, which is the Monday before in Mandalay Bay, and at the AT&T Developer Conference which is the Sunday and Monday before at the Palms hotel.

And finally there's NAIAS at Cobo Hall.  I'm skipping CES this year to give some love to my home town.  I'll be back in Detroit, keepin' it old school. If I don't see you there, look me up. Peace out.

I've always wondered about Android support...

My colleague Jeff Schaffer sent me this link, which gives an interesting analysis of Android support on various devices.

Clearly, it's pretty tough to stay on top of the Android release game. One very good reason for car makers to be wary, as they'll be bound to move even slower than handset makers.

Adobe’s out of mobile? Read the fine print

The blogosphere is a-buzz with Adobe’s apparent decision to abandon Flash in mobile devices. I get the impression, though, that many people haven’t bothered to read Adobe’s announcement. If they did, they would come away with a very different conclusion.

Let me quote what Adobe actually said (emphasis mine):

"Our future work with Flash on mobile devices will be focused on enabling Flash developers to package native apps with Adobe AIR for all the major app stores. We will no longer adapt Flash Player for mobile devices to new browser, OS version or device configurations. Some of our source code licensees may opt to continue working on and releasing their own implementations. We will continue to support the current Android and PlayBook configurations with critical bug fixes and security updates."

What’s being discontinued is the Flash plug-in for mobile browsers. Adobe will still support and work on Mobile AIR, and on the development of standalone mobile applications.

A number of cross-platform applications today are implemented in Adobe AIR, and that’s staying the same. Adobe is being smart — they’re picking and choosing their battles, and have decided to give this one to HTML5. We’re big believers in HTML5, and Adobe's announcement makes complete sense: Don’t bother with the burden of Flash plug-in support when you can do it all in the browser. You can still build killer apps using Adobe AIR.
 

BBDevCon — Apps on BlackBerry couldn't be better

Unfortunately I joined the BBDevCon live broadcast a little too late to capture some of the absolutely amazing TAT Cascades video. RIM announced that TAT will be fully supported as a new HMI framework on BBX (yes, the new name of QNX OS for PlayBook and phones has been officially announced now). The video was mesmerizing — a picture album with slightly folded pictures falling down in an array, shaded and lit, with tags flying in from the side. It looked absolutely amazing, and it was created with simple code that configured the TAT framework "list" class with some standard properties. And there was another very cool TAT demo that showed an email filter with an active touch mesh, letting you filter your email in a very visual way. Super cool looking.

HTML5 support is huge, too — RIM has had WebWorks and Torch for a while, but their importance continues to grow. HTML5 apps provide the way to unify older BB devices and any of the new BBX-based PlayBooks and phones. That's a beautiful tie-in to automotive, where we're building our next generation QNX CAR software using HTML5. The same apps running on desktops, phones, tablets, and cars? And on every mobile device, not just one flavor like iOS or Android? Sounds like the winning technology to me.

Finally, they talked about the success of App World. There were some really nice facts to constrast with the negative press RIM has received on "apps". First some interesting comparisons: 1% of Apple developers made more than $1000, but 13% of BlackBerry developers made more than $100,000. Whoa. And that App World generates the 2nd most amount of money — more than Android. Also very interesting!

I can't do better than the presenters, so I'll finish up with some pics for the rest of the stats...