Kortum P. (ed.) HCI Beyond the GUI. Design for Haptic, Speech, Olfactory, and Other Nontraditional Interfaces

Подождите немного. Документ загружается.

thus decrease the resulting simulator sickness. The characteristics in the lower list

are qualities that are often desired in systems. Longer exposures might be

required to simulate long missions or to allow users to carry out meaningful tasks.

Stereoscopic displays can improve task performance (Pang, Lim, & Quek, 2000)

but increase simulator sickness, and higher field-of-view (FOV) displays result in

better training and higher levels of user immersion (Arthur, 2000).

There are many theories as to what causes simulator sickness; see LaViola Jr.

(2000) for a brief introduction to several theories, and Razzaque (2005) for more

in-depth discussion. From a practical point of view, our advice to the designer is

to be on the lookout for symptoms of simulator sickness (particularly nausea

and dizziness) in your test users, and then to investigate more deeply if you

suspect a problem.

4.5

TECHNIQUES FOR TESTING THE INTERFACE

Why are there so many different locomotion interfaces? Each must have its own

advantages and shortcomings. However, it is very difficult to make quantitative

comparisons among them. Even when the researchers do conduct user studies

to compare techniques, the results are often not widely comparable because they

study different user populations and different tasks, and evaluate using different

metrics. Furthermore, nonlocomotion parameters of the systems, such as frame

rate, field of view, latency, and image quality, are different and, in many cases,

not measured. These factors can confound any study results, particularly task

performance measures.

One particularly impressive comparison of locomotion techniques is a study

by Bowman and coworkers (1997). They evaluated several variations of flying

by reimplementing each technique to run on the same hardware and having each

subject perform the same task using all the flying techniques. These authors eval-

uated each technique using several criteria: ease of learning, spatial awareness,

speed, accuracy, and cognitive load, and pointed out that different applications

have different needs. A phobia treatment application may be more concerned

with evaluating naturalness and presence, whereas a game may be more concerned

with speed and agility so that the user can get to the target quickly. As the applica-

tion designer, you should first decide which attributes are important, choose a loco-

motion technique that optimizes the particular attributes important for that

application, and then evaluate those attributes.

4.5.1 Guidelines for Testing

One naı

ve way to test an interface might be to assign a task to a sample of users,

and then measure how quickly they perform this task. But faster task performance

4 Locomotion Interfaces

132

does not always imply a better interface. For example, imagine a simulator

intended to help a patient get over a fear of heights, wherein the user’s task is

to cross a river using a narrow rope and plank bridge. One interface design might

require the user to hold handrails, and look down and slowly step from plank to

plank, whereas another interface design might have the user point her hand at

the opposite end of the bridge in order to instantly teleport there. Even though

the latter has her at the other side of the bridge sooner, it is contrary to the objec-

tive of the interface—to expose the patient to the stimulus that evokes the fear of

heights response.

Standard practice in usability testing dictates that the designer use test tasks

that are appropriate to the goal of the interface, and that the testing must

include real users who carry out the entire task for entire sessions. Tasks that

seem easy in short sessions can become fatiguing or even undoable in longer

sessions.

Many of the specific tests described in the next section result in quantitative

data, but are expensive to conduct. While quantitative tests with a large number

of users results in more convincing study results, doing more informal tests

and/or qualitative tests can result in more insight, and can save time and

resources, allowing for more iterations of designing and testing. In this regard,

the design and testing of locomotion interfaces is no different than for any other

kind of user interface.

4.5.2 Qualities to Consider for Testing

and Specific Tests

In this section, we enumerate qualities of a whole-body locomotion interface that

you might want to test, and provide specific methods for testing each.

Distraction

The first testing category is simply effectiveness: Can the user move around so

that she can perform her tasks, or does the interface interfere with or distract

her from the tasks? Distractions may be cognitive—the user has to pay attention

to using the interface rather than to doing her task, or they can be physical—the

interface device or its cables encumber the user in ways that interfere with task

performance.

One example of a cognitive distraction is an interface with poor motion con-

trol. Evidence of poor control (in addition to users simply complaining about it)

includes the user overshooting her intended target or unintentionally colliding

with objects, walls, or the edges of doorways. Such a locomotion interface is not

transparent to the user, but constantly requires the user’s attention, reducing

the cognitive resources available for her primary task. The number of overshoots

(where the user goes past the target and must reverse or turn around), the

4.5 Techniques for Testing the Interfa ce

133

distance of each overshoot, and the number of unintended collisions can be

recorded and counted during testing. When the user performs that same task

in different versions of the interface, these counts can be used to compare the

different versions.

As an example of physical distraction, consider the case of a soldier or game

player who is supposed to wield a gun while moving through a virtual building,

but must use both hands to control the locomotion interface. In this situation,

the user may well not be able aim or shoot her gun effectively while moving.

One way to test for this kind of physical distraction is to measure the user’s perfor-

mance on the nonlocomotion part of her task while using different versions of

the locomotion interface, and then to attribute the differences in performance to

the distraction caused by the locomotion interface itself.

Training Transfer

Some systems that include locomotion interfaces are intended to train users for

some task, such as evacuating a building during a fire. One way of testing the

effectiveness of such a system is by measuring

training transfer

—how well does

it train the user? This is done by using the system (or a prototype) to train a group

of users, and then measuring their performance on the real task afterward. This

task performance is compared against the performance of other users who were

trained using some other system (or a previous version).

As an example, Insko (2001) tested a system (designed to train users to learn a

virtual maze) to see if letting the users feel the virtual walls (via haptic feedback)

as they moved through the virtual maze would result in their having better

learned the maze. It turned out that those users who used the interface with hap-

tics made fewer errors in the real maze. The specific methods to test training

transfer, of course, depend on the specific tasks that the interface is intended to

train.

Presence

In the context of a virtual scene,

presence

is the feeling, in the user, of being in

the virtual scene, as opposed to being in the room where she is physically stand-

ing. For applications such as phobia desensitization, presence is the most impor-

tant quality of a system, and therefore merits testing. One way of testing presence

is to use a questionnaire, such as the Slater-Usoh-Steed questionnaire (Slater &

Usoh, 1993; Slater et al., 1995; Usoh et al., 1999). Another involves counting

break-in-presence (BIP) events (Slater & Steed, 2000). BIPs are defined as events

where the illusion of

being somewhere else

is broken and the user’s attention is

brought back to her physical surroundings.

One example of a BIP event is when the user’s virtual body penetrates or

intersects a virtual object (Figure 4.20). The user can push a button or call out

to the experimenter each time she experience a BIP event, and then the counts

can be compared against the counts from users in other interfaces. Using the

4 Locomotion Interfaces

134

BIP measures, Slater et al. (1995) determined that the walking-in-place interface

results in greater presence than locomotion via flying with hand controller.

We have also explored physiological indicators of presence, such as heart rate

and skin conductance. The general idea is to place the user in a simulated stress-

ful situation and record physiological data. The more similar her physical

responses in the virtual scene are to responses to a corresponding stressful situa-

tion in the real world, the more presence inducing the simulator is. Physiological

measures have been used to test the effects of interface design parameters such as

the display’s frame rate and lag (Meehan et al., 2003, 2005).

One problem with all three ways of testing presence mentioned in this section is

that there is large variation between individuals and from session to session. While

you might have a

qualitative

feel for which locomotion interface is better after sam-

pling half a dozen users, several dozen to hundreds of users might need to be tested

to get a statistically significant

quantitative

indication from physiological data.

4.5.3 Locomotion Realism and Preservation

of Spatial Understanding

Another testable quality of a whole-body locomotion interface is how realistic

the motion displayed to the user is. Remember that

display

is a generic term

FIGURE

4.20

Example of an event that causes a break in presence.

Unnatural events, such as walking through a wall, break the user’s illusion that

she is “in” the virtual scene, and remind her that she is really in a laboratory.

(Courtesy of the Department of Computer Science, UNC at Chapel Hill.)

4.5 Techniques for Testing the Interfa ce

135

and may refer to a visual display, an audio display, or a motion display (motion

platform or treadmill). When a user is walking on a treadmill, does visual dis-

play match how fast she feels she is walking? With a walk-in-place interface,

when the user takes a virtual step, does the step length feel consistent with

her expectation? Some researchers have found that when a user is physically

pushed in a cart at some acceleration, and the virtual viewpoint moves at the

same acceleration in the virtual scene, the user often feels that the virtual accel-

eration (seen) and the real acceleration (felt) do not match up (Harris, Jenkin, &

Zikovitz, 1999). One theory is that the mismatch could be due to the narrow

FOV in systems that have the user wear an HMD. Whatever the reasons, you

should query your test users as to whether the distance, velocity, and/or accel-

eration of the displayed movement feels too fast or too slow, and adjust it

accordingly.

You can also test how well the locomotion interface preserves the user’s

spatial awareness. Peterson and colleagues (1998) had users move through a vir-

tual maze and then had them point toward the location in the virtual maze from

which they started. He compared the pointing accuracy of two different loco-

motion interfaces. Iwata and Yoshida (1999) compared the shape of the path

that users took when walking in the real world and when using the Torus

treadmill.

4.5.4 Simulator Sickness

When designing a whole-body locomotion interface, you should pay careful atten-

tion to the extent the interface induces simulator sickness in users, and decide

whether a certain amount of sickness is acceptable for a particular application.

The most common way of measuring simulator sickness is Kennedy’s simulator

sickness questionnaire (SSQ) (Kennedy et al., 2003).

The SSQ consists of 16 multiple-choice items, and results in an overall sick-

ness score as well as three subscores. It can be administered to a test user very

quickly, but because the scores vary greatly from person to person, large numbers

(many dozens) of test users must be used. Also, the experimenter must not

administer the SSQ to test users before they use the locomotion interface, as there

is evidence that using the SSQ in a pre-exposure/postexposure fashion causes

users to report more sickness in the postexposure test than users who have the

same virtual locomotion experience, but take the test only after exposure (Young,

Adelstein, & Ellis, 2006). The SSQ was developed from an analysis of over a thou-

sand flight simulator sessions by U.S. Navy and Marine pilots. In our experience

with whole-body locomotion interfaces, rather than comparing the SSQ scores

of test users to the sickness levels reported by military pilots, it is more useful

to compare SSQ scores between different locomotion interfaces (or different

versions of the same interface).

4 Locomotion Interfaces

136

Researchers have proposed other ways of measuring simulator sickness,

such as looking at the change in a user’s postural stability—her ability to

balance—when measured before and after using the locomotion interface (Stoffregen

et al., 2000).

Finally, when you design an interface, you should also consider testing

the qualities of the locomotion system that might lead to increases in simulator

sickness. For example, the display frame rate and end-to-end system latency

(Meehan et al., 2003) can be measured without having to run user studies. We

find that a frame rate of 60 frames per second or greater and an end-to-end

latency of less than 100 milliseconds are generally acceptable. Values higher

than these should cause you to look more carefully for symptoms of sickness

in users.

4.6

DESIGN GUIDELINES

General interface design rules apply to locomotion interfaces as well:

1. Always consider the user’s goals for the interface as the highest priority.

2. Perform many iterations of the design ! test ! revise cycle.

3. Always include tests with actual users and the actual tasks those users will

perform.

We also suggest guidelines that are specific to whole-body locomotion interfaces.

4.6.1 Match the Locomotion Metaphor to the Goals

for the Interface

You should always consider whether the locomotion metaphor suits the goal of

the whole-body locomotion interface. For example, if the interface’s goal is to sim-

ulate real walking, then the interface should require the user to really turn her

body to turn (walking metaphor), rather than turning by manipulating a steering

wheel or hand controller (vehicle metaphor).

4.6.2 Match the Interface Capabilities to the Task

Requirements

Because the user employs the interface to specify locomotion, you must consider

how fast the user will need to move, how finely or accurately she must be able to

control her locomotion (e.g., will she need to walk through tight spaces?), and if

she will be performing other tasks while she is moving. Not being able to move

4.6 Design Guidelines

137

fast enough will result in the user finding the interface tedious, whereas not

providing fine enough control will result in unintended collisions and inability

to stop exactly where desired.

4.6.3 Consider Supplementing Visual Motion Cues

Using Other Senses

The visual display alone may not always communicate some kinds of movement.

For example, if the user of a game is hit with bullets, the quick and transient

shock

movement will be imperceptible in a visual display because the visual system

is not sensitive to those kinds of motions. An auditory display and motion plat-

form (e.g., a shaker) would work better. On the other hand, a motion platform

would not be appropriate for conveying very slow and smooth motion such as

canoeing on a still pond.

4.6.4 Consider User Safety

Since the user will be physically moving, consider her safety. One thing you must

always consider as a designer is the set of cables that might connect to equipment

worn by the user. Will the cables unintentionally restrict her movement or entan-

gle her or cause her to fall? What prevents her from falling? And if she does fall,

does the equipment she is wearing cause her additional injury? How will the

cables be managed?

4.6.5 Consider How Long and How Often the

Interface Will Be Used

As a designer you must also consider the length of time the person will be using

the interface and how physically fatiguing and stressful the motions she must

make are. For example, if the interface requires her to hold her arms out in front

of her, she will quickly tire. If the interface requires her to slam her feet into the

ground, repeated use might accelerate knee and joint injury. As discussed above,

you should also be on the lookout for symptoms of simulator sickness, and if you

suspect that your locomotion interface is causing some users to become sick,

investigate ways of changing the interface (e.g., reducing the exposure time,

reducing the display’s FOV) to address it. For example, the IMAX 3D version of

the movie,

Harry Potter and the Order of the Phoenix

, limited the 3D visuals to

only the final 20 minutes of the movie.

The applications of whole-body locomotion interfaces are so varied that

there are very few things that a design should never do, no matter what the

circumstance or application.

4 Locomotion Interfaces

138

4.6.6 Do Not Assume that More Sophisticated

Technology (Higher Tech) Is Better

One assumption that we have seen novice interface designers make that often

results in a bad interface design is that an interface is better simply because it is

“higher tech.” You must consider the goals of the user and make design choices

based on that.

4.6.7 Do Not Deploy Head-Directed Interfaces

Although easy to implement, a locomotion interface that forces the user to move

in the direction in which her head is pointing (or, inversely, forces her to point

her head in the direction she wishes to move) is almost always suboptimal.

On foot, humans look in the direction they are moving roughly 75 percent of

the time (Hollands, Patla, & Vickers, 2002); about 25 percent of the time we are

moving in one direction and looking in another. For example, people look around

while

crossing a street or merging into a lane of traffic. If you can only move in

the direction you are facing, you cannot look around and move at the same time.

Templeman et al. (2007) provide a detailed analysis of why motion direction and

head direction must be decoupled if locomotion systems for training soldiers on

foot are to be effective. Many designers (including the authors) who first imple-

mented a head-directed locomotion interface then discovered this problem and

had to redevelop the interface. On this point, we recommend that you learn

from the experience of others and avoid head-directed locomotion interfaces in

production systems.

4.6.8 Summary of Practical Considerations

There are myriad practical considerations when designing, implementing, and

deploying a locomotion interface. Table 4.3 summarizes some of the factors that

should be considered to ensure that an interface will be successful—that users will

accept it and that the virtual locomotion interface is effective.

The factors are categorized as functionality, systems and sensor characteris-

tics, and encumbrances and restraints. The Comments column variously explains

why a locomotion interface designer should care about the factor, expands on

what the factor means, or gives an example of the kinds of problems that can arise

if the factor is ignored.

4.7

CASE STUDY

A case study for a walking-in-place locomotion interface can be found at

www.

beyondthegui.com

4.7 Case Study

139

TABLE 4.3 Items Considered in Design, Implementation, and Deployment

of Virtual Locomotion Systems

Practical Considerations Comments

Functionality

How hard is it to learn the interface? If a “natural” interface is hard to use, users will

prefer a less natural but easy-to-learn interface.

Is viewing direction independent of motion

direction?

Allows you to look around at the same time you are

moving.

Are hands used for locomotion? It is good to have hands free for use during tasks.

Able to move in any direction and change direction

easily?

It is difficult to make a sharp corner on some

treadmills and with some joysticks.

Able to move in any direction while body faces

forward?

Backward? Sideways?

Can base walking speed or step length be set for

each individual?

Familiarity with one’s own step length is a factor

contributing to spatial understanding.

Able to move at different paces, and move quickly

(run) or slowly (creep)?

Extends range of applications that can be

supported.

Able to adjust step length, that is, take larger or

smaller steps?

Without the ability to take small steps, users cannot

fine-tune where they stop.

Magical interfaces for fast movement between

distant places?

Most often needed for very large virtual scenes;

likely used with a mundane-style interface for

human-scale movements.

System and Sensor Characteristics

Are there more than one or two frames of latency

between signaling intent to move and visual

feedback of movement?

Trade-off between start-up lag and detecting

unintended steps.

Does the user move one or more steps further than

intended when stopping (stopping lag)?

Trade-off between stopping lag and missing

intended steps.

Is tracker technology compatible with the physical

environment?

For example, steel raised flooring compromises

accuracy of magnetic trackers.

Are tracker sensors immune to other signals in the

room?

Are there sources in the room (other than the

tracker beacons) that the sensors will detect, thus

compromising tracking accuracy?

Are wireless trackers used? Is there sufficient bandwidth? Is room electrically

“noisy” from other devices and wireless hub?

Encumbrances and Restraints

What parts of the body will have sensors or

markers on them?

Will user be able to make appropriate motions with

sensors on?

Can cables be managed so they do not interfere

with user’s motion?

Will user get wound up in the cables when

performing the task?

Do you need a fixture to restrict user’s real

movement in the lab?

This may be a safety/institutional review board

issue in addition to keeping the user within range

of the tracking system.

4 Locomotion Interfaces

140

4.8

FUTURE TRENDS

Future locomotion interface designers will still face the same problems we

do today: how to sense body position and movement and map into locomotion

direction and speed while meeting application constraints that may vary from

maximizing naturalness to minimizing the range of movement required.

4.8.1 New Tracker Technologies

Our bodies have only a set range of motions; so, to increase the number of para-

meters that can be controlled with body movement and/or to increase the preci-

sion with which those parameters can be controlled, we must have more precise

data about the position and motion of the user. The trend to smaller and wireless

trackers means that these devices can be put in many more places on the body.

Since having more markers can result in slower tracker updates, data-mining tech-

niques are being applied to logs of data from motion capture systems to identify

the set of marker locations that are most critical for determining body pose (Liu

et al., 2005).

The vision for the future is fully unencumbered tracking of the whole body

for several users sharing the same physical space at the same time: no wires, no

body suits, and no markers or other devices placed on the user’s body. Computer

vision algorithms will use as input synchronized frames of video taken from a

number of cameras surrounding the space. The output per time step will be an

estimation of the body position (pose) of each user that is computed by tracking

features between frames and between camera views. There are successful

vision-based techniques today that use markers; the challenge for the future is a

markerless system.

4.8.2 Reducing the Physical Space Needed

for Real-Walking Interfaces

The advantages of the naturalness of a real-walking virtual-locomotion inter-

face are offset by the fact that the virtual scene is limited to the size of the physical

space covered by the tracking system. For example, to allow the user to explore a

virtual museum while really walking, the tracking space must be as large as the

museum. Several efforts are under way to overcome this limitation. Some of the

new techniques strive to be imperceptible, such as redirected walking (Razzaque,

2001); some strive to maintain the actual distance walked, such as motion com-

pression (Nitzsche, Hanebeck, & Schmidt, 2004), and others explicitly interrupt

users to “reset” them in the physical space while not changing their location in

the virtual scene (Mohler et al., 2004).

4.8 Future Trends

141