Experience Prototyping: A New Approach to Designing Firefighter Navigation Support

68 PERVASIVE computing Published by the IEEE CS n 1536-1268/12/$31.00 © 2012 IEEE

F e a t u r e : r a p i d p r o t o t y p i n g

experience prototyping: a new approach to designing Firefighter navigation Support

S ome argue that it’s more difficult to design pervasive computing systems than traditional systems because of their increased design space, higher development costs, and more intricate

and unpredictable effect on the use context.1 Although researchers have, with comparatively little effort, successfully applied various rapid prototyping techniques to explore the design space of traditional information technology,

we need adapted proto typing tools and techniques to real-ize pervasive computing’s full potential. For emergency response work in particular, some implications of using new technologies are unpredict-

able, because they depend on the correspond-ing work practices, which are in turn influenced by the technology.2 We thus must engage pro-spective users in experiencing the technologies in realistic scenarios to observe how their work practices might evolve.

An important element of many rapid proto-typing approaches is the partial simulation of system functionality. This makes the prototype systems available for user testing with minimal

effort, which is crucial when it’s difficult—or still technically impossible—to implement a fully functional prototype. For example, sev-eral approaches adapt the traditional Wizard of Oz (WOz) technique, which involves simulating selected system functionalities through the ac-tions of human “wizards.”1 Simulations require certain abstractions as well as tradeoffs between the benefits and limitations, so different proto-typing approaches prove more or less useful, de-pending on the design, technology, and applica-tion. For example, for location-based services, a WOz simulation might allocate certain tasks to the wizard and let the prototype system au-tomate other tasks.3

The challenge of properly exploring the de-sign space is particularly difficult when design-ing pervasive computing systems for hostile environments, as is the case with structural firefighting. The dangerous environment and physiological and psychological stress make enhanced support desirable, yet it’s very diffi-cult to design and effectively deliver such sup-port systems without overloading users and in-creasing dependencies. Numerous studies have explored various technologies for this type of support,4–8 some of which include empirical

Designing pervasive computing for hostile environments is challenging, because it’s difficult to assess the many design options and their implications. To help address this issue, the authors developed the FireSim experience-prototyping approach. They report on FireSim studies of the LifeNet navigation system for firefighters.

Markus Klann and Mirko GeisslerFraunhofer Institute for Applied Information Technology

PC-11-04-Kla.indd 68 9/22/12 3:21 PM

OctObEr–dEcEmbEr 2012 PERVASIVE computing 69

investigations of firefighting work practices and system evaluations with firefighters.5–7 However, most address specific technological questions with lit-tle or no user involvement. For realistic navigation support, important dimen-sions of the design space—including user interfaces, collaboration support, and work practices—require further exploration.6

As a case in point, we encountered difficulties developing a physical proto-type of our LifeNet tactical firefighter navigation support system that was mature enough for tests with users in the field. The purely virtual simulations we used were helpful but not sufficient. We thus developed the FireSim mixed-reality proto typing (MRP) approach to help us better test the LifeNet system in the field. The MRP approach helped provide a richer and higher quality user experience, improving user involve-ment and feedback.

the design Space for Firefighter navigation SupportIn smoke-filled environments, firefight-ers use protective clothing and breath-ing apparatuses, affording them limited protection for a certain time. Under poor or zero visibility, many firefighters use ropes as navigational aids, called lifelines.

Firefighters engage in teams of two, connected by a short rope, and oper-ate under the orders and supervision of a group leader. The leader remains near the dangerous environment’s entry point and is usually responsible for up to three teams. A security team is on standby, and the leader can send them in to rescue a team if need be.

The first firefighter of a team at-taches himself to one end of a lifeline, attaching the other end to the entry point. When sweeping an area, the team proceeds in a crouched position along the walls, dragging the lifeline behind them, while their colleagues at the entry point typically hold it un-der some tension to maintain a sense

of connectedness and make entangle-ments less likely. Eventually, the team can decide to attach their end of the lifeline to some object such as a door knob before starting their retreat to en-able the team replacing them to more quickly navigate to their last location.

Whether following a previously es-tablished lifeline or not, firefighters use their hands and feet to carefully check whether it’s safe to proceed in a given direction, which is notoriously ques-tionable under often rapidly deterio-rating conditions. Moreover, constant probing of the environment by touch lets firefighters identify doors, wall cor-ners, and other building features, which they use as additional clues for finding their way. To inform subsequent teams of locations and search status, fire-fighters use crayons to label the doors of rooms they’ve already searched, and they scribble simple floor plans when returning to their group leaders.

Lifelines thus constitute a naviga-tion support system that provides lo-cal guidance, and firefighters use this support in combination with all other available information, including that acquired through their sense of touch and locomotion. Exploring an area us-ing lifelines can be a time-consuming process, involving several teams.

Fire services drill their members to reliably execute these practices under stress to maximize safety while fac-ing the operational realities of unpre-dictable environment changes, failing tools, and firefighters being pushed to their physiological and psychological limits. The practices introduce consid-erable redundancy and provide a cer-tain level of resilience. To protect this

system of tools and practices from un-foreseen consequences, fire services are extremely cautious about introducing new tools and deviating from estab-lished practices.

However, accident reports and our own observations reveal numerous limitations with lifelines. They can get burned by fire, cut or stuck under doors, and entangled with other objects, such as furniture and railings. They afford limited operational range; only a single (and typically suboptimal) retreat path; and only limited support for navigating to tagged locations. Once dropped, life-lines can be very hard to recover.

However, despite these limitations, lifelines provide robust navigational support based on local guidance with-out absolute localization. Furthermore, firefighters trust their lives to this sys-tem because, as they say, it provides them with a physical link to their group leaders.

LifenetWe based the LifeNet system on a net-work of sensor nodes, called beacons, to offer firefighters better navigational support during structural fires.6,9 (For a discussion of two similar approaches, see the “Related Firefighter Navigation Support Systems” sidebar.)

Frontline firefighters use the system by deploying beacons while moving about, effectively creating an ad hoc sen-sor network capable of environmental sensing, wireless multihop communica-tion, and navigation support. The system comprises the following components:

• a beacon ejector that can automati-cally deploy beacons;

Fire services are extremely cautious about

introducing new tools and deviating from

established practices.

PC-11-04-Kla.indd 69 9/22/12 3:21 PM

70 PERVASIVE computing www.computer.org/pervasive

Feature: rapid prototyping

• one beacon integrated into each fire-fighter’s boot;

• a computing unit, exchanging infor-mation with the beacons in the boots;

• a microdisplay, integrated into the breathing mask, that shows naviga-tional instructions provided by the computing unit; and

• a device that lets the firefighters input information.

The practice of using physical lifelines motivated several LifeNet features. In particular, we adopted the principle of providing local guidance based on an ad hoc deployed system without pro-viding absolute positioning. This re-duces the technical requirement for the beacons in terms of estimating their

relative location (angle and distance) among neighboring beacons with suf-ficient precision to support navigating from one beacon to the next.

The downside of this simplification is a limitation for showing objects at their absolute location on a map. We read-ily accepted this consequence, because maps aren’t available for the vast ma-jority of buildings. Nonetheless, the sys-tem does support navigation to tagged locations anywhere in the network of deployed beacons.

Consequently, we had to find inter-face designs that aren’t based on maps and that support navigation based on the information available for the fire-fighters’ local neighborhood. Figure 1 shows the design we used—a radar-like

interface showing surrounding beacons in a top-view of the user’s local neigh-borhood, with the next beacon to navigate to marked with crosshairs. Moreover, the interface shows the esti-mated duration for up to two available retreat paths, the estimated duration and length to the current navigational target, and the estimated time until fire-fighters must start their retreat. (More details on this interface, and an arrow-based variant, appear elsewhere.6,9)

To support the collaborative work-flow of search-and-rescue operations, we added an additional LifeNet cli-ent for the group leader—a TabletPC offering LifeNet-based command-and-control functions for registered fire-fighters (discussed in more detail later).

A mong the numerous approaches1,2 that have been tried to

bring advanced support to the wider localization and navi-

gation requirements of firefighters, two are particularly relevant

for our LifeNet approach and design space explorations: Siren3

and the more recent Fire Information and rescue Equipment

(FIrE) project.4

As with LifeNet, both Siren and FIrE propose the use of sensor

networks to support localization, multihop messaging, and envi-

ronmental sensing. Siren puts particular emphasis on customiz-

able alerts and messaging and proposes a PdA-based interface.

meanwhile, FIrE focuses on the design of an interface for a

microdisplay integrated into the breathing mask. they mention,

without providing details, that an arrow5 could be displayed for

guiding firefighters and warn against the risk that firefighters

might misinterpret interfaces that don’t show particular hazards

as meaning that these hazards aren’t present.

Unlike LifeNet, both Siren and FIrE propose that objects are

shown on floor plans at the absolute positions that the sensor

networks are capable of estimating for them. FIrE explicitly men-

tions the need for calibrating a pre-installed sensor network to

obtain satisfactory localization and—as with Siren—mentions that

ad hoc deployment of the sensor nodes could be an option to

avoid dependency from such an infrastructure. but neither pro-

vides details on how this ad hoc deployment could be achieved,

how satisfactory localization and navigation support could be

provided on the basis of such an uncalibrated system, or how

the workflow of an actual search-and-rescue mission would be

supported.

the FIrE researchers argue that “successful implementation of

an advanced information technology system for emergency re-

sponse will require gradual enhancements to the currently used

system, and careful consideration of how to gain and maintain

trust in the system.” they qualify their own research as explor-

atory and assert that their system is meant to be complementary

to existing firefighting techniques and requires extensive user

testing to determine its actual benefit.

REfEREnCES

1. c. Fischer and H.W. Gellersen, “Location and Navigation Support for Emergency responders: A Survey,” IEEE Pervasive Computing, vol. 9, no. 1, pp. 38–47.

2. m. Klann, “tactical Navigation Support for Firefighters: the LifeNet Ad-Hoc Sensor-Network and Wearable System,” Proc. 2nd Int’l Workshop on Mobile Information Technology for Emergency Response (mobileresponse 08), J. Löffler and m. Klann, eds., Springer, 2009, pp. 41–56.

3. X. Jiang et al., “Siren: context-Aware computing for Firefighting,” Proc. 2nd Int’l Conf. Pervasive Computing, LNcS 3001, Springer, 2004, pp. 87–105.

4. J. Wilson et al., “A Wireless Sensor Network and Incident command Interface for Urban Firefighting,” Proc. 4th Ann. Int’l Conf. Mobile and Ubiquitous Systems: Networking & Services (mobiQuitous 07), Acm, 2007, pp. 1–7.

5. d. Steingart et al., “Augmented cognition for Fire Emergency response: An Iterative User Study,” Proc. 11th Int. Conf. Human- Computer Interaction (HcI 05), Lawrence Erlbaum, 2005.

related Firefighter navigation Support Systems

PC-11-04-Kla.indd 70 9/22/12 3:21 PM


For both the firefighter and group-leader interfaces, we included all of the features required to carry out a realistic scenario—including features for navi-gating to previously tagged locations.

design ContextOur design process started with immer-sive ethnographic studies of firefighting work practices,10 creating the grounded domain understanding and inspiration for defining the original LifeNet con-cept. Throughout this process, we ap-plied different techniques to foster par-ticipatory design—in particular, three custom, simulation-based prototyping techniques.11

The first was a low-effort board-game simulation with paper proto-typing, which we mainly used at an early stage to explore scenarios on building maps.

The second was a virtual simulation. To better investigate the highly interac-tive aspects of indoor navigation sup-port without having to resolve the many technical challenges of implementing a functional physical LifeNet prototype, we developed a purely virtual but other-wise fully functional game-like multi-player LifeNet simulation. We used this technique by having groups of firefight-ers play out the same kind of search-and-rescue scenarios as before, letting us study different navigation interfaces and refine the workflow between col-laborating firefighters.6

Although similar virtual simula-tions have successfully been used to explore certain ubiquitous computing applications—for example, with the UbiREAL simulator12—the spatial and bodily nature of activities such as firefighter navigation limits the extent to which they can be studied satisfacto-rily with purely virtual simulations. So, we implemented a functional, physical LifeNet prototype for field testing.9 Al-though this prototype demonstrated that the LifeNet concept could be im-plemented, the actual implementation proved very challenging. The prototype was too fragile and had insufficient

power for infield user testing. In fact, firefighters to whom we presented this system had reservations about using the brittle devices.

This prompted us to develop the third prototyping technique—a mixed-reality simulation. We created the MRP approach by combining elements from two existing prototyping approaches and adapting them for infield studies of firefighter navigation support.

Mixed-reality prototypingThe first approach we adapted is one in which, for an avatar using virtual prototype systems within a simulation, there’s a corresponding human player using partial physical prototypes of the same systems. We linked these real and virtual systems into a coherent mixed-reality system, so we could implement functionality more or less flexibly either in the real system or as a virtual simula-tion. (This approach is commonly used in car and aircraft simulators, and a case similar to our scenario of guiding

navigation in a virtual environment through tactile cues delivered over real actuators appears elsewhere.13)

The second approach addresses the challenge of prototyping location-aware applications for users that move about in a real environment by having human facilitators track the users’ loca-tions over dedicated systems, the WOz technique discussed earlier.3

The specific way in which we in-corporated these two approaches ad-dresses a number of requirements related to the system usage being pro-totyped. These include the required level of system interaction and respon-siveness, the type and speed of the fire-fighters’ motions, the ability to flexibly respond to prototype evolution, and the ability to handle search and rescue operations in confined spaces.

Another implication of our specific realization of the MRP approach is the varying fidelity levels it achieves for the different aspects of the system. For example, the visual feedback users

Figure 1. LifeNet’s radar-like interface for firefighters. It shows the estimated duration for up to two available retreat paths, the estimated duration and length to the current navigational target, and the estimated time until firefighters must start their retreat.

Team

OK

B02 7:45m 0:33

Temp.

19°C

Heart rate

107

Airtime

4:37

4:04

30

Length and time to target

Retreat

0:33

Exit

0:45B02

B17

5m

Mission Extraction

Time leftbeforeretreat

Retreatpath

PC-11-04-Kla.indd 71 9/22/12 3:21 PM



receive on deployed beacons via their interfaces is quite authentic—that is, it corresponds well with what they would see using a fully functional physical system. Conversely, in this realization of the MRP approach, us-ers don’t get any acoustical feedback of deployed beacons hitting the ground, which they would in reality, depending on the environmental circumstances.

Prototype fidelity can significantly affect the user experience,10 and dif-ferent levels of fidelity can be com-bined in a mixed-fidelity prototype.14 Our approach results in a particular fidelity mix, and we present results from a field study on the suitability of this mix for the intended design-space exploration.

As a design technique, our MRP approach is targeted at the central stages of design processes, between

early low-fidelity prototyping and later fully physical prototyping. It can help designers in two specific ways. First, it can help them explore and as-sess design options, such as interface variants, network density, and sensor accuracy in the context of realistic, collaborative field studies in which users exhibit and evolve actual work practices. This affords a strong em-pirical indication for selecting design options for implementing promising physical prototypes.

Second, it yields precise empirical data on how domain experts would op-erate the system in realistic settings. This data can be used to define grounded user models for computer-controlled ac-tors using the prototype system. These user models enable simulations of large-scale scenarios with possibly hundreds of actors, letting designers study the

corresponding phenomena, which would be impractical with the MRP ap-proach. Of course, results of such sim-ulations must be carefully interpreted within the constraints defined by the user models on which they’re based.

Virtual Lifenet SimulationWith this game-like multiplayer simula-tion, human players can control virtual firefighters and simulate complete search-and-rescue scenarios, includ-ing all LifeNet functionality. Figure 2 shows the environment from the first-person perspective of a virtual firefighter, with the mask-integrated microdisplay providing navigational instructions.

The virtual LifeNet implementation includes beacons that are indestructi-ble but otherwise behave realistically as physical objects during deployment,

Figure 2. The FireSim simulation station on the second floor of the training building. The right screen shows the first-person view of a virtual firefighter on the first floor of a virtual model of the training building using a fully functional virtual LifeNet system. The left screen shows video feeds from surveillance cameras covering the entire first floor of the training building.

PC-11-04-Kla.indd 72 9/22/12 3:21 PM


have reliable communication between them, and have virtual sensors that can determine the distance and relative orientation to beacons within a cer-tain range (provided they have line of sight). Although these virtual sensors obtain their data from knowledge of the virtual environment, processing the data—and the networking and com-munication services on the beacons— is essentially implemented in the same way as in any standard ad hoc sensor network. Finally, the wearable and group-leader systems within the virtual environment use exactly the same pro-gram code as the real systems.

A central feature of the virtual simu-lation is that it incorporates obstruction of line-of-sight between beacons by the building structure, including dynamic elements such as doors. This is a cru-cial factor for the functioning of the LifeNet system and highly relevant for its use. This is an example of how the 3D virtual simulation extends be-yond the mere location of firefighters and beacons, showing that it couldn’t

simply be replaced by 2D maps to represent these objects’ locations for mixed-reality simulations.

Mixed-reality Lifenet SimulationThe key idea behind the MRP approach is to maintain a synchronized virtual simulation while a real scenario un-folds. This lets you connect partially implemented real prototypes with their fully implemented virtual counterparts, and share information and services be-tween them as needed to support your investigation.

To this end, we set up a virtual LifeNet simulation on the second floor of the training building of the Paris Fire Brigade (see Figure 2). This simulation was extended to connect actual fire-fighters (Figure 3a) and group leaders (Figure 3b) on the first floor to their virtual counterparts over a wireless network. The real systems then inter-acted with the virtual simulation—that is, the virtual LifeNet simulation for which no real counterpart existed. As a result, the real firefighter system’s

microdisplay showed the same infor-mation as the virtual one.

To synchronize the virtual simula-tion with the real scenario, we had a facilitator observe the actions of a real firefighter through video feeds on a monitor (see Figure 2), sent from cameras we had installed to cover the entire first floor. The facilitator also controlled a virtual firefighter, repli-cating these actions as similarly as pos-sible. To the same degree, the interface perceived by the real firefighter corre-sponded with his actions.

FireSim applicationWe applied the FireSim approach dur-ing a two-day field study in May 2009 at the Paris Fire Brigade. Three teams of five firefighters, recruited for the occa-sion from different fire stations, partici-pated in several simulation runs with changing roles.

For each simulation run, we obtained video feeds covering the firefighters’ actions, log-data from the virtual en-vironment for later reconstruction

Figure 3. Actual firefighters and a group leader on the first floor. (a) Firefighters at the moment of changing from one retreat path to another and (b) a group leader sending his team on the rescue mission.

(a) (b)

PC-11-04-Kla.indd 73 9/22/12 3:21 PM



of paths and interfaces, and video re-cordings of feedback sessions directly after each simulation run and of one final group discussion. We describe one session in detail here—Figure 4 gives an overview of the scenario. It starts with two groups arriving at the first floor and entering through two differ-ent access points. Each group has two teams comprising two firefighters each (1A and 1B for the first group; 2A and 2B for the second group) and a group leader (GL 1 and GL 2).

By assigning reconnaissance mis-sions to their respective teams via the TabletPC (see Figure 5), the group lead-ers send in firefighter teams 1A and 2A to systematically search the floor while keeping teams 1B and 2B standing by

as security. As the search teams start their missions, their beacon ejectors automatically deploy an initial beacon, thus effectively starting one separate LifeNet at each access point.

As the teams proceed along the walls, they deploy additional beacons (shown in green and blue in Figure 4 for 1A and 2A, respectively). Because these are the first teams on this floor, LifeNet ini-tially only provides them with direc-tions for their current retreat path.

Eventually, 2A finds two victims lo-cated in a bathroom (grid cell L15 in Figure 4). The leader of team 2A taps a button once for each victim, tagging the location as containing two victims. This information is stored in the closest deployed beacon, and a “victim found”

message containing the ID of this bea-con is sent from beacon to beacon and eventually reaches Leader 2’s device (see Figure 5). Leader 2 then tasks 2A with retrieving (“extracting”) the first victim, because retrieving both at the same time wouldn’t be feasible.

In the meantime, 1A eventually de-ploys a beacon at location I13, effec-tively linking both LifeNets such that information propagates across the en-tire network, and both teams acquire an additional retreat path to the other access point (see Figure 1). As a result, the unhandled “victim found” mes-sage from team 2A also reaches Leader 1. Shortly thereafter, team 1A finds a third victim at location J11 and quickly completes extraction to access point 1,

Figure 4. The search-and-rescue scenario for the LifeNet field evaluation at the Paris Fire Brigade. In this instance, team 1B is going to be rerouted to a different exit because LifeNet has detected a fire blocking the original retreat path.

Fire detection

Shortcut

Rerouting

Alternativeretreatpath

2B

2AAccesspoint 2

1M

CHAMBRE I

LLE DEBAIN

NE

SALON CHAMBRE

+ 4.02

± 0.00

CHAMBRE 2

PREMIER ETAGE

DATE:

WC

ALLEDE BAINS

1B

GL 11A

GL 2

Locationtagging

Accesspoint 1

PC-11-04-Kla.indd 74 9/22/12 3:22 PM


enabling Leader 1 to engage the backup team 1B.

We carried out the steps just de-scribed only in the virtual environment and then, at that point, we started the mixed-reality simulation. As shown on the group leader system, the “victim found” message from team 2A was re-ceived at 17:38 in this particular ses-sion. Leader 1 then processed it to start a “rescue” at 17:39 for 1B (see Figure 5). By doing so, Leader 1 implicitly used the beacon location contained in the “victim found” message as the destina-tion for this rescue mission. As shown by the grey line in Figure 4, 1B was guided on the shortest path to the vic-tim, using the shortcut previously es-tablished by 1A and using the beacons deployed by 2A for the second part.

Upon reaching the victim, the leader of team 1B tapped a button located on his right trouser leg, indicating that they would start the victim extraction. The button used was actually a sticker, and the action was executed by the facilitator watching the tapping on the video feed. As a result, their mission changed to “extraction” with their current access point becoming their new navigation target, and Leader 1 received the corre-sponding “extraction started” message at 17:42 (Figure 5). About half a minute later, 1B reached the location shown in Figure 3a as well as Figure 4.

Shortly before, the facilitator had created a fire at location G10 resulting in the surrounding beacons registering rising temperatures and eventually fail-ing. Although this cut off communica-tion between Leader 1 and firefighter 1B, LifeNet could still alert both par-ties of the cut-off retreat path. Conse-quently, the alternative retreat path to access point 2 became active for 1B. The interface of 1B (Figure 1) therefore indicated the next beacon to navigate to—the one behind and to the right of the team. The firefighters stopped their progression and waited for a few sec-onds before slowly turning and starting on the new path. As shown in Figure 4, they then took a direct path of beacons

to access point 2 and completed the extraction shortly thereafter.

results and discussionThe study showed that the LifeNet con-cept of only local guidance based on a self-deployed ad hoc infrastructure yields effective navigation support. More specifically, unanimous feedback from the firefighters indicated that they found the support easy to use and that they appreciated the extended LifeNet capabilities, including the sense of con-nectedness to their group leader, while suggesting a number of new modifica-tions for the interface, such as connect-ing beacons belonging to a path.

We also learned that connectivity between beacons could be disturbed or interrupted by obstacles such as fur-niture or wall corners. This limitation

was present in our simulation due to connectivity being defined by line of sight. The firefighters successfully de-veloped and applied an ad hoc work practice of probing movements to work around this limitation. This indicates that the limitation might be acceptable to some degree in combination with an appropriate work practice. If con-firmed by more comprehensive stud-ies, this would substantially facilitate a physical LifeNet implementation.

Considering Work practicesAs we mentioned, the firefighters spon-taneously developed a technique of moving about in a small area around their current location in case they lost connectivity. They thus consis-tently could reestablish connectivity by effectively using themselves as relay

Figure 5. The interface for the group leader system at access point 1. The “victim found” message from one of the firefighters was received at 17:38, and the leader processed it to start a “rescue” at 17:39. At 17:42, the leader received the corresponding “extraction started” message.

PC-11-04-Kla.indd 75 9/22/12 3:22 PM



beacons in the network. This illus-trates the simple but often neglected fact that the firefighters’ abilities can be an important factor in system performance.

The typically rejected idea of us-ing another team’s path in case your own team’s path became unavailable received significantly higher approval (compared to our previous studies

with other techniques6,11), especially after the firefighters successfully ex-perienced how the LifeNet would sup-port this.

The moment shown in Figure 3a is essential in this respect. Before reach-ing this location, the firefighters had progressed confidently and quickly along the same path they had taken on their way in, relying both on the navi-gation interface and their trained abil-ity to remember their path. Receiving directions to deviate from this path in the depicted moment constituted an unprecedented experience and resulted in a moment of consternation and ini-tial probing of the situation before em-barking with increasing confidence on the new path.

Despite this unprecedented ap-proval, and much to our satisfaction, the firefighters also went on to further critically explore the concept beyond the scope of what they had directly experienced during the study. For ex-ample, they pointed out the problem-atic tactical implications regarding accountability and availability of teams being rerouted to different access points and started a discussion on how these could be handled.

Furthermore, they discussed comple-menting automatic with manual bea-con deployment and whether beacons should be integrated with traditional lifelines, contrasting opinions voiced after previous virtual simulations.

reviewing the Mrp approachOur approach enabled low-cost ex-ploration of a number of axes of the

design space, including sensor per-formance of the beacons (such as ac-curacy and latency) and deployment strategy (spatial resolution and redun-dancy) through virtual simulation. Although this virtually simulated LifeNet was in fact invisible to the firefighters, the firefighter system was intentionally rugged, which not only allowed comparatively rough handling but also avoided raising skepticism about brittle devices.

Compared to the related approaches discussed in the sidebar, the MRP ap-proach exhibits two important differ-ences. First, the firefighters didn’t have to control an actor in a virtual environ-ment to experience the corresponding behavior of a real system.13 Instead, they could indirectly control the simu-lation through their bodily behavior, as is appropriate for the embodied interac-tion with LifeNet, bringing all the pre-viously explained factors of firefighter navigation into play.

Second, informing the wizards of the firefighters’ locomotion via top-view video feeds not only provided material for later analysis but also left the firefight-ers virtually unobstructed by any pro-totyping infrastructure. This provided

the wizards with a first-person vir-tual interface, enabling them to repli-cate these movements with compara-tively high precision, provided there was sufficient lighting. This certainly helped the participating firefighters in reappropriating the scenario as their own experimental space, which they did by introducing new navigational chal-lenges, such as opening and closing certain doors and having one of their colleagues play the victim in need of extraction. Both of these aspects are crucial for dealing with the relatively subtle interaction of the firefighters’ navigational movements with the sup-porting system, and both aspects would have been problematic to achieve with other approaches.15

In terms of synchronization, using human facilitators proved to be a highly flexible option, allowing for spontane-ous extensions and modifications with minimal effort, as illustrated by the makeshift “victim found” button. Still, using one human facilitator per simu-lated firefighter makes scaling up this approach relatively expensive.

The most visible effect of being able to use the systems in realistic work set-tings was that all participants exhibited a highly satisfactory level of engage-ment in the sense of taking the missions seriously, focusing on the assignments, and behaving realistically. Evidence for the interest created by this engagement was that they requested and carried out more sessions than originally sched-uled, debriefings showed an atypical balance of perspectives from all partic-ipating roles, and they introduced sce-nario variations.

The variation of introducing a human victim led to a particular unexpected and instructive exploration. In this configuration, the leading firefighter moved backward during extraction, which had not been the case before. While the firefighters completed the extraction successfully in both cases, an observing firefighter argued that his colleagues had to interpret the naviga-tion interface differently when moving

the mixed-reality prototyping approach strikes

a good tradeoff between effort and obtainable

results for exploring the support of embodied

experiences such as navigation.

PC-11-04-Kla.indd 76 9/22/12 3:22 PM


backwards and his colleagues tried to convince him that this was in fact not the case. While his colleagues were obviously right, since the interface is relative to the firefighter’s orientation, it was much to our surprise that they confirmed this by going back to the virtual simulation.

T he MRP approach strikes a particularly good tradeoff between effort and obtain-able results for exploring

the support of embodied experiences such as navigation. The users’ decision to explore a question encountered in the mixed-reality simulation by going back to the virtual simulation shows that different techniques don’t exist independently within a design process but actually form a kind of method-ological ecosystem. Their motivational effect and powers as design tools de-pend on how they’re adapted, applied, and combined based on the context of the design process.

We hope that these results encour-age other researchers working on simi-lar systems to explore them in realistic scenarios by using this or similar tech-niques. This might help compare ap-proaches on a level that’s meaningful for eventual applications,2 reduce risks of costly and potentially dangerous erroneous developments, and reduce unfounded user skepticism toward new technologies.

We’re continuing our research along two lines. We’re exploring design op-tions for implementing a navigation support system integrated into life-lines (www.project-profitex.eu), and we’re creating grounded user models for computer-driven simulations of technology use in complex large-scale emergencies (www.socionical.eu).

AckNowLedgmeNTSthe European commission supported this re-search as part of two projects (www.wearitatwork.com and www.socioncal.eu). We greatly appreci-ate the participation of the Paris Fire brigade in this research.

ReFeReNceS

1. N. Davies et al., “Rapid Prototyping for Ubiquitous Computing,” IEEE Pervasive Computing, vol. 4, no. 4, 2005, pp. 15–17.

2. M. Büscher, M. Kristensen, and P.H. Mogensen, “Making the Future Pal-pable: Notes from a Major Incident Future Laboratory,” Int’l J. Emergency Management, vol. 5, nos. 1–2, 2008, pp. 145–163.

3. L. Yang, I.H. Jason, and A.L. James, “Design Challenges and Principles for Wizard of Oz Testing of Location-Enhanced Applications,” IEEE Per-vasive Computing, vol. 6, no. 2, 2007, pp. 70–75.

4. C. Fischer and H.W. Gellersen, “Location and Navigation Support for Emergency Responders: A Survey,” IEEE Pervasive Computing, vol. 9, no. 1, pp. 38–47.

5. X. Jiang et al., “Siren: Context-Aware Computing for Firefighting,” Proc. 2nd Int’l Conf. Pervasive Computing, LNCS 3001, Springer, 2004, pp. 87–105.

6. M. Klann, “Tactical Navigation Sup-port for Firefighters: The LifeNet Ad-Hoc Sensor-Network and Wearable System,” Proc. 2nd Int’l Workshop on Mobile Infor-mation Technology for Emergency Response (MobileResponse 08), J. Löffler and M. Klann, eds., Springer, 2009, pp. 41–56.

7. J. Wilson et al., “A Wireless Sensor Net-work and Incident Command Interface for Urban Firefighting,” Proc. 4th Ann. Int’l Conf. Mobile and Ubiquitous Sys-tems: Networking & Services (MobiQui-tous 07), ACM, 2007, pp. 1–7.

8. K. Lorincz et al., “Sensor Networks for Emergency Response: Challenges and

Opportunities,” IEEE Pervasive Com-puting, vol. 3, no. 4, 2004, pp. 16–23.

9. M. Klann et al., “LifeNet: An Ad-Hoc Sensor Network and Wearable System to Provide Firefighters with Naviga-tion Support,” Adjust Proc. UbiComp, 2007; http://eprints.lancs.ac.uk/id /eprint/13037.

10. D. Reilly et al., “Evaluating Early Proto-types in Context: Trade-offs, Challenges, and Successes,” IEEE Pervasive Comput-ing, vol. 4, no. 4, 2005, pp. 42–50.

11. M. Klann et al., “Playing with Fire: User-Centered Design of Wearable Computing for Emergency Response,” Proc. CHI Extended Abstracts, ACM, 2007, pp. 1665–1668; http://doi.acm.org/10.1145/1240866.1240878.

12. H. Nishikawa et al., “UbiREAL: Realis-tic Smartspace Simulator for Systematic Testing,” Proc. 8th Int’l Conf. Ubiqui-tous Computing (UbiComp 06), Springer, 2006, pp. 459–476.

13. R.W. Lindeman et al., “Effectiveness of Directional Vibrotactile Cuing on a Building-Clearing Task,” Proc. SIGCHI Conf. Human Factors in Computing Systems, ACM, 2005, pp. 271–280.

14. M. McCurdy et al., “Breaking the Fidelity Barrier: An Examination of Our Current Characterization of Prototypes and an Example of a Mixed-Fidelity Success,” Proc. SIGCHI Conf. Human Factors in Computing Systems, ACM, 2006, pp. 1233–1242.

15. Y. Li, J.I. Hong, and J.A. Landay, “Topiary: A Tool for Prototyping Loca-tion-Enhanced Applications,” Proc. 17th Ann. ACM Symp. User Interface Software and Technology, ACM, 2004, pp. 217–226.

the AuThoRSMarkus Klann is the head of the Situated computing Lab at the Fraunhofer Institute for Applied Information technology and a doctoral candidate at the department of information systems at rWtH Aachen University. His research interests include HcI, experience prototyping, design and innova-tion processes, and emergency response. Klann has a diploma in computer science from the University of Hamburg. contact him at markus.klann@ fit.fraunhofer.de.

Mirko Geissler is a researcher in the Situated computing Lab at the Fraunhofer Institute for Applied Information technology. His research interests include virtual and mixed-reality simulations, visualization, and HcI. Geissler has a diploma in computer visualistics from the University of Koblenz-Landau. contact him at [email protected].

PC-11-04-Kla.indd 77 9/22/12 3:22 PM

Documents

Experience Prototyping: A New Approach to Designing Firefighter Navigation Support