Considering CarPlay for Inclusive Design

At Oneflare, we just had our 5th hackathon (!!). In the past, we’ve been given carte blanche to do basically whatever we like. This time around, we wanted to give the hackathon a more narrow focus, so we decided to focus it around Inclusive Design.

Inclusive Design is an amazing field of research, and once you start understanding the foundations, you can literally apply it to every product decision you make.

We had some fascinating projects come from the hackathon, I’m going to discuss just one of them. But keep your eyes peeled to our blog this week to hear about all of them!

My team decided that we’d try to tackle usability issues when you cannot dedicate 100% of your focus to the product, say if you’re interacting with the product while driving, or while performing another task. The solution we ended up with was a CarKit app that is bundled with the existing iOS app, so that when the user plugs their phone into their CarKit enabled car, a version of Oneflare is launched.

This was a super interesting problem to solve! CarKit apps don’t have their own view layouts or storyboards – instead, they are presented by constructing a series of Templates, and feeding those templates with data. You start with a Map template (in fact, all CarKit apps must use the Map template as their starting point), and then you build up the UI by adding additional templates over the map.

Designing an app without actually building a UI was a really interesting challenge. Apple provide a bit of assistance, but really, you’re left on your own to try and figure stuff out. I assume this is because they’re typically working closely with car companies and app developers who might be building CarKit apps themselves, and as such, they don’t need to document it too much.

For example, just getting the app to actually present the CarKit app was very tricky. Because it’s not a seperate target, like say a Watch app, but it’s actually a seperate screen output. So you need to add an entitlement to get access to that screen. But you cant add the entitlement without being entitled to, so you have to add a fake entitlement. This tidbit is buried deep in Apple’s own documentation, but for anyone interested, this is what you add to your entitlement file:

Once you add that, you should be able to get something to show when you add the external display to your simulator. There’s another trick to get additional features to your CarKit external display. In terminal, enter the following:

This will give you extra options when you add the CarKit external display, like exactly setting the width/height, and specifying if the display has a wheel, etc.

Extra options for spinning up a CarKit display

Once that’s done, you then register your AppDelegate as a delegate for CPApplicationDelegate as a minimum, and then for each template type you’d like to use individually. For example, if you’re only using CPListTemplates, you need only add CPListTemplateDelegate extra.

Now’s where it gets tricky. Remember I said that there is no UI? I meant it. You have to use a combination of delegate calls to get CarKit to display the correct thing. It all starts when the phone is plugged into a CarKit enabled dash.

The above block will store a reference to the CPInterfaceController, which is like a skinned down View Controller, and also store a reference to the Car Window. You’re on your honour to also store references to the root template, just in case. In this instance, we just made a simple Map Template. If we were plugged into a real car, this would give us a view of the cars current location on a map. But since we’re using the simulator, we don’t want to start with the map. Also, for our use case, we assume that the user doesnt actually care about where they physically are at the moment they use our app, rather they want to know where they’re supposed to go.

So, the next thing we do is present a List Template, with a few options. The way to present a List Template is by using the following code snippet:

This will present an empty list. We need to fill the template with sections, which are filled with items.

Once the user selects an item, we then use a list template delegate method to figure out what.

The best way to figure out exactly what item was selected is to set some userInfo on each item before adding it to the sections.

By adopting a similar pattern to UITableView’s delegate and data source methods, we’re able to roughly reproduce that experience when creating these apps. All we need do then is inspect the userInfo of the item that was selected, and then perform the appropriate action.

Overall, CarKit was an interesting platform to build an app for. In a few short days, we were able to get a pretty good proof of concept built, and were even able to add stuff like voice over (using AVSpeechSynthesizer) and Turn by Turn navigation (by using CLGeocoder).

CarKit is, by no means, the only way that app developers have to create really cool experiences with CarPlay enabled systems, but it’s the way that made the most sense for us based on what we wanted the app to do, which is ultimately give the user directions to the job destination.

Leave a reply:

Your email address will not be published.

Site Footer