Probing Technology with Technology Probes *
* © The authors, 2004. This is the Andy Crabtree’s version of the work. It is posted here for your personal use. Not for
redistribution. The definitive version was presented at the Equator Workshop on Record and Replay Technologies, February
12-13, London: EPSRC.
Dan Fitton, Keith Cheverst, Mark Rouncefield,
Alan Dix Lancaster University
Lancaster, UK
LA1 4YR +44 (0)1524 594532
{d.fitton,k.cheverst, a.dix, m.rouncefield}@ lancaster.ac.uk
Andy Crabtree
University of Nottingham Nottingham, UK
NG8 1BB
+44 (0)115 846 6512
[email protected]
1. INTRODUCTION: INVESTIGATING
TEXTING In ‘Smart Mobs’ Howard Rheingold [22] makes dramatic claims
about the social and political impact of texting, drawing particular
attention to the emergence of ‘thumb tribes’ and ‘generation txt’
and the potential impact of texting on practices as diverse as
teenage mating rituals and demonstrations. Like Rheingold we are
equally interested in one of the most surprising phenomena to have
occurred within the field of mobile computing within recent years -
the uptake of SMS (or Short Message Service) text messaging.
According to the Mobile Data Association [18], the total number of
chargeable person-to-person SMS text messages sent across the
main four UK GSM network operators between 31st December
2003 and 1st January 2004, was 111 million, an 8% increase
compared to figures over the same period the previous year
(http://www.text.it/mediacentre), and new uses of SMS messaging
are emerging in conjunction with interactive TV services, for
example. Unlike Rheingold we are rather reluctant to speculate
wildly on what exactly this development might amount to or mean.
There are, of course, various well-known problems involved in
interpreting statistical data [3] [2], along with associated issues
concerning what data is appropriate and how it might be collected
[17]. In this paper we wish to consider some of the technical
difficulties involved in data collection.
Our studies are particularly concerned to understand a use of SMS
texting that has received little investigation to date, largely due to
its novel character. The topic we have in mind is the use of texting
as a means of enabling people to send messages to displays
situated in the fabric of a setting rather than to another mobile
device owned by a particular individual. Such a facility has clear
potential in cooperative work settings where the need to distribute
awareness amongst members [9] means that messaging to a place
may be more appropriate than messaging directly to a particular
individual. The potential utility of ‘situated displays’ is articulated
by O’Hara et al. [20] -
In recent years, more and more information is being
presented on dedicated digital displays situated at
particular locations within our environment. At their most
basic, digital display technologies allow information to be
more easily updated dynamically and remotely. However,
these new kinds of interaction technologies also allow
people to use these situated displays in novel ways both as
for the individual’s purposes and in the support of group
work.
O’Hara et al.[20] draw particular attention to the potential for
texting to and updating situated displays remotely, and it is this
functionality and how we might measure and assess it that forms
the focus of this paper.
2. TEXTING TECHNOLOGIES: HERMES
AND SPAM In this paper we describe two applications. Hermes
([4],[5],[6],[11]), which was deployed in a university, and SPAM
[8], which was deployed in a residential care setting. Both of these
applications enable users to text to and update situated displays
remotely. The Hermes system enables users to interact remotely
with office door displays via their mobile phone using SMS. The
SPAM messaging system evolved from our experiences with
Hermes and also enables users to remotely update situated displays
(using SMS) in order to facilitate coordination and cooperation
with remote work colleagues. In texting to situated displays users
of the Hermes and SPAM systems may make available to others
their location, plans, and activities, and thereby draw upon and
reflect social aspects of everyday life that are essential to
collaboration and coordination. Another way of thinking about the
Hermes and SPAM technology is in terms of ‘affordances’ [1] and
the notion that we can treat technology as affording knowledge and
as having been designed with this possibility in mind. Here our
interest is in how the different features of the assembled systems
are constructed so as to ‘afford knowledge’ to, for example, the
working division of labour through the reflexive articulation of
which the various workaday activities in a setting are coordinated
and performed [24]. Accordingly, texts (to both Hermes and
SPAM) become both the focus of work and a visible record of
work that has been done, put on hold, remains to be done, and so
on. By embedding messages in the fabric of the workplace, by
putting the work on display so that others may be aware of it, these
textual representations make everyday work ‘visible’ so that it can
be ‘taken note of’, ‘reviewed’, ‘queried’ and in other ways be made
accountable by and for others involved in the work.
2.1 Hermes and SPAM: Overview and
Requirements This section provides some technical details of the Hermes and
SPAM systems. The Hermes system supports remote interaction by
allowing messages to be created and read via the web or a mobile
phone. We hoped that by supporting remote interaction and
observing how the new system was used over a significant period
of time we would gain some useful insights into the relative
importance and interaction of ‘place’ ‘space’ and ‘text’ within this
application domain. For example, what kinds of messages would
members of university staff post on their door when texting remotely?
The Hermes system comprises a central server and a number of
wall or door mountable units (referred to as Hermes displays). At
present we have 10 units deployed on one floor of the Computing
Department at Lancaster University. Our intention was for Hermes
displays to have the ease of use and dependability associated with
an information appliance - i.e., to perform a small number of tasks
simply and well. The system provides the owner of the Hermes
display with two key functions:
1) The ability to create a message to appear on the display.
2) The ability to read messages left by visitors.
Typically, the owner will create a message to appear on their
Hermes display by entering some appropriate text using the web
interface (Figure 1.) The web interface can also be used to upload a
graphical image for display, such as an animated GIF.
The overall system architecture of the Hermes system is illustrated
in Figure 2. In this figure, the yellow oval represents the typical
entities associated with a given user. At the heart of the system is a
single central server application written in Java that runs on the
Linux platform and provides the following key functions:
1) Centralized storage for messages and user profile
information.
2) Communication with the SMS Gateway.
3) Hosting of the web portal.
Figure 1. The Hermes Web Interface [5]
The system utilizes both wireless (802.11b) and wired Ethernet
network infrastructures. In order to support the reception of SMS
messages, the central server communicates with a Wavecom DB02
GSM terminal. The web portal is implemented using Java Servlets
and this enables the dynamical generation and publication of html
web pages. The Hermes displays themselves use the CrEme Java
virtual machine, and run the PocketPC operating system.
Figure 2. The System Architecture of Hermes [5]
The SPAM system has been developed to support cooperation
between staff working at two associated sites located in Carlisle, a
small city in the North of England. The requirements for SPAM
were obtained through ethnographic study, informational probes
[7] and design workshops with the staff. The overall response to
the idea of a messaging system was extremely positive. In
particular, such a system was viewed as another, alternative, tool
for communication capable of supporting staff in their everyday
work and interaction with residents. This then became the rationale
for the construction, testing and deployment of the SPAM system.
Figure 3. One of the SPAM Displays
The SPAM system has been designed to run an SMS messaging
application, allowing staff from the hostel office to communicate
easily with staff from the semi-independent living accommodation
office (and vice-versa) by composing messages using an on screen
keyboard displayed on a touch sensitive screen (Figure 3). When
messages are received by a SPAM unit they are displayed on the
screen until deleted by a member of staff. Staff can also use their
own mobile phones in order to send text messages to the SPAM
displays when they are out of the office and to receive messages
originating from a SPAM display.
The overall design of the system architecture is shown in Figure 4.
This highlights the way in which SMS messages sent via mobile
phones and by the SPAM units themselves are handled by the
system.
Figure 4. Architecture of the SPAM system
The typical use scenario is illustrated by SMS Message 1 - i.e., the
message originating from a mobile phone is successfully delivered
to the permanently staffed hostel (Location B) and the transmission
of a ‘message read’ acknowledgement is triggered by a member of
staff reading the message. Message forwarding is performed by the
system if a message is sent to the semi-independent living
accommodation (Location A) at a time when no member of staff is
providing cover (denoted by AWAY STATE). In this case, the
message (Message 2) is automatically forwarded to the display of
the hostel with 24-hour cover. The two SPAM displays were
deployed in the two offices in October 2002. Since that time the
units have been used on a daily basis.
3. TECHNOLOGY PROBES: GETTING
DATA FROM HERMES AND SPAM In a number of papers ([7],[8]) we have outlined a range of factors
that conspire to render our usual ethnographic data collection
techniques inappropriate and how we have sought to supplement
our understanding of the care setting ‘from within’ by adapting
Cultural Probes. Cultural Probes [13] have achieved some
prominence in interactive systems design, where they have been
employed to inspire design as computing moves out of the
workplace and into everyday life more generally. In contrast, we
have elected to adapt Cultural Probes through the incorporation of
social science research methods to gather data about participants’
daily lives. Our Informational Probes have been employed to
sensitise parties involved in design to the local cultures within
which new technology will be embedded and to elaborate the needs
of users. As SPAM and Hermes have been put to use in their
respective settings we have found that the technology also acts as a
probe – i.e., as a means of gathering data. The text logs generated
through the technology’s employment provide us with a
complementary source of information, which may be used to
measure and assess the functional value of our systems from the
point of view of day-to-day use.
3.1 Technology Probes The notion of Technology Probes has recently been employed in
the Interliving Project [15]. In this context Technology Probes are
adaptations of Cultural Probes that seek to embed inspiration
within the design process, in contrast to providing inspiration for
design. Hutchinson et al’s Technology Probes situate existing
technologies in real homes rather than ‘lab houses’ in order to
inspire design by exposing inhabitants to new experiences. While
there is merit and value to this approach, this is not what we mean
when we invoke the notion of a Technology Probe. Our take on
Technology Probes is different and perhaps simpler, involving the
embedding of a logging system into the technology itself.
3.2 Logging Hermes and SPAM Usage Both Hermes and SPAM perform their logging functions by
appending messages to a text file, though the source of these
messages differs between the two systems due to their design and
implementation.
In Hermes we log many aspects of the system ranging from user
interfaces actions to messages sent to the system via SMS. Due to
the multitude of devices generating messages to log, we provide a
central logging agent accessible over a network.
The SPAM application runs on a stand-alone miniature PC and all
messages to log are generated by the SPAM main application. The
GSM terminal is interfaced though a Java class sending and
parsing AT commands (a separate piece of 3rd
party software is
used in Hermes), so much more debugging information about
communication with the GSM terminal is available. This enables
all information sent to and from the GSM terminal to be logged.
In the Hermes project the emphasis has been on logging the user
interactions which occur, as we provide many different
mechanisms for interactions. While with SPAM there are fewer
mechanisms for interactions, consequently we concentrate on
logging the messages sent and received.
3.3 Examples of Raw Log Data Figure 8a shows a sample of the log file entries generated by the
SPAM system for a message sent to Location A from Location B,
figure 8b shows a sample of the log entries generated at Location A
when this message arrives. This is a mixture of debug output from
communication with the GSM terminal, and ‘higher-level’
messages indicating that a message has been sent, received etc.
Figure 9 shows a sample from the Hermes log. This logs stores
user interface actions from the Hermes doorplate appliances, along
with information about the appliance from which the message
originated and a timestamp. The log also explicitly stores messages
about other actions which occur such as messages sent and users
logging in/out.
Figure 8a: Log of message sent from Loc. B to Loc. A
Figure 8b: Log showing message received at Loc. A
Figure 9 – A sample from the Hermes log
3.4 Working with Logs: Technical Issues One of the initial technical issues encountered was that of what
information to log, as it is difficult to predict which information
may be useful in the future. It is sometimes obvious from the outset
which information will give the best clues about use (etc), though it
may not be apparent until thorough analysis of the logs what
additional information it would have been useful to collect. When
collecting information there are usually limits on the amount that
can be collected, so a balance is necessary between what is
essential and what is possible to store. For example, for the Hermes
doorplate appliances most user interface actions are logged, but the
pen movements (i.e. a user drawing a note) are not, as this would
require large amounts of network bandwidth between the appliance
and the logging agent, and place a high processing load on both
devices. The doorplate appliance would definitely not be able to
cope with the additional load and the ‘leaving a note’ process
would be so un-responsive it would be unusable. However, in
general our policy is a prudent one, i.e. to collect more information
than may at first appear necessary.
The safe storage of the logs is another important technical issue
which needs to be addressed. Initially all the logs were stored on
single computers, but (typically!) we experienced hard disk failure
with both the Hermes and SPAM systems. Our initial solution had
been to make backups of the logs as regularity as possible and
replicate these across many machines. The opportunity to backup
logs also provides a good point to start a new log file, we do this as
our logs file tend to reach several hundred megabytes in size which
can introduce problems for analysis. As the Hermes system is
located inside the computing department we are in the process of
altering the logging system to store an additional copy of the log
file on a departmental fileserver, which is regularly backed up.
However this approach cannot be used for the SPAM system, as
the two end units are located geographically far from the university
(approximately 90 miles) and currently have no (reasonable
bandwidth) connectivity with the university. Obviously this factor
means that collection of the logs is difficult. The SPAM units are
also very compact machines, making it very difficult to add
additional redundant storage, e.g. extra hard drives etc.
Reliability of the logging functions can also be a problematic issue.
This is especially true of Hermes where the logging is done by a
separate agent. If the Logging Agent stops functioning or crashes
there is currently no easy way to detect that this has occurred. This
is a scenario we have already encountered and are working on
implementing a ‘watcher’ to monitor the Logging Agent.
Furthermore, we do not have an active feedback mechanism to
monitor free disk space available for the logs or any other problems
which may occur while attempting to write to a file. The
aforementioned problems must be solved to increase the
dependability of the logging function. Furthermore, clearly when
either system is not running then no information will be logged.
Both Hermes and SPAM systems have suffered unscheduled
‘downtime’.
3.5 Experiences Analysing Log data To date, we have done a preliminary analysis of 300 messages set
by the owners of Hermes displays over a continuous period of
approximately five months. The goal of this analysis was to obtain
a rough approximation of the proportion of messages which shared
personal context in some way, and the breakdown of these
messages in terms of their containing location, activity or temporal
information. For example, through analysis we found that 250 (83
%) contained some aspect of sharing context [5], the breakdown of
these messages is shown in figure 10.
8
location6
29
1812
5 5
activity
temporal
Figure 10: Analysis of Hermes messages according to the
categories of shared context [5]
In order to obtain this statistical breakdown from the Hermes logs
several phases of parsing and analysis were required. It was first
necessary to extract all the parts of the log concerned with users
setting messages on their doorplates (this was achieved using the
standard Unix ‘grep’ command). A program was then written to
parse the remaining parts of the log, separating the entries and
formatting the text. The fourth phase was then to perform a search
to replace the user identifiers used by the system with users full
names. The fifth phase was to go through each entry by hand
looking at the message and categorising (using tags) its context. A
sample from the log including tags is shown in figure 11. The final
phase was to write a program to analyse the context each message
was tagged with and produce the statistics, which could then be
used to generate figure 10.
Figure 11: Part of the Hermes Message Log including Context
Tags [5]
Clearly the analysis of logs such as those produced by Hermes can
be a difficult and time consuming process. Performing the analysis
in phases is useful as the information generated at each phase can
be used for different types of analysis and to look at different
factors.
The manual tagging of entries was an unfortunate but necessary
step which required a large degree of human judgement. In more
detail, some messages required careful consideration to decide
what types of context they actually shared. For example, the
message: 'At CSCW'02 back Monday 25th Nov' has been
categorized as containing activity + location + temporal but it
could be argued that the message only contains temporal and
location attributes.
When we attempted to analyse the SPAM logs to look at the
dialogue taking place we found this to be an unexpected challenge.
After attempting various means to parse the logs in different ways,
programs were written to extract messages sent and received from
the SPAM logs and place them in separate text files, separating and
formatting the entries. An example of the results from this process
for Location A’s log file can be seen in figures 12a and 12b, this
sample includes the messages which can be seen in figures 8a and
8b. It is interesting to note that we only have to look at the log file
at one of the locations (in this case Location A) to see all the
messages sent between the two.
Figure 12a: Messages Received at Location A
Figure 12b Messages Sent by Location A
Initially it was very hard to follow the chronological order of
dialogues using two separate files for messages sent and received,
so the analysis program was modified to output to a single file.
Unfortunately we found that only the time and date of messages
received had been logged, not the time and date that messages were
sent. The SPAM system does provide an acknowledgement reply
SMS message when a message has been read, this means that
usually the next entry in the log gives a good approximation of
when the previous message has been sent. This is obviously not
ideal, and makes analysis of the logs more difficult, as the
acknowledgement messages entries in the logs tend to make it
harder to see the actual messages being sent and received (and
should ideally be filtered out). Our solution to this problems has
again been to modify the analysis program to make the
acknowledgement entries much smaller (so they only take up a
single line), and to highlight by hand the messages sent and
received using different coloured marker pens. Additionally we
performed a search and replace to add names to known mobile
phone numbers. The final result can be seem in figure 13 where
messages received are highlighted in green and messages sent in
yellow, this makes it much easier to see dialogue taking place than
in figures 12a and 12b.
Figure 13: Manually amalgamated (and annotated) log file
showing dialogue between SPAM units at Loc. A (Durran Hill)
and Loc. B (Botcherby)
3.6 Future Work We hope to further analyse the SPAM logs, using a similar
approach as with Hermes, to tag and analyse messages sent (e.g.
one category might be a request to switch communication
mediums) and dialogues taking place. This will help us to explore
how the SPAM systems is actually being used; and how this use
has changed over time and whether or not the types of usage follow
regular patterns.
It is crucial that we strive for an overall improvement in the
dependability and flexibility of our logging systems. To this end,
we plan to investigate the approaches adopted by other systems
(e.g. safety critical control systems) for managing the production of
log files, and this should reveal some useful insights into how we
might improve the reliability of our logging processes, e.g. through
the use of monitoring and notification mechanisms.
3.7 Human Troubles Involved in Getting the
Data One of the key issues with both texting systems, and particularly
the ability to collect any worthwhile data from them, is the need for
users to have a strong trust in the reliability of the system - i.e., a
strong belief that any SMS text message that they send to a situated
display will (indeed) appear on the situated display and remain
there for an appropriate period of time. In the absence of such
dependability any interpretation of the data from the technology
probes is, at best, problematic. In the case of Hermes this means
messages staying there until removed or replaced by another
message while in the case of SPAM it means staying visible until
deleted by a member of staff. Of course, in order to encourage
users to trust the system, they need to see the system functioning
correctly over a protracted period of time - i.e., months rather than
minutes. We have found achieving this kind of dependability
difficult, especially for the Hermes system. The ideal situation
would be to develop a system in which all components work
faultlessly or at least have an extremely long mean-time to failure
(MTF). However, such a situation is indeed ideal. For example,
SMS messages are not always delivered in a timely way by a given
GSM service provider (especially where a message requires
routing between different service providers). It has been interesting
to observe how some users have developed coping strategies to
deal with early reliability problems. For example, on one occasion,
a user’s Hermes display did not update properly so that for a week
while he was away his door displayed “I am in! Alan”. Now he
always includes with such messages an explicit date, e.g. “Alan in
all day today, Thurs 13th”. In this case because Alan possesses a
good ‘mental model’ of the Hermes system he was able to adapt
his behaviour through a subtle change in message composition to
overcome the potential problem caused by a Hermes update failure
[4]. Providing users with appropriate feedback is of paramount
importance when supporting such interaction and is one means for
tackling the complex dependability requirements inherent in
systems such as Hermes and SPAM - the quantum leap in difficulty
of building and deploying systems that need to be operational on a
constant basis. Crucially, we believe that it is important to deploy
such systems in the long term. This is necessary in order for users
to have sufficient time to domesticate the technology by adapting it
to particular features of the domain and/or to develop new forms of
use (‘innofusion’ in [12]).
4. UNDERSTANDING USER EXPERIENCE
WITH HERMES AND SPAM This section presents some reflections on the data we have
obtained from the ‘technology probes’ in the Hermes and SPAM
systems. Despite the difficulties of extracting coherent data from
the probes we believe that some interesting and important material
has been produced. Our emphasis has been on studying technology
in use, reflecting a longstanding tradition if not research orthodoxy
in the field of Computer Supported Cooperative Work
([14],[21],[10]). Our interest is in understanding the data on texting
as ‘everyday occurrences’, as constituent features of ordinary
workaday activities. The point of this is, as the late Harvey Sacks
might say, is to examine the data to see what details it provides of
how the technology is ‘made at home’ in the settings it inhabits and
how it comes to fit into and resonate with a domain of practical
action ‘that has whatever organization it already has’ [23]. Our
concern, then, is with how this technology finds a place within the
day-to-day work of a setting and is responsive to the ‘working
sensibility’ of those under study. This interest and the kind of data
collection it requires is, perhaps, remote from the kinds of general
reflections that someone in an occupation (e.g., a university
lecturer or care worker) can produce, and much more attuned to
their consciousness and attention when they are actually engaged
in their work. In particular we are interested in the use of texting in
the exercise and development of users working sensibility and
especially how and in what circumstances they react to or decide to
initiate text messaging. The development, deployment and
evaluation of the Hermes and SPAM systems have revealed a
number of interesting issues in this regard.
Having installed the text messaging equipment, ensured it
functioned adequately, and demonstrated it to users, the systems
have now been in constant use for over a year. Without necessarily
subscribing to the fetishization of quantitative data, our analysis to
date has been hampered by an inability to easily compile statistical
data on usage and so our analysis has largely been based on a time-
consuming manual examination of the logs. Manual examination of
the logs suggests that current usage seems focused on:
Awareness (e.g., “Has fax, email got through? Has X left yet?”).
Coordination between sites (e.g., “I keep ringing and nobody
answers? Can you ring me please”; “Pizza & and chips ready
come on in !”).
Coordination between staff (e.g., “Please ring car wont start”;
“Alison can you ask terri to ring me when she comes in about the
swop”).
Tracking schedules (e.g., “What shift is steve doing tomorrow and
where”; “Alison on visits and has mobile. Brian out with hh and
has own mobile”
Queries (e.g., “Which keys should we hand over?”; “Can I possibly
get a lift into town”).
The SPAM logs reveal a growing familiarity with SMS or
‘textspeak’ (e.g., “What does 18tr mean?” - “Later in SMS speak,
get with it babe”) and its use to tell jokes (e.g., “how do u turn a
duck in2 a soul singer: put it in the microwave until its bill
withers”) suggests the technology is slowly but surely becoming
organizationally embedded in the day-to-day work of the
residential care setting, as the following extracts also indicate:
“SORRY IM GOING 2B LATE DARRIN”
“Blocked in snow will be late”
“Snow problem please ring Barbara”
“Penny am with mr gate closed bvt not locked”
“Hold up with s m money will be delayed back a s a p Barbara”
The organizational character of texting has also become evident in
the use of Hermes, as the following extracts make perspicuous:
“Am running 20 mins late”
“On bus - in shortly”
“Gone to the gym”
“Johm - in ww burger joint.”
“Maomao going to be late – will catch up later. A.”
“ In big q at post office … Will be a bit late”
As these examples illustrate, the organizational character of texting
consists of an explicit sharing of context in order to support (or
potentially support) collaboration with others.
Like Nardi et al. [19] and Isaacs et al. [16], when examining the
sharing of context we are interested in the communicative functions
of texting - of the use of texting for quick questions and
clarifications, for example (e.g., “Do you know if Helen has any
medicine”; “ Wot time is Paul calling to c hh”). Similarly, there is
evidence in the logs that texting is useful for various kinds of
coordination. Texting is particularly useful to coordination when
immediate responses are required (e.g., “D ... XXX has to have
blood test at cc at 10 30 i will take him can you tell him to be ready
- let me know if you have got message” - “Got message have
cancelled his taxi”). However, the use of text also extends to
coordinating the use of technology when, for example, a
conversation is complicated and/or involves too much typing (e.g.,
“Please phone house when you are able”). In other instances
texting is relied upon when other technologies (phone, fax, email,
etc.) are in use or are being kept clear in the anticipation of urgent
use and to alert others on occasions where technical failures occur
(e.g., “Put the phone on to answerphone”; “Please switch the
mobile phone on”; “u r blocking the phone line after someone
telephoned here it sounded like mike. Please sort out as we can not
use the mobile if needed”).
What becomes obvious in reading the text logs is the flexibility of
text messaging in terms of supporting the everyday work of the
hostel and the university department. The expressive’ character of
texting is also noteworthy. Even without the addition of emoticons,
our users routinely employ texting for affective communication
about work, work crises, jokes and general social banter.
“I can hear a kind of jingley sound and there are animals on the
roof what does this mean?” “It means that Santa is passing over
the house and making his way down to see me”
“Help please its all too much on my first day back”
“Hello ian i was wondering if everything was alright?”
“A man went to the doctors with a lettuce up his bum and the
doctor said its just the tip of the iceberg im afraid”
The affective character of texting has been observed by other
researchers in other settings [25]. As Nardi et al. [19] put it,
It is interesting that a lightweight technology consisting of
no more than typing text into a window succeeds in
providing enough context to make a variety of social
exchanges vivid, pleasurable, capable of conveying humour and emotional nuance.
Of particular interest to us is what Nardi et al. characterise as
‘outeraction’, where text messaging does more than support rapid
informal communication but also facilitates practices that make
communication possible. Such practices include negotiating the
availability of others for conversation (e.g. “Please phone the house
when you are able”). Such negotiation requires some sensitivity
towards the work and pace of work of others and involves
recognizing appropriate and inappropriate times to contact others,
appropriate modes of interruption, and so on. Texting allows
people to address the kind of issues on which communication turns
in that it is less obviously ‘in your face’ than some other forms of
communication. It permits delayed response or easy
acknowledgement (pressing the acknowledgement button), for
example, and at the same time facilitates multi-tasking, allowing
workers to monitor texts whilst engaged in other jobs. The logs
suggest that texting in the hostel allows workers to negotiate their
availability and maintain their connection with the rest of the staff.
Knowing who is around, what people are doing at weekends or
during sleepovers at the main hostel, for example, enables workers
to establish and project a range of possible interactions, much as
the door displays at the university allow people to project
appropriate course of action in response to messages left by staff.
Texting, in other words, enables users to plan joint activities as
much as it enables their coordination.
5. CONCLUDING REMARKS In this paper we have commented on some of the technical
difficulties we have faced in our deployment and use of
'technology probes' as an attempt to log activity and use of two
SMS applications.
From a technical perspective we have certainly found that
managing and maintaining the logging functions of both the
Hermes and SPAM systems has raised some unexpected
challenges. We have certainly learnt that appropriate support for
logging needs to be considered at design time given the potential
implications that appropriate support for logging can have on
system design. For example, with both the Hermes and SPAM
systems the adopted network infrastructure limits the flexibility
with which logs can be maintained.
We believe that the experiences we have had with the logging
aspects associated with Hermes and SPAM would generalise
significantly with that of other systems in the loosely defined
ubicomp domain. In more detail, we believe that logging tools need
to be developed to support remote monitoring and/or capturing of
logs from different (but related) sources that are potentially
producing data 24/7. Clearly, we need to look to the solutions that
have been found in domains such as safely critical control systems
to provide us with insights, e.g. the need to develop special
‘watcher’ processes to monitor the correct functioning of the
logging function by detecting and warn of potential problems, e.g.
approaching storage limits.
One requirement that is perhaps more peculiar to ubicomp systems
(given the potential range and number of sources of logging
information) is the need to consider the design of appropriate tools
to support the amalgamation of separate logs and the need to
support human augmentation (e.g. categorising data in the logs) of
these logs, we have found this latter requirement to be a key
requirement for analysing usage patterns from both Hermes and
SPAM. Supporting an automated categorisation process certainly
poses an interesting AI challenge.
For the social scientists on the project the logs provided a valued
and worthwhile resource that supplemented existing social research
techniques. The value of the logs resides in providing a record of
and thereby facilitating our understanding social action and the
members' standpoint in real time. The logs produced by the
technology probes sustain the distinctiveness of our
ethnomethodological approach to understanding social action and
its insistence upon a conception of social action in real time. Of
course, this may seem, and probably is, no more than common
sense to those who are not sociologists. Because we are interested
in understanding exactly how people carry out their activities the
concern to consider their action in ‘real time’ is similarly obvious.
Our point is that sociological analyses often benefit from hindsight,
they often know how things turned out and therefore whether
something was (ultimately) a mistake, foolish wise, hopeless and
so on. But people cannot know how their activities will turn out -
whatever their intentions and best efforts accidents and mistakes
sometimes occur - and these happen in real time. Consequently
getting a better understanding of the actor’s point of view - which
is the essence of this approach to usability - requires the
examination of the organisation of social action over its course -
an activity promoted by the logs. This is a basic feature of our
ethnomethodological investigations, regarding the social actor as a
practical doer, needing to get things done. The logs tap into the
fact that everyday activities possess an essentially temporal
character; for lacking the benefit of hindsight the actor’s point of
view is always located as some here and now within any particular
course of action. Even the idea that something is part of a course of
action is integral to the production of the course of action itself.
That is, determinations the actor makes as part of the means of
carrying out the action as to ‘where I am now’?, ‘how much have I
done?’, ‘is this course of action working out as I anticipated or do
I need to adjust the prepared course’, ‘how much more is there left
to do’, ‘how can I get from doing what I am doing now to doing
what I need to do next?’, ‘what do I need to do next, exactly’, etc.
To the extent to which the logs reflect and document these kinds of
processes we have found them invaluable. This is not to suggest
that either getting or analysing the data is easy, for the data is
indexical to the activities that generated it. Knowledge of those
activities - obtained through our other researches - is brought to
bear on analysis of the data and to make sense of it – to make it
meaningful. In other words, the data depends for its adequacy on
knowledge of the activities in which the technology is embedded
and used. That knowledge is used to interpret the data but is not
contained within the data [3]. Consequently where the
measurement and assessment of the functional value of
collaborative systems is concerned there remains a need to exercise
caution and leave certain tasks to human skill and judgement.
6. ACKNOWLEDGEMENTS This work described in this chapter has been conducted under the
auspices of the CASCO project (grant number GR/R54200/01), the
Equator IRC (www.equator.ac.uk) and Dependability IRC
(www.dirc.org.uk) funded by the UK Engineering and Physical
Sciences Research Council. We would also like to acknowledge
the members of Lancaster University’s Computing Department and
the Croftlands Trust for their continued tolerance and support.
7. REFERENCES 1. Anderson, R.J., and Sharrock W.W Can organizations afford
knowledge Computer Supported Cooperative Work: The
Journal of Collaborative Computing, vol. 1 (3), 1993, 143-161.
2. Benson, D. and Hughes, J.A “Method: evidence and
inference”, Ethnomethodology and the Human Sciences (ed.
Button, G.), Cambridge: Cambridge University Press, 1991, 109-136.
3. Cicourel, A.V. Method and Measurement in Sociology, New York: Free Press, 1964.
4. Cheverst, K., Dix, A., Fitton, D., Friday, A. and Rouncefield,
M. “Exploring the utility of remote messaging and situated
office door displays”, Proceedings of the 5th
International
Symposium on Human Computer Interaction with Mobile Devices and Services, Udine, Italy: Springer, 2003, 336-341.
5. Cheverst, K., Dix, A., Fitton, D. and Rouncefield, M. “‘Out to
lunch’: exploring the sharing of personal context through
office door displays”, Proceedings of OzCHI 2003, Brisbane Australia: Ergonomics Society of Australia, 2003, 74-83.
6. Cheverst, K., D. Fitton, and A. Dix. Exploring the evolution
of office door displays, Public and Situated Displays: Social
and Interactional Aspects of Shared Display Technologies.
(eds. O’Hara, K., Perry, M., Churchill, E. and Russell, D.), Dordrecht: Kluwer Academic Publishers, 2003, 141-169.
7. Cheverst, K., Clarke, K., Dewsbury, G., Hughes, J.,
Rouncefield, M., Crabtree, A., Hemmings, T. and Rodden, T.
“Designing with care: adapting cultural probes to inform
design in sensitive settings”, Proceedings of OZCHI 2003,
Brisbane, Australia: Ergonomics Society of Australia, 2003, 4-13.
8. Cheverst, K., Clarke, K., Fitton, D., Rouncefield, M.,
Crabtree, A. and Hemmings, T. “SPAM on the menu: the
practical use of remote messaging in community care”,
Proceedings of the 2003 ACM Conference on Universal Usability, Vancouver, Canada: ACM Press, 2003, 23-29.
9. COMIC Deliverable 2.1 Informing CSCW Requirements,
Lancaster University: Sociology & Computing Departments. ftp.comp.lancs.ac.uk/pub/comic/, 1994.
10. Crabtree, A. Designing Collaborative Systems: A Practical Guide to Ethnography, London: Springer, 2003.
11. Fitton, D., Cheverst K., Experiences Managing and
Maintaining a Collection of Interactive Office Door Displays,
in proc. of 1st European Symposium on Ambient Intelligence
(EUSAI’03) (Eindhoven, Netherlands, November 2003)
Lecture Notes in Computer Science, Springer-Verlag, 2003,
394-410.
12. Fleck, J. Innofusion or diffusation? The Nature of
Technological Development in Robotics, Edinburgh PICT
Working Paper No 4, www.rcss.ed.ac.uk/ publications/, 1988.
13. Gaver, W.H., Dunne, A. and Pacenti, E. Design: cultural probes, Interactions, vol. 6 (1), 1999, 21-29.
14. Hughes, J.A., King, V., Rodden, T. and Andersen, H. Moving
out of the control room: ethnography in systems design,
Proceedings of the 1994 ACM Conference on Computer
Supported Cooperative Work, Chapel Hill, North Carolina: ACM Press, 1994, 429-438.
15. Hutchinson, H., Mackay, W., Westerlund, B., Bederson, B.B,
Druin, A., Plaisant, C., Beaudouin-Lafon, M., Conversy, S.,
Evans, H., Hansen, H., Roussel, N. and Eiderbäck, B.
Technology probes: inspiring design for and with families,
Proceedings of the 2003 CHI Conference on Human Factors in Computing Systems, Florida: ACM Press, 2003, 17-24.
16. Isaacs, E., Walendowski, A., Whittaker, S., Schiano, D. and
Kamm, C. The character, functions, and styles of instant
messaging in the workplace, Proceedings of the 2002 ACM
Conference on Computer Supported Cooperative Work, New Orleans: ACM Press, 2002, 11-20.
17. Lazarsfeld, P.F. and Rosenburg, M. The Language of Social Research, New York: Free Press, 1955
18. Mobile Data Association, www.mda-mobiledata.org/resource/hottopics/sms.asp, 2004
19. Nardi, B., Whittaker, S. and Bradner, E. Interaction and
outeraction: instant messaging in action, Proceedings of the
2000 ACM Conference on Computer Supported Cooperative Work, Philadelphia: ACM Press, 2000, 79-88.
20. O’Hara, K. E. Churchill, M. Perry, D. Russell, N. A. Streitz,
Public, Community and Situated Displays: Design, Use and
Interaction around Shared Information Displays,
www.appliancestudio.com/cscw/cscwdisplayworkshopcall.htm, 2002.
21. Randall, D., Rouncefield, M. and Hughes, J.A. Chalk and
cheese: BPR and ethnomethodologically informed
ethnography in CSCW, Proceedings of the 4th
European
Conference on Computer Supported Cooperative Work,
Stockholm, Sweden: Kluwer Academic Publishers, 1995, 325-340.
22. Rheingold, H. Smart Mobs: the next social revolution. Perseus Publishing, Cambridge MA, 2002.
23. Sacks, H. A single instance of a phone-call opening, Lectures
on Conversation (ed. Jefferson, G.), vol. II, Oxford: Blackwell, 1992, 542-553.
24. Schmidt, K. and Bannon, L. Taking CSCW seriously:
supporting articulation work, Computer Supported
Cooperative Work: The Journal of Collaborative Computing, vol. 1 (1), 1992, 7-40.
25. Taylor, S. and Harper, R. “Age-old practices in the ‘new
world’: a study of gift-giving between teenage mobile phone
users, Proceedings of the 2002 CHI Conference on Human
Factors in Computing Systems, Minneapolis: ACM Press, 2002, 439-446.
