Making the future palpable: notes from a major incidents future laboratory
ABSTRACT Future laboratories allow users to experiment with future technologies in as realistic as possible conditions. We have devised this method because, to realize the potential of ubiquitous computing technologies it is essential to anticipate and design for future practices, but for prospective users it is often difficult to imagine and articulate future practices and provide design specifications. They readily invent new ways of working in engagement with new technologies, though and, by facilitating as realistic as possible use of prototype technologies in Future Laboratories designers and users can define both opportunities and constraints for design. We present 11 scenes from a Major Incidents Future Laboratory held in September 2005. For each scene we point out key results. Many raise tough questions rather than provide quick answers. In the discussion we summarize important lessons learnt.
-
Citations (0)
- Cited In (1)
-
Article: Handy navigation in ever-changing spaces - an ethnographic study of firefighting practices
[show abstract] [hide abstract]
ABSTRACT: This paper presents an ethnographic study, conducted to gain an insight of the practices around navigation of firefighters on the first line of intervention. We argue that the common approach of looking only at the technical aspects is incomplete. We show instead, that navigation of firefighters in ever-changing spaces is a collective craft or art, where technology is only one of the relevant pieces, but not the only one. Therefore design should take a deep look at existing navigation practices of firefighters. In order to identify relevant work practices, we conducted our ethnographic study to find out patterns of navigation work and based on our findings, we provide an outline of how the navigation practices can be supported by ubiquitous computing.
Page 1
Making the future palpable: Notes from a major
incident Future Laboratory
Monika Büscher
Department of Sociology
Lancaster University
UK
m.buscher@lancaster.ac.uk
Margit Kristensen
Computer Science Department
Aarhus University
Denmark
margit@daimi.au.dk
Preben Mogensen
Computer Science Department
Aarhus University
Denmark
preben@daimi.au.dk
ABSTRACT
Future laboratories allow users to experiment with future technologies in as realistic as possible conditions. We have
devised this method because, to realize the potential of ubiquitous computing technologies it is essential to anticipate
and design for future practices, but for prospective users it is often difficult to imagine and articulate future practices
and provide design specifications. They readily invent new ways of working in engagement with new technologies,
though and, by facilitating as realistic as possible use of prototype technologies in Future Laboratories designers and
users can define both opportunities and constraints for design. We present 11 scenes from a Major Incidents Future
Laboratory held in September 2005. For each scene we point out key results. Many raise tough questions rather than
provide quick answers. In the discussion we summarize important lessons learnt.
Keywords
Ubiquitous computing, future practice, emergency response
INTRODUCTION
Ubiquitous computing refers to the fact that computation is increasingly embedded in small and large devices
(biomonitors, mobile telephones, personal digital assistants, ambulances) and dependent on digital services
(connectivity, storage, geographical information services (GIS), location tracking). Ubiquitous computing
technologies have enormous potential to support (new forms of) emergency response work. Resources like
ubiquitous connectivity and location information, combined with sensors, wireless communication, displays, or data
devices like cameras, etc. could enhance people’s ability to make sense of emergency situations, to formulate an
appropriate response and collaborate with colleagues – both on the scene and remotely, in hospitals, and incident
control rooms. However, the urgency of emergency situations makes invention and adoption of new technologies
and new practices hard to realize. Two issues in particular hamper innovation:
•
Future practice. In interaction with new technologies people change established practices. Unpredictable
and sometimes unintended consequences ensue. Future technologies should anticipate and support new
ways of working. Yet, it is impossible for designers to predict future practices and consequences of change.
As realistic as possible experimentation is required. This general challenge is exacerbated in real life
emergency response work where there is little room for experimentation.
’Invisibility’. Weiser’s ‘invisibility’ principle for ubiquitous computing (1991) prompts many designers to
make computing literally invisible by embedding it and by automating processes e.g. of establishing
networks. This protects people from complex choices, but it takes the human ‘out of the loop’ (Endsley,
Bolté and Jones 2003) and makes it hard for people to know what technologies are doing and to trust them.
•
71
Page 2
Proceedings ISCRAM2007 (B. Van de Walle, P. Burghardt and C. Nieuwenhuis, eds.)
We carry out field studies, and take a participatory design approach (Grønbæk, Kyng and Mogensen, 1997) to
address these difficulties, bringing together an interdisciplinary team of practitioners, designers, and work analysts
to design ubiquitous computing technologies for a range of different domains. Researchers/designers have to
understand existing and future work practices, as they create prototype technologies, while professional practitioners
take part in analysis/design and explore new ways of working. Currently, our main design goal is to provide
infrastructural support for making ubiquitous computing ‘palpable’, that is, ‘noticeable, ‘manifest, obvious, clear’
(http://dictionary.oed.com/). In other words, we seek to enable people to put themselves in the loop where
computational processes and services are concerned. The work described in this paper is part of a project called
PalCom, which pursues this goal (http://www.ist-palcom.org).
Supporting the work of emergency response personnel is a particularly fruitful part of this work, because there is a
clear potential for ubiquitous computing to augment the work and a need to be understand and trust the technology.
To maximize the ‘hard test case qualities’ of emergency work for design, we focus on ‘major incidents’. Within
Europe, major incidents are declared when massive damage to persons or property is caused or projected. They
require collaboration between different emergency response agencies (police, fire services, hospitals, etc.), giving
rise to many uses of ubiquitous information and communication technologies.
METHODOLOGICAL BACKGROUND
Within socio-technical innovation in general, naturalistic experiments with new technologies have been used
productively. They can inspire ideas, but also function as ‘breaching experiments’ (Garfinkel 1967) that draw the
practices on which participants ordinarily depend to the designers’ attention. In one of our examples below, we see,
for example, how cumbersome a request like ‘take a picture of that victim’ can be when one of the speakers is only
virtually on the scene and neither knows what the other can see or where s/he is looking.
Within participatory design, approaches such as co-realization (Hartswood, Procter, Slack, Voß, Büscher,
Rouncefield, Rouchy 2002) draw experiments, analysis and design inside the process of socio-technical innovation,
helping greatly in producing viable and desirable innovations. However, this approach is difficult when more
futuristic socio-technical imagination is the goal. In particular, experimentation and futuristic imagination are highly
desirable, but impossible to achieve in the context of real emergency response situations. Seen from a practitioners
point of view, training exercises are well known and well used, both regarding everyday response and major
emergencies, but they are designed to hone use of existing technologies and established ways of working rather than
explore the potential of new technologies and new practices.
To facilitate imagination and experimentation, we have devised the method of Future Laboratories. Future
Laboratories introduce functional prototypes into realistic enactments of work. They foster the emergence and
exploration of new ways of working – not only through discursive ‘what if’ scenarios, but also as practically
discovered, often tacit but observable possibilities. Ideally, the practitioners should be experienced professionals.
THE MAJOR INCIDENTS FUTURE LABORATORY
The major incidents Future Laboratory took place over two days in September 2005. It generated a host of design
ideas and activities, described elsewhere (e.g. in Kramp et al. 2006, Kristensen and Kyng 2006, Büscher and
Mogensen 2007). It was the first major incidents future laboratory, and the first time we experimented with the
prototypes and mock-ups1. The first day was held an a training site for emergency response personnel – an area
where car accidents, building fires and other incidents can be staged (Figure 1). The participants included 14
researchers, 10 practitioners and 3 ‘victims’. We started with a short introduction in a class room, then moved into
the grounds, where we had staged a car accident (Figure 1), to explore – hands-on – 11 incident ‘scenes’, planned
beforehand. The professionals had brought new radios they wanted to test and, with the help of
researchers/designers, they used the PalCom prototypes and mock-ups at the ‘accident site’ and in an ‘Acute
1 We seek to develop technology to support all the agencies involved in the emergency response effort: police,
firefighters, ambulance people and medical teams (doctors and nurses) and all levels of the hierarchies in the
emergency response. At the time of the future laboratory described in this paper, we had mainly realised prototypes
for the medical staff, but were starting to move into development of technologies also to be used by the police and
firefighters. Our location within this overall design process is reflected in the (im)maturity of technology
development and the focus of the future laboratory.
72
Page 3
Büscher et al. Making the future palpable
Medical Coordination Centre (AMC)’ which would normally be at the hospital, but which we had set up in a barn
close by. Responders from all major incident agencies participated in the Future Laboratory.
While our main focus is on major incidents, our technologies must also support response to everyday incidents: One
key insight from our field studies is that new technologies should not only be used in major incidents situations –
they also have to be used and be useful in everyday situations. This – together with the level of maturity of the
prototypes – informed the set-up in this first major incidents Future Laboratory. Below we describe the prototypes
and the accident set-up, followed by analysis of 11 Future Laboratory scenes – where professionals enact realistic
work, using prototype ubiquitous technologies, designed to allow staff to make their functioning ‘palpable’. Key
results are highlighted after each scene.
Figure 1 A car accident staged at Aarhus ‘Brandskolen’. Source: http://www.aarhuskommune.dk
The prototypes and the set-up
To make realistic enactment of work possible, we set up an accident, where two cars have crashed and one has spun
several meters away through the impact. There is one severely injured person trapped in the car shown in Figure 1.
Petrol is spilling out of this car, which means only specially trained rescue personnel will be allowed to approach it.
The other car carried two persons. The passenger has been thrown out of the car and lies, heavily injured, on the
roadside. The driver managed to crawl out into the road.
A passer-by has called 112 (911) and the emergency responders arrive at the site. At the hospital AMC is activated,
meaning the doctor there opens her connection to the emergency responders and the technologies at site: She can see
live video from the scene, she receives pictures of the injured persons, taken by staff on the ground, she can speak
with personnel, e.g. the medical responders and she receives signals from biomonitors mounted on injured persons.
Figure 2 A wireless biomonitor prototype, its
data inspected on a ‘wearable’ display.
Figure 3 The wireless bio-monitoring system.
73
Page 4
Proceedings ISCRAM2007 (B. Van de Walle, P. Burghardt and C. Nieuwenhuis, eds.)
To realize a prototypical technological future the researchers/designers set up or brought:
•
•
•
•
•
•
•
A wireless network
Wireless biomonitors (Figure 2)
Wearable displays (these are simulated by portable PC’s)
Basestations (relaying communication from sensors into the network)
Still and video cameras
Mobile phones
Radios
The wireless biomonitoring system comprises a wireless biomonitor (Figure 2), basestations and connectivity. It
works as shown in Figure 3.
As a biomonitor is mounted on a victim, it collects bio signals from the victim’s body by use of sensors. The
collected signals are – via BlueTooth – sent to a basestation – a computer that can store those signals. From the
basestation (and, within a radius of about 100 meters, also by use of Blue Tooth) the signals can be shown on any
number of displays. One can see data from all patients on one display or focus on the data of individual patients. In
the Future laboratory we had three biomonitors and two ‘wearable’ displays (simulated by laptops). The data can
also be accessed elsewhere, e.g. at hospitals (in AMC or the emergency department) using existing networks such as
WIFI, GPRS or ad hoc networks. In the future laboratory a wireless network was used to communicate to the AMC.
A video camera is mounted on one of the ‘response vehicles’ nearby (in the Future Laboratory this was simulated by
a car wreck in the training area, but in ‘real life’ the camera is meant to be on a telescopic pole on the roof of an
emergency vehicle), and live video is transferred to the AMC. Moreover, one of the researchers takes pictures,
including pictures of injured persons. In the Future Laboratory a digital camera was used, but in future cameras
could be embedded in helmets or glasses, so that the action ‘taking a picture’ could be done by looking at the point
of interest and pushing a button. The process could also be automated – taking pictures at specified time intervals,
for example. These pictures are also transferred to AMC (Figure 4).
Figure 4 The ‘Overview’ relayed to the AMC, and a researcher taking pictures of victims to send to the AMC.
In addition, all the professionals brought mobile phones. They were used for communication (e.g. between the
incident site and AMC). The professionals also brought and tested a new radio system for communication across
distances and at the incident site.
Exploring socio-technical futures of major incidents work – 11 scenes
Scene 1: Multiple teams arriving
The police, the medical team and the fire service arrive at the scene. They bring with them different kinds of
equipment such as wireless biomonitors, wearable displays, cameras, mobile phones, radios and video cameras.
Key results: Enactment and verbal accounts of what would happen if this was real combine and ‘take’ people ‘into
the scene’, enhancing the realism of this future populated with professionals and future technologies. During a think
aloud session researchers and professionals discuss what each group/person would do in this situation. What is
needed in terms of information and equipment?
74
Page 5
Büscher et al. Making the future palpable
Scene 2: Forming a first picture of the victims
The medical team forms a first picture of the victims on the roadside by examination. In this way they judge who
needs help first. One of the victims lay on the ground on his back, the other facedown.
Figure 5 Wireless biomonitors are placed on the injured persons.
Key results: The discussion focuses on whose responsibility this task is: If the doctor is there the responsibility is
his/hers. If not, it is the ambulance staff that is responsible. Hands-on experience provides insight into the handling
of monitors. An important discussion develops regarding where to place the wireless biomonitor – theoretically it
can collect data, no matter where it is placed on the body, but during this hands-on session we realize that it should
probably not be on the back since almost all injured persons are placed on their back during transportation.
Scene 3: Patients in dangerous situations
The doctor cannot get close to the injured person trapped in the car, who is also threatened by leaking petrol. The
fire fighter places a biomonitor on him. If this was a real situation, he would be wearing thick, heat resistant gloves.
Figure 6 The victim trapped inside the car
Key results: An expansion of the discussion regarding responsibilities begins to explore important questions:
Is it realistic to expect firefighters in a real major incident situation where medical staff are unable to get to injured
persons (e.g. in a train), to mount wireless biomonitors? If this could happen – what influence would it have on the
emergency response organization and process, regarding division of work, responsibility, accountability and
continuity? How would one know from a distance that the biomonitor is working? Taking a more technology
focused turn, the discussion explored how biomonitors could be inspected on site and remotely. Moreover, could
biomonitors be designed to be more ‘foolproof’ and robust in terms of the:
•
•
•
casing that protects their ‘insides’
connections they need to the victim’s body
connectivity they need to be a part of PalCom assemblies?
Scene 4: Collecting information for an overview
The doctor creates connections between his wearable display and the biomonitors.
75
Page 6
Proceedings ISCRAM2007 (B. Van de Walle, P. Burghardt and C. Nieuwenhuis, eds.)
Figure 7 Linking biomonitors to a wearable display (here a laptop carried by a researcher/designer)
Key results: A series of questions emerged when the professionals tried to establish connections and use the
information. For example:
•
•
•
•
•
•
How does one establish the connection?
How does one know the connection is working?
What if there are a number of different biomonitors?
Are pictures a good way of identifying injured persons?
What should happen automatically and what should the doctor (or others) do explicitely?
How should data be presented in the overview and for individual patients?
Moreover, it became obvious that personnel working with injured persons should not access their wearable display
with their hands – the hands are needed for other work.
Scene 5: Cordoning off the area
The professionals describe and demonstrate how they would cordon off the area and police the boundary
Key results: The professionals had found different movable marking materials. It is common practice to use large
cars for cordoning off. However often there will be shortage of responders and equipment, so that other solutions
should be investigated. This led to a discussion of ideas that could exploit and augment material practices and
material objects to support and police the structuring of the incident site (Büscher and Mogensen 2007).
Scene 6: Freeing the victim trapped in the car
The doctor works with the firefighter to ensure the person is harmed as little as possible in the effort of freeing him
from the car. However, the doctor must work from a safe distance, as fuel has escaped and sparks may trigger a fire.
Figure 8 The doctor working with the fire fighter to free the victim from the car
76
Page 7
Büscher et al. Making the future palpable
Key results:
•
How does the doctor use the information s/he receives from the wireless biomonitors, if s/he is not right
beside the injured person?
What other information does s/he need? How much can intelligibly be displayed on the screen and how?
Could an audio-visual link between the doctor and the victim be useful? Perhaps a link that shows the
doctor what the firefighter sees, using the camera embedded in the fire fighter’s helmet?
If the alarm is coming from a distant source (even a few metres away), the receiver should have some local
notification – a beeper, message on radio?
Should there be audio-visual links to the hospital trauma unit?
•
•
•
•
Scene 7: Patients’ conditions change
As the doctor is treating one of the injured persons, the status of another, who is out of sight, worsens. The
biomonitor data reflect the change.
Key results: A discussion of how the the medical team should be supported in perceiving such changes raises a
number of important questions:
•
•
Should people routinely monitor all data? How?
Should there be alarms? How would they be triggered? A system could not easily ‘know’ when a change is
critical. After an accident bio-data that would normally be considered critical (e.g. bloodloss) may not seem
critical. Dynamically determined thresholds were discussed. They raise issues about who would do the
adjusting. If it was done automatically, how could staff be sure that the levels are correct?
What form should alarms take in a stressful environment that is already saturated with stimuli?
What actions are to be taken? Who is to act? What support for coordinating action is available?
•
•
Scene 8: Technical failure?
Suddenly the doctor does not receive data from one of the biomonitors.
Key results: The professionals check potential causes and discussion reveals a number of further possible reasons for
the lack of data. The person may have died, the monitor may have fallen off, there may be a loss of power, system
failure, the network could be down, … (Büscher 2007). The question is how staff could be supported in finding out
and addressing the problem. Data streams should not simply stop but document their ceasing according to the cause.
Moreover it becomes clear that it will not be the professionals on site that can analyze and solve the problems. It is
suggested that a person off-site could be responsible for remote inspection and repair. However, an on-site presence
of technical responders – already introduced by some large disaster response organizations – seems highly desirable.
Scene 9: The ambulance stretcher
While the patient is moved onto the ambulance stretcher, the data from biomonitors is still received on the doctor’s
wearable display.
Key results:
•
Should there be automatic changes to subscriptions? That is, should data now be displayed on the
paramedic’s wearable display? On the screen inside the ambulance?
Should the doctor be notified of the change? Should his subscription be terminated?
•
Scene 10: Emergency room
The patient arrives in the emergency room with biomonitors, evidence of emergency treatment (e.g. intravenous
fluid infusions, neck-collar or bandages) but with very limited records/documentation and a temporary ID.
Key results: Since it is mainly the on site emergency response effort we focused on in this future laboratory we had
not established an emergency room setting, so this scene is only discussed, not enacted. Nevertheless important
questions were raised:
•
How to switch assemblies and subscriptions for data transfers between pre-hospital and hospital systems?
77
Page 8
Proceedings ISCRAM2007 (B. Van de Walle, P. Burghardt and C. Nieuwenhuis, eds.)
•
•
Should the wireless biomonitor also be used within the hospital setting?
How could emergency room staff prepare to receive injured persons? – Which information would help?
Scene 11: In AMC at the hospital
For each of the scenes above, Erica, the trauma doctor, was in the AMC. She remotely participated in the activities
on the scene and joined all discussions, providing valuable insights from the AMC perspective.
Figure 9 Discussion of events seen from the AMC perspective
Erica’s job is to coordinate the transport of victims to hospitals that have the capacity and specialists to deal with the
victims’ injuries, and to prepare the respective trauma teams for the arrival of the patients. Below we describe key
moments in her collaboration with the staff on the scene and her use of the prototypes.
Erica gains a sense of people’s injuries from the data she receives from the incident site. On the screen in front of
her she sees live video from the scene (Figure 10, left). The camera was mounted on one of the ‘response vehicles’,
and – in communication with Erica – a researcher/designer acting as a ‘remote controlled motor’ moved it to show
an appropriate overview (Figure 10, right).) Erica communicates with her colleagues via radio.
Figure 10 Erica in the AMC, working with colleagues on the scene. A researcher/designer moves the camera.
She has two more screens with pictures of patients and data from the biomonitors placed on victims (Figure 10,
middle). Initially Michael, a researcher/designer does takes pictures of victims on the scene. Erica finds it necessary
but difficult to know where the victim is located in the video overview, because, while she can see where Michael is
taking pictures, their arrival on her screen is delayed (due to a design flaw discovered as a result of the future
laboratory). Moreover, Michael is photographing whole victims’ bodies, but Erica needs close-ups to see the nature
of the victim’s injuries. At the discussion after Scene 2 (‘Forming a first picture of the victims’) she asks whether
one of the medical team could take pictures instead. Troels, the on-site doctor, agrees to do so. This provides Erica
with a better sense of the victims’ injuries. However, in order to tell Troels what she needs to see, fairly cumbersome
communications are required:
Yes… Ok…now I received one ((picture)). He lies with one arm under his head and dark hair …
78
Page 9
Büscher et al. Making the future palpable
As Erica requests more and more specific pictures, Troels is getting stressed. He needs to treat the victims, not just
take pictures of them. He puts his radio in his pocket. Erica notices this on the video overview. She recognizes that
she can use the video to find out when it is appropriate to disturb Troels, and when not.
Key results: Scene 11 was carried out in parallel with all other scenes with common discussion regarding AMC after
Scene 10. The participants agreed that being able to see the incident site and the injured persons and their
biomedical data gives the AMC physician a valuable basis for coordinating work across hospitals. The experience
points to design opportunities which Erica summarizes thus:
What I need is that I can use [and remote control] the camera myself …. when I get pictures of
individual patients, I need to know how [where] are they [located] in the overview? Then I need some
identification of the patients because when I say ‘oh this was the dark haired guy and this was ...’ [it
can be difficult for others to know which victim I mean]. And then one thing that is very good is that I
can see if the doctor is very busy and then I’ll not call him, [knowing that] he’s not able to talk to me.
Moreover:
•
Information from biomonitors, video, location information, still cameras, and communication channels
should be linked. For example, when selecting an image of an individual patient, the biomonitor data of this
patient should be highlighted. The location of this patient should be available. Communication channels (if
available) to personnel currently dealing with this patient should be visible.
The video overview and the data for individual patients creates a sense of involvement and a desire to help
as well as a demand for more information. This seems difficult to integrate into the frantic work on the
incident site. Moreover, such remote collaboration could complicate the production of situational
awareness. However, it could be a vital component of the response effort, making the AMC doctor a
resource that – because of the distance – can ‘keep cool’.
•
DISCUSSION - SUMMARY OF LESSONS LEARNT
On the following day we split into a researcher and a practitioner group and identified a set of key insights from the
different perspectives, before meeting in plenum. The Future Laboratory produced insights and experiences
otherwise very hard to gain and allowed us to share them across the team. As staff appropriated the prototypes a host
of issues arose concretely, with many pointing to a need for further research:
•
The physical design of the wireless biomonitor should be flatter and use softer material.
•
Without doubt technologies need to support people in making their states and processes palpable, or to put
themselves ‘in the loop’ (Endsley et al 2003). While staff on the scene of an accident may be too busy to
notice and attend to failures of assemblies and opportunities for better kinds of assemblies, staff elsewhere
may be able to address some of these issues. Technologies should facilitate inspection, assembly and repair
remotely. Such practices require a live representation of assemblies. How this should be realized needs
research, as does the collaboration between technical personnel and the professionals on site.
•
Bringing the AMC closer to the incident site supports communication and collaboration, but
o it is difficult to refer to things and patients economically and intelligibly across different spaces.
Use of pictures seems useful, but how should pictures be taken?
o intervention from ‘outsiders’ (e.g. AMC doctor) could seriously complicate the production of
situational awareness.
•
It is difficult to notify people of relevant events in appropriate ways and at appropriate times. Research into
sense-making practices in stressful situations, and how alarms may fit into these is required.
•
It is necessary to explore how wireless biomonitors would be used: How should they be kept before use?
What happens when a biomonitor is taken from the bag (?) by a doctor (?)? When is it turned on? When
does it connect, to which display? How is it connected to person IDs, location information or pictures? (A
separate workshop on this has informed design and will be reported upon in due course).
•
If assemblies are automatically established, the professionals need to know whether connections and
services have been activated, whether they are (still) working, and which elements belong together. In an
assembly of bio-monitors and an ID tag on a patient, how could one be sure that they are in one assembly
79
Page 10
Proceedings ISCRAM2007 (B. Van de Walle, P. Burghardt and C. Nieuwenhuis, eds.)
(and not sending the heartbeat to the display of the patient on the right). One example we explored were
patterns of synchronized blinking (known from marine buoys) (Figure 11)
Figure 11 Bio-monitors blinking in synchronized patterns.
•
We should investigate in-hospital efforts, especially the transition and transfer of responsibility for patients,
and the change from temporary identifications and rudimentary records to more accurate information.
In interaction with the new technologies existing work practices change, and ongoing evaluation is needed
Further research into how the information from the scene can be utilized for situational awareness is needed
(Büscher and Mogensen 2007).
•
•
CONCLUSION
Future Laboratories, as a part of a participatory design process, are an extremely powerful way of bringing reality
and visions of future desirable socio-technical integrations together. By enabling hands-on, as realistic as possible,
experience of such socio-material-technical integration, Future Laboratories provide insight and knowledge that
could not be obtained through discussions or “play” around a table. Most importantly, they give rise to the intuitive,
embodied (i.e. more than discursive and rational) invention and exploration of potentially viable future practices
emerging around future technologies.
ACKNOWLEDGMENTS
We thank our colleagues in the PalCom project and the pre-hospital effort in Aarhus, Susanne Jul and the
anonymous reviewers for ISCRAM for their insightful comments, and the engineers S. Kucharski, L. Kubala and M.
Byczuk, who developed the first version of the biomonitor system.
REFERENCES
1. Büscher, M. (2007) Accounting, Cutting, Abstracting: Ways of making computing palpable. Workshop on
Designing for palpability, Pervasive 2007, May 13-16, Toronto, Canada. Available at http://www.ist-
palcom.org/palpable_pervasive_2007
2. Büscher, M. and Mogensen, P. (2007) Designing for material practices of coordinating emergency teamwork .
Proceedings of the 4th International ISCRAM Conference (B. Van de Walle, P. Burghardt and C. Nieuwenhuis,
eds.)Delft, the Netherlands, May 2007.
3. Endsley, M., Bolté, B., Jones, D.G. (2003). Designing for Situation Awareness: An Approach to User-Centred
Design. London: Taylor and Francis.
4. Garfinkel, H. Studies in Ethnomethodology Cambridge: Polity, 1967.
5. Grønbæk K, Kyng M, Mogensen P. Toward a cooperative experimental system development approach. In: M.
Kyng, L. Mathiassen, editors. Computers and design in context. MIT Press; 1997. p 201-38.
6. Hartswood M., Procter R., Slack R, Voß A., Büscher M., Rouncefield, M. and Rouchy, P. Co-realisation:
Towards a principled synthesis of ethnomethodology and participatory Design. Scandinavian Journal of
Information Systems, Vol. 14, Issue 2, 2002, pp. 9-30.
80
Page 11
Büscher et al. Making the future palpable
7. Kristensen M, Kyng M, Nielsen ET. IT support for healthcare professionals acting in major incidents. SHI2005,
Proceedings, 3rd scandinavian conference on health informatics; August 25-26; Aalborg: Aalborg University;
2005. pp 37-41.
8. Kristensen, M., Kyng, M., Palen, L. “Participatory design in emergency medical service: designing for future
practice,” in Proc.SIGCHI conf. Human Factors in computing systems, Montreal, 2006, pp. 161-170.
9. Kristensen, M; Kyng, M., Proceedings CSCW 2006, W1: Media Space: Reflecting on 20 Years.
10. M. Kyng, E. T. Nielsen, M. Kristensen, “Challenges in Designing Interactive Systems for Emergency Response
Proc. DIS conf. Designing Interactive Systems, Pennsylvania, 2006, pp. 301-310.
11. Kramp, G., Kristensen, M., Pedersen, J.F. “Physical and digital design of the BlueBio biomonitoring system
prototype, to be used in emergency medical response”. Proc 1st Intl. Conf. Pervasive Computing Techn. For
Healthcare, Innsbruck, Austia, Nov. 29-Dec. 1, 2006.
12. The PalCom project. http://www.ist-palcom.org
13. Weiser, M. The computer for the 21st century, Scientific American, 13(2): pp 94-10, 1991.
81
View other sources
Hide other sources
-
Available from Monika Büscher · 17 Oct 2012
-
Available from psu.edu