Briefing: In-vehicle information system interfaces

People flying into an intelligent city may want to pick up an intelligent car—one with an in-vehicle information system—to help them get to where they want to go or decide what they want to do. Similarly organisations within the city, for example the emergency services, distribution companies or bus companies, may want to manage their resources more effectively through the use of in-vehicle systems. Such technology is in place today with in-car telematics systems becoming increasingly abundant in the commercial and consumer arena, providing route guidance, in-car entertainment, remote access to office systems, resource management and a variety of other applications.

What matters to the people who use telematics devices is that these systems are easy to use, that they make things easier to do (than they would be by another method) and that they do not excessively distract from the primary task of driving,1 although the latter may not necessarily be a conscious consideration. This briefing paper will investigate the human issues associated with the implementation of telematics systems, highlighting the barriers that can impact on system success and how these can potentially be addressed. The paper focuses on the design of the visual interaction, but it is noted that as natural language processing techniques evolve, the facility to interact with in-vehicle systems through speech will improve and it is probable that a synthesis of manual, visual and aural interaction will be employed.

Minimising distraction should be the primary objective when designing telematics systems. The general approach to achieving this is for international bodies to define what acceptable levels of distraction are and for designers to build systems that fit these criteria. Both are significant challenges. A simple benchmark principle to follow when specifying criteria for acceptable distraction levels of any in-vehicle system is to keep ‘eyes-off-the-road’ time to a minimum, which could be written as: acceptable distraction = acceptable glance duration.

The International Organization for Standardization (ISO) has a draft specification stating maximum glance durations should not exceed 1·5 s with a minimum of 2 s eyes-on-the-road in between.2 It is not only the time of individual glances that is important, but also the number of glances required to complete a task. The European Community has a specification stating a task should not exceed four glances with a maximum of 2 s per glance. Unfortunately, there is the unavoidable caveat that glances that correspond to critical events in the road scene can have adverse consequences.3 

Considering the issue of distraction in more detail illustrates how complex the matter of precisely defining acceptability becomes. Even when a driver has his eyes on the road, thoughts, conversations and the environment are all vying for attention. How badly do these distractors impact on driving skills? As cognitive load increases4 

• visual inspection patterns reduce in size, thereby reducing the amount of the road scene that is being observed

• fixation durations increase, indicating that it is taking longer to process the visual input

• inspection rates of speedometer and mirrors decrease, so that it is less likely the driver will see the police car coming up behind when drifting over the speed limit.

While these degradations in processing would imply a reduction in the driver's ability to react to the ever-changing road scene, it will also depend on how much of what the driver is observing is visually relevant to the driving task in the first place (which in itself is dependent on issues such as speed, weather conditions, traffic volume and road layout).

In summary, acceptable distraction is an ever-changing variable that is highly complex to determine from one moment to the next. It is therefore common practice to generalise to defined criteria that fall within what are considered to be safe levels of glance duration. Armed with these criteria, designers have the benchmarks around which they can test their devices and applications (using, for example, simulators and eye-tracking equipment), but how do they go about making these systems useful?

Designing useful systems requires an in-depth understanding of both the task and the context in which the task is being completed.5 There are various ways to achieve this understanding, but one of the most effective is to observe people performing real tasks in context. Some of the research over the last five years has focused on evaluating telematics systems being used on a day-today basis (primarily with the emergency services).6 This has involved going out on patrol in a wide variety of contexts; taking into consideration such factors as single/double crewing, day/night-time usage, differing job roles and vehicle types. This work has identified several issues that can impact on system success, some of the key ones being the following.

• Installation: where do installers put these devices? Space on vehicle dashboards and consoles is at a premium. Often every spare inch is taken up with controls, ventilation ports, air bags and so forth. Putting the device on top of the dashboard can make it susceptible to glare, while placing it low down on the console can make it inaccessible. An emerging practice is for organisations to coordinate with vehicle manufacturers to have the dashboards designed to accommodate their in-vehicle systems (Fig. 1).

• Battery life: these devices may need to be left on while the vehicle is not running. This can lead to the driver and vehicle being stuck in the same place a lot longer than planned.

• User adoption: the system may not fit into work practice effectively. For example, it may take so long to boot up and log in to that the user may not bother turning it on when doing short journeys. It may not fit into work culture appropriately; for example, it may be perceived to change the way the organisation and the staff communicate, in a manner that is considered detrimental to the staff. Or it may simply be considered an imposed solution that has involved no user consultation during the development process.

• Reliability: the system suffers from ongoing technical problems.

• Usability: the layout and simplicity of the interfaces could be improved. In particular, when an in-vehicle system is linked to an existing office system, it is important to review the existing interface and redesign to meet in-vehicle requirements, a practice that is not always followed.

It is essential that all these issues are adequately addressed. If the system is not reliable, is not easy to view or access, and does not meet the needs of the user from a usability, work practice and work culture perspective, it will not be used to its full potential and it may not be used at all. Furthermore, these issues may impact to a varying degree on the distraction the system can cause.

The research discussed in this paper focused on user-centred evaluation, not user-centred design, but it all feeds back into the process of improving in-vehicle information systems. As a result of lessons learnt, telematics systems are in general getting increasingly user friendly, but if more emphasis had been placed on user-centred design from the outset, how much better would they be now, than they are?

Design that focuses on minimising task complexity helps satisfy the requirement for easy-to-use systems, which in turn has a positive impact on eyes-off-the-road time and the likelihood of meeting glance duration specifications. The success of in-vehicle information systems therefore begins by understanding the needs of the user in context and designing accordingly. Only then will intelligent cars satisfy the needs of the intelligent city.