On-the-Move and in Your Car - Human-Computer Interaction and Innovation in Handheld, Mobile and Wearable Technologies - page 66

the breadth versus depth of menus in graphical
user-interfaces (Shneiderman, 1998). An overall
recommendation from such HCI research is that
breadth should generally be favoured over depth,
as excessive depth can cause considerably more
problems for the user than an equivalent breadth,
largely due to the cognitive problems of naviga-
tion (Shneiderman, 1998). Whilst such guidance
is considered to be of relevance to the design of
in-car computing, research is still required which
considers the trade-off existing in the multiple-task
driving environment.

environment between the need for control
and the validity of results. Choosing an
environment will also be largely influenced
by practical considerations, the knowledge/
skills of the design/evaluation team and
resource limitations.
2. Which task manipulations occur (multiple
task, single task loading, no tasks given, etc.).
In certain methods, there is an attempt to
replicate or simulate the multiple task nature
of driving. For other methods, performance
and/or behaviour on a single task may be
assessed and the potential impact on other
tasks inferred from this. Most removed from
actual driving, some methods do not involve
users, but instead aim to predict impacts or
issues, for instance through the use of expert
ratings or modelling techniques.
3. Which dependent variables (operationalised
as metrics) are of interest. In assessing an
in-car computing user-interface, a large
range of possible metrics could be imple-
mented. Some will relate to drivers' per-
formance with primary driving tasks (e.g.
lane position, hazard detection) or their
use of primary vehicle controls (e.g. use of
brake, steering wheel). Other metrics focus
on driver performance and/or the demand
of secondary tasks (e.g. task times, errors,
display glances). As noted by Parkes (1991),

METHODS FOR USE IN
DESIGN AND EVALUATION

In considering the range of methods that a de-
signer can utilise when designing and evaluating
in-car computing systems, the first difficulty is
in establishing what is meant by a method. In
this respect, a “human factors method for testing
in-car systems” can be seen to be a combination
of three factors:

1. Which environment is the method used
in (road, test track, simulator, laboratory,
etc.). As can be seen in Figure 2 (redrawn
and adapted from Parkes, 1991), there is a
fundamental trade off in choosing a method

Figure 2. Environments for evaluation of in-car computing devices and the relationship between validity
and control (adapted from Parkes, 1991)