Cars and computers [closed]

Question

what are some of the problems with the user interface of computers in cars(media, maps, vehicle/travel data)? what works in terms of interaction types - manipulating, conversing, instructing , dare i say exploring? how do they stand up to Nielsen's and Norman's heuristics? what doesn't work? what is the way forward?

Answer 1

Jacob Nielsen offered this analysis of the first version of BMWs 'iDrive' interface:

http://www.useit.com/alertbox/20040315.html

Here are just few examples of the BMW 745i's clueless interaction design:

• Response times are incredibly slow. Each time you select something, you must wait several seconds for the next screen to appear. It's common to ridicule German engineers for their ignorance of customer needs, but no hardcore engineer should ever accept a slow computer for a high-end product. The hardware fails Geek 101. Slow response times mean that you must allocate more attention to operating the UI -- dangerous for an in-car user experience.

• Clumsy task flows. When you program a destination for the route guidance system, for example, you are (slowly) taken to an additional screen where you must move the pointer to a command that actually initiates route guidance. I'd bet that the vast majority of people who enter a destination also want to drive there. The system should start by offering directions, and give those exceptional users who enter a destination that they don't want to drive to a command that turns the directions off.

• Misleading mapping between input device and screen. In the screen to delete items from the destination list, you turn the knob left to make the cursor move right.

• Obscure abbreviations. Although the designers have a fairly big screen at their disposal, they've littered the UI with commands like "DSC/DTC," "BC," "Avoid sect.," "WB," and "Recirc. air MFL." What they mean is anybody's guess. Better to spell out the commands when you have the space (for example, "Weather" instead of "WB").

• Lack of situational awareness. Each time you use the GPS, you must laboriously spell out your destination, with many twists and turns of the input device. The system's design makes it equally easy (and thus equally difficult) to get directions to any U.S. city. Do you know how many American cities have names starting with "San"? But, given where we live, we almost always want to go to San Jose or San Francisco, and typically use GPS to find shortcuts to our local destinations. How often do Californians drive 1,755 miles to have lunch in San Marcos, Texas?

• Different function, same look. The car has customized settings for the driver's seat, mirrors, and so on. These settings are tied to individual keys so that the car can adjust to specific drivers when they insert their key into the ignition. Great example of a non-command UI. The car comes with two keys, which is perfect for a two-driver household. Unfortunately, the keys look identical. It would have been so easy to add a different color or symbol to each key so that drivers could identify the key with their individual settings. But no. If the two drivers ever put their keys down on the same table, they're doomed; there's a 50% probability that they'd grab the wrong key.

Answer 2

The biggest problem with the user interface is the amount of twiddling you have to do. For example, if you want to hear a certain artist's songs from your iPod you have to go through a lot of changes while attempting to keep your eyes on the road.

Voice activated blue tooth for your phone and navigation is helpful, but the radio/CD player/MP3 player is almost never voice activated. This will lead to accidents, but maybe not as many as with texting and driving. If you do that, it's only a matter of time before you get in an accident.

In short, the controls needed to drive a car are simple, well thought out, and can be used without active thought (about the control). These are all very good things. However, the creature features on the console are not nearly as well thought out. They require more steps than you would normally have to do with equivalent products dedicated to the task (such as trip planning, music selection, climate control).

As a counter example of blue tooth voice activation being helpful, consider the process the Nissan Altima forces you through to register your phone.

1. Put your car in Park (it's a good idea anyway, but you can't access this feature when the car is in gear)
2. Press the blue tooth button on the steering wheel
3. Wait for the car to ask you what you want to do (and the list is endless)
4. Speak the phrase "Add Phone"
5. Wait for the car to tell you to turn on blue tooth
6. Turn blue tooth on in your phone
7. Wait for the car to tell you the pin code for the blue tooth connection
8. Wake up your phone (because it fell asleep), and try to enter the pin code before it times out
9. If the car get's tired of waiting for the phone, start all over again
10. Wait for the car to ask you what you want to call the phone
11. Name the phone
12. Wait for the car to tell you everything is OK
13. End the voice activated session

All of this would be quicker, easier, and less painful if they simply used the media screen to set up the phone call. The problem is that they are different systems. The only interface to your phone is through the voice activated dialog. That also means that if you didn't spring for the full navigation package you can't stream audio using blue tooth.

A car is a system of isolated components that on the whole seem like they are put together. For some systems it is quite useful, and provides redundancy for safety reasons. For the creature features it becomes a great hindrance, and reduces the quality of user interface. I can't answer who it applies to Nielson or Norman's heuristics.

The way forward is to provide more than one interface to the cockpit functions. That means a passenger should be allowed to connect a new phone while the car is in motion. That means really thinking about interacting with the media devices--and tying the systems together. While we are at it, if an iPod can contain a complete character set for Unicode, why can't a car? It's rather silly for a Japanese designed car not to be able to display Japanese characters just because it was manufactured in America. As a result some lesson titles on my iPod show up blank on the console monitor. Voice activation is useful, but simplify the interface and allow the user to interrupt with their voice.

Answer 3

Driver distractions are the leading cause of most vehicle crashes and near-crashes. One of the main causes are related with use of GUI's. Learning: The whatever interface is additional and should work as much intuitive as possible. The lower the extra cognitive effort for using it can be the better and more safer the solution is.

Guided simplicity over rules efficiency, I would say. For instance kinetic list scrolling vs paging. Usually you would browse a list via kinetic scrolling so that it feels smooth when you flick through it. In a car this doesn't work, because you can't watch the list until the scroll slows down. Otherwise you risk an accident. So as a result, you would use scroll buttons (paging) to go through the list. Because it is just simple and easy to use.

There are many more aspects. But I guess it would be too much for this thread here.