MOBILE SOCIAL SOFTWARE

The design, implementation and usage of a system for mobile group communication,
coordination and sharing.

Clint Heyer
B.InfEnv Hons. I
 A thesis submitted for the degree of Doctor of Philosophy at
The University of Queensland in May , by Clint Heyer,
School of Information Technology and Electrical Engineering.

Academic advisors:
Dr. Margot Brereton and Dr. Stephen Viller.
Candidate’s Statement of Originality

The research, implementation and account thereof presented in this thesis are, to the best of
my knowledge original work except as acknowledged in the text. The material has not been
submitted, either in whole or in part, for a degree at this or any other university.

Copyright © Clint Heyer, .

The University of Queensland

Brisbane, QLD 
Australia

i
ii
Acknowledgements

As is so often the case with theses, this work could not have been done without the support of a
number of people. With this work in particular, the support of my friends was instrumental.
They not only helped get me through these four years with my sanity (mostly) intact, but they
also generously gave of themselves as research subjects, to be poked and prodded. In no
particular order, I would like to especially thank Gally, Rod, James, Jared and Keiran for their
inspiration, effort and friendship. I also gratefully acknowledge the help and friendship of Yann,
Chopsy, Erin, Beau, LG, Storm, Dave, Elin and Jemma, and everyone else who participated in
the Rhub study.
On a more personal level, I am indebted to Fi for her inspiration, provocation, care, packed
lunches and working beachside holidays. I could not have completed the writing without
Marine and her limitless patience, understanding, warmth and tenderness. Merci d'avoir été à
mes côtés et de m'avoir épaulé pendant cette année.
I was the kite, and my advisor, Margot, was the holding the end of the string. Sometimes she
pulled it in a direction, sometimes she tied it to a tree. In either case, her movements, guidance
and feedback was subtle, wise, insightful and generous. She provided an environment where I
could do what I did, and I am thankful for that. Thanks also to Stephen who helped my work
along, and kept employing me, irrespective of pesky TEVALs. I am appreciative for my PIG
colleagues Jared, Brett, Tim, McGarry, Matthews, and Jeff, who blazed a path of scholarly
excellence and empty beer jugs. Jared’s insanity and Brett’s relentless, dry, cutting wit kept me
amused daily, while Matthews offhandedly sent me tumbling into the dank abyss of symbolic
interactionism. McGarry generously provided campfire stories and chapter reviews, and Tim
improved my appreciation of beer and Bluetooth profile support.
Most important of all is my family: mum, dad and Simone, the Jeffries, as well as the rest of
the wider clan. Their faith, support and love is enduring, unquestioning and without a doubt
how I got to this point in life.
I would also like to acknowledge the financial support of the Australian Postgraduate Award
(APA) programme, the Australasian CRC for Interaction Design (ACID) as well as Margot’s
generous sharing of her research budget.

Clint Heyer
Oslo, ..

iii
iv
Abstract

Informal social groups utilise everyday, mundane technologies to communicate, coordinate and
share. Often, these technologies, such as text messaging, have not expressly been designed for
such use, but have rather been appropriated for this purpose and used because they are widely
available and relatively simple. There is not a good understanding of how to better support
groups’ socialising activity with technology, or even how to go about designing a solution in the
first place. This thesis addresses this problem through four contributions.
Firstly, I propose a new design framework, Reflective Agile Iterative Design (RAID), which
combines elements of action research and agile development to evolve a design in a thoughtful,
responsive manner. RAID is particularly suited to the development of social systems that
demand an exploratory, reflective approach to understanding and shaping their evolution.
Secondly, I describe a novel exploratory prototype, Rhub, which aims to support group
communication, coordination and sharing. The prototype was developed over time using RAID
and was deployed for over . years with over  participants. Because of this ‘real world’
deployment, it was exposed to a variety of uses, personalities, behaviours and situations which
would not happen for a short study, or a study run within narrow parameters. The prototype
presents a method for cross-channel interaction that supports pervasive group messaging, and
a flexible presence awareness system.
Thirdly, I present the analysis of qualitative and quantitative results from the usage of the
prototype, and a number of other studies. These results show that participants favoured using
the messaging feature for coordination rather than chat, particularly a “half-invite” style of ad-
hoc, last-minute coordination which is afforded by Rhub. I also describe how the prototype was
appropriated by the group through the awareness and negotiation of use, development of
norms and new emergent behaviours. Such data is missing from the literature, as research
prototypes are typically deployed for only a short period of time or with a limited number of
participants.
Finally, a discussion on the design of social systems, grounded in the experience of
developing and deploying Rhub, provides a number of design considerations for other
practitioners and suggestions for features to support informal group socialising. I argue that
utility within design is underrated, and should be given more prominence as a design goal. I
also suggest that the design should always reward people for participation, and that as much
value as possible should be extracted from a user’s interaction with the system. Anti-social user
behaviour can never be entirely prevented in a social system, or it would cease to be a social
system, so I suggest the designer empowers users to protect themselves where possible.
Through the exploration of the research problem, and the resulting four contributions, this
thesis provides a better understanding of not only mobile social computing, but also describes
empirical results and introduces new methods for design.

v
vi
Table of Contents

 Introduction 
. Research Aims 
. Background 
. Thesis Outline 
 Mobile Social Computing 
. Mobile Phones & Text Messaging 
. Context in Computer Science 
. Mobile Social Software 
. Technology Adoption & Use 
. Conclusion 
 Design Methods 
. Plan-Driven Strategies 
. Interlude: Dealing with Uncertainty in Design 
. Goal-Driven Strategies 
. User-Centred & Participatory Design 
. Conclusion 
 Research Methodology 
. Background 
. The Mobile Context 
. Rhub: an Exploratory Prototype 
. Conclusion 
 Rhub 
. Introduction 
. Website 
. Console 
. Messaging 
. Presence 
. Profile, Settings & Contacts 
. User-Generated Content 
. Implementation 
. Conclusion 
 Reflective Agile Iterative Design 
. Method 

vii
 . Results 
. Discussion 
. Conclusion 
 Studies & Results 
. Introduction 
. Prototype 
. Reflective Journal 
. Interviews 
. Quiz 
. Workshop 
. Conclusion 
 Discussion 
. MoSoSo in Action 
. Messaging 
. Coordination 
. Presence: Location & Status 
. Cross-Channel Usability: The Console 
. Design Considerations 
. Conclusion 
 Conclusions 
 Appendices 
 References 

viii
List of Figures

. Mobile and fixed line penetration. 

. Action Research cycle, with one iteration outlined. 
. Page sections. 
. Header section. 
. Drop-down menus for contacts, groups, locations and ‘me!’ 
. Breadcrumb navigation trail allows for backwards traversal 
. Console and search dialogs. 
. Footer links that appear after content. 
. Action buttons available when viewing a person. 
. The index page’s sidebar. 
. Links to help topics integrated into pages. 
. Schematic view of console access. 
. Message inbox and conversation view. 
. Composing a new message. 
. New group message interface. 
. Discussions interface displaying threads and the reply panel. 
. Discussions interface displaying messages in a thread. 
. Message delivery is governed by six major factors. 
. Message forwarding and notification user preferences. 
. Presence overview seen on index page. 
. 'Presence gem'. 
. Presence as displayed on the presence page. 
. People depicted on the map interface. 
. Levels of privacy access. 
. Relations used to determine access to presence information. 
. Console system invitation process, in this case, using text messaging. 
. Web interface for a system invite. 
. Browsing objects by a particular tag, or tag cloud. 
. Location page. 
. Browsing locations by locality. 
. Locality hierarchy can be traversed to zoom in or out. 
. Map interface. 

ix
. Dynamic presence setting interface. 
. Schematic view. 
. RAID process. 
. Rapid Evolutionary Development. 
. Feedback solicitation. 
. Source code repository activity over time. 
. Invitation graph as of October . 
. Number of registered users over time. 
. Logins/day frequency. 
. Usage of IM, SMS and Web by hour of the day. 
. Frequency of different of lurking factors. 
. Lurking frequencies plotted. 
. Average weekly messaging activity. 
. Group size and average messaging. 
. Percentage of active users who sent a message, per week. 
. Messaging by day of the week. 
. Messaging by hour of the day. 
. Message content across sources. 
. Initiating and reply message sources. 
. How group instant messages were delivered. 
. Setting of status and location over time. 
. Temporal co-occurrence of status and location setting. 
. Presence usage by hour of the day. 
. Response rate for each quiz. 
. Response times. 
. Scale for three variables with three study types. 
. Participants during Operation Nag. 
. Two graphic answers to 'draw Rhub'. 
. Two depictions of how Rhub's messaging works. 
. Participant annotating messages. 
. Participant preparing a poster. 
. Location poster. 
. 'Me' poster. 5
. Percentage of messages by goal, compared with Swarm. 

x
. Referencing in messages for Rhub and Swarm. 
. Icon indicates presence information is available; Presence prompt. 5
. Quick-reference fold out card in action 
. Three panes of the reference card. 
. Percentage of total user console errors. 

List of Tables

. Names given to mobile phones around the world. 

. Average subscribers per  inhabitants for world regions. 
. Analysis of  messages from random Norwegians. 
. Percentage of people who use SMS and voice for different purposes. 
. Social network models. 
. Eight challenges for developers. 
. Top ten viewed wiki pages. 
. Commonly used console commands. 
. Messaging forms. 
. Group IM forwarding options. 
. Syntax changes for messaging commands 
. Overview of user-created items as of September . 
. Tag applications per object type. 
. Categorisation of groups. 
. Linking of external services and accounts to Rhub profiles. 
. Content analysis for  random messages from group Alpha. 
. Message goals: coordination and chat. 
. Message source channels. 
. Coordination forms. 
. Message references. 
. Quiz questions and number of responses. 3
. Response rate by topic 
. Microcoordination in action. 

xi
List of Abbreviations

D Three-dimensional
AR Action Research
AJAX Asynchronous JavaScript and XML
CSCW Computer-Supported Cooperative Work
GPS Global Positioning System
HCI Human-Computer Interaction
IM Instant Messaging
MMS Multimedia Message Service
MSN Microsoft Messenger (instant messaging service)
PAR Participatory Action Research
PD Participatory Design
PDA Personal Digital Assistant
RAID Reflective Agile Iterative Design
RSS Really Simple Syndication
SCM Source code management system
SMS Short Message Service
SVN Subversion source code management system
UCD User-Centered Design
URL Uniform Resource Locator
XML Extensible Mark-up Language
XP Extreme Programming

Conventions Used in this Thesis

Quotes, from cited literature, participants, hypothetical examples, or messages sent using the
prototype are denoted with a double apostrophe, “such as this,” with the context of use making
it clear what style of quote it is. Phrases or noun-phrases are denoted with single quotes, ‘like
this.’ Examples of console input or system responses are denoted using a fixed-width
typeface. Spelling is in Australian English, except for quotes, which are reproduced in their
original form. All names of users and participants appearing in this thesis have been changed
for privacy reasons.

xii
1 Introduction

In this introductory chapter, I provide a short background to contextualise the reader, declare my
research aims, and outline the structure of the thesis.

1.1 Research Aims

Primarily, this thesis is an exploratory one, seeking to investigate technology-mediated informal social
group communication, collaboration and sharing. The thesis seeks for opportunities to enhance how
informal social groups socialise, understand how they use technology and investigate how technology
is appropriated into everyday socialising. Through this exploration, it is intended that a series of
empirical observations and design considerations can be formulated to be of use to other social
system designers.
The secondary concern of this thesis is a methodological one. Designing and researching mobile
social systems is markedly different from traditional desktop-bound software systems or context-
bound mobile systems. Mobile social systems are used within, across, and in-between locations,
people, situations and environments on an ad-hoc basis. Techniques for designing systems in this area
are little understood, as is how to go about researching their use.
These aims can be formulated as three research questions:
. How can we enhance how social groups communicate, coordinate and share?
. How do social groups assimilate and use technology for communication, coordination and
sharing?
. How can mobile social systems be effectively designed, developed and studied?

1.1.1 HOW CAN WE ENHANCE HOW SOCIAL GROUPS COMMUNICATE,

COORDINATE AND SHARE?

Insight into design opportunities can be gained through reviewing related literature, conducting
research, or carrying out exploratory design methods such as participatory design. There is difficulty,
however, in establishing the value of design ideas outside of an actual social research context. Low-
fidelity prototypes might yield feedback on the form and function of an interface; however, the
emergent social aspect of a feature only comes about through use. Use of a social system typically

1
 entails not only having a subject using the system, but also the subject’s friends. Testing using
scenarios are only of limited use, as ultimately, they are plastic and contrived, and the design idea will
not be subjected to the breadth of behaviours and contexts of use that a social system needs to cope
with. What is needed is an exploratory prototype in which design ideas can be experimented with and
Introduction used by people outside of the confines of a typical study, and used for real socialising purposes. Then,
it may be possible to say how we can enhance how social groups communicate, coordinate and share.

1.1.2 HOW DO SOCIAL GROUPS ASSIMILATE AND USE TECHNOLOGY FOR

COMMUNICATION, COORDINATION AND SHARING?

There are few chances to observe how members of a social group assimilate a technology. Social
technology research typically happens on a limited time scale and/or number of participants, so the
social group never fully assimilates the technology. For technologies that have recently become widely
used, such as mobile telephones, or social network sites such as Facebook, researchers are often too
late to capture the early stages of appropriation, or are hampered in how they study the system due to
privacy or commercial reasons. There is extensive research in how dyads use technology such as
instant messaging, text messaging and the web for communication, coordination and sharing. There is
little, however, on how informal social groups use these technologies. What group-related literature
there is, such as the field of computer-supported cooperative work, typically focuses on the workplace
context.

1.1.3 HOW CAN MOBILE SOCIAL SYSTEMS BE EFFECTIVELY DESIGNED,

DEVELOPED AND STUDIED?

Mobile Social Systems pose unique difficulties for designers, developers and researchers.
Designers must design a solution which is coherent across a number of technologies, and can be
used whilst mobile, a new and challenging context for systems and interaction designers. A social
system involves people to a large degree, who create value within the system and give rise to emergent
behaviours, be they positive or negative. The designer cannot entirely foresee these emergent
properties, which have an important role in the success or failure of a system. The social affordances
of the design might be different from the purely functional properties of the design, however for a
social system to succeed, it must excel at both.

2
 Developers are faced with how to develop a design across a patchwork of platforms in a manner
that is tractable with the given development resources. Having a means to implement change quickly
and reliably is important, as the design typically undergoes frequent change whilst being used.
Researchers find that their traditional methods and tools do not necessarily adapt to the mobile
context. Socialising often takes place in an ad-hoc, opportunistic manner. Mobile social technologies, Background
such as mobile phones, are used in, through, between and outside of the traditional contexts of study
such as the workplace or domicile. How will the researcher be ready, in the right place, at the right
time? There are also other concerns with researching mobile social systems, such as privacy. Digital
artefacts, such as messages and personal mobile devices are generally considered by people as private
things, and are not readily available to researchers.

1.2 Background
This section aims to rapidly brief the reader on social systems, how Australians use mobile phones,
the social activity of the major group of participants in this study, and provide a definition of informal
social groups. The section is largely a personal, descriptive account, and further research relating to
these themes is presented in subsequent chapters.

1.2.1 SOCIAL SYSTEMS

In this thesis, I use the term ‘social system’ to refer to a system (particularly a software system) which
is designed to support socialisation, or has mediated socialisation as a significant aspect of its use. A
social system is a combination of features, users and behaviours. It is hard to argue that a social
system without users is social. It is ultimately through use that a system attains social properties, and
this comes from people.
Such systems, particularly web-based social networking systems, such as MySpace
(http://myspace.com) and Facebook (http://facebook.com) are becoming increasingly popular and
count their users in the tens of millions around the world (ITU ). These systems allow people to
connect to each other, share photographs, leave messages on each other’s public ‘wall,’ send private
messages and so on. When the research and implementation for this thesis began in , it was not
common for people I knew to be a member of social networking sites, and it was not until mid-
that Facebook in particular became almost ubiquitous. These systems are useful for keeping up to
date with people’s activity, however are typically not usable for mobile messaging, and are generally
less useful for group-oriented activity.

3
 Social systems are sometimes formed around a particular theme or activity, for example, Flickr
(http://flickr.com) a photo-sharing site with a number of social features, or LinkedIn
(http://linkedin.com) which is designed for professional networking. Other systems focus on presence
sharing, for example Twitter (http://twitter.com) which allows people to publish short status messages
Introduction which can be subscribed to by others, and can be used via text messaging or a number of other
communication channels. Within my social context, few people outside of the ‘techno-geek’ circle use
such services, however.
Naturally there is some overlap between Rhub’s functionality and other social systems, in
particular Facebook, Swarm, Twitter and Dodgeball (http://dodgeball.com). Rhub was deployed
before I was aware of these systems. Swarm and Dodgeball became known several months after the
initial design and prototype had been made and were particularly inspiring in the way they utilised
SMS. Facebook became known approximately a year after deployment, and as mentioned above,
became commonly used in mid-. Twitter was launched after the deployment of Rhub was stable.
At the time of writing, of the systems mentioned, I have only directly used Facebook. During the
ongoing development of Rhub, some elements of these systems were introduced into Rhub. As an
example, in the initial design of Rhub in , there were sophisticated presence features. After the
introduction of Twitter, which is essentially a presence logger, I added the presence log page to Rhub.
This took advantage of the existing presence features, but merely displayed the data in a new way.

1.2.2 AUSTRALIAN MOBILE PHONE MARKET

This research was conducted within the context of the Australian mobile phone market, so here I
briefly outline its characteristics for the reader unacquainted with it.
Unlike the markets of some countries, the initiator of contact pays rather than the recipient. The
recipient pays nothing to receive a call or text message (unless they are using international roaming).
People can communicate between mobile phone carriers for no extra charge or inconvenience,
although some carriers offer special rates when contacting people using the same carrier. For example,
one company offers free -minute calls between subscribers at night. The cost of messaging is fixed
and charged per message (a unit of  characters). In , the average cost was equivalent to USD
. (ITU ). Interaction between mobiles is at a fixed rate within all of Australia, regardless of
distance between people. By , there was almost  penetration of mobile phone usage (Access
Economics ).

4
 Below I present a number of statistics from an online survey of , individuals conducted over a
two month period in early  (Wajcman et al. ), which help to illustrate Australian usage.

a  of respondents access the internet using their handset.

a  of respondents use text messaging.
Background
a  of people make less than one call per day from their mobile.
a  of individuals own a mobile,  have two phones.

1.2.3 SOCIAL CONTEXT

In this section, I wish to briefly sketch the social context of the primary group of participants in this
study, which I refer to here as ‘Orange.’. Later in the thesis, this group as it was articulated in Rhub is
referred to as ‘Alpha’.
This research was conducted in the city of Brisbane, Queensland, Australia. Brisbane has several
university campuses, and hosts an active student population. With its sub-tropical environment,
Brisbane is known for its all-year-around sunny weather that facilitates outdoor activities. Brisbane is
Australia’s third-largest city, has the highest population grow rate, and is known for being more ‘laid-
back’ than Melbourne or Sydney.
Orange is social group of people, nominally connected by the membership of a university sporting
club. Typically, there are around  members per semester, with perhaps  of those being from the
previous semester, the rest new to the club, and usually, new to the university as well. Over the course
of the semester, the number of people actively coming to events (sporting or otherwise) dwindles to
around  people. Orange is mostly made up of international students, who typically come from the
northern hemisphere and spend one semester in Brisbane. They study a little, as for many their
performance in Brisbane only counts at their home university as a pass or fail, so there is no incentive
to do more than pass. Mostly, however, the students are oriented towards enjoying the culture and
lifestyle, and travelling around Australia. For these people, twice-a-week afternoon sport is a great
chance to meet other people, and many relationships grow out of this, such as travel partners, friends
and romantic partners. People who meet at the club often stay in contact and visit each other in their
respective home cities around the world. The club also organises various social events during each
semester that aim to bring people together and have fun, under the guise of playing sport. There are
also a number of people within Orange who approach the game more competitively and play in
competitive leagues. Most of Orange are university students, and most of the Australian members also
hold part time jobs. Some have finished university, but are still associated with the club. A small

5
 number of ‘regulars,’ consisting of long-term international students and domestic students, manage
the club and ensure it continues running from semester to semester.
Most Orange members are very socially active. Members regularly hold house parties, and there
are often groups going on short trips from Brisbane or simply going out at night. In Brisbane,
Introduction Thursday through to Sunday nights are popular nights for socialising. Often these events will be
organised whilst at the regular club times of Tuesday and Thursday afternoons while people are
collocated. Mobile phone numbers and email addresses are quickly exchanged, with text messaging
being the main way to communicate when not co-located. The club has a web-based forum that was
used by members to chat, share photos and coordinate, however this fell into disuse after the
introduction of the prototype, which was generally considered more useful and effective.
When ‘going out’ Orange members know there are likely to be other people who might want to
come, but the challenge is how to get in contact with them, particularly for ad-hoc events, or when
people are not co-located. Group text messages were typically used, however people only had a subset
of others’ numbers, and thus the group message would invariably miss people. People would also miss
out when plans changed, as often plan variations were not sent to the original recipients. For example,
a group might arrange to visit a particular bar, but when one or two arrived early and noted the long
queues, might instead go somewhere else, but would face a difficulty in knowing who to message to
inform the others.
People would often message a small number of people, and rely on them to forward the message
on to other people. These message relays would have to forward messages up and down the chain as
events unfolded. When smaller groups within Orange, of say three people, want to go out they might
also invite others to come, and for single people within Orange, this was often a way for them to go
out without a group of their own. Again, this was difficult to accomplish with group messaging
however, and it was often performed by someone declaring loudly to everyone on a Thursday
afternoon that they should all meet up at a particular pub that night.
Often group text messages would be sent to probe for interest in a particular event, say by a single
person or two people who want to do something, but need more people to make it worthwhile. For
example, Ted might message a group of people with “who wants to go to the pub tonight with me and
Bill?” Replies would go back to the original sender, and other people who received the message had no
way of monitoring the progress of the planning. If you have gone out with Bill and Ted the night
before, you might not want to go, but if you know that Wolfgang, Ludwig and Johannes are also going,
then it might be worthwhile. This stream of coordination messages is useful for everyone for a variety
of reasons, but with group text messages, it only goes to the original sender. As a result, the initiator

6
often has to send update group messages, for example, “Ok, Wolfie, Ludwig and Johannes are also in –
anyone else?”
In most cases this socialisation was very informal, people would show up, disappear, bring friends
and so on. Because of the number of Orange members, their geographic proximity, and the popularity
of two local student bars, members would often happen upon each other on the active nights, and Background
larger groups would form. One member in particular, if none of his immediate friends wanted to go
out, would sometimes go out alone, and count on meeting other members by chance.
I do not seek to make gross claims as to the generalisability of this context, however I feel this style
of ad-hoc, last-minute social interaction is increasingly the norm rather than exception for other
people in this age range (-) and social context (university students).

1.2.4 INFORMAL SOCIAL GROUPS

In this thesis frequent reference is made to ‘informal social groups,’ so it is prudent to define what I
mean by the term. Loosely, an informal social group is a set of people, such as a circle of friends, who
do informal social activities together. ‘Informal’ is used to differentiate groups who participate in
institutionally defined activities that happen to be social. In other words, informal social groups are
made up of people who want to be together, rather than those that are placed together.
Informal social groups might have a particular axis or shared interest that links them, but are
characterised by the fact that the socialising and activity goes beyond the axis. For example, consider
Orange from the previous section. Here the central axis is nominally a sport, yet this plays a
background role to the group’s social activity. The axis is merely a means of an introduction and
contact. Groups might have only remnants of an axis, such as a group of high school friends who still
socialise twenty years later, but since then the social group has expanded to include friends-of-friends
and relationship partners.

1.2.5 CONCLUSION

When this research commenced, most people in my social group did not use social sites such as
Facebook. For most, a simple web-based forum, email and instant messaging was the extent of their
online socialising. Very recently, Facebook has become almost pervasive across my entire social
‘world’, however it does not support ad-hoc situated organisation or communication.
For that, people still rely on text messaging, which is cheap, easy to use and pervasive, yet clearly
has deficiencies when used for group messaging. The Orange social group is active, yet activity is

7
 often organised at the last minute, or organised amongst a small group of two to four, who then desire
a greater number to attend. Socialising across the group is hampered because people might only know
the contact details for a subset of people. At the last minute, they do not necessarily have the details
they need for the people they would have liked to invite. Group text messaging is an awkward affair,
Introduction with many phones the user has to manually select each contact to receive the message, and replies
from recipients only go back to the original sender, not the group, so changes to a plan must be
manually distributed.
It is clear that a system that offers many of the benefits of text messaging, yet offers better support
for group oriented messaging would be beneficial. It was also of interest to see how a group might use
a social system for sharing, for example exchanging contact information and photographs. Because
most of the study participants were of a particular demographic (young university students), and
many were members of a single sporting club, the generalisability of the thesis may be limited.
However, I suggest that population is broad enough (for example made up of a number of different
ethnic and cultural backgrounds, native languages and study programmes) that it still has significant
merit. A formal requirements study was not conducted before this research commenced. Because I
was part of the target user group, I had a good conception of how technology was already being used
for socialisation within the group. Being a designer and researcher, I also had an initial conception as
to the potential of new technologies to enhance socialisation. As such, I started with an initial design
which would address the ‘low hanging fruit,’ and used an exploratory research process to flesh out my
preconceptions and as well as to reveal unanticipated opportunities.

1.3 Thesis Outline

Chapter  begins the content of the thesis with a review of literature relating to mobile and social
computing, discussing existing systems and their use. It highlights the usage of text messaging in
particular, and its use for microcoordination between two people. Two systems from academia are
discussed which provide group text messaging support, however it is noted that only limited data is
available as one only ran for a short period of time, and the other only had a small number of users.
The chapter concludes by highlighting the opportunities for new design as evidenced by the literature,
as well as noting the lack of empirical data on the use of mobile social systems.
Chapter  reviews design and development methodology literature, as well as a brief interlude on
uncertainty in design. The chapter makes a case for agile, goal-directed methods being well suited to
deal with complexity and uncertainty.

8
 Chapter  is the final literature review chapter, and focuses on research methodologies relating to
the context of this thesis. The context of mobile use is sketched, highlighting the problems with many
traditional investigative techniques. It also makes the case for the exploratory prototype as a key
method to investigate emergent social behaviour, use and appropriation.
Chapter  takes a quick detour in the narrative by outlining the form and function of Rhub, the Thesis Outline
exploratory prototype developed for this thesis. It is a necessary exposition for the reader
unacquainted with the system, as later discussion assumes a basic understanding of its workings.
Chapter  builds on the discussion of agile, iterative design methods in chapter three and the
discussion of the mobile context and suggestion of an exploratory prototype from chapter four. In this
chapter, a new method is outlined, which combines these methods into one cohesive framework –
Reflective Agile Iterative Design (RAID). RAID is designed specifically for mobile social software
development, and supports a reflective, exploratory, iterative approach that is demanded by the social
context of use. Reflections on the method itself are also noted.
Chapter  introduces, discusses and reflects upon studies conducted for this thesis: the prototype,
reflective journal, situated interviews, quiz and design workshop. The quiz is a novel method that uses
the prototype itself to gain an understanding of the everyday context of participants.
Chapter  combines data from the studies outlined in chapter seven, and discusses results in a
thematic way. In this chapter, significant findings are examined, and a number of considerations for
the design of mobile social systems are identified.
Chapter  concludes the thesis by revisiting the research aims introduced in this chapter and
stating the main contributions of the work.

9
Introduction

10
2 Mobile Social Computing

Literature Review

The general fields of mobile and social computing have existed for some time, however it is only
recently that their promise has been realised. Mobile computers, in the form of mobile phones, with a
long battery life, input/output capabilities and wireless connectivity are now in the pockets of millions
of people throughout the world. With widespread deployment and use, social-oriented systems which
build upon these “portable, personal and pedestrian” platforms (Ito ) can be built.
In this chapter, I present an overview of mobile social computing literature, which is broken into
four main sections: ) mobile telephones and text messaging, ) context in computer science, )
mobile social software and ) technology adoption. This structure begins with the relatively basic
form of technology, introduces context, and then moves on to software systems, and concludes with a
discussion on technology adoption and use.
In the first section, I discuss emergent use of mobile telephones – how people have appropriated
phones into their lives, what meaning they have for them, and typical usage for phone calls and text
messaging. This discussion also identifies design issues pertaining to mobile phones and their use,
which has import for design responses in the field. In the second section, rather than detailing work in
context-aware technological frameworks, I give a brief background to the role of context in computer
science. In the third section, I introduce mobile social software, including specific usability issues, and
related applications. In the fourth section, I discuss technology adoption, which has important
implications for how mobile social software can be deployed and used.
The chapter provides a basis for initial design of the Rhub prototype, covering usage of existing
systems and related design considerations as well as opportunities for innovation. I also discuss
technology adoption, particularly pertinent to social computing, as often, utility is only realised when
many people use the system.

2.1 Mobile Phones & Text Messaging

In the last decade mobiles phones have quickly become a ubiquitous technology in many parts of the
world, including poorer regions where landline telephones and Internet access are lacking. Mobile
phones enable social connection and commerce and new forms of wireless, mobile services, even in

11
 the absence of high-speed access. Text messaging, a cheap ubiquitous communication medium allows
people to maintain a continuous presence (Väänänen-Vainio-Mattila ) with a series of short,
background messages. When a quick asynchronous message will suffice, text messages are favoured
over voice calls as they are cheap, quick to compose and send and the receiver can read and respond at
Mobile Social their leisure. Although mediated, the social connection afforded by mobiles is meaningful to people;
Computing
even virtual artefacts such as messages and contacts hold value. Particularly in developed countries,
mobile phone usage is high amongst youth, who appreciate its affordability and ability to connect to
peers without parental oversight. Whilst mobile phones bring people together and make it easier to
socialise and coordinate, they can disrupt public places with ringtones and one-sided conversation.
There tends to be an emphasis in the literature on teenager usage of mobile phones, as Matsuda
writes in her introduction to an edited volume on mobile phone (keitai) usage in Japan:

“Most of the chapters in this book follow the trend set in the mid-s of focusing on youth use. These
studies analyze keitai use by young people because they foreshadow subsequent developments and
highlight what is distinctive about keitai.” (Matsuda :).

While perhaps currently true, older persons usage of mobiles is not necessarily informed from
studying youth as they are different demographics with different requirements (see for example
Osman et al. ). There is a risk then of older persons being marginalised if designers exclude their
perspective, a problem particularly salient as many countries have an increasingly aging population.
The reader should consider this age bias when perusing the presented literature.

2.1.1 WEARABLE COMPUTING

Wearable computing is typically defined as computing which is always on, always connected and
always available, and has some awareness of its context. Futurists envisage personal wearables as a
small computing package that people always wear (or perhaps integrated into clothing) that uses its
computing facilities to serve the individual. Because it is always with the person and always on, it is
well placed to be able to sense the user’s current environment so as to generate longer-term trends or
predictions. This learning is used by a software agent to pre-emptively serve the user, for example to
pre-fetch traffic information for the part of the city that the person travels to every day. This vision is
somewhat different from ubiquitous computing (Weiser ) in that wearables are user-centric,
rather than environment-centric. As the computer is with the users whenever they need it, it has been

12
suggested that wearables can support situated computing – supporting action and requirements in
situ (Gershman et al. ; Hull et al. ; Rhodes ).
The situatedness of wearables can also be utilised in context-aware applications. Pentland and
colleagues have investigated applying machine learning to wearable-located sensor data to synthesise
new social information which in turn can be used to improve group coordination, or to identify social Mobile Phones &
Text Messaging
networks (Choudhury and Pentland ; Clarkson et al. ; Eagle and Pentland ; Maden et al.
).
Because of their sophistication and connectivity, wearables are natural platforms for mobile social
computing (Korteum and Segall ) and computer supported cooperative work (Bauer et al. ;
Billinghurst et al. ). A common theme of wearable social computing is a ‘match making’
application, which aims to bring strangers together based on some (previously unknown) shared
attribute (Kortuem et al. ), for example notifying two people who are nearby that they both like a
particular band.
Prototyping a mobile social system with wearables presents difficulties as there are no large-scale
deployments of wearables, or consistent platforms, and resultantly most social computing applications
have been untested, or have seen only limited deployments. Furthermore, wearables present several
interaction barriers to observers, mostly a result of the non-shared nature of a wearable’s input and
output systems. These barriers, or “involvement shields” (Goffman ) can negatively affect others’
perceptions of the wearable user, characterising them as un-agreeable, distracting and in some cases,
physically handicapped (Dryer et al. ; Sheridan et al. ).
Modern mobile phones however are highly sophisticated and widely deployed - meeting the
definition of a wearable in many regards - and as such the more favourable contemporary choice of
platform by both commercial and academic designers.

2.1.2 WORLD PERSPECTIVE

Whilst computer science research often dwells on the American and European perspective, mobile
phones have proved to be a successful technology around the world (Figure , Table ). In some cases
mobiles have ‘leapfrogged’ over intermediate technologies such as landline phones and wired internet
(Kolko et al. ). Mobile phone infrastructure can completely avoid problems with existing badly-
maintained, unreliable landline networks and easily cover a broad geographical area, as seen in
Swaziland, Somalia and Bangladesh (Ito ; Plant ).

13
 Different cultures and languages have their own names for mobile phones, which may hint as to
how they are perceived (Table ). In some, mobile phones are referred to as a by-product of its
implementation or infrastructure, such as cellular phone in America, while others seem to relate more
to a freedom, such as kanny in Finland.
Mobile Social
Computing
Language Name Signifies
Arabic telephone sayaar / makhmul Mobility/technology
Portable / wireless telephone
Chinese - Mandarin sho ji Personal enablement/technology
Hand machine
English - American Cellular phone / cell Technology

English - British Mobile phone / mobile Mobility/technology

Finnish Kanny Personal enablement

Extension of the hand
French le portable Mobility/technology
Portable
German Handy Personal enablement
Handy
Japanese keitai denwa (keitai) Mobility/technology
Carried telephone
Spanish et movil Mobility
Mobile
Table . Names given to mobile phones around the world (adapted from Plant, ; Ito, ).

14
 Mobile and fixed telep
phone subscription rates, 
Mobile subscribers per 100 inhabiitants Subscriber lines per 100 inhabitants

100

50
Mobile Phones &
0
Text Messaging

Figure . Mobile and fixed line penetration

n (ITU )

Table . Average subscribers per  inha

abitants for world regions. Africa has a high ratio of mobiile subscribers
to fixed line subscribers.

Region Mobile subscribers Fixxed line subscribers Ratio Mobile to Fixed

Africa 21.59 3.10 6.96
Americas 61.95 32
2.43 1.91
Asia 29.28 15
5.81 1.85
Europe 94.29 39
9.71 2.37
Oceania 72.57 36
6.57 1.98

2.1.3 TEXT MESSAGING

“There's actually quite a lot [of] text messages flying about. You can say you're moving to the n
next bar,
or on the way to have a cup of coff
ffee or something. It's like a kind of unnoticed continuous use."
( year old female respondent quoteed by Kopomaa :)

Text messaging is typically used for iinformal lightweight notifications and background,, continuous
conversations (Kopomaa ). Alth
hough SMS is an asynchronous medium, people can tightly
synchronise as its low threshold of u
use and low costs permits sending a large number of messages
(Table ). Svendsen et al. () found
d that SMS was little used in business communication
n because of
its private, personal and informal charracteristics. Practically, SMS is used for a variety of pu
urposes such
as chatting, coordination (discussed laater), play and information-sharing (such as birthdayy reminders)
with several studies demonstrating coordination being most used (Grinter and Eldridge ;
 Ling et
al. ).

15
 Social protocols such as greetings and salutations are regularly dropped when messaging, allowing
communication to be quick and succinct. Because sending and receiving parties are aware of the
limitations and properties of text messaging, (messages might be composed whilst mobile and that
messages have limited length, for example) such lapses in protocol are permissible without the
Mobile Social recipient necessarily judging the sender. The text medium also allows people to conduct word games,
Computing
playing with the form and structure of the written language for effect (Rivière and Licoppe ).
Youth use text messaging to a much larger degree compared to other ages. For example, Okada
() reports that students receive . messages per week on average, while the overall average for
the entire study’s population was . messages per week. Miyata et al.’s () ethnographic study in
Yamanashi, Japan, found that text messaging tends to be sent to people nearby; for those farther away
email tends to be used and that people were more likely to use a phone to send a message instead of a
PC even when a PC is available.

There is evidence of gender difference in text messaging usage. Females tend to write longer and
more linguistically complex messages than males, and send a greater quantity of messages (Grinter
and Palen ; Kasesniemi and Rautiainen ; Ling ; Matsuda b). Girls will sometimes
write messages out to a diary if their phone’s message storage is full and also tend to send more
messages from home than boys (Kasesniemi and Rautiainen ; Kopomaa ).

Genre Messages ()

Middle future coordination (things happening in next hours or day) 23
Questions 11
Grooming (compliments/small-talk) 10
Near future coordination (already begun or next few minutes) 8
Short one word answers 8
Emotional grooming 6
Commands/requests 6
Information 5
Personal news 5
Location information 3
Sexually related jokes 2
Distant future coordination 2
Invitations 1
Jokes 1
Table . Analysis of  messages from random Norwegians, from Ling et al. :.

16
2.1.4 WHEN TO TEXT, WHEN TO CALL

Text messaging is generally preferred for quick messages as it is cheaper and requires less time
(Barkhuus ; Elwood-Clayton ; Grinter and Eldridge ; Kopomaa ; Ling ). A
voice call is more disruptive and costs more, but is considered more important and credible, and is
Mobile Phones &
most useful when synchronous communication and quick resolution is desired (Höflich and Gebhardt Text Messaging
; Jensen et al. ). Out of common media (phone, mobile phone, SMS, email, fax and letters),
SMS was rated as the least important and least credible ( adult participants, Höflich and Gebhardt
).
Social psychology research indicates that paralanguage - the manner of speech and facial gestures
- are weighted highly when a listener is considering a face-to-face communication (Heslin and
Patterson ). If there is dissent between what the speaker says and the facial expression used to
convey the message, the listener considers the facial expression to be a better indicator for the true
meaning (ibid.). This can partially explain the higher credibility of phone call over text messaging –
text messaging is disembodied, lacking a second ‘channel’ with which a recipient can use to confirm or
deny the intent of a message.
Okada () cites data from the Japanese Mobile Communications Research Group, showing that
mobile calls are used slightly more than SMS for urgent communication, chatting and coordination
(Table ). SMS, on the other hand, is preferred for background communication such as status updates
and irreverent messages. Text messaging is used in Japan more for communicating with friends and
colleagues while calls are preferred for spouses and lovers (Matsuda a), perhaps indicating that
SMS imparts a lower emotional value than hearing someone’s voice and that interruptions caused by a
call are more acceptable between partners.
Location and time are also important when deciding to either text or call. Text messaging is used
more commonly from fixed locations, such as homes or workplaces, whereas calls are often made
while mobile, such as in a car or on the street (Dobashi ). While text messaging may disregard
some social formalities and conventions such using salutations and closings, it permits people to
respect others, for example texting someone late at night instead of ringing (Grinter and Eldridge
).

17
 Purpose SMS () Voice ()
Arranging and coordinating 64 73.3
Urgent communication 44.9 57.9
Chatting 30.9 43.6
Status updates 49.6 33
Mobile Social Consulting about their worries 25.1 26
Computing Nothing in particular 33 20.3
Mood checks 22.6 13.3
Going-home time 14.3 13.3
No use 7 4.3
N.A. 2.7 1.7
Table . Percentage of people who use SMS and voice for different purposes in the general Japanese population
(cited by Okada )

2.1.5 MEANING

When considered as objects, phones and the data within them have meaning apart from their
functional role. In some cultures, phones are symbols of wealth and importance (Matsuda b;
Varbanov ) which may be placed or worn conspicuously to display power or hidden away when
the phone is inferior or when such display is considered crass (Plant ). Some go as far as showing
off replica phones with no functional value (Plant ) or customising phones extensively to reflect
individuality (Ling : ).
Virtual objects stored, sent and received by the phone have meaning too. The number of contacts
stored can be used to signify popularity (Matsuda a), and text messages can be highly valued gifts
that are kept and treasured (Taylor and Harper ).
Text messaging is a medium of uncertainty. Carriers do not guarantee delivery and unlike phone
calls, there is neither negative nor positive acknowledgement of a normal message’s reception or
reading. Because of the shared knowledge of uncertainty, a recipient has plausible deniability – he can
plausibly claim that he had not read a message and cite a number of valid reasons, even if he had. It is
difficult on the other hand to deny to a caller that you spoke to them on the phone. Uncertainty can
help explain the expectation of reply (Ito and Okabe ; Laursen ), and the medium’s low level
of credibility (Höflich and Gebhardt ). A reply naturally assuages a sender’s concern about
whether a message has been received and therefore is considered a polite or necessary gesture
depending on the context. Because there is no certainty when sending text messages, they cannot be

18
relied on for important information†, and therefore lacks credibility – after all, if intended
communication was important and credible, it would be sent using a reliable medium.

2.1.6 PRIVACY

Mobile Phones &

"The thing is that nowadays nobody likes to give their phone into someone else's hands. Text messages,
Text Messaging
phone calls, photos, emails, all your life is there"
(Participant response cited in Häkkilä and Chatfield : )

Mobile phones, and data held within them, such as call history, contacts and message logs are
considered private, however may be made selectively public. People are less likely to read someone’s
text message than answer their phone, as the text message contains the information up front, while a
caller can selectively reveal information depending on the receiver (Häkkilä and Chatfield ). In
their study of mostly under  year olds, Häkkilä and Chatfield () report that . consider
mobile phones private devices and . wouldn’t answer a friends’ phone if it were ringing. Privacy
and social norms are not universal, for example Weilenmann and Larsson ()’s observation of
teenage girlfriends reading aloud and writing text messages amongst their group as well as answering
and carrying each others’ handsets. The medium itself affords easy sharing: messages and contacts are
easily forwarded to others:

"Kristine (): If you have gotten an SMS from the guy you are interested in then you can share it with
others, perhaps even send it [via SMS]. You can even send it with comments."
(Kristine,  years old, quoted in Ling et al. : )

2.1.7 ENABLER OF MULTIPLE FRONTS

Goffman () used theatrical metaphors in discussing social interaction. Social interaction is played
out on a stage, with social actors maintaining faces, or fronts. A front could be thought of as a public
display of character. A schoolteacher maintains one front whilst teaching, but on retreating to the staff
room may take on a different front, and there may be a different one again at home. Confusion and
embarrassment can occur when a performance with one front compromises another, such as a
married man caught with his lover in a cafe. Mobile phones permit – and sometimes require –
multiple fronts to be maintained. This can be positive or negative, depending on the context, however

†
There have been anecdotal cases of wedding proposals, divorce notices and retrenchment notices
delivered via SMS however

19
 juggling multiple fronts is always more difficult and strenuous than not. Plant () reports of people
using a number of phones, one to communicate with a spouse, one for a lover, one for work, and so on
– in effect, a phone for each front. Multiple physical handsets make face management easier, as
incoming communication for one face can be simply turned off whilst ‘performing’ with another.
Mobile Social
Computing 2.1.8 DISRUPTOR OF SOCIAL ORDER

Mobile phones are often characterised as a social menace. They are making the younger generation
illiterate, antisocial and violent; they intrude on public space with physical noise and violations of
privacy (Australian Associated Press ; Honigsbaum ; Matsuda a). Mostly, these gross
stereotypes are not supported by the literature. There is a positive correlation between sociability and
mobile phone usage (Kim ; Matsuda b), Hård af Segerstad () found that abbreviations
were little used in text messages and literacy has not dropped among youth (Fresco ).
Intrusions of public ‘tranquillity’ are common as people use a greater volume and quantity of
speech to make up for the lack of subtle physical gestures when talking on mobile phone (Ling ).
As a result no-phone zones have been declared in places where peace is valued, such as restaurants
and train carriages (Matsuda b; Plant ). A similar concern was aroused with the introduction
of landline telephones, however then the concern was the public infringement of private space rather
than the private infringement of public space (Palen et al. ). It is interesting perhaps that two
world cultures characterised for their affinity for restrained conversation, Finnish and Japanese, both
have higher than average phone usage statistics (Matsuda b; Puro ). Many of the worries
associated with mobile phones came about when the devices were new and few people had used them
personally. Those with experience of using phones are less likely to agree that phones disturb others
(Ling : ; Palen et al. ).
A mobile phone offers the dual possibilities of initiating contact and being contacted, wherever
you may be. Furthermore, mobiles offer a more balanced share of power between initiator and
recipient than landline calls. With phone calls, the power lies with the initiator. Recipients of a call
have few clues to decide if a call should be taken – at most the name of the caller and their number –
making the unexpected intrusion all the more difficult to deal with. It is not until accepting the call
(and accepting an interruption) that the meaning and value of the call be ascertained. With text
messages however, the content of the interaction is made bare immediately, and they can be triaged
effectively. Landlines on the other hand have traditionally only offered voice calls, without providing

20
the name or number of caller (although modern handsets can offer caller display as well as text
messaging).

2.1.9 SOCIAL CONNECTION

Mobile Phones &

“Interviewer: When do you call or send a message?
Text Messaging
Respondent: On a Sunday or day off [I’ll text], “good morning” or a greeting like that. Even if you don’t
call you can kind of keep a connection. If you send one [text] message, you feel connected”
(Okada :)

Omitting purely functional uses, such as coordination and urgent communication, mobile phones are
used for social upkeep: making, maintaining and breaking social ties. Text messaging in particular
allows people to maintain a “continuous presence” by the exchange of constant, micro-messages with
friends (Väänänen-Vainio-Mattila ). While one in four Japanese college students would give their
mobile number to anyone, regardless of relationship status, only a few are regularly contacted
(Matsuda a). This results in bloated address books; however, contacts can serve as a type of social
currency – popularity expressed by the number of contacts (Ling ) – with the actual number of
people being contacted small (Grinter and Palen ; Matsuda a).
Although text messaging is highly mediated and has limits on style and expressiveness,
relationship bonds can be maintained, strengthened and felt (Elwood-Clayton ). The indirectness
can also help shy people express emotion they would find difficult to express verbally (Barkhuus ;
Rivière and Licoppe ) and allows the deaf to communicate equally with others (Bakken ).

2.1.10 COORDINATION

“Arguably, the greatest social consequence arising from the adoption of the mobile telephone is that it
challenges mechanical timekeeping as a way of coordinating everyday activities" (Ling : )

Coordination relies on the agreement of shared reference points, such as time and place. Prior to
instant long-distance communication mediums such as the telegraph and telephone, remote
coordination had to be arranged sometime in advance, by post, for example, with time as a central
point for coordination. There was little avenue for ongoing negotiation because of the slow,
asynchronous medium, and time was the central axis for coordination. Remote communication
improved with the introduction of landline telephones however demanded callees to be at a fixed
location: calls made to a house or office, not to a person. Public telephones proliferated and it then

21
 became possible to makes changes to coordination specifics closer to the time and the location of the
event. By agreeing beforehand to be available at a certain payphone at a certain time, calls could be
received, or two parties could make ongoing coordination changes using an intermediary such as a
secretary. The introduction of the mobile phone did away with prior restraints. Now calls are made
Mobile Social directly to a person, irrespective of their location†, and synchronous or asynchronous communication
Computing
is possible using voice or text messaging. Fine-grained, iterative coordination is viable, with changes
made to plans as dictated by whim or circumstance. Instead of party plans sent out weeks in advance a
party might be announced to a group the very day of its undertaking. Ling and Yttri () refer to
this as microcoordination, with time having a greatly diminished role in coordination. Coordination
might be roughly sketched and as time progresses, refinements and agreements are made to specifics,
supporting a type of distributed, remote situated action (Suchman ). Between groups, however,
microcoordination is a more difficult task as each party needs to be kept abreast of the ongoing
coordination, suggesting that above a certain threshold of participants, time is still a better axis for
coordination (Ling ).

2.1.11 INTERACTION CUES

Face to face social interaction makes use of subtle non-verbal cues which supplement the verbal
interaction (Heslin and Patterson ). Cues are generally recognised and used either at a conscious
or unconscious level; conscious use of cues allow for subtle shaping of the interaction or provide
feedback which would be inappropriate to make explicit using spoken words. Mediated interaction
cannot always carry traditional cues, for example a phone call cannot express physical gesture,
however new techniques have emerged to fill the void. For text messages, it is inconsiderate not to
respond immediately (Ito and Okabe ; Laursen ), so delay can be manipulated to conjure
meaning (Ling ). Like traditional cues, there is a level of ambiguity: a delay in answering a text
message is not necessarily because recipient is exerting power over the sender, rather they have
forgotten their phone at home.
New forms of signalling have also developed which take advantage of the technology. Callers can
‘prank’ or ‘beep’ phones by dialling, and then hanging up after one or two rings, incurring no cost. The
recipient is then aware of who called, and when, and there may be mutually agreed meanings for such
an action, such as ‘call me back’ or to get attention ‘I’m outside now, come and meet me’ (Matsuda

†
Network coverage permitting

22
b). In sub-Saharan Africa a proportionally very low amount of calls was explained when
researchers discovered highly sophisticated ‘beeping’ practice (Donner ).

2.1.12 CONCLUSION

Context in
It can be easily argued that mobile telephones represent the most successful example of personal Computer
ubiquitous computing or wearable computing ever developed. Modern day handsets usually feature Science

internet connectivity, programmability, have long battery lives, versatile input and output mechanisms
and are easily pocketable. Importantly, mobile phones have existed for long enough that emergent
behaviour has not only come about, but has been extensively studied. This represents a compelling
opportunity for future development in the area of mobile social computing. The platform for running
sophisticated systems is already there and being carried around by people of all lifestyles on a
continuous basis. Now, the focus of the research needs to be on understanding what people might
want to do with such platforms, beyond current applications.
Learning from usage of mobiles is important for any such future development. People use text
messaging to maintain continuous contact with friends, for communicating status, presence and
coordination. Voice calls on the other hand are used for important concerns, such as when an answer
is immediately required. People find meaning in other people’s use of mobiles, such as how quickly
someone replies to a message, as well as digital representations such as messages and contacts, and
the handsets themselves. Mobile technologies impact the social environment they are in, which can
have ramifications for people’s privacy and ego. Currently, people mostly use mobiles for social
purposes, such as maintaining relationship ties. Coordination appears to be a major component of
this social use, yet there is little specific support designed for it.

2.2 Context in Computer Science

There is possibly as much promise in context-aware systems as there are pitfalls. The relatively simple
desire of the designer to automate a task based on contextual information belies the complexity and
subtlety required in its approach. Designers should not necessarily add context-awareness to all
systems; again, consideration is required as to where it is best used to benefit people (Oulasvirta
).
Typically, a context-aware system takes data from inputs, performs some analysis function on it,
producing an inference, which triggers an action to take place as a result. Context, as humans
understand and use it, is not completely quantifiable, which can lead to false assumptions by the

23
 system. The human dimension of context, with its social, emergent characteristics cannot be sensed
by technology, and it is this dimension which plays a large role in how people make use of context as a
resource in action (Bellotti and Edwards ). Dourish (), following Suchman (), notes the
emergent nature of context, that it is neither a property, stable or delimited. This view proposes that:
Mobile Social
Computing “Context arises from activity. Context isn’t just ‘there’, but is actively produced, maintained and
enacted in the course of activity” (Dourish : )

To minimise usability problems, it has been suggested to use contextual information defensively
and cautiously (Bellotti and Edwards ; Brown and Randell ). Rather than automate tasks
based on context, perhaps merely displaying contextual information and allowing the user to make
their own decisions is sufficient. If, however, automation is highly desired, it should be easy to undo
and its side effects minimal. Bellotti and Edwards propose two required key features, intelligibility and
accountability. Intelligibility so users know what the system knows, how it knows it and what it is
doing about it. Accountability so that users always have control and their action through the
technology is transparent.
Deciding what aspects of context are important is difficult, as is determining how context should
be expressed to the user (or other observers) so that it is meaningful. Privacy considerations also play
a part in the dissemination of context information. Even if it is possible to glean some information
automatically, reliably and accurately, this precise data may not be meaningful to observers, or the
user may deem it too specific to reveal to others. For example, a system may reliably determine a
person’s latitude and longitude using GPS. To observers, these coordinates are meaningless unless
depicted on a map, and a user may not want their precise location disclosed, but rather a ‘fuzzy’
location such as suburb. Establishing how to map contextual information to meaningful, or possibly
more generalised information is also a consideration.
Allowing people to manually specify contextual information alleviates some difficulties with
designing context-aware systems, however it must be quick, easy and rewarding to do so, otherwise
the person may not bother (Bellotti ).
Essentially, contemporary understanding is that contextual inferences are bound to fail, either by
making false inferences or missing inferences the user deems important. Consequently, the system
should minimise any effort required on the part of the user to deal with this possible failure.

24
2.3 Mobile Social Software
Mobile Social Software (MoSoSo) identifies systems that can be used whilst mobile and aim to either
directly support socialising or indirectly take advantage of social information or social networks.
Social systems can be generally identified as one of three social network models: intimate, crowd and
hybrid (Table ). Intimate networks are those in which the utility only arises when close personal Mobile Social
Software
connections such as friends and family are also using the system (such as Facebook). Crowd networks
are those that provide utility to users when any other people are using it (such as eBay), no matter
what the relation to the user. Hybrid networks combine aspects of both the intimate and crowd
models (such as Flickr), allowing users to take advantage of personal relations as well as the collective
crowd.

Table . Social network models.

Type General examples

Intimate Facebook, telephone networks
Crowd eBay, elections
Hybrid Flickr, recruiting

Early MoSoSo work utilised wearable computers as they offered higher levels of sophistication than the
days’ mobile phones. Today, however, even baseline mobile phone models offer some level of
programmability and have varying forms of wireless data access. ContextPhone is an example
platform for prototyping context-aware mobile applications which offers a high degree of
sophistication (Raento et al. ). In developing countries where internet access is not widespread or
reliable, yet widespread mobile phone coverage may exist, MoSoSo can serve as a bridge linking the
two systems and providing easier access to the internet (Kolko et al. ). Moreover, in cultures
where personal social ties are highly valued, MoSoSo can allow people to define and express social
relationships (Kolko et al. ) which might for example assign incoming messages from family
members a higher priority than messages from strangers.
Mobile phone-based MoSoSo systems were often SMS-based: utilising a feature that is available on
all handsets and does not require installation of custom software or particular configuration to use. In
this case, the user is typically required to send a command, expressed within the -character limit of
a text message, to a service that parses the message, performs an action and sends a response. Because
there is no visible interface or cues, such services require simple or highly memorable command
syntax in order to be useful without resorting to separate instructions. Alternatively, MoSoSo might be

25
 delivered using an installed client application on the handset. Systems that are more sophisticated are
possible as the client application can interface with the phone’s hardware as well as display a full
interface on the screen. As there are several platforms for mobile development, it is difficult to
produce a single application that can be used across all phones reliably and efficiently; and an
Mobile Social application usually requires user intervention to install, maintain and configure it.
Computing

2.3.1 USABILITY CHALLENGES

With mobile devices’ limited input and output capabilities, designers face challenges when adapting
desktop-based systems for mobile use. When reappropriating a system for an alternative purpose,
designers also have to be aware of entrenched user conceptual models. For example, SMS can be an
interface to a service, however users conceptualise SMS as a technology for talking with people, not
machines. SMS-based systems have no affordances for use. “Affordances,” as appropriated by Norman
() are aspects of the design that provide clues for their use. Such a service however has no
observable interface; the only observable aspect is the written syntax help. Any arbitrary string of
characters can be sent, and the user does not know what is possible, available or legitimate until a
response is received from the service. In the design of a Google SMS-based service, Schusteritsch et al.
() use extensive contextualised help responses, online help and printable ‘cheat-sheet’ cards to
help overcome the lack of cues.

2.3.2 CONTEXT-ORIENTED

Context’s role in computer science was introduced in the previous section, in this section however,
we consider mobile systems that are context-oriented. That is, those which have a focus on current
location, time, presence or status. Disclosure of context information has obvious privacy implications.
Most systems address this issue by only exposing information to people the user has previously
established a relationship with using a contact or ‘friend’ feature. Barkhuus and Dey () studied
privacy concerns in the context of location-based services with  participants. They distinguished
between two types of location-awareness: ) location-tracking, in which other parties can see your
location and ) position-aware, in which your own device or service knows where it is. Participants
were generally more concerned with privacy in location-tracking than position-aware services.
However, if the service offered by location-tracking is useful enough, privacy concerns were ignored.
DeDe (Jung et al. ) is a system which augments text messaging allowing the sender to set
contextual parameters which determine when a message appears to the recipient. In the prototype

26
implementation, DeDe supports time, location (cellular tower-based), devices within range (Bluetooth-
based) and phone logs as contextual parameters. Messages are sent immediately, however, client
software running on the recipient’s phone hides the message until one of the contextual parameters
activates. Overall, only two parameters were mostly used, location () and time () and more
than half of the specified locations were someone’s home, i.e. the recipient receives the message when Mobile Social
Software
they arrived home. Participants in total sent . of their messages using the system, the remainder
being sent using other means such as SMS. Whilst participants reported that they liked the
automation, they perceived DeDe messages as being unreliable, as they were never quite sure when a
message would appear to the recipient. SMS is already an uncertain medium, so adding further
uncertainty might hinder use; DeDe’s users adapted to this uncertainty by appending requests such as
“please reply to me if you get this” to messages.
Dodgeball (http://dodgeball.com) and Playtxt (http://playtxt.net) are two commercial location-
oriented systems that allow people to indicate they are at a particular location. Locations are
referenced by name and are typically cafes, restaurants pubs and clubs. Once a person sets their
location via a text message, their friends, or friends-of-friends are notified if they are nearby. While
such systems require all users to manually specify their location for the notifications to take place,
people can choose when to reveal their location. Building on this concept, Loopt (http://loopt.com)
utilises phone-based Global Positioning System (GPS) so that location can be set without the user
having to enter the information manually. Because it uses latitude and longitude for location
referencing, Loopt’s notion of a location lacks semantic meaning for others. A location of ‘-.,
.’ requires placement on a map to impart meaning, while a group of friends may have an existing
shared meaning of the location ‘the pub’.
Reno (Smith et al. ) is a system which, like Dodgeball, allows for meaningful location names
and, like Loopt, allows for automatic location identification, however it uses cellular towers for
positioning instead of GPS. Rather than merely pushing location information, it allows people to
request the location of others, a request that can then be accepted or denied by the receiver. In the
discussion of the results, Smith et al. report on several common difficulties such systems face. When
sending a notification that they are at a particular location, there is ambiguity in the meaning of the
notification, and successful interpretation relies on consistent meaning between interactional
partners. In one cited example, one person uses the location ‘Home Depot’ to signify they have
finished work and will be stopping at Home Depot for a personal errand, while the receiver of the
notification interpreted it to mean the sender was passing a Home Depot, and was left wondering
which Home Depot it was. Both parties inferred higher meaning from the location, but

27
 misunderstanding resulted because the meaning was not shared. Automatic disclosure of location,
even between a married couple, can be seen as positive and negative depending on the situation. One
user of Reno found that its automatic notification was useful on occasion, so that he could quickly put
the house in order when his spouse arrived home, however if the house is already in order, such
Mobile Social notifications might be irritating.
Computing
Presence sharing, as part of a larger coordination activity, is a common use of text messaging,, and
there are services that attempt to make this type of context information easily disseminated, such as
Twitter (http://twitter.com) and Jaiku (http://jaiku.com). Presence notifications are textual and free
form, for example using the message ‘I’m at work having a dull day’ rather than setting a location to a
specific, pre-determined place or coordinate. Notifications can be sent and received with variety of
technologies and systems such as the web, SMS and instant messaging.

2.3.3 GROUP MESSAGING

Text messaging is not designed for group usage. If a single text message is sent to multiple recipients,
each is unaware of who else it was sent to (or indeed that is a group message), making group replies
difficult. There has been various studies which explores the possibilities and usage of more
sophisticated group text messaging systems (Counts ; Farnham and Keyani ; Hirsch and
Henry ; Sillence and Baber ). Typically, these use the existing text messaging infrastructure,
however messages are sent via a dispatching service which receives and forwards messages to and
from a group of people. Because (from the phone’s perspective) they are normal text messages, group
messages are not treated any differently and the user is alerted in the same way as with a personal
message. Beeps, vibrations or displays that the phone normally makes for personal messages now also
occur for group messages, diminishing their novelty and attention-getting value and making attention
triage difficult. Sillence and Baber () report participants saying that if the group had been any
larger (the group had  participants), the interruption caused by the group messages would have not
been acceptable. ‘Swarm’ (Farnham and Keyani ) is only used via text-messaging and supports a
few simple commands for creating groups and adding people to a group (a detailed comparison with
the messaging and usage characteristics of Swarm and Rhub is provided in chapter eight).
For enhanced functionality and to better notify and display group messages, some systems use
specialised client software installed on the mobile device. ‘Slam’ (Counts ) is an example, which
transmits and receives messages over a wireless internet connection, but allows those without
sophisticated phones to participate with plain text messaging.

28
 Reported usage of group messaging systems varies. With Slam,  of group communication was
chat,  coordination. This is quite different from the results of Swarm, mostly used by one large
social group ( members) in which  of messages were coordination,  social bonding. Some of
the variance is likely due to the subjective nature of categorising messages, as well as differences in
group sizes and participant social cohesion. Mobile Social
Software

2.3.4 CROSS-MEDIA COMMUNICATION

Cross-media or cross-channel communication is conversation that can span multiple forms of

mediation, for example, allowing people to communicate between email and SMS. By smoothing over
irregularities between technologies, cross-media systems allow people to select a technology based on
current convenience or suitability, rather than requiring people to use one particular system. For
example, the ‘old-fashioned’ email list was typically interacted with purely using email. You had to use
email to check messages sent to the list and you had to use email to send messages to the list. A
person is out of the conversation for the period in which they do not have email access. If that person’s
input is required, it necessitates a branching side-channel to be established – such as a phone call.
Side-channel communication needs to be reintegrated into the main conversation if everyone is to
benefit. For example, the caller sends an email to the list to provide a summary of the call. Obviously,
the greater number of side-channels required, the greater the effort required to keep the conversation
integrated, and thereby, everyone informed. If a single conversation, however, can be participated in
via a variety of means, it makes it easier for people to be involved.
When contacting someone, a person must select a medium or channel for the interaction. Do I
call? Do I visit them in person? Do I send a text message? There are a number of factors that
determine the choice, such as what technology is at hand, the expected context of the recipient, intent
of the message and so on (see an in-depth discussion in chapter seven). When communicating with a
group, the selection of media is of a magnitude harder because all these factors have to be balanced
across a number of people. Because of the extra effort required to use the best media for each person,
a single media is likely to be used, for example a single mass email or group text message. Cross-media
systems might bridge this gap by selecting media appropriate to each recipient with minimal effort
required on the part of the sender.
Existing cross-media systems have been varied in which mediums they combine, for example, SMS
and the web (Sillence and Baber ). Integration has also been used for practical purposes, such as

29
 having industrial processes send event notifications (Ghini et al. ), or using SMS for pervasive
‘push’ notifications (such as Twitter and Jaiku).

2.4 Technology Adoption & Use

Mobile Social People tend not to be very good at predicting how they will use a new technology, which has
Computing ramifications for design (particularly participatory design) and research. Palen et al. () found in
their study of  first time American mobile phone owners that those with the least exposure to
phones were least able to predict how they’d use them.  of Palen’s participants cite functional
reasons for acquiring a mobile, such as security. They also had strong opinions about how other
people should use the technology, and it was not until they started using it themselves that their
conception of use changed.
Adopting a technology and appropriating it into everyday life is not as straightforward as it might
seem; it is not a matter of merely acquiring it and using it. Silverstone (cited by Ling : )
proposes adoption modelled as a series of negotiations:

Commodification  Imagination  appropriation  objectification  incorporation  conversion

You first have to predict, or imagine how a device is to be used, then how to actually use it, when
to use it, where to use it and who to use it with. Through appropriation, users customise their practice
and the technology itself (Dourish ). When a technology is used publicly or socially it becomes
part of your “face,” (Goffman ) or image, so there are additional factors: ‘what will people think of
me if I use it?’, ‘should I wear it on a belt or hide it away?’, ‘what does this technology say about me?’
Designers of social technologies need to not only consider the end user, but also how other people
(users of the system or otherwise) interact and perceive with the end user individually, or as a group
(Bullen and Bennett ). Carroll also notes that design can take place for appropriation, but also
designers can learn from appropriation (Carroll ). Drawing from Dourish and Carroll, I use
appropriation to refer to the process of ‘meaning making’ which users may go through during
adoption. During appropriation people change their practices and habits, and also tweak, customise
or alter the artefact itself. These changes in both people and artefact can be a valuable resource for
design, perhaps revealing new insights and providing further inspiration.
Brown and Randell () note that people come to dwell with technology rather than simply use
it, with action taking place through technology rather than on it. In other words, flirting using text
messaging is flirting, not merely ‘using text messaging’.

30
 Social technologies often rely on ‘network effects’, in that their effectiveness is governed by the
number of people using the system or the number of people using the system effectively. For these,
there is a motivating factor for groups to establish effective usage norms so everyone may reap higher
benefits themselves. Wielenmann () observed people using two broad forms to negotiate social
use: talk and action. People talked about the way to ‘properly’ use the technology and reflect upon its Conclusion
current use, and reinforced talk through action: ‘properly’ using the device in an observable way.
Reducing the friction of use is important in social systems because of the aforementioned network
effects (Bullen and Bennett ). Grudin () outlines eight challenges in the design of groupware
or CSCW systems which may hinder adoption. These challenges are also salient for social technologies
generally (Table ).

Table . Eight challenges for developers, from Grudin ().

Challenge Response

Disparity between who does the work and who
gets the benefit
Critical mass and the Prisoner’s Dilemma
problems
Social, political and motivational factors
Exception handling in workgroups (software is
often too brittle to handle the work is actually
done as opposed to the way it is supposed to be
done)
Designing for infrequently used features
The underestimated difficulty of evaluating
groupware
The breakdown of intuitive decision-making
Demonstrate application’s collective and indirect benefits, reduce work
required by non-beneficiaries of create benefit for all
Reduce disincentive, increase incentives for use
Avoid the common assumption of a ‘rational’ work environment; work
with representative users
Learn how work is actually done
Infrequently used features should not obstruct more frequently used
features
Longitudinal, qualitative evaluation required
Include actual users in design process

Managing acceptance Introduction to workplace must be careful and measured

2.5 Conclusion
Mobile telephones are clearly a worldwide phenomenon, finding use and meaning in a variety of
cultures, in a variety of ways. Mobiles are generally used for ‘relationship work’ and coordination
mostly through text messaging and voice calls. Ling () argues that mobiles offer a new form of
coordination hitherto impossible using other forms of communication or technology. This
microcoordination is a dynamic, fluid interaction stream that unfolds through mobile

31
 communications and permits frequent and rapid revisions to a plan. Mobile social software, usually
implemented on mobile phones, provides additional functionality for example group messaging or
mobile blogging. These systems often provide features missing from phones, or a ‘mobile’ version of
an internet-based service.
Mobile Social Extensive research on mobile telephone usage has given us a good understanding of how mobiles
Computing
are used and the meaning associated with them. With mobile social software however, there are
significant gaps in knowledge about how such systems are used, or indeed, even what types of systems
are needed. Studies of mobile social software from academia usually either run for a short period, or
have a small number of users. Slam (Counts ), for example was tested for approximately  days
with approximately  participants. Swarm (Farnham and Keyani ), on the other hand, was tested
for over a year but had only approximately  users†. Existing commercial systems have both a large
number of users and have been deployed for a long time, yet remain essentially opaque from a
researcher’s perspective.
It is clear that a long-term study of a mobile social system with a reasonably large number of
participants could provide useful, empirical data that is currently unavailable. Reviewing the mobile
and social computing literature provides a useful insight for designing an initial prototype, suggesting
not only how existing systems are used, but also opportunities for new functionality:
Group messaging. The literature has demonstrated text messaging’s effective, and frequent use
for coordination, even though it offers no specific support for that task. Coordination between more
than two people however is difficult, as replies must be manually distributed to all people and
recipients are never sure if a text message was sent to others, or to whom. Group messaging might
allow people to coordinate amongst a group more effectively.
Presence. Presence information such as status and location can be used as a resource for
coordination. This use is revealed in text messaging studies, for example, Okada () cites data
showing nearly  of people have used SMS for status updates. A potential design could ease the
sharing and setting of presence information, and enable it to be easily shared with friends, and use
meaningful representations of context.
Persistency. Messages have been shown to be meaningful, and are also useful to refer back to,
however handsets often have limited storage capacity for storing received text messages. Furthermore,
for group communication, there is no shared pool of messages; each has to be forwarded to everyone
else.

†
User counts and study period times inferred from published papers

32
 Cross-channel: While mobile use is useful, many people frequently find themselves in front of a
computer at work and home. A computer permits an information-rich display and fast input using a
keyboard and mouse, and increasingly has high-bandwidth access to the internet. Compare that with
most mobile phones that have a very low-resolution screen, limited buttons, slow or non-existent
internet connectivity and typically costs money on a ‘per-use’ basis, such as sending a message or Conclusion

making a call. There are opportunities then for linking various channels, such as text messaging, the
web, instant messaging and so forth to allow users to select that which is most appropriate.
Furthermore, cross-channel messaging could offer easy, quick, reliable and pervasive communication,
by automatically selection appropriate channels, requiring minimal effort on the sender’s part.

In the next chapter, I introduce literature relating to design and development, with a brief interlude on
uncertainty in design.

33
Mobile Social
Computing

34
3 Design Methods

Design and development methods have become increasingly agile and flexible, as limitations with top-
down, heavily stratified processes have been realised. This change has come about due to the
recognition that it is difficult, and in some cases impossible, to create complete plans for a design in
advance of it being engineered. Incompleteness in plans is revealed during the development,
manifested by bugs, reengineering and ongoing changes in specifications. Invariably, initial plans
failed to capture important aspects of a problem and the rigid development process did not allow
required revisions to be integrated during development.
The following survey encompasses three major themes: plan-driven development, goal-driven
development and user-centred design along with an interlude on uncertainty in design. I focus on
systems design and development, however there is an overlap with other fields of design, such as
industrial design. The first two themes have slight project management bias however all three themes
address how to progress from a problem to a solution. User-centred design could be thought of as an
ancillary process to either plan or goal-driven projects; however, my position is that user-centred
design is best placed within goal-driven development. This survey does not attempt to be exhaustive.
The field of systems development and user-centred design is vast and here I only scratch the surface.

3.1 Plan-Driven Strategies

Early software development (-) was performed without formal methods. Projects were small,
in terms of both the number of contributing engineers and the scope of the work. As computational
power increased, so too did the project size as ever-more complex problems were attempted. With the
complexity came problems: late project completion and budget-overruns; poorly performing and
crash-prone systems; and in some cases systems even injured people (S. Garfinkel ). A “software
crisis” was declared (Naur and Randell ), and efforts were made across the burgeoning field to
develop the methods, tools and systems required to create quality systems which met system
requirements. One of the models developed was Royce’s “waterfall” (), which dates from the
sixties and is still popular today (Laplante and Neill ). As its name would suggest, the process
consists of a series of steps, with the output leading into the next as an input. Other concrete methods

35
 have a waterfall style, such as the Systems Development Life Cycle. The waterfall process is typified by
its sequential flow, with planning and specifications produced early in the process before any
engineering is undertaken.
Plan-driven methods emphasise ‘big design up front,’ with a design produced first, along with a
Design Methods plan for production. The process continues by following the plan until completion. Difficulty occurs
however when changes in the design are required either by requirement omission, a client’s desire, or
because unexpected problems were encountered during development. Changes in prior ‘completed’
stages cannot be rationalised in the method without incurring project delays as subsequent steps are
revisited. The benefits of having a predetermined, holistic, canonical design are negated when changes
are made to what was supposed to be a concrete specification, or worse, when development diverges
from the specification.

3.2 Interlude: Dealing with Uncertainty in Design

The s and s are popularly known as decades of optimism in science and technology - after all,
this period had given society nuclear energy, the space age and domestic appliances. However, there
also arose a realisation that complex problems were not necessarily yielding to the advanced
technology of the era. To put it plainly, things do not always go to plan and complex problems are
difficult to solve. A gradual understanding and respect for complexity has emerged during this period
and continues to develop today. Such complex problems were termed “wicked problems” by Rittel and
Webber () in the early seventies (see Conklin  for a recent review). Wicked problems are
those that defy naïve analysis or understanding. They are dynamic: they change their shape, structure
and requirements and no definite solution can be reached for them, only one that is ‘good enough.’ It
is through attempting to design a solution that a problem reveals its wicked nature, and in doing so
may invalidate an existing design, indeed Rittel and Webber go so far as to suggest that a problem is
not understood until after a solution has been developed. Through its investigating and teasing apart,
a designer might better understand a wicked problem. Software engineering is an empirical, as
opposed to a defined process (Williams and Cockburn ). Defined processes, like building an
automobile, are those that, when followed directly will produce an expected result, consistently.
Empirical processes however do not produce consistent results, and the steps themselves change
during the course of production. While not all problems in system design can be characterised as
wicked, many do have wicked characteristics.
Situated action (Blumer b; Suchman ) derives from the philosophical lineage of
ethnomethodology, symbolic interactionism, phenomenology and activity theory. Suchman’s theory

36
of situated action builds upon symbolic interaction, suggesting that problems are normally
approached goal-first, rather than plan-first, with intermediate action being determined by the
prevailing context. Goals themselves might also change during action as conditions change. Plans,
according to this theory, are merely “a weak resource for what is primarily an ad-hoc activity”
(Suchman :). In other words, people’s action is dependent on the social and environmental Goal-Driven
Strategies
context in which it carried out. Understanding action requires understanding the context, and to
understand the context, one needs to understand the action. ‘Understand’ here is not meant in a
quantifiable, scientific sense; rather an understanding is approached in the same way the solution to a
wicked problem is approached. Situated cognition, a movement within cognitive psychology, tells us
that learning is best achieved when a pupil’s prior experiences and cultural framework are harnessed,
and that there is much merit in learning through doing.
Both situated action and situated cognition would indicate that design through experimentation
(learning from doing) and reflective, iterative design without rigid plans (allowing natural situated
action to take place) might be useful for both understanding a problem space and for implementing a
solution. Methods which recognise that uncertainty may (and probably will) arise during development
and can harness this change positively would seem more effective than methods which ignore it.
Schön’s () description of reflective design practice demonstrates how the designer can engage
with a problem by making design moves and listening to the back-talk of the design to inform further
responses.

3.3 Goal-Driven Strategies

Goal-driven methods differ from plan-driven in that they emphasise the final result – a working
system – over fastidious specifications, documents or progress along a predefined plan.
Contemporary goal-driven, rapid iterative design methods sprung from early iterative methods. While
in use since the mid-s (Larman and Basili ) iterative development processes have not
properly been described, generalised and formalised until recently.
Development methodologies progressed with practical experience. In the mid-seventies Brooks
() suggested building a prototype†, a pilot system which is intended to being thrown away after
development, or at the very least substantially rebuilt. Developing a rough prototype can help flesh
out the problem space, and as it was intended to be discarded, the focus of the design can be

†
It is worth noting that Royce originally suggested (:) two iterations of the design, however
this suggestion was largely lost on practitioners.

37
 exploratory as opposed to making a solid, quality end design. The spiral model (Boehm ) was an
early form of iterative development, where a final design emerges after a series of iterations. Each
period of iteration ends with a roughly functional design which is then critiqued. Requirements and
specifications for the next iteration stage are identified and work commences on a new prototype, or a
Design Methods revised version of the existing design. When a satisfactory prototype has been built (according to the
client or other appropriate stakeholder), the final implementation can take place either by completing
the prototype, or by developing a fresh system. Unlike the sequential model, which fixes requirements
early in the process, iterative processes allow requirements to emerge as both the design team and the
client reach an understanding of what is required. Further advantages are that as problems (invariably)
arise, they can be dealt with in a measured manner and estimates for the final cost and time required
become more accurate as they are revised with each iteration. The time period for each iteration
varies with particular iterative methods, ranging from years to hours.

3.3.1 ITERATIVE METHODS

From the mid-s a series of rapid iterative software development methods were developed and in
, a group of supporters met and decided on the term “agile methods” for the family of methods.
They also outlined a manifesto for agile software development (Beck et al. ). Agile methods are
goal-driven: delivering a functional design is more important than following a plan. Not all iterative
methods share this characteristic - some may be seem to be just as plan-driven as most sequential
methods.
Two popular methods developed in this period are Scrum (Schwaber and Beedle ) and
Extreme Programming (Beck ). Scrum involves creating a “backlog” of to-do work units,
implementing the work units within an iteration (“sprint” in Scrum parlance), daily meetings to
discuss ongoing work (“scrums”), planning sessions to determine the backlog for the next iteration
and finally a reflective period after each iteration. Extreme Programming (XP) consists of four
activities: programming, testing, design and listening. Programming is emphasised over
documentation and design: XP’s philosophy is that it is better to have something running and working
instead of having extensive design or architectural documents. Testing takes the form of unit tests,
routines that test small segments of code (such as an individual function, or class) and are run
automatically over an entire code base. Unit test code is written before the actual implementation
code. Design plays a role within XP, and is the activity through which refactoring occurs, where
portions of the code are re-architected to allow for better performance or extensibility. Finally, the

38
listening stage advocates respecting the customer and their domain knowledge. XP defines
requirements using prioritised “user story cards” (similarly to Scrum’s work units) with specifications
described from the user perspective using scenarios or simple examples instead of formal
requirements.
Rapid iterative design methods often go beyond a pure iterative process in that they require User-Centred &
Participatory
specific work practices to be conducted, such as writing test code before implementation and
Design
programming in pairs for extreme programming. Primary criticisms of rapid iterative methods are
that quality of design is not emphasised, documentation is neglected, significant cultural change is
required and that fluid requirements require ongoing negotiations with the client.
Iterative processes has been successfully applied to interface design (Buxton and Sniderman ;
Nielsen ), yet does not necessarily require an iterative development method. Nielsen ()
reports iterative user interface design can be effective after only three iterations. Changes in the
interface trigger reflection, “reconceptualising,” which may cause a drop in usability as the new
interface’s paradigm and design is grasped but may lead to higher performance later.
As Tohidi et al. (b) note however, it is important to get the right design before trying to get the
design right. In other words, once embarked on an iterative process with a particular design, there will
be limited opportunity for a radical redesign, only the gradual improvement of the chosen design.

3.4 User-Centred & Participatory Design

Design, especially within an organisational context, can involve many different stakeholders, and each
may be affected differently by the resulting design. The holders of power, such as management,
obviously exert an influence over the design process, and as such, design may be skewed towards their
needs as opposed to the needs of users. In many organisations, the end-user may have the least power
of all, yet will be most directly affected by the design. For example, consider the design of a point of
sale interface and the relative power between two stakeholders: the supermarket store manager and
the checkout clerk end-user. User-Centred Design’s (UCD) primary aim is the production of a usable
and useful design, as informed by actual users (Sharp et al. ). Participatory Design (PD) has the
same overarching goals however with significantly different philosophies and methods.
The general UCD approach taken is for a system’s end-users to be the priority for the design, rather
other stakeholders that are not actual end-users of the system. UCD also recognises that practice is
often different from procedure. An organisation may have a set of procedures for a particular process,
but the actual practice by employees may be different. End users are those who are experienced in
carrying out the practice and therefore best placed to share it. For example, a UCD approach to

39
 designing a bank teller user interface might prefer to involve tellers over bank managers, because
tellers are the individuals who are most acutely aware about practice. Other stakeholders may have
input into a design, however greater importance is placed on the user’s needs. Historically, the
approach has been the reverse, with upper management determining design based on business
Design Methods requirements instead of user requirements. Often the end results were designs that fulfilled their
business role but were disliked by users because of poor usability, which can lead to outright rejection
or creative ‘workarounds’ by users (Grudin ).
Participatory design (PD) has its basis in the Scandinavian Collective Resource approach of the
s (Bjerknes and Bratteteig ) and advances UCD primarily by further integrating potential
users of a system into the design process. The philosophy behind PD is much akin to Participatory
Action Research (PAR), a reflective, iterative research process from the s (Whyte ). Both share
a Wittgensteinian view of meaning in action, rather than language (see §..). The user-designer
dialogue in PD is bidirectional instead of unidirectional: users as co-designers instead of mere sources
of information, akin to PAR:

“participants are truly co-researchers whose insider ‘local knowledge’ is as necessary for valid scientific
sense-making as the outsider researchers’ technical expertise and abstract general knowledge.”
(Elder and Chrisholm : -, cited by Bartunek )

PD is seen as a method to promote workplace democracy, by allowing workers to have influence over
their work practices. Early research resultantly leveraged trade unions as key players (Ehn ). It is
not, however, a matter of course that workplace democracy follows the use or deployment of a PD-
originated system. Bjerknes and Bratteteig () point out that an early archetypal PD-originated
system (a desktop graphic compositor) would have only reinforced the role of female typists within
the production of a publication, rather than liberation to more creative, interesting work.
Participatory Design has been more broadly characterised as an ethical stance that commits the
designer to engage with intended users from the outset in order to ensure that the design prioritises
the agency and quality of experience of its intended users (Robertson and Brereton , personal
communication).
As users are not design practitioners, PD often uses practical, engaging exercises and games as part
of the dialogue with users. For example, by employing props and prototypes (of varying fidelity), users
can express their knowledge naturally through use: ‘design-by-doing.’ Furthermore, PD takes a more
holistic, ethnological view of design by including social context, physical context and work practice as

40
important aspects of a problem space. People’s comfort and enjoyment of the system is also respected
in PD, for example designing to allowing people to exercise creativity and expression.
There are other kinds of design frameworks for example those that strive for human
empowerment and relevance (Oulasvirta ), reflection (Sengers et al. ), morals (Friedman
) and play and discovery (W. W. Gaver et al. ). Rather than being cohesive systems, these User-Centred &
Participatory
could be considered perspectives to bring to particular problems when necessary. It would not be
Design
possible or desirous to create an über method that encompasses all such design perspectives, for the
design would be fragmented, and in any case there is often some merit in designing with a restricted
palette.
Many UCD methods are derived from ethnographic fieldwork practices. Ethnography is a practice
for studying people and culture that has its roots in anthropology. Ethnographic studies consist of a
variety of types of fieldwork leading to rich understandings and rich descriptions. Designers have
found this kind of work useful to inform design and various practices and methods from ethnography
have been adopted by designers in order to undertake User Centred Design. By comparison, methods
from cognitive science have focussed on aspects of interaction and thought related to individuals,
largely ignoring the wider social and physical context that the interaction is situated in. Early
application of ethnography in systems design has been to understand and describe the sociality of
work (Hughes et al. ) which has lead to broader application for gaining rich understandings of
situated action. Ball and Ormerod () make a distinction between ‘pure’ ethnography and ‘applied
ethnography’. Pure ethnography comes from the anthropological and social research tradition, and
seeks to describe a particular context in a manner that is as impartial and external as possible. Applied
ethnography has the ethos of pure ethnographic yet is purposeful, for example conducted with
particular design intent such as looking for opportunities for technology mediation. It also tends to
produce data more readily consumable by designers and developers, often summed up in a final
‘implications for design’ section which lists actionable ‘ethno-requirements’. Button () suggests
that such ethnography, what he terms “scenic fieldwork,” is often lacking insight as to how people do
what they do, instead describing what it is that people do. How data from an ethnographic field study
can be appropriately used for design is something that practitioners often grapple with (Dourish
).
UCD methods emphasise design that is user-focussed, however they place limits on the user’s
involvement in the actual design work. UCD deems that a user, whilst an expert in their own domain
and a valuable source of knowledge, is not a designer or necessarily skilled in designerly practice and
therefore limits their engagement in the design. Indeed, users within a UCD process might be more

41
 successful in identifying usability flaws in a presented design rather than proposing new ideas (Tohidi
et al. b). PD however, reflecting its social democratic origins, treats the user an equal member of
the design team, and uses methods to actively engage the participants. Concisely, PD is about
participation (part of or sharing of something) and UCD is about involvement (implicated, entangled,
Design Methods engaged).

3.5 Conclusion
Understanding the nature of the problem can itself be difficult, Schön () claims that design is
essentially about solving wicked problems and that designers spend much of their time grappling with
the meaning of the problem. Creating usable and useful designs require a rich, holistic understanding
of people’s context, practice and desires. Such understanding is not trivial, reachable through simple
questions. Understanding develops through an ongoing dialogue and negotiation between designer
and user, with both parties attaining increasingly accurate representations of the problem space. User-
centred design reframes design problems as wicked problems: no solution is necessarily ‘correct’ -
only good enough - and understanding is reached through the exploration, reflection and designing.
Naïve application of methods does not necessarily result in success; for example, a participatory
design might focus on one user’s problem at the expense of others outside of the design scope. Ackoff,
cited by Ehn (), states that PD requires three conditions to be successful: ) it makes a difference
for the participants, ) implementation of the results is likely, and ) it is fun. Unless participants are
engaged in the process, representations developed will be shallow or outright wrong.
Goal-driven development strategies, such as agile development, are similar to how people
naturally approach problems: by focussing on arriving at the goal rather than following a prescribed
sequence of steps. While uncertainty present in the design of wicked problems cannot be tamed
entirely, a goal-driven method offers the possibility for development to evolve with the understanding
of the problem.
In the next chapter, I move from design and development methods to research methodologies. In
it, I make a case for the use of an exploratory prototype as method for studying mobile social software.

42
4 R e s e a r c h M e t h o d o l o gy

Understanding the mobile social context

This chapter outlines the methodological approach taken to address the general research goals† of
exploring how to support informal social group communication, coordination and sharing. Because of
the mobile, social context of the study, I took an Action Research-inspired approach, which uses
iterative cycles of planning, action, observation and evaluation, and its use is well established for
studying social phenomena. There is some discussion as to whether there is a true dichotomy between
qualitative and quantitative research (Blumer a; Hammersley ); for this work a dual approach
was preferred. Qualitative methods are often used when the topic under study is unexplored and there
is still some question as to exactly what the researcher could or should measure. Once the researcher
starts to understand the topic sufficiently, she might devise and run quantitative studies to provide
establish the generalisability of the observations, for example. Qualitative methods are useful in the
research of human and social concerns, where often quantification is not helpful, yet a rich descriptive
qualitative account can yield penetrating insight. As quantitative methods can be a support for
qualitative methods, the reverse can also be true, for example a qualitative study might be used to
explore the reasoning and meaning behind data gathered in a quantitative fashion.
Methodologies for understanding human computer interaction in the mobile context (Mobile HCI)
are an ongoing subject of research. Existing methods were designed to study relatively fixed contexts
of use, particularly with regard to location. Mobile use however is dynamic and fluid, and usage of
mobile technologies cuts across traditional boundaries of context and location.
This section discusses the merits and challenges of developing a large-scale, long-term, widely
deployed prototype. I characterise this type of deployed prototype an ‘exploratory prototype,’ and
relate it to existing literature and discuss its implications. As part of the discussion, the philosophical
position of this work is stated, and I introduce and discuss action research and issues relating to
mobile research.

†
See introduction chapter for research aims in full

43
 4.1 Background

4.1.1 PHILOSOPHICAL POSITION

“If we had to name anything which is the life of the sign, we should say that it was its use”
Research
Methodology (Wittgenstein, The Blue Book, , cited by Biletzki and Matar )

For the reader’s interest (and forewarning), I thought it prudent to state the philosophical tradition
and perspective of this work, however further inquiry is beyond the scope of this work. The central
philosophical alignment of this work is that of Wittgenstein, in his Philosophical Investigations (),
and mostly particularly the suggestion that meaning is evident through action. A number of aspects of
his philosophy, particularly with respect to meaning, understanding and the fundamentally social
nature of language can also be found in Vygotsky’s activity theory, symbolic interaction and situated
action. These in turn inform the practical approaches of ethnomethodology, participatory design,
action research and user-centred design.
Symbolic interactionism, developed by Mead, and later clarified and expounded by Blumer, posits
action mediated through meaning, and meaning shaped through action and reflection. For social
interaction (where symbolic interaction is typically applied), behaviour is not “an outward flow or
expression of forces playing on them” (Blumer b), rather that behaviour results in people’s
interpretation of the situation in which they are placed. Blumer identifies three premises for symbolic
interactionism:

. Human beings act towards things on the basis of the meanings the things have for them.
. The meaning of such things is derived from, or arises out of, the social interaction that one has with
one’s fellows
. These meanings are handled in, and modified through, an interpretive process used by the person in
dealing with the things he encounters
(Blumer : )

Given the difficulties encountered in studying mobile social groups identified in the literature, I found
it helpful to articulate a broader philosophical frame to inform the research approach. This approach
which was one of exploratory design inquiry, expanded upon in §.. and §..

44
4.1.2 ACTION RESEARCH

Action research (AR) theory originates from Lewin (), originally applied to sociological scenarios,
but also applied extensively to organisational contexts. AR is an iterative process, applying cycles of
planning, action, observation and evaluation (Figure ). AR is frequently used in understanding and
Background
making positive change in social phenomena, for example in communities, classrooms or enterprises.
Reflection is a critical part of AR, and is applied to the objects of study, methods used as well as the
researcher themselves. AR not only produces research outcomes, but acts upon the researcher.
Additionally, AR acknowledges the interventionalist role of the researcher: that the researcher is to
some extent embedded in the phenomena under study, and not the theoretical impartial, external
observer ideal of the natural sciences. From a critical perspective, AR has elements of risk, and internal
politics may hamper the democratising nature of the method (Greenwood ).

Figure . Action Research cycle, with one iteration outlined.

Participatory action research (PAR) (Whyte ), builds upon AR and found early use and success
in Norway in the late s during a series of Scandinavia-wide industrial democracy projects (Whyte
). PAR varies from action research in that the group under study participates as action researchers
themselves. Rather than action research being applied to them, action research is a process that the
participants and the researcher carry out, similarly to participatory design. Participants might not
only benefit from the research outcomes, but may also share in the benefits that arise from the
reflective practice:

“Accordingly, participatory action research involves people in theorizing about their practices – being
inquisitive about circumstances, action, and consequences and coming to understand the relationships
between circumstance, actions, and consequences in their own lives”
(McTaggart : , original emphasis)

45
 AR has been successfully used in the context of information systems for many decades (Checkland
and Scholes ), and more broadly used for workplace and systems designs and teaching methods
(McTaggart ; Rasmussen ; Whyte ). Similar reflective iterative practices have also been
used by Bellotti and Smith () and there are many similarities in the motivations and methods
Research between action research and participatory design (§).
Methodology

4.2 The Mobile Context

Studying usage of personal mobile technology is problematic for two main reasons (which may be
guessed from its adjectives): mobility and privacy. People often use personal mobile technology on an
ad-hoc basis, wherever they may be, and also use the device to store personal information. Non-
personal mobile technology, for example a portable barcode scanner used by a grocery store clerk,
presents slightly less difficulty to study because its use is restricted by the workplace context. You
would not find a clerk using the scanner outside of work hours or the grocery store itself and because
the scanner is one of an anonymous pool of scanners, it is not personalised nor does it hold personal
information.
Traditional usability methods, such as observation, contextual interviews or lab-based testing are
usually applied within limited physical contexts, such as a desk, office, workplace or home, whereas
mobile technologies can be in or in-between these spaces and others. Additionally, usage of a mobile
device, such as a PDA or mobile phone, crosses contextual boundaries. A bank teller uses their
specially designed system when they are actively working, and never on the way to work or at home:
the use of the artefact is constrained by the work context. Devices designed for other scenarios such as
play, such as a portable games system are likewise constrained as to how and where they are used, yet
to a lesser degree. Mobile telephones and PDAs, I believe are special in that their use is not dependant
on particular contexts. A mobile telephone at work might be used to talk to a client or order work
supplies, but it can equally be used to flirt with a lover or chat with a friend. The same could be said
for a workplace computer; however, its fixed location does not offer the variety of use contexts of a
mobile phone.
Privacy is another concern. Mobiles typically store records of incoming and outgoing calls, contact
information and text messages. Phones that are more sophisticated may also record email,
photographs taken, sent or received and video clips. As such, the researcher is unlikely to have
complete and unfettered access to mobiles, and need alternative techniques of getting data.
Tamminen et al.’s () ethnographic study of  Helsinki residents travelling around the city
provides some insight into mobile context. Random situational acts often occurred within planned

46
ones, such as chancing upon an interesting shop on the way to visit a friend for coffee. People used
“social solutions” to navigation problems, for example phoning a friend to enquire about busses, even
though they had a timetable in hand. Temporal tensions were evident, in that time appeared to slow
when waiting or speed up when several tasks were being juggled. These examples highlight the fluid,
dynamic nature of the mobile context, which suggest that not only are adaptive systems required as The Mobile
Context
design solutions, but the design, research and development methods themselves must be adaptive.

4.2.1 MOBILE HCI METHODS

Research methods used for typical desktop-orientated systems are limited in their application to
mobile systems. Mobile devices are ‘in’ the wider physical world to a greater extent than systems
typically studied in computer science. As a reaction, researchers are increasingly appropriating
methods such as ethnography from the social sciences to make sense of the mobile world as well as
mobilising data gathering, such as using body-mounted sensors and cameras (Mark et al. ).
Hagen et al. () surveyed mobile research papers’ methods and organised them into three main
approaches: mediated data collection, simulations and enactments or multi-method approaches.
Mediated data collection relies on the self-reporting of usage data (such as dictating selected SMSes to
the researcher or diary studies) or the device itself gathering data from use. Simulations and
enactments tended to be in a laboratory environment, with researchers employing various means to
recreate usage scenarios. In some respects methods such as technology probes (Hutchinson et al.
) - which have been adapted to the mobile context (Hulkko et al. ) – are multi-method
approaches as they often employ a technological artefact in conjunction with quantitative logged data
and qualitative contextual interview data.
Several widely used methods seemed unsuitable for use in this research because of the focus on
group social use of mobile technologies which is largely ad-hoc and opportunistic. For example
shadowing a subject around might provide information on their ‘everyday’† life however might not
reveal anything about how they communicate with their social group if nothing happens that day.
Social use of technology typically happens in snatches of time within a person’s frame of activity, such
as work. It would appear that when socialising becomes the sole frame of activity, the role of
technology is diminished – at this point people are face to face, and there is little need for technology.

†
The presence of a stalking researcher for a day might suggest a less than ‘everyday’ day.

47
 At the time of writing, research into mobile HCI methods is still early in its ascendance, and there is
ongoing work to develop or adapt methods to this unique context.

4.2.2 EXPLORATORY INQUIRY

Research
"For symbolic interactionism the nature of the empirical social world is to be discovered, to be dug out
Methodology
by a direct, careful, and probing examinations of that world." (Blumer : )

When the researcher has a symbolic interactionist view of social interaction, exploratory inquiry is a
natural choice of method. Exploratory inquiries begin with a broad scope and progressively narrow
during its course, using a small number of well-informed direct, active, participants. Blumer explains
the process as:

"Exploration is by definition a flexible procedure in which the scholar shifts from one to another line of
inquiry, adopts new points of observation as his study progresses, moves in new directions previously
un-thought of, and changes his recognition of what are relevant data as he acquires more information
and better understanding" (Blumer : )

Exploratory inquiry has also been suggested as a method for approaching “wicked” problems (§.)
and complex design generally as part of a reflective process (Schön ).
Because action (from a symbolic interactionism viewpoint) has its basis in the interpreted
meaning of objects, the key to understanding action is understanding meaning. It can also be said that
people’s meaning for action becomes buried, so much a part of everyday, that it ceases to be readily
available for recall or reflection. Breaching experiments (H. Garfinkel ) are an example
exploratory inquiry which seeks to force participants to call into question their everyday assumptions,
and reflect upon meaning they hold of objects and action. Reflective Design (Sengers et al. ), a
series of strategies that aims to encourage reflective use on the part of users, also advocates using
prototypes for exploratory inquiries, likening them to a social scientist’s experiments.

4.3 Rhub: an Exploratory Prototype

"Let's do smart things with stupid technology today, rather than wait and do stupid things with smart
technology tomorrow" (Bill Buxton, September , cited by Ishii and Miyake : )

The deployment of a working prototype that participants can use for actual socialising would seem a
useful approach. It can be approached as an exploratory inquiry – sketching functionality, seeing how

48
people use it, and ‘digging deeper’ by soliciting feedback or by refining the design further. If meaning
is evident by use, then how the prototype is used and appropriated into a group might reveal not only
insights into its functionality and usability, but also how people considered it. A long-term
deployment, with a large number of participants would help to bolster the generalisability of findings,
and would provide the time scope necessary to ‘capture’ ad-hoc situations, events and uses that arise. Rhub: an
Exploratory
While a “continuously usable prototype” (Bellotti et al. ) has the benefit of being subjected to
Prototype
user scrutiny for a longer period of time, it may be less innovative than mock-ups or low-fidelity
prototypes because of its requirement to be functional during the duration of its deployment (ibid.)

4.3.1 PROTOTYPE OR PROBE

Technology probes as defined by Hutchinson et al. () are designed primarily for data gathering,
are open in their use, have limited functionality and are thrown away after the data gathering period
while prototypes tend to have more extensive features and be more useful. This definition is quite
different however from the more common usage of ‘probe’ in design literature which relates to Gaver’s
() cultural probes. Gaver’s probes are designed for gathering inspiration for design, rather than
data to support design, which is of a vastly different character and form.
The experimentation platform, Rhub, has the characteristics of both prototypes and probes and as
such is difficult to categorise exclusively into this dichotomy. As a platform, it offers some features
which are developed and useful (prototype-ish), and others that are more ‘sketchy:’ introductions of
features to see how they might be used and to inform further design (probe-ish). It is worth noting
that some research employs cultural or technology probes in a manner different to how the early
authors defined them. For example, many technology probes are not simply used for gathering data,
but also serve to inspire design ideas, and may be kept running for a long period.
Empirical studies show that there is little difference in the performance of low or high-fidelity
prototypes for identifying usability errors (Virzi et al. ; Walker et al. ), with low-fidelity,
paper-based prototypes having the advantage of being cheap, quick and easy to make (Arnowitz et al.
). The nature of feedback reflects the level of fidelity of a design. A rough sketch of a piece of
furniture is less likely to elicit comments on the type of finish than a textured, D render, but it may be
more likely to elicit comments on the general form of the piece. At the same time however, there must
be enough richness in the design in order for it to resonate meaningfully with participants (Buur and
Binder ). Fidelity within a prototype need not be universal, for example the visual design of a
prototype might be highly developed and resultantly only attract a small amount of specific feedback.

49
 Elements of the functional design however may be roughly ‘sketched’ using quick programming
methods to introduce some form of functionality but might suffer from poor usability or sub-optimal
implementation. Here, in these roughly-hewn elements of the design, there is still ample opportunity
for feedback.
Research
Methodology 4.3.2 IN THE WILD

It is hard to investigate usage of a system that does not yet exist, and here prototypes and probes are
useful. Crabtree () promotes deploying a system ‘in the wild’ as a means to explore usage where
there is no prior practice to draw upon. He suggests such deployment is similar in spirit to Garfinkel’s
() breaching experiments, however I would suggest that Garfinkel’s experiments emphasise
exposing and calling into question existing, well-established behaviours rather than discovering
possibly overlooked or emergent behaviours in a new context. In any case, ‘real world’ deployment out
of the laboratory has a number of benefits, most importantly being that the use and context of use are
authentic.
Laboratory deployments typically involve a small number of participants and in many cases, the
participant pool consists mostly of academic colleagues or students who may have differing needs and
usage habits than the broader population. In the laboratory, studies can be closely monitored, often
using prepared equipment and scenarios, and can focus on a narrow aspect of use. There is less
potential for emergent or reactive practice, and participants do not have the full freedom to explore
the system themselves. Additionally, the scenario and wider physical and social context in which use
takes place is artificial, which has ramifications for the study’s validity. Exploration requires time and
space, neither of which is well afforded by a laboratory study. Laboratory studies are particularly
limiting for mobile technologies where the mobile, ad-hoc, on-demand usage is highly prominent.
When released from the confines of the laboratory, the ability of the researchers to control
experimental variables is hampered, in turn limiting the kinds of assertions that can be made from
quantitative results. Real world studies however allow the researcher to study the situated action
aspect of authentic use as well as the authentic social context, which can lead to a richer, more valid
understanding.

4.3.3 NETWORK EFFECTS

It can be difficult to investigate a social system without other people actually using it. Unlike single-
user systems, or experiments involving narrow aspects of a system, a social system encompasses not

50
only the prototype and a user, but potentially also that user’s friends, their friends and so on (see
discussion in §). Thus, the true ‘use’ of the system does not occur when a single person makes use of
it, rather when they use it with other people. In a similar manner, it would be difficult to understand
how telephones might be used for coordination before telephones had a widespread deployment.
A user’s prior experience with similar social systems can leveraged in the investigation of new Rhub: an
Exploratory
designs, for example by boot-strapping the user’s learning process, however the meaning a user has
Prototype
for one system is not directly transferrable to another. Users’ meaning for a system naturally varies
from user to user and system to system. Each system has its own set of behaviours; norms and culture
(see Danah Boyd’s writings on the appropriation of web-based social systems) and each user has their
own experience, culture and personality that all play a part in how the user interprets the system. On
one social system, adding someone as a contact may seem relatively worthless, while on another
system, it might seem an honour.
Because of user’s deeply-imbued meaning present in social systems, and that true ‘use’ only
emerges when several people are using it, an exploratory prototype can be useful. With a longitudinal
deployment, there is the opportunity for people to invite their friends to use the system, and social use
can take place naturally.

4.3.4 EXPERIMENTAL PLATFORM

Rather than running discreet studies for different prototypes, it is my aim to introduce an
experimental platform on which individual prototypes may be tested. Through the one platform, any
number of mobile social prototypes could be deployed, for example a prototype presence notifier, or
public display of group-related information. The platform provides a layer of services that enable such
prototypes to be easily built, and because the platform runs on an ongoing basis, can take advantage
of accumulated data and social networking activities within it.
This will aid the research in several ways. Firstly, there are overlaps in functionality between
prototypes so engineering effort can be reduced. Secondly, users introduced to one prototype can
seamlessly use others with zero (or minimal) extra effort required on their part. To run individual
studies might require users to re-establish themselves and their friends in the technology-supported
social network. Additionally, presenting prototypes within a cohesive whole reduces the novelty effect
and may aid usability.

51
 4.3.5 PARTICIPANT-USERS

Motivations for users to be participant-users, and actively participate in feedback processes vary. In
social research, some kind of tangible reward is typically offered, such as monetary compensation,
prizes or in the common case of undergraduate psychology students, passing grades. However
Research
Methodology because any reward affects participation it is important not to induce participation using methods
that are not intrinsic to the use of the system and that are not sustainable.
With the exploratory prototype, I suggest that usage is the reward to participate. In other words,
the benefit people gain by using the prototype should be enough incentive for them to not only
continue using the system after an introductory period, but to also participate in research. This view is
similar to the “make it work first” priority of agile development methods, which seek to deliver
functionality over specifications. The exploratory prototype however seeks to deliver utility over pure
functionality. Simple designs might have minimal functionality, yet offer a large amount of utility, so
the single-minded pursuit of functionality is well intentioned but ultimately short-sighted.

4.3.6 RE-USING MUNDANE TECHNOLOGIES

To increase the potential participant pool it was important to use everyday technologies, such as
mobile phones, email, instant messaging and the web. A mobile device, such as a mobile phone is
required to support mobile usage of the prototype, important as socialising happens without regard to
common boundaries of space, time or context. Naturally, designs that are more sophisticated could be
tested using small portable devices with in-built high-speed wireless data technologies, cameras, GPS
(Global Positioning System) receiver, biometric sensors and so forth. There are several problems with
this approach:
. There would be a significant cost with distributing such devices to a large pool of participants.
. Devices would likely only be available to participants for a short period, and thus longer-term
usage data could not be gathered.
. Phones are personal devices (see literature survey in chapter ) and are usually well integrated
into a person’s life. Witness the customization of screens, chassis, lanyards, ring tones and so
forth. Giving a participant a new phone will require time for reintegration and since the phone
will only be used for a short period of time the person might choose not to integrate it at all,
and it becomes a secondary phone used only for the research.
. New devices would require participants to learn and adapt to a new system.

52
 . ‘Client-side’ applications require configuration and maintenance, and requires development for
different handset platforms.
“Everyday” common phones are becoming more sophisticated, however broadly speaking the lowest
common denominator is a phone that is capable of making and receiving voice calls, sending and
receiving text messages and managing contacts, and not capable of running custom client Conclusion
applications.
There are also benefits from re-using other software-based mundane technologies, such as instant
messaging and email. For these, people already have established work practices and habits. People
already have client software installed and have likely configured it to automatically connect and notify
them when new messages are received. To provide similar functionality, yet use custom software,
would require the participant to download, maintain, configure and continuously run the software.

4.4 Conclusion
Meaning, according to Wittgenstein is evident in action - meaning as use - so to understand meaning
and design appropriately, methods must be participatory, exploratory, and agile. Participatory so that
design represents actual practice and knowledge rather than procedure. Exploratory permits and
encourages meaning to arise in the user and researcher during design, instead of imagining that
meaning is fixed and easily quantifiable. Agile so that development processes can be reactive during
exploration and still produce a deliverable design.
Rhub, the exploratory prototype, introduced in the next chapter, meets these criteria and offers
additional benefits for the particular domain under study: how social groups use technology to
communicate, coordinate and share. When face-to-face, technology is seldom needed, however it can
play a useful role in the maintenance of social ties within a group when members are apart and also to
coordinate future events. This type of use is typically ad-hoc and opportunistic, and happens within
another primary activity: for example, whilst at work, emailing friends to organise a weekend
barbeque. Because of this ad-hoc nature, it is difficult to study social interaction under naturalistic
conditions using some methods; a longitudinal deployment however is well suited for this task. Whilst
low-fidelity prototypes are useful in the design process, and are quick and easy to make, the prototype
needs to be sufficiently rich so that people can use it to meet real needs.
The general approach taken in this work is informed by action research theory. While
participatory action research may have been beneficial, due to the context in which the research was
carried out, I could not demand the level of participation from subjects required for a complete PAR
approach, nor was I sufficiently embedded in their context to be a participant in the more traditional

53
 sense. Other researchers and practitioners have also adapted participatory design methods for
pragmatic reasons, yet like this work, still maintain the PD ethos. To allow as many participants as
possible to use the prototype, it was built upon commonly used and available technologies. This
permits the prototype to be used for a long period and people can use their own devices and
Research applications with which they are familiar. In turn, this reduces the level of technical understanding or
Methodology
knowledge required for participation and thus broadens the variety of participants. Utilising everyday
technologies also allows for a longitudinal deployment, and therefore provides useful information
about usage over time.
In the next chapter, I outline the form and function of the Rhub, the exploratory prototype
developed as part of the inquiry into the mobile social software domain.

54
5 Rhub

Design, functionality and implementation

5.1 Introduction
Rhub is the prototype developed to explore the research questions this thesis seeks to answer. A
website is its most visually prominent aspect, and the focus for design and implementation as it is the
basis for most of the features. The console was developed to support interaction with the system
across a variety of systems, such as text messaging, instant messaging and email. Messaging between
people is supported in a number of different forms, and the prototype has the ability to push messages
to people, so they do not need to be checked for manually. To support context-orientated
coordination and communication, Rhub also supports the sharing or expression of context
information such as location and status. Many parts of Rhub’s functionality are supported through
users’ contribution of locations, tags, photographs and bookmarks, which people can create, edit,
search and browse. The website was developed in PHP and works in concert with a C# component that
handles the dispatching of messages and handling of console input.
This chapter introduces the design, functionality and implementation of the prototype, Rhub. It is
a reference chapter, and I hope to provide background and technical information to ground later
discussion - particularly for the reader unfamiliar with this system. As such, the evolution of the
design and its rationale is not discussed here, nor are usage results, these can be found in chapters
seven and eight.

5.2 Website
The most visible part of the prototype is the website, publicly accessible from http://rhub.net. It is
designed using contemporary web best practices and aims to provide an enjoyable, accessible and
usable experience. In this section, I will briefly outline its visual design and structure, and detail
individual features later.

5.2.1 LAYOUT AND VISUAL DESIGN

A consistent template is used across the website, made up of three main content areas: header, body
and sidebar. The header contains a hyperlinked logo that returns users to the index page, along with

55
 five top-level command
ds, a sign-out link and mail indicator. Within the body section is a
“breadcrumb” navigation
n trail and the text for the page. The sidebar app
pears on most pages and
contains shortcut links to
o items relevant to the content and usage hints.

Header
Rhub

Body Side
Sebar
idebar

Figure . Page sections.

5.2.2 HEADER

The header (Figure ), which

w appears at the top of every page, serves as a visual and logical anchor.
The ‘Rhub’ logotype is hyperlinked to the index hub page, and there are linkks to six top-level features:
mapping, contacts, grou
ups, locations, personal settings and items, and maiil. An icon of an envelope
brightens when a new message
m is received, and is hyperlinked to take the user
u to their inbox. To the
right of the mail icon, a link allows users to forcibly end their session, or if they are not logged in, to
start a new session.

Figure . Header section.

Four top-level options (ccontacts, groups, locations and me!) also have a drop-down menu (Figure )
which allows the user to
t select sub-features or relevant items quickly. Menus
M can be activated by
clicking the correspondin
ng downward-facing arrow, and are dismissed after either selecting an item or
after a short period has elapsed. Because people might easily overlook drop
p-down menus, no critical
functionality is containeed within them, merely shortcuts. The ‘contacts’ meenu allows users to access
the pages of people theyy frequently contact, the ‘groups’ menu displays frrequently accessed groups
and the locations menu llists recently added locations.

56
 Website

Figure . Drop-down menus for contacts, groups,

g locations and ‘me!’ Items listed below the horizonttal divider for
contacts, groups and locations are determiined on a per-user basis.

5.2.3 BODY

The main content area of the page, the body also uses a uniform internal design for navigation
elements, such as the breadcrumb and header and footer buttons and links. The breadcrumb
navigation allows users to gauge their location within the site, and easily jump to a higher point in the
navigation hierarchy (Figure ).

Figure . Breadcrumb navigation trail alloows for backwards traversal.

The two characters on the left of the trrail, the hash (#) and question mark both serve a speecial purpose
(Figure ). Clicking the hash brings up the console interface which allows users to en
nter console
commands the same way they would from their instant messaging client or SMS. The qu
uestion mark
brings up a small search dialog that enables quick searching of content. Both of these features are
designed to be quick short cuts for advanced users, and are displayed in-page, rather than
n requiring a
new page to be loaded. The features are
a also available from the bottom footer links (Figu
ure ) and is
labelled more verbosely but does not appear
a in a consistent position on screen.

57
 Figure . Console and searcch dialogs, summoned by clicking their respective breadcru
umb symbols.
Rhub

Figure . Footer links that a

appear after content.

When actions or functio

ons are available for the page, they are generally avaailable under a horizontal
line as a collection of bu
uttons (Figure ), with commonly used functions also
o available near the top of
the page.

Figure . Action buttons avvailable when viewing a person.

5.2.4 SIDEBAR

The sidebar appears on most pages and lists related links and information for the current page. For
example, when viewing a person’s page, the groups they are on and tags they have used are listed. On
the index page (Figure 
), the side bar is used to collect shortcut links to frrequently accessed groups
and site features, user’s m
messages and an overview of who else is viewing the site.

58
 Website

Figure . The index page’s sidebar (appea

ars on far right of screen).

5.2.5 HELP

A wiki (Leuf and Cunningham ) was

w deployed to host help content. Over  topics were
w written
and organised into categories, with an
n average of  of views per page (including web sspiders). Any
registered user of the prototype can ed
dit the wiki pages, however this was not utilised by an
nyone.

Table . Top ten viewed wiki pages.

Rank Topic H
Hits
1 Help index 1,624
2 Getting started 946
3 Messaging 811
4 MSN 799
5 Console 728
6 Tags 614
7 Console message commands 590
8 Presence: location 572
9 Home base 572
10 Using your mobile phone 543

59
 Wiki topics are integrateed into the website using a contextual help system. The ‘Help’ hyperlink that
appears at the bottom of
o all Rhub pages automatically takes the user to the most appropriate help
page. Additional links arre often employed in introductory paragraphs to pro
ovide further information,
such as in Figure , whiich direct users to a topic on the invite console com
mmand when they use the
Rhub web invitation interfacee. Short hints are also provided as ‘tooltips’ when the mouse cursor was
hovered over an interfacee element.

Figure . Links to help topiics integrated into pages.

5.3 Console
The “console” is a language, or syntax, rather than a visible part of the inteerface. It is text-based and
offers a subset of the fun
nctionality exposed through the web interface. It is designed
d to be used when
speed or directness is deesired or when the web is unavailable, such as whilstt mobile. Text is sent from
a supported system to a Rhub proxy entity on that system (for example, a ‘Rh
hub’ contact on an instant
messaging system), which is routed to the Rhub web server, parsed, exeecuted, and the response
returned via the proxy entity (Figure ). All of the console channels requiree some form of address to
which the user can direect input, for example a telephone number or an instant messaging address
which can typically be stored by the client software or system as a contact.

60
 Console

Figure . Schematic view of console access. User communication indicated using dashed lines, internal
communication indicated using solid lines.

A grammar was developed in order to aid in the memorability and understandability of the syntax.
For example, the at symbol ‘@’ denotes presence and location, angle bracket, ‘>’ denotes sending
(imagine it as arrow, pushing things), ampersand ‘&’ denotes groups (imagine as one person and
another person and another) and the bang ‘!’ denotes an action or command. Symbols are combined
with command words and or user input to form a parsable sentence. For example, to send a message
to a location (‘pub’), the user can input:
>@pub: What’s the band like?
The same two symbols > and @ can be reconstituted to form different commands, for example to
send a message to James:
>James: Are you going to the pub later?
Or to find out which friends are at the pub:
@pub?
A full list of console commands and example syntax is provided in the appendix, however the table
below lists commonly used commands, organised thematically.

61
 Table . Commonly used console commands.

Symbol Metaphor Examples

Send to >Clint: Hello!
> Sends message to Clint
>&tennis: Hello!
Rhub Sends message to the ‘tennis’ group
>>Hello!
Sends message to all friends
>>@library: Hello!
Sends message to friends nearby or at library
>@:Hello!
Sends message to nearby friends
At @library
@ Sets location to library
@cafe?
Finds out who is at the cafe
Action! !info Carsten
! Returns Carsten’s contact information
!invite Michael 555-123
Invites Michael, specifying his mobile phone number
And &tennis add Michael
& Adds Michael to group
&tennis?
Returns who belongs to group

Command responses are sent back to the user using the same channel as the command, and several
commands format their replies depending on the channel used. Responses via instant messaging or
the web can make use of hyperlinks for example, while text messaging responses demand brevity.
Commands can be compounded together using the pipe character ‘|’ so that a single SMS might
contain several commands, such as >@work:going home, adios|!bus home, which would send “going
home, adios” to everyone at the location ‘work’ and then find how to get home using public transport.
In this case, only a reply is sent for the last command, rather than a concatenated reply message.

5.4 Messaging
Most messaging in Rhub is performed using the console or the web interface. The web interface
allows users to specify more options, and it is easier to initiate conversations because the address (or
name) of the recipient or entity does not need to be recalled, rather it can be browsed for and clicked
on. Messaging takes a variety of forms, with different characteristics in where messages are sent and
how replies are distributed (Table ). One-to-one messaging is between two people, and is akin to

62
instant messaging but allows people to converse across different communication channells. Many-to-
many supports group communication
ns, with messages going to everyone within the gro
oup. One-to-
many messaging allows a single user tto broadcast a message to a group of people, but rep
plies only go
to the sender, not back to the group aggain.
Messaging
Table . Messaging forms.

Type One-to-one Manyy-to-many One-to-many

Private messages •
Group messages •
Discussions •
Locations •
Friend broadcasts •

5.4.1 PRIVATE MESSAGES

Messages can be sent person-to-perso

on with the web interface or by using the console, in
n the form of
>[user]: [msg], for example >Bob: Hello. Using the console requires the sender to
t know the
recipient’s Rhub username, while the w
web interface supports browsing and higher-fidelity ssearch.
The default view for messages is a combined inbox that shows the sender and the co
ontent of the
message. Clicking on a sender or the text
t of a message takes the user to the conversation view, which
aggregates messages to and from th
he sender and permits replying or deletion of olld messages.

Figure . Message inbox (left) and converssation view (right).

63
 New conversations arre initiated in several ways. From the messages pagee (Figure ), the name or
icon of someone the useer frequently contacts can be clicked to start a new
w conversation with them.
Alternatively, when view
wing a user’s profile page, clicking ‘Send an IM’ p
produces the same effect.
Another method of startting a conversation is to select ‘Send a message’ fro
om the messages page (or
Rhub elsewhere) and address tthe message.

Figure . Composing a new

w message.

When sending private messages

m using the web, a subject can be specified. T
This appears in larger type
when received, but otherrwise has little meaning. The user can opt to forwarrd the message using IM or
email however this is deselected by default. When sending messages using the console, Rhub
automatically forwards m
messages using all available mediums.

5.4.2 GROUP MESSAGES

Group messages are dessigned to support short, quick messaging to a grou

up. Messages can be sent
using the console syntaxx >&[group]: [message], for example >&tennis: Hello, or by clicking ‘Post’
from a group’s page on th
he web.

64
 Messaging
Figure . New group message interface.

The web allows users to specify how th

he message should be forwarded (Table ), with a default
d of no
forwarding (the message only appears to those that check the website or subscribe to partiicular feeds).
Sending messages using the console ho
owever defaults to forwarding using any channel posssible.
When composing messages on the web, a character count indicator to the right of tthe message
entry box (the number ‘’ in Figure ) increments with each letter typed. It flashes red if the message
reaches  characters, indicating thee message will be truncated if dispatched via a textt message. A
soft limit of  characters is in place so that the message has room for the system-added prefixes and
suffixes, and still be within the hard lim
mit of  characters.
Group messages are readable by all members using the web, and typically, all members
m get
messages forwarded to them via emaill, SMS or IM. It is possible for the group owner to sett restrictions
on which members can send messagees to the group or which channels they can opt to
o use. When
forwarded, messages start with the sen
nder’s name followed by the message and finally, the name of the
group the message was sent to. For exxample, ‘hello’ sent to the group ‘tennis’ from Bob ap
ppears as an
SMS like this:
Bob: Hello
To: &tennis {to reply, txt ‘>&tennis
&tennis [msg]’}

Table . Group IM forwarding options.

Option SMS IM Email

Don’t forward
Online IM •
Offline IM • •
Any • • •
Only online • •

65
 5.4.3 DISCUSSIONS

Discussions allow people to engage in topical, threaded conversations, akin to email lists or web
forums, and are anchored around a particular group or location. Message forwarding allows messages
to be sent to people via SMS, IM or email.
Rhub
There are three forms of discussions. The first is a web-only discussion, which is most similar to a
web forum in which no messages are forwarded to people. The second is an opt-out discussion, in
which the title of the discussion and subsequent replies are forwarded to everyone, requiring
members to opt-out if they are not interested. The third type is opt-in, whereby the title of the first
post is forwarded to everyone and members can opt-in to receive replies if they are interested in the
thread. Ideally, these features allow senders to reduce the messaging load on others yet still get their
message out, and allow receivers to selectively ‘tune’ in and out of discussions according to interest.
Opting in and out is done using a console command or with a visual web interface.
On the web, discussions can be browsed either by visiting the object around which the discussion
takes place (Figure ), or by visiting the discussions page, which aggregates discussions from groups
you are on and other discussions that you or your friends have contributed to. Clicking the thread’s
subject displays the posts within the thread and also a reply interface (Figure ). When viewing a
thread, it is also possible to see who has viewed it and the type of discussion. For individual posts, it is
also possible to see which channel the post was sent from, which is useful for contextualising
messages.
Discussion messages received via the console include the ‘thread id’ a number which the user
needs to opt-in or out, or to post new messages. For example, to send a message to thread  and
then opt out:
>#100: Sorry guys can’t make it | !unsubscribe #100.

As a convenience, the system automatically subscribes people to an opt-in discussion if they reply to
the first post using the console.

66
 Messaging

Figure . Discussions interface displayingg threads and the reply panel.

Figure . Discussions interface displayingg messages in a thread.

5.4.4 LOCATIONS

Messages can be sent to people at, or n

nearby, a particular location. This feature is only exp
posed via the
console - there is no web interface tto achieve the same effect. For example to send a message to
everyone at the library:

67
 >@library: Can someone do some printing for me please?
The utility of location messaging is naturally governed by other’s use of the presence feature (see later
discussion on presence in this chapter) as well as which places they frequent. Replies sent to a location
message are routed to the sender of the message rather than to everyone at the location.

Rhub
5.4.5 DISPATCHING

Rather than requiring people to check a website for new messages, Rhub can forward, or dispatch
messages to systems that notify the user when a new message has arrived, such as text messaging,
email or instant messaging. These systems effectively do the polling for new messages on behalf of the
user, notifying them with a sound, visual alert or vibration when a message has arrived. Additionally,
should a person miss a notification, these systems generally make it easy to ‘catch-up’ with
notifications queued since they last checked. For example, an email client might display unread email
in a bold face and a text messaging client might display the total number of unread messages.
Internally, a number of heuristics are applied to determine how or if a message should be
dispatched (Figure ). While the sender of the message can specify how they want their message
forwarded when using the web, the system treats this as an ‘ideal’ rather than requirement, for there
are many variables that limit forwarding. The sender can have general preferences for how all their
messages should be delivered, for example opting to never send any messages via SMS. Likewise, all
users as recipients can set general preferences (Figure ) on which channels they will accept
messages from, and under which circumstances. For example, a user can opt to never receive group
messages, yet still receive private messages and other notifications. Users can also be blocked from
messaging each other, or might opt to have a temporary ‘silence’ on messaging. The messaging context
(for example a particular group for group messaging) might also restrict forwarding, for example only
allowing moderators to send messages, or not permitting group members from having messages
forwarded via SMS. When a message has multiple recipients, these factors are examined for each
person. Because of the large number of variables and the fact that most are not accessible to the
sender, it can be difficult for them to determine exactly how the message would reach people. In most
cases, however, forwarding happened according to their original specification.

68
 Presence

Figure . Message delivery is governed by six major factors.

Figure . Message forwarding and notifica

ation user preferences.

5.5 Presence
The prototype’s presence functionalityy captures two main aspects of a person’s context – location
l and
status. Location can ‘place’ someone at a particular geographical coordinate or arbitraarily defined
named location, and status allows a person to set any kind of message which is then displayed to
friends (by default).

69
 5.5.1 LOCATION

Utilising the locations database (discussed later) which is geo-coded with latitude, longitude and other
addressing information, the system establishes the proximity of people to each other and also display
them on a map interface. Locations have a canonical title but can also have aliases allowing people to
Rhub
refer to a location by a personal, shortened, convenient form that makes their usage easier using the
console. Location can be set using the console, for example @library, which would set the person’s
current location to a defined location with a name or alias of ‘library.’ Should the location resolver fail
to find a matching location, Rhub displays it to others as text. In this case, the location is meaningless
to Rhub itself, as the text cannot be resolved to a geographic coordinate, however other users will
likely know what is being referred to. When attempting to resolve a location from user input the
following four steps are tried until a match is found:
. Is there a location with the exact name?
. Does it match one of this user’s location aliases?
. Does it match one of this user’s friends’ location aliases?
. Is there a location with a similar name? (Soundex matching)

5.5.2 STATUS

A status message, an arbitrary string up to  characters long that automatically expires after eight
hours, can be set by a user for whatever purpose they wish and is displayed prominently on the
website. With the console, the user can send @=[message] (for example, @=writing thesis) to set
their presence, or use the web interface which also allows them to control message expiry.
Status messages set using instant messaging clients are automatically integrated into the Rhub
presence framework when the user has set their IM account details in their profile. In this way, a status
message set in MSN Messenger or GTalk will automatically appear in Rhub, removing the need to set
two (or more) presence messages. If the IM status message begins with an @ symbol, the message is
parsed and their location and status message is set, allowing users to set their location as well.

5.5.3 NOTIFICATION AND DISPLAY

When someone sets their current location (with optional accompanying status message) a notification
is sent to friends (by default). For example, if Fry sends the following console command to set his
location and status message:

70
 @soho: Shopping away!
Laurie, his friend, might receive:
Fry is @soho: Shopping away!
way!
In order to minimise disturbance, presence
p notifications are assigned a high or a low priority. High
priority notifications are those destined for friends currently at the same location, in th
he vicinity or
Presence
have recently set their own location tto the same place. These are dispatched using SMSS or IM. Low
priority notifications are those destineed for all other friends and only use IM. People can opt to never
receive these types of notifications if they wish (Figure ) or the sender may opt to no
ot generate a
notification by unchecking a box wheen using the web, or suffixing their presence comm
mand with an
underscore, for example @soho_.
When logging in, a user sees all his or her friends’ presence information (Figure ). In addition,
wherever their username appears on the website, presence information is displayed as a tooltip to a
‘presence gem’ that appears next to theeir name (Figure ). There is also the presence pagee (Figure ),
which lists aggregate presence inforrmation for all friends, and additionally, each u
user has an
associated presence log, which displaays recent presence history, should the user enablle it. Finally,
presence information is also integrated into Rhub’s map interface, with people’s p
profile icons
appearing at their set physical location
n (Figure ).

Figure . Presence overview seen on indexx page.

Figure . 'Presence gem' displays information when the mouse cursor hovers over it.

71
Rhub

Figure . Presence as displlayed on the presence page. Note IM status is also displayeed.

Figure . People are depiicted on the map interface when their location is set too a location with address or
coordinates. Clicking their name from the top right pans the map to their location, or clicking their icon on the
map displays a pop-up win
ndow.

72
5.6 Profile, Settings & Contacts

5.6.1 PRIVACY

Privacy is naturally important to conssider in the design of social systems. To this end, th
he prototype Profile, Settings &
has a variety of user-definable privacyy controls, to govern the exposure of information an
nd limit how Contacts

other users can interact with a person

n. Friends’ activity on the system was emphasised, whilst
w activity
by other people on the system could go by generally unnoticed. Contacts by default are tagged with
‘friend,’ which is the most exclusive level
l of relation. Relation levels allow for fine-grained control,
from granting everyone access, only co
ontacts, only friends to no-one at all (Figure ).

Everyone

Contacts

Friends

No-one

Figure . Levels of privacy access. ‘Everyone’ is anyone who has an account on Rhub.

Figure . Relations used to determine acccess to presence information.

Privacy restrictions can be applied to

o the various properties of a person’s profile and gaathered data,
such as presence (Figure ), limitingg which people can see the information. Viewers off the website
who have not logged in cannot see anyy profiles.

73
 5.6.2 PROFILE

Users have a number of profile properties available that can be set. Most profile properties are
displayed on a person’s Rhub page, which is accessible by clicking their name wherever it appears on
the site. A user can share contact information with others, such email and instant messaging
Rhub
addresses, their phone number and website. If the person uses one of a number of supported web
services, such as Flickr for photo sharing, or a blog, they may add links to their presence on these
services, and in many cases can opt to ‘publish’ the data they produce on their Rhub profile, for
example displaying recent blog entries and photos. A person can also set a free-form ‘description’ that
appears on their profile and an image, which is displayed throughout the site.

5.6.3 INVITING PEOPLE

Invitations take two forms, system invites and group invites. Users can use the console (Figure ) or
the web (Figure ) for either. With the console, the !invite command can be used for system invites,
and the invite can be addressed to a mobile phone or email address, such as !invite Jane
jane@host.com or !invite Jane 5551234. Group invites use the & (group) prefix, for example
&tennis add Jane.

Figure . Console system invitation process, in this case, using text messaging.

74
 User-Generated
Content

Figure . Web interface for a system invitte.

5.7 User-Generated Content

People can contribute to Rhub in a vaariety of ways, which helps to improve their own exp
perience and
also that of others. There are five main
n types of entities users can create: groups, tags, setts, locations,
photos and bookmarks.

5.7.1 GROUPS

Anyone can create a group on Rhub, which

w acts as a hub around which activity can take pllace. Groups
can have associated instant messages, sets of photos or bookmarks, tags and discussions.. The system
automatically creates a ‘short name’ for the group on the basis of the title of the gro
oup the user
originally sets, for example ‘Tennis Cllub’ might become ‘TennisClub.’ This short name fo
orms part of
the group’s URL, (for example, http://rh
hub.net/groups/TennisClub/) and is also used when
n referencing
the group via the console. The shorrt name is changeable during the group creation process, so

75
 continuing the previous example, the user might instead choose ‘tennis’ to be the short name for the
group ‘Tennis Club.’
The creator of the group can set who can join the group, and under what circumstances, for
example a group might be open to anyone, might require another member to invite them, or might
Rhub require the group owner to invite them. Visibility of the group can also be set, which determines if the
group appears in the group directory, or whether people who know the name of the group, but aren’t
members can access it directly. Administrators can also determine who can send instant messages to
the group, who can start discussions and who can create sets. How group messages and notifications
get forwarded are also controllable. For example, a group owner might disallow members’ messages
from being forwarded, and prevent users from creating new discussions. The group administrator can
also disable or edit which feeds of the group’s activity are available to others.

5.7.2 TAGS

Tags are a lightweight method for categorisation. Rather than a strict administrator-defined ontology,
tags allow a “folksonomy” (Mathes ; Morville ) to emerge – a bottom-up rather than top-
down approach to organising data. Typically, tags are a single word, with punctuation stripped when a
tag is created. Hyphens can be used as inter-word spacing if compound words are desired. Tags are
easily entered or edited. Clicking the tags icon reveals a small entry box and pressing enter commits
the edit. Internally, Rhub supports tags on any kind of object, however in practice the functionality is
only exposed for contact relations, bookmarks, groups and locations. Sets aggregate the tags of their
contents, so for example you can browse all photos within a set tagged with ‘jim’.
Tags appear alongside items when they are displayed, but also appear as aggregate ‘tag clouds’
when browsing items, or browsing tags themselves. There are no namespaces for tags, so tag meaning
might vary between people or social groups. Adding multiple tags to an object is a way of further
defining the object. For example, the tag ‘cheap’ by itself could be applied to any number of things, but
when a cheap coffee is desired, the user can look for locations tagged with both ‘cheap’ and ‘coffee.’
When a number of tags have been defined, it is relatively straightforward to analyse tag co-
occurrence to identify items that are related, or tags that are related to other tags. For example, when
viewing locations with the tag ‘takeaway’ the system has automatically identified some other food-
related tags as related (Figure ).

76
 User-Generated
Content

Figure . Browsing objects by a particularr tag (top), tag cloud for locations (below).

5.7.3 SETS

Sets within Rhub are generic contaainers for objects. Although they could theoreticcally contain
anything, in practice they hold photos, bookmarks and feeds. Sets are always associated with an object
– typically a group or person. When viiewing a group or user’s page, associated sets are listted, and they
in turn can reveal objects ‘inside’ them
m. A set of photos functions like a photo album. A user can page
through the images one by one, or as
a a set of thumbnails. Collections of bookmarks can also be
created and shared with others. When
n an address of a feed (an RSS/Atom data source) is added
a to the
set, the set becomes an aggregator forr the feed items. For example, a group might use th
his to display
latest news posts from a related blog.
The creator of a set can establish access
a controls, such as who can view it and who can contribute
items. When a set is associated with a group, permissions depend on group membership. For
F example,
the creator of a set might only allow group members to add new images, but migh
ht allow any
registered Rhub user viewing permissiion.
Sets also aggregate tags and comments of objects contained within and can be vieewed with a
number of sort orderings. Larger setss can be navigated using a simple pagination meth
hod that lets

77
 people navigate forward or backward, jump to the beginning, end or a partticular page. The contents
of a set are also exposed
d using feeds, so someone might subscribe to her friend’s photo set using her
desktop newsreader so sh
he is notified when new photos are uploaded.

Rhub 5.7.4 LOCATIONS

Locations can be created

d or edited by any registered user. A location has asssociated contact, address
and location information
n as well as a description and image. Once created, th
he location can be viewed,
edited, referenced, tagged, discussed and aliased by others.

Figure . Location page.

Locations can also be browsed by locality or tags. Localities offer a hierarchaal geographical navigation
allowing users to drill-do
own to a more specific area, or up to a broader one.. For example, clicking the
suburb Taringa from the location shown above lists other locations in the sam
me suburb:

78
 User-Generated
Content

Figure . Browsing locations by locality.

Using the breadcrumb navigation traiil at the top of the page, it is possible to broaden tthe view, for
example by selecting Brisbane (Figure ). When a locality has sub-localities, they are disp
played using
a typeface size proportional to their level
l of representation, with more frequent localitiees appearing
larger (Figure ).

Figure . Locality hierarchy can be traverrsed to zoom in or out.

A map interface (Figure ), develop

ped using the Google Maps API, was also available to browse
locations. The map interface re-uses the map navigation paradigm provided by the Google
G Maps
toolkit, such as click and drag to pan, mouse-wheel zooming, and icons to switch views. On
O the right-
hand side of the page, people can seleect a user who has set their presence or a location,, which then
repositions the map so that the object is in the centre. The list of places shows locations tthat are in or
nearby to the current view, and changges as the user pans around. Underneath the map, a number of
other controls are offered. The first, ‘G
Go to’ allows people to jump to other user’s defined “h
home bases”

79
 which are marked with a blue ‘H’ pushpin on the map. The ‘view’ options allow people to toggle which
types of entities are displayed on the map. Finally, the ‘tags’ section allows people to filter out locations
by selecting tags, for example clicking ‘beer’ and ensuring ‘show selected’ is checked will only show
locations tagged with the word ‘beer.’ Multiple tags can be selected, and the filter can also be reversed
Rhub or unset. Clicking on a pushpin reveals information about it, and allows users to visit the location or
user’s page within Rhub.

Figure . Map interface.

5.7.5 PHOTOGRAPHS

Photographs can be shared with others either by uploading an image using the website, through a
client program or from a multimedia text message (MMS). Photos can be titled, tagged, commented on
and added to sets, which work like a photo album. The website allows multiple photos to be uploaded

80
at once, and after uploading, it is easy to work with the new images as a batch and place them in a
particular set. It is also possible to upload an image from a user-supplied web address, allowing people
to easily share an image they may already have on the web. A downloadable program was developed to
make it easier to upload images in bulk. The program automatically downsizes large images and uses a
simple drag and drop interface. Implementation
Using sets, photos can be associated with a particular user (like a private album), location or
group. For example you might upload pictures of a restaurant into a set associated with the location,
while you might upload pictures from a group dinner at the restaurant into a set associated with the
group. People can ‘remix’ sets by including images that have already been uploaded into their own set.
Email notifications are sent to group members when photos have been uploaded to that group.
An interface is available to add a comment (and see existing comments) when viewing a particular
photo. By default this is collapsed to minimise visual clutter unless the picture has prior comments.
The initial ‘browse’ view for a set displays aggregate comments for the set’s contents, so it is easy to
see at a glance which images have been commented on. It is also possible to check a box and only
show items in a set which have a comment.

5.7.6 BOOKMARKS

Bookmarks allow people to share interesting or useful web links with each other. Bookmarks have an
associated title, description, URI and set of tags. A bookmark can also have an associated feed URL,
which is a machine-readable list of items on the page that can be displayed with the bookmark. For
example a news website might have a feed for individual news stories. A JavaScript ‘bookmarklet’ is
also available, which allows people to add the page they are currently viewing as a new bookmark
within Rhub.

5.8 Implementation

5.8.1 WEBSITE

The website, the majority of the implementation effort, is written in PHP using a framework of my own
devising. The framework eased interface development, provided a database abstraction and many
utility methods. In addition to the website, PHP is also used for behind-the-scenes scripting and
automated maintenance.

81
 Taking advantage of contemporary web design technologies and trends, the implementation
supports a dynamic style of interaction. Tasks can be accomplished ‘in page’ obliterating the need for
visiting a separate page. Forms make use of automatic entry completion, which allows a user to enter a
predefined option quickly and correctly, and also supports a basic form of in-form browsing.
Rhub For example, the three pictures below show the interface component for setting presence: location
and a status message (Figure ). By default, the boxes show a pre-existing setting for the user, or hint
text (which is styled on the console syntax). A small box on the far right allows the dialog to be
expanded to show additional options. When the user begins to type in a box, a list appears with items
that match the partial text. For example, typing ‘caf’ matches locations containing the word ‘cafeteria’
as well as those with ‘cafe.’ As the user types, the list narrows until it returns one or zero results.
Pressing enter or clicking ‘set’ sets the presence status, which takes place in the background. No new
page is loaded and the user’s view state remains the same. A small notification appears briefly to signal
the result of the command.

Figure . Dynamic presence setting interface.

Other parts of the interface use this style of interaction to reduce the effort to carry out a task, such as
tagging items, defining locations, addressing instant messages and so on. These features are
accomplished with a mixture of client and server-side programming, commonly labelled AJAX (for
Asynchronous JavaScript And Xml). Two client-side JavaScript frameworks have been utilised,
Scriptaculous (http://script.aculo.us/) and JQuery (http://jquery.com/), and the server-side is my own
framework in PHP. Data is stored in a MySQL (http://mysql.com/) relational database over  tables.
The website also uses human-friendly URLs for major types of objects. For example, the profile
page for the user Bob is available at:
http://rhub.net/people/Bob/

82
And the group page for the group tennis is available at
http://rhub.net/groups/tennis/

This provides usability in a number of ways. Firstly, the address that appears in the browser is clean,
and easily readable so there is no confusion. Secondly, the URL is self-describing, for example if it is
Implementation
forwarded to someone, they could make a reasonable guess as to what the address is about, rather
than a URL which uses opaque values as a reference (for example
http://somesite.com/people?id=4539201). Thirdly, the URL can be easily dictated which means it
can be exchanged verbally with a good degree of reliability. Fourthly, such URL structures allow
advanced users to use them as direct navigation, for example, once they see the pattern of users, could
replace ‘Bob’ with the name of another user. Furthermore, particular views are often expressed using
the URL, for example, to view the messages for the tennis group, the address is:
http://rhub.net/groups/tennis/msgs/

5.8.2 MESSAGE DISPATCHER

To allow the system to receive messages from alternative channels, such as instant messaging and SMS,
and to allow it send out notifications or command responses, a message dispatcher was needed to
mediate between the systems.
Originally, an off-the-shelf mobile phone was used for sending and receiving text messages. This
necessitated some type of code to run on a desktop machine to interface with it. Because of this
requirement, and the easy availability of desktop programming-orientated frameworks for the other
channels I wanted to support, I decided to implement the dispatcher as program (or daemon) to run
on a personal computer, rather than a server-side collection of scripts. It is programmed in C# and
used libraries to support XML-RPC, MSN Messenger and Jabber connectivity.
Because the dispatcher is located behind a firewall, special consideration is needed as to how the
dispatcher could reliably communicate with the website, which is hosted on a different network, on a
different continent. Additionally, the dispatcher needs to be resilient in the face of loss of connectivity
or server down-time, and likewise the server must be able have messages dispatched in verifiable way.
A messaging queuing system was developed so that the server, which was PHP-based and hosted in
the United States, can reliably dispatch messages using a system hosted on a firewalled desktop
computer residing in Australia. I wanted to ensure that messages could be delivered reliably and that
the system was resilient in the face of either system crashing or losing connectivity. The dispatcher

83
 runs on a normal workstation, which is used for everyday tasks and often needs rebooting, while the
server is managed by a hosting company and rarely fails.
On the server side, queued messages are added to a database each with a unique identifier and
other metadata, with the message itself stored as an XML blob. Queued messages contain all the
Rhub information required to dispatch a message to a number of channel types, along with an ordered list
of channels that the message should be dispatched along. For example, a queued message might
contain instant messaging and text messaging addresses, and request that instant messaging be tried
before text messaging.
When the client dispatcher first starts, it requests a client id from the server. This client id remains
static until the program exits (crash or otherwise). The client then begins a polling loop, asking the
server for un-processed messages. The server returns a list of ids for the client, and marks each one as
being ‘in-progress’, and associating them with the client id. On receiving a list of message ids, the
client begins to fetch and process each message in turn. After each message is processed (which might
involve sending an instant message or email, for example) a reply is sent to the server indicating the
result. Periodically, the server resets the status of ‘in-progress’ messages if they have not been
processed in a timely fashion. A watchdog process on the desktop restarts the dispatcher if it crashes
or on system restart.
With this system, messages cannot be lost should the client crash, as they will be re-issued after a
period. The server can also determine the status of delivery and how a message was eventually
delivered, which in turn can be made available to the user.
Incoming console commands are also handled by the dispatcher, which stores them in a persistent
queue and forwards them to the server for processing. If the server returns with an internal error (for
example if it cannot be contacted, or there was a server-side bug), the dispatcher tries re-sending it for
eight hours before finally dropping it. Figure , below, presents a schematic view of the system.
Human access to the system is mediated via a number of interfaces and gateways. For example, when
using the console via SMS, the message is received via handset, which then passes the message to the
message processor, which passes through a firewall, an XML-RPC transport and finally reaches the
webserver for processing.

84
 Conclusion

Figure . Schematic view.

5.9 Conclusion
Rhub was developed into a fully functional prototype using a mixture of server-side and client-side
programming. The website used contemporary “Web .” design techniques to allow users to perform
some functions with a minimal amount of effort or disruption.
Functionality wise, Rhub supports a variety of forms of messaging that can also be forwarded or
dispatched to people using alternative systems such as text messaging, instant messaging and email.
People can also use presence features to notify others of their physical location or status. Profiles can
be defined to share information with others, and there are a host of settings and privacy controls to
govern disclosure of personal information. People can share a variety of information with the broader
Rhub community or friends, such as photos, favourite locations and bookmarks and use tags and sets
to organise and structure the data. A fault-resilient message queuing system was developed to support
reliable message dispatching and processing of incoming commands.
This chapter provides an overview of the functionality and visual design of Rhub for the reader
unacquainted with it. In the next chapter, I introduce the method used to design and develop Rhub,
and discuss how certain features evolved over time. In chapters seven and eight, the usage of the
prototype is examined in detail.

85
Rhub

86
6 R e f l e c t i v e Ag i l e I t e r at i v e D e s i g n

Designing and deploying mobile social systems

Whilst usable, useful, social systems are developed and deployed, there is little discussion about
their design process. These systems, typically of a commercial nature, are relatively opaque in terms of
development processes and results. Academic systems on the other hand are often developed for very
specific tasks, for a short period of time, which is not reflective of actual practice. Contemporary, so-
called ‘Web .’ social systems are deployed in a semi-permanent ‘beta’ status and slowly iteratively
improved whilst under active use. This style of development is much more agile than other forms of
software development, in which updates might be shipped on a monthly or yearly basis. The processes
through which these systems are designed and improved are not well elucidated or formalised.
Additionally, and as discussed in the previous chapter, the mobile social context demands new
research methods because of its fluid, dynamic nature which cuts across traditional boundaries of
context and location.
Reflective Agile Iterative Design (RAID) is a holistic framework encompassing the initial design,
development, continued iterations, and evaluation, which aims to be a first step in a formalised
approach to designing, understanding and developing systems in the dynamic, social context.
In this chapter I describe RAID, the framework under which Rhub was developed, and discuss how
it worked in action. The process evolved from the practical realities of developing a working, large-
scale mobile social system and also reflects the scenario I was working in: a single practitioner who
was also an embedded researcher. I do not suggest that RAID is a wholly novel method - indeed it has
integrated many existing methods - and there may be limits to its generalisability, however it
addresses several aspects of MoSoSo design not described elsewhere, and is a first step in producing a
cohesive design framework for this domain.

6.1 Method
RAID primarily consists of three steps (Figure ) performed in large number of iterations over short
time periods. Steps may be run in parallel, reflecting the multi-faceted nature of design, for example
reflection on the use of one aspect of the system may take place whilst feedback is gathered on
another aspect.

87
 . Design Planning & Implementation
. Feedback Hunting & Gathering
. Reflection Digestion & Response

Reflective Agile
Iterative Design
Reflection

Design

Feedback

Figure . RAID process.

Several artefacts are used within the RAID process. The foremost of these is the exploratory prototype,
a working system which is improved during iterations, and is the foundation for further
experimentation and data gathering. Other artefacts are documents which journal the progress of the
design and act as a repository for transient information that might otherwise be forgotten. The four
primary artefacts are:
. Exploratory prototype
. Question log
. Change log
. Reflective journal

This framework seeks to provide excellence in five main themes:

. Sociability Promoting and supporting socialising whilst reducing the impact of anti-
social behaviour
. Usability Supports a natural, simple, easy interaction
. Functionality Provides features people want and need
. Insight gained Designer has ‘deep’ insight into how the system is being used beyond simple
usage metrics
. Accessibility Design is usable beyond the context of a desktop computer

88
Importantly for mobile social systems, the themes specifically address socialability and accessibility,
which is not typically a priority for many design frameworks.
In essence, this method advocates deploying a prototype as early as possible, and improving it as
frequently as possible on the basis of a reflective process. The prototype is therefore an exploratory
inquiry which helps to unravel the wicked problem of the context. While being deployed and actively Method
used, data is gathered by the system and by the designer, which is reflected upon and used to inform
the next series of design changes. Insights gained from the researcher’s reflection on aspects of use
might feed in to other areas, as Bellotti and Smith recount:

"...fieldwork preceded the engineering and continued while there was a two-way interaction between
the design of the system prototype and the nature of the fieldwork (in terms of the questions we were
asking in our interviews)" (Bellotti and Smith : , original emphasis)

6.1.1 RELATED WORK

In chapter , I discussed design and development frameworks, concluding that goal-driven, user-
centred methods are best suited to not only develop usable designs, but also have the capacity to deal
with the uncertainty that emerges during design. With social systems requiring a high level of usability
and subject to variable user interaction (after all, without human use, a social system is nothing), these
methods would seem highly appropriate. How people will use a social system is not entirely known in
advance, only how the designer hopes they will use it, or how they use similar systems. It is through
people using the system that the designer begins to understand how it is used, and as such, agile
methods are needed to adapt the design appropriately. Thus, RAID holds the exploratory prototype
(introduced and discussed in the previous chapter) as a core component of its overall strategy for
investigating social use. Emergent behaviours are a key feedback mechanism in Vogiazou et al.’s ()
design of mobile social systems, and were used in an iterative process to understand the design and
inspire new development.
Bellotti et al. () discusses how to integrate development with user-centred design. After the
failure of one design using development methods which did not effectively account for user feedback,
the authors tried an agile method (extreme programming) when starting anew. They found that the
agile method supported the user-centred design process, allowing the continual integration of user
feedback to take place with development of a continuously usable prototype. In this paper however, a
cohesive framework or method is not discussed, focussing instead on the design itself, and the use of
extreme programming.

89
 Rapid Evolutionary Development (Arthur ) shares similar goals to RAID. Arthur suggests that
software is grown or evolved, rather than simply built or created, likening software development to
nature rather than industrial processes such as building construction. There are a number of ways RED
can be carried out, including an online system, which is akin to the exploratory prototype RAID uses as
Reflective Agile its core. Significantly, the method largely ignores use or emergent social behaviour as part of the
Iterative Design
design process, and focuses on software ‘quality’ as a metric of success. The process through which
feedback is reflected upon and a design response formulated is also not articulated.

Choose the ‘right’ work Gather requirements

Improve Create prototype

Deliver working system Evaluate

Figure . Rapid Evolutionary Development (adapted from Arthur :).

Prior chapters have discussed design, development and research methodologies (chapters three and
four respectively), so I shall not delve deeply into them here. The primary framework which informs
RAID is Action Research (AR), however it also draws upon and utilises aspects of agile development,
iterative design, user-centred design and exploratory inquiry. ‘Standard’ positivist sociological
research models have been compared to participatory action research (interpretivist/post-positivist),
suggesting that the former is paradigm-driven, and the latter client-centred (Whyte : ). This
dichotomy is similar with the plan-driven versus goal-driven development models discussed in
chapter , and suggests a natural cohesion between action research and agile methods.
There is a need for an ‘end-to-end’ framework that informs not only the design, but also the
development, deployment and ongoing iterative improvement of systems which aim to be usable and
user-centred.

90
6.1.2 STEP 1. DESIGN: PLANNING & IMPLEMENTATION

The first step is the conceptual design: thinking about what needs to be done, how to go about doing it
and then actually doing it. In this step, RAID borrows heavily from agile methods such as extreme
programming.
Method

Planning
Thinking about what needs to be done necessarily involves critical reflective thought. In typical
systems design, this might be thought of as requirements engineering; capturing and collating a set of
requirements into a specification document which can then be passed on to a team for
implementation. Depending on the development model used, this specification is a static document
(such as in the waterfall model) or something which is much looser and flexible, such as user story
cards (for extreme programming). Requirements should be structured as user goals, or ‘stories’ which
express in a person-centric way what the person wants to accomplish with the system, ignoring
specifics of the implementation and design, such as:

Locations can be created by clicking on a graphical map, with address information automatically filled
out.

In this way, requirements, should they be accepted, are flexible enough to handle unanticipated
technical problems which may limit aspects of its design, yet still be able to meet goals of the user. An
inflexible requirement is brittle, and when an unexpected circumstance arises would either have to be
ignored altogether or altered, which requires further consultation and slows the project.
Requirements can emerge in a number of ways. In the very first iteration, functionality might be
determined by examining related systems, running design workshops, and naturally from the
designer’s own inspiration and creativity. In subsequent iterations of the process, determining tasks is
mostly informed through the feedback and reflective steps, discussed later. At the outset, it may be
useful to define a short motto for the system, something which can be written out and kept visible in
the workplace. The motto (or one line manifesto) seeks to keep the design true to a theme, or spirit,
and in many ways is the ultimate requirement against which others are judged. A useful motto can
enforce design discipline, favouring simplicity and focus over multitudinous features. For Rhub, this
was:
y To Support Communication, Coordination & Sharing amongst Informal Social Groups z

How to go about the task is a consideration which begins the bridging between the world of the user
and the world of technical reality. Requirements need to be prioritised with regard to their feasibility

91
 considering the technical and resource scope of the project. Ideally this weighting is done - such as
with agile methods - as a collaborative exercise between the development team, designers and
participant-users. At this stage the current architecture of the system, such as object model and
database schema might reveal themselves to be deficient in light of new required functionality, and
Reflective Agile refactoring (Beck ) might be required. Test cases can be written before implementation to judge
Iterative Design
the success of the requirement; however it is not always straightforward to express user goals as
procedural test cases. Success can also be judged in the later stages of feedback and reflection.

Implementation
It is in this step that goals are transformed into something tangible, and typically, functional. Like agile
methods, implementation should take a minimalistic approach, only implementing what is required,
rather than covering all eventualities.
Goals might require interpretation by the implementers, and a dialogue may be needed between
implementers, designers and participant-users. It may also be the case that difficulty may emerge
during development which was hitherto unknown, and may impact the feasibility or scope of the
requirement. Changes made to the implementation of the system, in terms of both new features as
well as modifications or bug fixes should be recorded in a change log. The change log’s entries should
be dated, and ideally should identify exactly which parts of the implementation were changed and
why.

6.1.3 STEP 2. FEEDBACK: HUNTING & GATHERING

Feedback from a system can come in a variety of forms. Usage data can be collected automatically,
people can send comments, interviews and field studies can be conducted, workshops can be run and
people might talk to each other about a system. Making using of feedback requires a combination of
hunting and gathering: deciding where and how to look for data, and then bringing it together in a
way which feeds into the next stage of the RAID process.
It is important to note that term ‘feedback’ here is not restricted to its typical definition of a free-
form comment explicitly articulated by a user. Rather, it is akin to Schön’s () description of design
‘back-talk.’ Feedback can be any kind of data which might be related to the system, be it actively
solicited or passively gathered, direct or ambient. For example, conversation about the system,
mediated or unmediated can take place between people. This ambient feedback, such as face-to-face
conversation, and weblogs, might also be useful for the designer. Feedback is also present through use.
How people use, mis-use or under-use the prototype can also provide insight.

92
Hunting : What data is needed and how to get it
Data usually has to be specifically sought out, and deciding what data to gather and how to go about it
is itself a process which requires critical thought, which I describe here as ‘hunting.’ The social
sciences have developed many methods for both quantitative and qualitative data gathering and it is
not my intention to catalogue them here (see Chamblis and Schutt ; Lee ; Weiss ). Method
Deciding what data to gather depends on active questions the designer has, which may be
relatively straightforward, such as ‘how many people are logging in per week?’ or complex, such as
‘what are the differences in how people use the system across different channels?’ Questions can come
about throughout any part of the RAID process, and should be recorded in a consistent ‘question log’
so they can be revisited at a later point. During the development of a feature, the designer will have
certain expectations of usage in mind, so questions might be created at this stage to follow-up on later
when the feature is deployed. During reflection, the designer might be aware that certain observations
lack supporting data, so questions might be formulated so that the observations might be confirmed,
denied or further refined.
Once questions have been identified, they need to be analysed to see exactly how they might be
answered. This might involve a combination of methods, studies, or simply instrumenting the
prototype to gather data. Selection of the method needs to be done with respect to the type of data
that is needed, as well constraints on resources, such as participant’s time (Matthews ).

Gathering : Analysis, abstraction and articulation

Once the designer knows what data is needed, and what methods are to be used, the methods need to
be carried out to produce or gather raw data. After raw data has been gathered it needs to be analysed,
abstracted and articulated. How the data is gathered, and the types of analysis performed depends on
the questions that need answering, and methods used. For some questions, it might be enough to
simply instrument the prototype to log data, and display it in aggregate form, but for others a much
deeper level of analysis is required. Ultimately, the analysis needs to serve the question.
Data can also be available in an ‘online’ form, that is, data which is aggregated, processed and
displayed in a real-time, continuous manner. A simple example of this is the common hit counter
visible on many web pages. Online data is useful for the designer because of its accessibility and
currency, but while it can represent a large amount of data, it might lack depth of meaning.

93
 6.1.4 STEP 3. REFLECTION: DIGESTION AND RESPONSE

"[Reflection is] the probing playful activity by which we get a feel for things. It succeeds when it leads to
the discovery of something there" (Schön : )

Reflective Agile Reflection is a critical part of RAID, much like in action research, upon which RAID is based. It is in this
Iterative Design stage that designer blends the existing design, feedback and their own knowledge and imagination to
produce a design response. For an in-depth discussion of reflection, the reader is referred to Schön’s
The Reflective Practitioner ().

Digestion
Combining the disparate - and sometimes conflicting – bits of information that inform the design is a
necessary skill for the designer. Interview data might conflict with usage data, and technical
limitations might hamper design responses. Correlating information into threads, and ensuring
interesting observations are seen through to conclusion requires some level of information
management, which the reflective journal aims to provide.
A reflective journal can be kept to maintain observations, thoughts and ideas. Dated entries should
be created at regular periods of a minimum period (such as one per week), and might contain free-
form text, sketches, screenshots, photos and extracts of data. Ideally, the journal would be a
confidential document, so usage of the system can be discussed fully and frankly without necessitating
excessive abstraction and anonymisation. Entries should be immutable, save perhaps for minor
grammar and spelling correction: new or corrected ideas should be in a new entry, rather than an edit
of an old in order to maintain continuity and accuracy.
The journal and its composite artefacts together permit a dialogue to take place between the
design and the designer. The designer can ask questions of the design in one entry, which might be
answered in a later entry when feedback is available. Feedback can be dissected, discussed and
analysed in the journal, which can then lead to new ideas or new understandings. New ideas might
then be ‘sketched’ as a rough implementation within the exploratory prototype, which the designer
can investigate further with later questions.

Response
Response to reflection takes place when the spiral of the RAID process returns to step one. Rather than
returning to the same place as she was before, the designer and the design has changed. Now the
design is approached with a new understanding, insight and curiosity. Schön describes the response as

94
a “move-testing” experiment, in which theory, developed through reflection can be affirmed or
negated (:) in the course of action.
Responses can take many forms, depending on the issue. For example, it might be alteration in the
design, a new data gathering technique, documentation or so on. Understanding what to respond to
and how is critical for the next iteration to progress, instead of regress. A badly-judged response may Results
set back a design, a poorly-judged response might not advance it any further but a well-judged
response might improve it. In their discussion of response to emergent social behaviours in mobile
social games, Vogiazou et al. (:) note that in some cases, explicitly designing support for an
observed behaviour might in fact not be desirable, and it would be better to leave the design as is.
Responses can not only generate change in the design (enacted in on the loop back to step ) but
also generate change within the designer and the designer’s practices, much like action research. For
example, the designer might employ new tools to support a different development workflow, such as a
source code management system.
The design motto, or one-line manifesto developed at the beginning (see step ), can be a useful
metric to judge what to respond to. Ultimately however, it is design that determines the response.
RAID suggests that changes can and should be swift. Once a response has been validated in terms
of functional performance, it should be deployed so that its social and usability properties can be
examined. The quicker it is deployed, the quicker the true merits of the response can be judged. The
quicker the merits can be judged, the quicker the next design response can be made. Software, when
developed with sound engineering practices, can be changed quickly and reliably, minutes after an
observation has been made. When deploying a live prototype which was developed in a lean, agile
way, users are bound to encounter errors, and these should be fixed as a matter of priority. Trust
needs to be established with the participants, trust that the system will be able to carry out functions
asked of it. Ongoing reliability problems can break this trust, which risks alienating participants who
might then reduce their usage of the prototype.

6.2 Results
In this section I’ll discuss how RAID worked in action, in the development of Rhub. To this end, the
discussion focuses on four particular ‘case study’ features, the console, messaging, invitations and
presence (see chapter  for more information on the features). I’ve organised them by each step of the
RAID method: design, feedback and reflection, rather than a strict temporal account of their design, so
that the role of the individual steps is clear.

95
 6.2.1 CASE STUDY: CONSOLE

The console is the text-based command syntax which allows users to interact with Rhub over a variety
of channels, such as instant messaging, SMS, email and the web. Users can send commands to Rhub
using one of the supported channels, and Rhub can send notifications and messages to the user. While
Reflective Agile
Iterative Design enabling interesting features, the console was never a particularly ‘user-friendly’ interface, and
underwent frequent changes.

Design
The initial planning for the feature called for a method by which users can interact with a system
across a variety of different methods in a way that was feasible to implement. I decided on a text-based
syntax. Command syntaxes are not uncommon in other MoSoSo literature or commercial systems, and
a high level of SMS usage indicates that people are willing to adapt to limitations of a medium if it is
worthwhile. After mapping out potential features, an overarching framework or style for commands
was designed and each feature mapped to a command.
The console was one of the few features which existed from the first version of the prototype;
however, many users were not aware of it. It is largely invisible, and remains in the background until a
message is received or sent. For most users (see detailed usage information in the next chapter), the
console was something that let them receive messages on their phone, and they could occasionally use
it to send a message. Few users took full advantage of it, and this was obvious from the very earliest
feedback.

Feedback
Originally, the command parser strictly enforced adherence to the syntax. If the command failed to
meet the syntax, a generic error message was returned and the user would either have to reformulate
their command and resend, or (more likely) give up. The console parser was instrumented from the
beginning to display input and debugging information for any command it could not parse, and this
log was monitored typically on a continuous basis. When an error appeared in the log, I could usually
ascertain what the person was trying to do, and this was often noted in the reflective journal.
End-user syntax help (within messages or in the user documentation) denoted user input with
square brackets, for example, the syntax hint: >&[group]: [msg] means that the user should replace
[group] and [msg] with the appropriate terms, such as >&tennis: Hello. It was not uncommon for
users to initially misunderstand this nomenclature, for example sending >&[tennis]: [Hello], which
resulted in the tennis group being sent [Hello] (the square brackets from message destination are

96
removed as part of the internal processing). Thus, successful, albeit strangely-formatted messages
were also a useful source of feedback in addition to those that failed to be parsed outright.
After some months of usage I was curious as to what errors people were experiencing with the
console, and undertook a variety of analysis of logged data to investigate (results discussed in the next
chapter). During interviews with participants, usage of the console was often brought up, and these Results
discussions, along with others outside of a formal interview context were highly useful. For example,
one participant showed me the poor pagination of Rhub-sent messages on his low resolution phone,
which was not an issue I would have been aware of otherwise.

Reflection
It was clear shortly after first deploying the prototype that the parser would have to be more
permissive, however if it was too permissive, mistaken input might result in negative effects, for
example sending a private message accidently to a group. Thus, the parser was successively ‘loosened’
to accept slight syntax errors whilst attempting to maintain a high degree of reliability and accuracy
(Table ). Additionally, hints were later postfixed to messages sent by Rhub to demonstrate and
reinforce messaging syntax.

Table . Syntax changes for messaging commands

Week of Syntax Example Description

deployment
 >[name]: [msg] >&tennis: Hello Initial design
 >[name] [msg] >&tennis Hello Colon can be omitted
 [msg] Hello Replies sent within  hours are
automatically routed
 >[name without >tennis Hello Ampersand to qualify entity as a group
qualifier] [msg] can be omitted
 >[full person name >John Doe: Hello Only contacts could be messaged
or user]: [msg] before, now any registered user can be
contacted

On several occasions console-related direct feedback did not require lengthy reflection: it was simply
a good idea that wasn’t otherwise implemented. When designing the prototype, there may be many
features which await implementation, and feedback is useful to aid in their prioritisation.

97
 Feedback is not always direct, and sometimes ‘obvious’ feature omissions are never actually
articulated by participants. As an example, for most of its existence, Rhub did not offer the ability to
reset a lost password, which is a standard feature on sites that require a login. People sometimes
forgot their password, especially if they didn’t sign in to the website frequently (as this is the only place
Reflective Agile it is required). Typically, these people would directly ask me to help them, or for those that didn’t
Iterative Design
know me personally, ask through a friend that did. I would then reset their password, and forward
along the details. As the social network grew, it was clear this system would not scale, so a password-
reset feature was developed which could be used via the console or the website.
When internal errors occurred with processing console messages, I would often intercede on
behalf of the user and ensure that the correct action took place, usually after fixing the error in
question. These types of changes would happen within minutes of observing the error. In some cases,
a fix was deployed by the time the user retried the action. Response to feedback can also be a message
to someone, for example, if a user is observed having trouble with the syntax, I occasionally would
message them (using Rhub) to give them further help.
Contextualised help was developed so that the console could return error messages appropriate to
what the user attempted. This was partially possible due to the use of consistent prefix characters for
commands (such as ! for commands, or @ for presence features), which allowed the parser to make a
reasonable guess as to the user’s intention. It also allowed the user, should they know the prefix
characters, to effectively browse console commands by theme. Specific help was also given when a
command was missing required parameters, for example, if the user sent !invite Bob, omitting a
phone number or email, Rhub would reply: Address missing, try !invite Bob [email or phone
number]. In some cases, like this one, the error response is personalised to reflect the information the
user submitted in the initial request, such as the name Bob.
I also observed several users ‘probing’ the console trying different variations of syntax, which
might also suggest design opportunities. For example not knowing how to list his contacts, one person
tried a few commands that he thought might produce the desired result:
Who?
Friends?
?friends

98
Interestingly, the commands he tried had no relation to actual console commands, nor was it
suggested by any documentation. He was merely trying to see what might or what he thought should
work†.

6.2.2 CASE STUDY: MESSAGING Results

Because of its prominence in usage and the thesis topic, many parts of the discussion here are
purposefully short as they receive a full in-depth treatment in chapters seven and eight.

Design
The goal for messaging in Rhub was to allow groups to easily coordinate and communicate. Whilst
messaging needed to easily support group conversation and keep everyone informed, I did not want it
to be overly ‘spammy’ or obnoxious. It was clear that while traditionaltext messaging had many
positive properties, it was less than adequate for group messaging.
Initially, Rhub supported person-to-person messaging (akin to instant messaging), group instant
messaging and threaded discussions. Discussions could be centred around a group or location. Later,
it also supported messaging to a particular location, and sending a message to all friends.

Feedback
Messaging was by far the most popular and used part of Rhub, and as a result, a popular topic of
feedback. Feedback was received through formal studies (discussed in the next chapter) but more so
than other features, through informal channels. Typically this was through face-to-face conversation,
but I also received several emails from participants with comments.
How people used messaging was also an important part of feedback. Unlike other features,
feedback about messaging sometimes took place using the feature itself, for example people chastising
others if they were considered misusing messaging. Messaging was a feature in which a single person’s
use can impact many others, in a publicly visible manner. Consequentially, feedback was often
received about how others’ used the feature, and what constituted appropriate usage.

Reflection
Ideally the mass messaging features of Rhub would only ever message the people interested in the
message, no more, and no less. This of course is an unattainable goal (technology assisted or
otherwise) but was the major point of reflection. Participants can send text messages for free using

†
The actual command for listing contacts is !contacts.

99
 Rhub, but this had to be paid using research funds. In order to save resources, I, as a researcher, had to
work to restrict people’s ability to misuse or overuse this functionality. In the absence of a moderating
economic pressure on participants, the design had to provide a similar pressure on participant
behaviour. At the same time however, it was desirous to be as ‘hands off’ as possible, to allow group
Reflective Agile usage norms to develop naturally. Feedback from participants often negatively referred to the volume
Iterative Design
of messages they received or messages they received that they weren’t interested in. Messaging
quantity was a concern shared by designer and participants, albeit for different reasons.
During the iterative development of messaging, which sought to provide controls for senders and
receivers to better manage distribution of messages, it became evident that people wanted to exert as
little as possible effort. Senders did not want to go to special effort in addressing or marking messages,
and recipients did not want to have set what types of messages to receive or stop the flow completely.
Two designs which would have provided very reliable control were ultimately ineffectual because of
the added effort they demanded. Many participants directed their blame for the volume of messages
to the system, others to the people responsible for sending the messages in the first place. Even after
various features were designed to help reduce the number of messages received, some participants
preferred to complain than actually take proactive measures, which would have required only two
mouse clicks. During the design of a temporary message blocking feature (which would allow users to
issue a ‘silence’ command to stop all incoming group messages for a period of time), participants said
it would be a good idea and would help, but few said they would bother sending a SMS to actually
invoke it. They thought it easier to set their phone to silent and delete messages than compose a
command (and pay for the cost of a message) and stop messages for a period of time.
Other changes took place with the display of messages. In order to increase the visibility of
messages on the website, recent group messages and discussions are displayed on the home page,
along with unread private messages. The original person-to-person instant messaging interface was
modelled on email, with message subject lines grouped into an ‘inbox’ and ‘outbox,’ and to view the
body of the message, the subject line had to be clicked. Participants felt this view was too limiting, and
preferred organisation according to conversation. The resulting redesign (Figure , p ) was well
received and permitted messages to be sent back and forth between two people with much less effort,
whilst maintaining a conversational context.

100
6.2.3 CASE STUDY: INVITATIONS

The process through which people joined Rhub and groups was facilitated by invitations, which could
be sent from one person to another.

Design Results
Invitations took two forms. System invitations, invites to join Rhub itself, and group invitations,
invites to join particular groups. Because access to most of Rhub’s functionality was only possible with
an account, and gaining an account was only possible through an invitation, system invitations were
important for the user base to grow. Likewise group invitations were important, for if a user is not a
member of a group, they miss out on a large amount of activity. Additionally, group invitations were
the only way to join invite-only groups.

Feedback
Feedback on invitations came primarily through participants, who articulated opinions on the subject
in interviews, conversation and several unsolicited messages and emails. Primarily, participants were
frustrated by the enforced delay between wanting to interact with someone via Rhub, and being able
to. The delay was brought about because invitees had to manually approve invitations before they
would join the system or group, and for some people there was a delay before they checked their
email. Delays were particularly nettlesome when forming a group, as the group could not properly be
used until all members had accepted the invitation, and meant that creating quick, spontaneous
groups was not practical. Participants would often contact me when a system invite failed, usually
because the invitation email was sent to the wrong address or was intercepted by a spam filter.

Reflection
Several design improvements were made to make establishing links as easy as possible to encourage
people to inter-connect and invite their friends. Originally, the process of creating a Rhub group for
some friends would involve creating the group, inviting the friends to Rhub, waiting for each one to
accept the invitation, inviting each one to join the group, waiting for each one to accept, and then
finally being able to interact with them as a group. It was designed this way so that people weren’t
joining a system they didn’t specifically authorise, and weren’t receiving messages from a group unless
they specifically joined it. It was obvious however that these requirements retarded the usefulness of
groups, particularly their use for short-term events. This behaviour was changed so that after inviting
someone, they can be interacted with via Rhub immediately, and that inviting someone to a group
adds to the group immediately rather than waiting for their authorisation at each step. Abuse of this

101
 system could easily happen, however with the small, localised community using Rhub, it was never a
problem. If a user rejected an invitation to join the system or a group, any repeated attempts to invite
them would fail. Rather than requiring people to opt-in, the system now required them to opt-out.
Rarely was an opt-out wanted, so the change streamlined the process dramatically and was received
Reflective Agile positively by participants.
Iterative Design
Initially, invitations could only be sent from the website, and could only be sent to someone’s email
address. For some users this caused problems because the people they were inviting didn’t check email
often, or the invitation email was stopped by a spam filter. As a result, people would have to ask their
friends to check their email, and should the invite email be lost, contact myself. Once accepting an
invitation by clicking a specially-formulated ‘magic’ URL, the new user would then have to link their
mobile phone to Rhub which required them to enter their phone number and then enter a randomly
selected word that gets sent to them via text messaging. This was done to ensure that the user is
actually in control of the handset, and was not linking their account with some arbitrary phone. This
process was tedious, and was a poor experience for new users. Many did not link their phone because
of the added effort, which in turn limited their perceived utility of Rhub. The first step to improving
this was by adding a console command to invite people, which meant that invitations could be sent
from a phone and addressed to someone’s email or mobile number. This became a very popular way
to invite people, and because the other person receives the invitation SMS immediately, the inviter can
coach the new user through the process. Afterwards, functionality was added so that invitations sent
via the web could be addressed to email or mobile, and the magic URL could be retrieved so that the
inviter could forward it to the person in any way they wished.

6.2.4 CASE STUDY: PRESENCE

Design
The presence feature was intended to be a way for people to share contextual information such as
location and status with their friends. If people regularly set their presence information, more
advanced features could be built which leveraged the data to provide further utility. As it was intended
for use whilst mobile, presence setting was only exposed via the console, with the web interface
developed later.

Feedback
Feedback on the presence features came through interviews, conversation and analysis of usage data.

102
Reflection
The major challenge with the feature has been how to reward people for setting presence information.
Participants could see the value of the feature, but wanted their effort better rewarded. Because some
of the more interesting features don’t eventuate until there are enough people setting their presence,
there needs to be a selfish reward to boot-strap the process. Discussion
Early changes made were to increase the visibility of presence data. First it was shown next to
people’s names wherever they appeared on the web, then friends’ presence was shown on first logging
in to the website, then people could opt to forward presence data to others, then forwarding became
automatic under certain circumstances. The interface to set presence information also became
progressively prominent. Initially it could be set only via a console command, then an interface was
provided on separate page and then an interface was shown at the very top of the home page. These
changes were the result of feedback from people who said they would set their presence more often if
it were easier.
As with messaging, I did not want the presence feature to needlessly annoy people with
notifications about presence changes, yet at the same time notifications were a useful way of diffusing
presence information. During the development of presence notifications, which forwarded presence
updates to a person’s contacts via instant messaging, I received an email from one participant saying
he didn’t want to receive the notifications, but under some circumstances he would. It is ultimately
impossible to design the feature so that notifications are only delivered to people who are expressly
interested in them at that particular time. Recipients would not want to exert effort to define filters or
selectively turn on or off notifications, and senders would not want to go to the effort to select which
people should receive presence notifications.

6.3 Discussion
In this section I outline the major issues relating to RAID. Some of these have a practical nature, and
address issues that arise from the application of RAID, such as communicating change, when iteration
should stop and source code management. Patterns of usage which may provide useful insight are
outlined, as well as the general issues of balancing the needs of data gathering against annoyance
inflicted on participants, using online data and how to respond to feedback.

103
 6.3.1 COMMUNICATING CHANGE

If a system is under ongoing change, consideration must be paid to how users are notified of new
features or options as well as inconvenience caused by change in the interface or processes. If change
is not communicated, there is reduced potential for active use, and therefore feedback will not flow
Reflective Agile
Iterative Design from the changes.
Communication can take place however is appropriate. On the web, it is common for modern
social sites (such as Flickr, Facebook or Delicious) to have a development blog for communicating
changes of the design to interested users, and mailing lists are also a widely used. Changes in a visual
interface can be highlighted using icons or highlighted text. Client applications often include a ‘what’s
new’ printed card or help topic to introduce changes. Visual display of changes are useful because the
changes are shown in-context, and are possibly exposed to more users that the smaller subset who
would bother subscribing to a mailing list or development blog.
Difficulty can emerge when an interface is hidden, or change to a behaviour takes place which does
not have a corresponding interface, for example the console in Rhub. Contrary to visual interface
options, if a new console command is added, it does not have any extra visual ‘weight’ and cannot be
easily discovered with normal use. In Rhub, change was communicated using in-page display,
discussions (similarly to a blog), mailing lists, talk and action.
In-page display of changes was suggested by a number of users during interviews – they wanted
short ‘tip of the day’ style information so they could possibly find out something new about the system
without having to spend too much effort reading long help documentation. Such a feature was
implemented, and over time  tips were created, shown on a random basis. Tips were of a light,
informal character, and usually included links to the wiki for more information on a feature. In
addition to the tip-of-the-day, which was displayed in the lower-right hand side of the home page, a
‘Feature Feature’ panel was also designed. This panel acts as a mini-tutorial on a particular Rhub
feature, and is designed to be displayed prominently once, and then to disappear until a new tutorial is
developed.
New changes were posted to the discussions for the Rhub ‘bugs’ group created by a participant and
was publicly viewable. A mailing list was created with all Rhub users added. Posts to the mailing list
were not made frequently, for participant’s sake, and instead were a digest of new features, changes
and other information sent out on an approximately two-monthly basis. An accompanying wiki page
was made for each mailing which contained the same content, but with hyperlinks taking the
interested reader to related wiki pages with more information.

104
 Finally, talk and action was also used to communicate change. Because my social group were Rhub
users, I could informally talk about new developments which I thought particular people would like.
There were two ‘early adopter’ users in particular who enjoyed trying new features and providing
feedback. Demonstration of changes through use was also important, however was only possible for
changes which were externally observable. For example, after implementing opt-in and opt-out Discussion
discussions, I organised an event using it, thus exposing group members to the new feature. People
who knew about the !transport command (which provides public transport information for getting
from one location to another) used it to give answers to others they were collocated with.

6.3.2 FEEDBACK THROUGH USE

In this section, I attempt to identify some general patterns of usage which led to design responses
within RAID. With the exploratory prototype as its core, I suggest that RAID is well suited to exposing
the system to these patterns, because it is subjected to a variety of use over a long period of time.
Importantly, RAID also permits and encourages changes to be integrated back into the design.

Deluge
A rapid influx of usage can expose usability as well as functional problems. For example, when one
group was messaging with a high throughput, several stability problems arose, and people received
messages out of order, even though the total volume of messages was very low. If users are on the
receiving end of the deluge (as is the case for messaging, for example), they need to be able to stem or
redirect the flow. In the display of ‘recent’ items, a deluge can result in long lists which are not easily
browsable.

Drought
The under use (or non-existent use) of a feature can lead to flow on effects for dependant features or
might cause areas of the interface to become barren. For example, under use of location setting meant
that location-based messaging was never viable – not enough people were setting their location for it
to be useful. Within the interface, consideration needs to be given to how data visualisation takes into
account sparse or absent data. For example, the console command !find (which attempts to find a
matching location or person) successively broadens its search methods until it manages fills a quotient
of results, rather than returning zero results for a strict search.

105
 Accretion
Steady usage over time might result in scaling issues if usage results in the creation of artefacts. For
example, over time the number of photos hosted by Rhub grew, and more sophisticated controls were
needed to manage and display them. Likewise with other artefacts such as messages, tags, contacts
Reflective Agile and so on. As RAID advocates a minimal approach to implementation, it may be that such deficiencies
Iterative Design reveal themselves after time. Refactoring of internal code might also be required to increase
performance if algorithms and data structures cannot handle the quantity of data. With Rhub, several
types of data aggregation is now done periodically in the background to improve performance.

Erosion
Whilst physical artefacts might degrade from physical wear and tear and show frequency of use,
software (which this thesis focuses on) does not. Still, ‘wear’ can be exploited as design feedback. For
example, usage can be analysed to see common navigation paths or sequences of commands, which
might suggest an opportunity to design a short cut. Feedback related to inefficient usage can also
come from users too, for example the suggestion from one participant for the ability to add multiple
people to a group with a single console command.

Missteps
Mistakes will naturally happen, and not every mistake is a sign of a flaw in the design, however if
mistakes commonly occur it might be a sign of an underlying problem. For errors that are observable
or otherwise able to be logged, it is worthwhile to do so. In the case of Rhub, observing the variations
of syntax style people attempted, led to the relaxing of the parsing rules to accommodate frequent
errors.

6.3.3 LOW DISRUPTION FEEDBACK

Within the context of the RAID process, in which data is sought for a running prototype, minimising
the disruption to participant-users is important. If requests for feedback are too frequent, intrusive or
time-consuming, the designer risks alienating participants. On the opposite end of the spectrum, the
designer risks not having enough information to inform reflection and improvements to the design if
data is not sought with enough vigour. This relationship could be expressed as a ratio of data potential
to disruption. Forcing all users who access a website to fill out a five question survey before they can
use the site will have a poor ratio, because although more data might be recorded, the level of
disruption is so high that it may drive users away. Linking to the same survey at the bottom of the

106
page also has a poor ratio because although the disruption is low, few people will click the link to visit
the survey. Automatically logged data has a good ratio, because a large amount can be gathered with
no disruption caused. Qualitative-style interviews might also have a good ratio, because a single
interview can gather a lot of data, and disruption is limited to the few people interviewed. It is also
worth noting that a method with a good ratio does not necessarily produce valuable data, only Discussion
potentially valuable data. Selecting appropriate methods or refining existing methods can improve the
data to disruption ratio.
Technological systems can be instrumented, so that data is automatically collected with zero
intervention required on the part of users. This kind of data is effectively ‘free’ in that no extra cost or
burden is placed on the users, and large amounts can be gathered with minimal effort. Logged data
can be stored into a database for easy online querying and analysis, or logged to a file where the speed
of logging is of utmost importance. With the low cost of disk space, there is little concern for
collecting too much, and in any case collected data can be periodically analysed into aggregate data
sets, with raw data deleted as necessary. Logging can be done quickly and easily to get a feel for how
the system or a particular aspect of the system is being used. Even though the quantitative data does
not provide the designer with the meaning or reasoning behind usage, it can be useful to test
hypothesis and can lead on to a more exhaustive, ‘expensive’ qualitative methods later. This data is
also useful to get an understanding of longitudinal usage trends, which might not be otherwise
noticeable.
There are of course many things which do not reveal themselves in quantitative data. For an online
system, there are different approaches that can be taken to solicit feedback, for example offering a
short feedback form or providing Likert scale-style ratings for content or features in which feedback
can be provided with a single mouse click (Figure ), however the extent to which these ratings work
is an open question.

Figure . Feedback solicitation from a Microsoft Developer Network article (highlighted) and Google search
results.

107
 6.3.4 ONLINE DATA

RAID advocates rapid, agile development, so it essential that feedback is similarly rapid and agile, and
online data is one such method. Online data can be gathered automatically from a system’s logs or
database and presented in a real time fashion. Because of the ease in which data can be analysed and
Reflective Agile
Iterative Design displayed, online data is useful to establish the generalisability of observations, or to identify patterns
to explore further with qualitative methods.
Technological systems permit online data analysis and display, not only for the designer, but also
end users. This democratisation of data can assist in users’ reflective use of a system, by providing
them with information about their own, as well as group or aggregate usage. For example, with Rhub,
a public page was developed which displayed a leader board of users who were most prolific in
inviting others, creating locations and so forth. This was partially designed as a reward mechanism, so
that users who do contribute their time receive recognition, and also as a guilt mechanism, for those
that do not. As with any such social system, there is a possibility of it being ‘gamed,’ or manipulated for
selfish benefit, although this was not observed in Rhub.
Online data is usually current, reflecting usage of the system at the instant the data is looked at, or
for short-term trends, like the last week’s usage. After a design response has taken place, online data is
a useful source of feedback because of its immediacy. Error logs are a form of online data too. Using
the common UNIX utility ‘tail,’ an error log can be viewed like a scrolling teletype display, with a new
line appearing at the bottom of the screen each time an error occurs, and older messages scrolling off
from the top. During Rhub development, this viewport to system internals was kept open
continuously. When bugs were noticed, they were usually fixed within a few minutes. In many cases, I
would also contact the user who experienced the bug, and advise them to try again or I would initiate
the action on their behalf.

6.3.5 RESPONDING TO FEEDBACK

Not all feedback received will result in change. It is through reflection that the designer needs to
decide if a response is warranted and if so, the nature of the response. It is impossible to create
concrete ‘rules’ for this process, for any such rules would define the rules for design itself. Through the
development of Rhub, I used three considerations when judging a response: generalisability, spirit and
constraints.

108
 For an investment in design to be worthwhile, there needs to be a certain level of generalisability. It
is often difficult to establish the a priori generalisability of a response, in which case the designer can
perhaps try a more modest design response, and allow further feedback to guide subsequent response.
Responses should adhere to the spirit of the design, and here the design motto (p ) is of utility. A
system should not do everything just because it can, as elegance and usability will likely suffer. Discussion
Modern software systems can stay true to a central tenet yet allow for divergent functionality by
allowing third parties to develop plug-ins or other services that reuse the system in some manner.
Rhub supported a series of application programming interfaces (APIs) some of which were used by
participants to provide additional functionality, such as a mapping page and external photo gallery.
Pragmatically, resource constraints can limit how an issue is responded to. Time, cost and
technical requirements might prohibit the scope of a response or preclude one altogether.

6.3.6 STOPPING CASE

Iteration within RAID will need to conclude at some point, so when should this take place? Nielsen
() suggests that at least three cycles are required for an iterative process to be effective, however
he leaves open the question as to how many iterations would be required to achieve ‘perfect’ usability.
Perfect usability is an impossible goal, and I would suggest the law of diminishing returns applies – at
some point, the investment in small incremental changes does not yield enough benefit to make it
worthwhile. Incremental changes – “getting the design right” as Buxton and Sniderman phrased it
(), can only go so far within the framework of that particular design. At some point, a radical shift
might be required, in essence, starting a new design from scratch, or “getting the right design.” This
new design will no doubt introduce regressions; however can be designed with the accumulated
experience, reflection and insight that the previous incarnation provided.
In the design of Rhub, several features reached limits to their iterative improvement and needed
‘resetting’ to a new design in order for greater gains to be realised. Making design resets tractable
requires having a sound systems foundation to permit this degree of change without impacting other
areas of the system.
Ultimately, the designer needs to judge, based on the available resources and potential benefit, if
there is merit in continuing to make changes to a design, be they incremental improvements or a
radical reset.

109
 6.3.7 APPLICABILITY OF THE METHOD

The applicability of RAID beyond this single prototype is a pertinent issue. Identifying what scenarios
RAID is applicable for, how it might work and its usefulness are important avenues of inquiry. Lacking
alternative case studies beyond the major context of Rhub, this discussion will have a hypothetical
Reflective Agile
Iterative Design nature; however it does identify opportunities for RAID to be applied elsewhere.
Essentially, RAID is a combination of agile methods and action research, or looked at another way,
the application of action research to the software domain. Resultantly, the discussion has focused on
software systems. Software is a dynamic medium, and as such supports the agile and iterative
components of RAID well – there are no requirements for tooling and distribution of changes can take
place automatically. Server-side software, such as websites, are even more appropriate, as changes to
the system do not require distribution at all. Only the server needs to be changed, and instantly every
client is using the modified system.
RAID uses rapid, iterative change to explore the design space, with feedback from use harnessed to
guide the direction of change. It is this ongoing cycle of design, feedback and reflection through which
design responses are made, improving the sociability, usability, functionality, insight, and accessibility
of the system. RAID therefore is limited primarily by the malleability of the artefact being designed. If
the artefact is not easily changed, then the benefits of the RAID will be diminished.

6.3.8 BUGS

As in any large system, Rhub had a number of bugs at any one time. These were usually identified by
entries in the error log, but were occasionally reported by people as well. Although there was a
‘Feedback’ link at the bottom of every page, few users took the time to send a notification when there
was a problem, so having good error logging was critical to identify problems. A major priority was to
ensure the reliability of the system, particularly the messaging aspect. If users could not rely on Rhub
to distribute their messages, its value would drop significantly, they might choose alternatives and it
would be difficult to convince them to use Rhub again. There were a several cases where Rhub did not
deliver messages as it should have, and in these cases, restoring functionality was a high priority, and I
would usually manually ensure messages got delivered, or notify the sender that something had gone
wrong. I would usually notify people that I had noticed they had encountered a bug, that I was
working on it, and would ensure their message would be sent at a later time.

110
6.3.9 SOURCE CODE MANAGEMENT

The prototype’s source code was stored with Subversion (http://subversion.tigris.org), a source code
management system (SCM). The SCM allows changes to take place to a code base in a managed manner,
allowing authors to ‘roll back’ to a prior version, branch changes and makes group development of a
Discussion
single code base significantly easier. After changes have been committed to the repository (hosted on
the same machine as the web server), they are automatically checked-out on the server to a staging
server, so that functionality can be verified using the live database. If no errors are noticed, a web-
accessible script is called which then updates the live website with the changes in the code. In this way,
changes to code that break when run on the server environment or using live data can be fixed before
users are affected. Copying changes from the staging area to the live area takes place in seconds so
users do not notice any down-time. If any errors reveal themselves afterwards, they can be fixed using
the same process, or the code can be rolled-back to a prior revision.
Prior to using SVN, changes were simply copied straight to the website, and after verification of
correctness, ‘pushed’ so that changes were publicly available. This hindered development as it was
difficult to synchronise changes when modifications were made from different computers. From a
safety perspective, the method did not offer automatic revisions, so using a prior revision was a
manual process. Once properly integrated into the development workflow, the use of SVN was a major
productivity boost.
The early stages of development and initial deployment was not done using a source code
repository system, so unfortunately statistics on development are only available from June , which
fails to capture the most active period of the prototype’s development. By June  the system was
considered stable and relatively feature-complete, so the statistics shown represent further iterations
and bug fixes of the original design. Over  weeks of the data sample (June  to September ),
excluding a holiday period in September , there was an average of eight ‘commits’ per week. A
commit is when one or more changes to the system’s code is committed to the repository and made
live on the public website.

111
 Source Code Respository Activity

Commits LOC ('000)

50 140
120
Reflective Agile 40
Iterative Design 100
30 80

20 60
40
10
20
0 0
Jun Jul Aug Sep Oct Nov Dec Jan Feb Mar Apr May Jun Jul Aug Sep
06 06 06 06 06 06 06 07 07 07 07 07 07 07 07 07

Figure . Source code repository activity over time. Commits (left axis) and Lines of Code (right axis, ').
Earlier intensive development did not use repository, and thus is not displayed.

6.4 Conclusion
Social systems design calls for a reflective, exploratory approach to their design. Exploratory
approaches in turn demand agile development, yet there is no cohesive framework which combines
the two. In this chapter I introduced Reflective Agile Iterative Design (RAID), a first step towards such a
framework, which integrates elements of Action Research (AR) and agile development. Modern
commercial web development appears to follow a similar approach as have some academic studies;
however there is little discussion about the methods they employed.
RAID consists of three steps, which are performed in frequent quick iterations around a
continuously-deployed exploratory prototype. The prototype is the core around which activity takes
place. The first step, design, involves forming the initial prototype, and shaping it over time. In the
second step, feedback, the designer works to coax information from the prototype and participant-
users as well as being aware to unsolicited forms of feedback. In the third step, reflection, the designer
takes a pause, to digest feedback with respect to the design and users and formulates a design
response, which might then lead back to the first step with further design and implementation.
It would be beneficial to develop a criterion for judging the success of the design in meeting the
five goal themes of sociability, usability, functionality, insight and accessibility. It is however, beyond
the scope of this thesis to address this beyond a qualitative, reflective appraisal. It is also difficult due

112
to the subjective nature of the themes – what is highly sociable for one person’s use might not be for
another.
Four case studies (within the context of the single system, Rhub) were discussed to demonstrate
RAID in practise. The cases, each a major feature of Rhub, demonstrate the degree of change which can
take place, and highlight how feedback is used within development. Conclusion
In the discussion section, I identified several key issues of the method. Because the design is
dynamic, communicating change to the users is important so the disruption caused by changes is
minimised, and also so that users can take advantage of changes. Feedback is a critical part of RAID,
and it takes many forms. Some feedback might need to be explicitly requested, some might need to
extracted from user behaviour, some might be offered to the researcher and some might need to be
looked for in conversation. Five patterns of use were identified which may produce useful feedback:
deluge, drought, accretion, erosion and missteps. Not all feedback can be acted upon however, and the
designer’s role is to formulate an appropriate design response for the situation.
Reflective Agile Iterative Design has been a highly effective framework for the development of
Rhub, and it is a useful step towards the formalisation of a design method which embraces the highly
iterative, agile nature of modern development, particularly that of social, web-based systems.
In the next chapter I outline a number of studies conducted to explore the research questions.
These studies all build upon the prototype developed using RAID.

113
Reflective Agile
Iterative Design

114
7 S t u d i e s & R e s u lt s

7.1 Introduction
In the previous chapter, I outlined the design framework used to develop the prototype Rhub. The
basis for this exploratory prototype approach was argued in chapter four, and the system itself was
described in chapter five. Attention is now drawn towards how I went about exploring and
understanding the use of the prototype, and related issues. Here I focus primarily on describing the
methods used, presenting short quantitative results and reflecting on the methods. In the next chapter
I will discuss the themes that arose from these studies.
After deployment of the first iteration of the prototype, people began to use it, and it started to
become integrated into one social group in particular (described later). Whilst many observations
could be made about how the system was being used, from both an internal view of the system as well
as externally observable usage, the meaning behind usage needed to be explored. For example, why
certain behaviours were taking place, or why particular features were under-used. Whilst the system
was under further development and being actively used, a series of studies were carried out to better
understand it. Qualitative interviews were held with participants on a one-on-one basis, the first being
conducted approximately six months after the system was first deployed. The interviews provided
very rich data, and provided early insight into themes that were to remain evident throughout the
entire study. To understand people’s everyday context better, a ‘quiz’ was devised. Quiz questions were
delivered using Rhub on a random basis and were a mixture of open-ended and closed questions;
however, all asked the subject about their current context. The quiz was not designed to produce
quantitative data, rather to inform a general understanding of the type of environment Rhub users
find themselves in. Finally, a participatory design workshop was held, approximately  months after
deployment, which aimed at developing themes of usage from the participants themselves.
By using a multi-method approach, I combined quantitative logged usage data with qualitative
insight, thus providing not only the how but also the why. This knowledge was harnessed using RAID
(chapter six) and folded back into the design process, producing ongoing change and improvement in
the prototype. Taking a general, exploratory approach allowed me to cover a broad spectrum of

115
 themes. Given more time, particular aspects of usage might be followed-up through in-depth studies
to provide greater statistical confidence and a more thorough qualitative understanding.
In this chapter, each study is detailed in relation to its participants, method, results and a
discussion on the method. The first study is the prototype, followed by the reflective journal,
Studies & Results interviews, quiz and workshop. The chapter concludes with a general discussion of results and
reflection on the methods used. The following chapter discusses themes that arose from the studies in
further detail.

7.2 Prototype
The most significant study was the design, development and deployment of the prototype. It was
constructed over a four-month period and then deployed. Although live and accessible on the
Internet, only people invited to join the study could create accounts and use the system, whereas
others could only read public data. The deployment ran for over one and half years, over which time
the prototype was in active use by participants. A full description of the prototype is provided in
chapter five.

7.2.1 PARTICIPANTS

Participation was limited to people invited by an existing participant. Initially, the first people invited
to join were my own friends and colleagues. Once the system became stable, I encouraged these
people to invite others, and the user base grew as a result. There are now three levels within the social
network, or to phrase awkwardly, someone I invited (level ), invited someone () who invited
someone () (Figure ). Participants are mostly university students or of student age. Once invited,
each participant is required to consent to their data being used for research purposes before they can
use the web interface. Users who did not consent could still send and receive messages via text
messaging; the subsequent analysis and discussion excludes these people’s messages. Incentive to
participate came through three means: one, most participants were friends, and therefore saw it as a
way of helping my work; two, participants could send group text messages for the cost of a single
message; and three, people found the prototype useful and participated because of the benefits it
offered.

116
 Prototype

Figure . Invitation graph as of October .

 Random numbers are used in place of user names, with the root
inviter, myself, denoted here as . Reprodu
uced larger in the Appendix A.

7.2.2 METHOD

As discussed in chapter , the prototyp

pe was designed as a platform on which smaller expeeriments are
run or probes deployed. The system was
w instrumented to collect data from participants’ ussage, such as
messages sent and received, objects accessed, sign-ins and console accesses. Data was logged to a
relational database and plain text filess. Scripts were written so I could get a representatiion of short-
(weekly) and long- (monthly) term trrends in usage. The error log, which recorded erro
oneous input
from users (and the system’s response) as well as internal errors, was monitored on a daily
d basis –
typically continuously – through officee hours.
Much of the data gathered is of a quantitative nature, and analysis is straightforward
d, however I
also analysed messages qualitatively. T
The content of  random group messages from a single group
was analysed using an ontology adaptted from Farnham and Keyani (). The ontologyy was slightly
expanded to include categories not prresent in the original ontology yet represented in th
he data. One
or more labels were used to describe the
t intent of the message, such as coordination or ch
hat as well as
noting of references contained within
n messages, such as time or location. Verification off labelling by
external researchers was not performeed for privacy reasons. Comparison with other grou
ups’ usage is
hampered because they were little useed, and there are few messages to analyse. However, analysis was

117
 completed for approximately  messages from two other groups, with full results presented in
chapter eight.
Being a member of the most active Rhub group, I was an ‘embedded researcher’ able to observe
dimensions of usage not captured by data logging. In this role, I observed how people used Rhub ‘in
Studies & Results the field’, chatted with users about Rhub and was privy to many spontaneous conversations that took
place around Rhub. Thoughts and observations were recorded in a reflective journal (discussed later)
and informed my general sense of how Rhub was being used. Additionally, this embedded researcher
position has allowed me to be a facilitator, addressing ‘social requirements’ for adoption (Bullen and
Bennett ). As a facilitator, I played an active role in teaching people about Rhub, and encouraging
people to use it. Facilitation was particularly pertinent when the prototype was first deployed, but as
time went on, this task was largely unnecessary because new members could observe older member’s
usage and talk to them about the system.

7.2.3 RESULTS

The system was first deployed in February , with  initial members. By September  (the
period to which results are reported in this section),  participants were registered, , messages
were dispatched,  groups created, , photos uploaded,  locations defined and , tags
applied (Table ). This active use of the prototype relied on a significant engineering effort. Over
, lines of code were produced for the server alone. Detailed analysis of Rhub’s usage,
particularly messaging and presence is provided in later sections. In the statistics quoted, my own
usage of the prototype has been excluded from analysis, unless otherwise noted. On average there
were  sign-ins to the site each week ( per day) - that is, a registered user visited Rhub and entered
their username and password, and the user population grew over time (Figure ).

Number of registered users over time

160
140
120
100
80
60
40
20
0
02.06

03.06

08.06

01.07

02.07

03.07

04.07

05.07

06.07

07.07

08.07
01.06

04.06

05.06

06.06

07.06

09.06

10.06

11.06

12.06

Figure . Number of registered users over time.

118
Table . Overview of user-created items as of September . I uploaded a large number of photos on others’
behalf, so the low level of user-created items is not representative for this field.

Item Total Total

(incl. author) (excl. author)
Prototype
Messages dispatched 54,665 52,467
Group messages 2,236 2,025
Photos 1,161 502
Tag applications (excl. contact tags) 1,045 670
Contact relations 950 874
Invitations 158 117
Locations 142 64
Location aliases 58 29
Sets 51 40
Groups 43 29

User participation
Two measures were used to determine user participation. The first was the ‘login rate,’ which takes the
total number of times the person had logged in divided by the days the person has been active for
(determined by their last login time or last time they received a message). The login rate thus
represents a person’s average logins per day, over their entire usage history. The second was the ‘lurk
factor,’ a number between  and  which is the relationship of group messages a person receives to the
number of group messages the person sent. A lurk factor of  would be someone who never sent any
messages yet received some, and a lurk factor of  would be a person who sent one message for every
message they received. For this analysis, data for  people who never received a message were
excluded, with  people remaining.
Most people averaged under . logins per day (Figure ), with only a handful of people having a
higher average. A quarter of the sample size ( people) never logged in, yet were receiving group
messages. Usage by channel (Figure ) per hour of the day was roughly similar; however, the web was
used more during office hours.

119
 Average logins/day frequency
76

Frequency

33
Studies & Results
9
4 3 2 0 0 0 0 1

0 0.25 0.5
.5 0.75 1 1.25 1.5 1.75 2 2.25
25 2.5

Average number of logins/day

Figure . Logins/day frequ

uency.  people have never logged in yet receive messages.. (n=)

Channel Use by Hour

IM SMS Web

300
Accumulated usage

200

100

0
0 1 2 3 4 5 6 7 8 9 10 11 12 13 14 15 16 177 18 19 20 21 22 23
Hour

Figure . Usage of IM, SM

MS and Web by hour of the day.

A large number of userss ( of sample) sent no messages (a lurk factor o

of , Figures  and ), yet
were receiving them. Wh
hen plotted (Figure ), a reverse Zipf curve is eviden
nt, with a small number of
users being responsible ffor a bulk of the sent messages.
The lurking factor is not a proper representation of actual social lurkingg. Rather it only indicates
peoples’ group messagin
ng behaviour on Rhub. People who do not send messages still read them and
act upon them, for exxample, by attending social events. Because this analysis looks at group
messaging, the frequenccy is invariably skewed toward the low end of th
he scale because a single
message sent might result in tens of messages received. Future work might lo
ook at lurking on the basis
of conversations within group message streams rather than message totals, for example defining
lurking by how often a usser participated in group conversations.

120
 Lurkin
ng Frequency

60
Frequency

42

13 Prototype
2 1 1 2 2 5
0 0 0

0 0.1 0.2 0.3 0.4 0.5 0.6 0.7 0.8 0.9 <1 1

Lurk facttor (1=complete lurker)

Figure . Frequency of different of lurkiing factors.  people have never sent a group messagee yet received
messages (n=).

Lurking facctor across user population

1
0.8
Lurk Factor

0.6
0.4
0.2 a b c

0
1 7 13 19 25 31 37 43 49 55 61 67 73 79 85 91 97 103 109 115 121 127
Users

Figure . Lurking frequencies plotted (n=

=). Region A represents users with a low lurk factor,, B represents
users with a medium lurk factor, C represeents users with a maximum lurk factor.

Photos
Photos were often uploaded after a gro
oup activity. Of the  users who uploaded photos (b
besides their
profile picture), they uploaded an aveerage of four photos each. A set (or ‘gallery’) would
d be created
within a particular group, and photoss uploaded. Other people might contribute to the seet with their
own photos, or leave comments. Peop
ple tagged photos, typically using them to describe who was in
the scene or characterise the photo in
n a humorous manner. One of the more prolific photto uploaders
previously used a group email to distrribute photos he had taken. He preferred using Rhu
ub because it
was quicker to do, gave his pictures a w
wider audience, and allowed others to leave commen
nts.

121
 Locations
Of the  users who created locations, an average of . locations were created by each. Some were
created out of necessity, for example so that the location could be used in conjunction with the
presence feature, but many were made for sharing with friends, for example letting others know of a
Studies & Results good restaurant. Locations have geographic coordinates, address and contact information, image and
free form description (see Figure , p ). The description was meant for an objective, neutral
overview of the location. However, people often used it to editorialise about the location, stating what
they liked and disliked about it.

Tags
Rhub’s architecture allows tags to be applied to any type of user-created object; however, the interface
only exposes tagging for locations, groups, photos and contacts. Tags typically take the form of single
words, or multiple words separated by hyphens. With the exception of those applied to contacts, tags
applied objects are viewable by others. Tags are hyperlinked, allowing objects with the same tags to be
easily navigated, regardless of their origin. Nearly all tags were applied to photos or contacts, with few
being applied to locations or groups. When use of tags is analysed with respect to the number of
objects that might potentially be tagged, however, we see that locations and photos had the highest
ratio of tags to objects.

Table . Tag applications per object type (excluding tags or objects I created)

Number of Number of Tags-to-

tags objects objects
Locations 90 64 1.41
Photos 560 502 1.12
Contacts 628 874 0.72
Groups 20 28 0.71

Because of the small number of groups, tagging for discoverability was not necessary. With locations
and photos on the other hand, tags were used extensively so items could be easily retrieved as related
sets. Tags applied to locations often reflected the type of cuisine for a restaurant, while tags applied to
photos often indicated who was in the photo.
Tags worked slightly differently with contacts. Firstly, the tag ‘friend,’ which is applied to contacts
by default, grants additional privileges within someone’s social network. For example, a user might
allow only friends to see their mobile phone number. For other objects, there is no inherent meaning

122
in the tags, and tags are treated as opaque values within the system: they are made by users, for users.
Secondly, tags applied to contacts are private and cannot be viewed by others, so it only has private
benefit.

Groups
Prototype
A total of  groups were created, for a number of purposes (Table ). Small groups of friends
created groups to organise events, people created groups for topical discussion around music and
film, housemates used groups to communicate with each other and so on. Some groups were
developed for a transient purpose, such as the  FIFA World Cup or a group of friends going on
holiday together. The most active groups tended to be those that supported communication or
coordination amongst a group of people that had pre-existing social ties.

Table . Categorisation of groups (including author-created groups).

Type or orientation Quantity

Activity 17
Topical discussion 8
Friends/social 6
Temporal 5
Housemates 3
Work 2
Other 2
Total 43

Activity within groups varied (Figure ), with a few groups constituting the majority of usage, and as
so-called “long tail” (Anderson ) of many groups with little usage. The top six groups (Figure ),
in terms of messaging frequency, were given anonymous monikers that will be used throughout this
thesis. It is useful however, to sketch briefly the purpose and character of the groups:
Alpha: The primary group for a university sporting club ‘Orange’ and focus group for this study.
The club mostly consists of international students, who typically stay for a single semester. Many of
the international students were invited to Rhub by existing club members, and used it whilst here, but
after returning home might only periodically check the website, if at all.
Beta: This group was created by a Rhub member to discuss the  FIFA World Cup. After the
World Cup finished, the group lay dormant. Members came from the creator’s pool of friends, many
of whom were also members of Alpha.

123
 Gamma: Created byy an Alpha member, Gamma was for a particular training
t group within the
sporting club.
Delta: As membersh
hip of Alpha grew, it became apparent that a new grroup was needed that was
focussed on sport, rather than social activity. Thus, I created Delta, which was
w used for spontaneous
Studies & Results game organisation and discussion
d of competitive events. The majority of D
Delta members were also
members of Alpha.
Epsilon: This group was created for the executive (or management) of the
t sporting club to use to
discuss organisation of th
he club. All members of Epsilon were members of Alpha,
A and most were also
members of Delta.
Digamma: Memberss of the research group I belong to were invited to tthis group. Because of the
low level of social cohesion, members did not use it to an appreciable degree.

18.2
16.1
Messages sent per week

5.5
3.11
1.8 1.3 1.3 1.2 1.1 0.8 0.7 0.7 0.6 0.5 0.5 0.33 0.2 0.2 0.2 0.2

1 2 3 4 5 6 7 8 9 10 11 12 13 14 15 16
6 17 18 19 20

Groups

Figure . Average weekly messaging

m activity for the most active  groups.
30

25

20

15

10

0
alpha beta gamma delta epsilon diagamma

Members Avg msgs/wk

Figure . Group size and average

a messaging for the top six groups (Alpha to Digamm
ma).

124
Feeds and external services
Feeds allow users to stay updated with changes that happen on the Rhub website. While all modern
web browsers now include functionality for subscribing to feeds, their use is limited. Rhub provides
feeds for several types of content, allowing users to subscribe just to channels of interest, such as
messages from a particular group, posted photos or aggregate feeds that combine data types. Only Prototype
four users subscribed to feeds.
Feeds and links from external services could be associated with a user’s profile. This feature was
used to a small degree (Table ):  users linked one or more external services to their profile. I
believe the small amount of usage is because most people do not use such services, even though they
are considered popular within the broader tech-savvy community.

Table . Linking of external services and accounts to Rhub profiles.

Service Users
Homepage 11
Delicious (bookmarks) 4
Weblog 4
Flickr (photo sharing) 2
Total unique users 15

Messaging
Participants used Rhub in a sustained manner over a long period, suggesting usage was not due to
novelty (Figure ).

60%
50%
40%
30%
20%
10%
0%
1 3 5 7 9 11 13 15 17 19 21 23 25 27 29 31 33 35 37 39 41 43 45 47 49 51 53

Figure . Percentage of active users who sent a message, per week. The spike at week  corresponds to the FIFA
World Cup, the trough at week  with a system failure while the author was away.  users are represented by
week . ‘Active user’ is defined as a user that logged in, or sent or received a message that week.

Much of this discussion centres on the usage of Rhub by the largest single group, Alpha. As a result,
the generalisability of the findings may be limited; however, I believe it is still a good illustration of

125
 how a group with existing social ties can use a mobile social system. Alph
ha, over the course of the
study, averaged  messaages per week with an average of  members. The mean
m weekly message rate
for all groups was  (staandard deviation .). Messaging throughout the week
w was relatively similar
(Figure ), with a spikee evident on Thursday, which is a popular night for students to go out, and a
Studies & Results day that Alpha has weekly events. During the day, messaging appears to rise to a peak during the
afternoon, and taper off late
l at night (Figure ).

23%
18%

12% 12% 13% 13%

9%

Sun Mon Tue Wed Thur Fri Sat

Figure . Messaging by dayy of the week.

12%

6%

0%
0 1 2 3 4 5 6 7 8 9 10 11 12 13 14 15 16 17 18 19 20 21 22 23

Figure . Messaging by hour of the day.

Messages could be sent to Rhub for distribution to others by any channel ssupported by the console,
such as instant messagin
ng, text messaging, email or the web. When it comes to actually forwarding the
message to recipients,  of messages were delivered via text messaging, 
 via instant messaging,
 via email and  via tthe web.

Message goals
Participants utilised messsaging in several ways within Rhub. Analysis of  random messages sent to
the group Alpha shows that participants mostly sent messages for coordinatiion (Table ).

126
Table . Content analysis for  random messages from group Alpha.

Family Categories
Coordination (70%) Invitations (28%)
Questions (18%) Prototype
Commitments (17%)
Reports (12%)
Directives (6%)
Buzz-building (4%)
References (50%) Location (25%)
Time (24%)
Activity (23%)
People (13%)
Status/presence (11%)
Social Bonding (30%) (No significant subcategories)

Social bonding (messages that have no particular coordination or organisation goal) was less prevalent
( of messages) than coordination messages (). Coordination messages were further broken
down into subcategories. Frequently, an invitation or idea is sent: “who’s getting funky nite? I finish
work soon!” ( invitations) which is usually followed by group negotiation of a time and location.
During this negotiation, some will indicate whether they will come ( commitment); query aspects
of the plan ( questions); direct others on a course of action “[…]RSVP me before Wednesday!” (
directives) or suggest alternative plans. While the event takes place, members might send messages to
report on how it is going ( reports), often with an aim to entice more people to come:
“Cookamungas anyone? it's got people!” Messages might also promote or hype an upcoming event (
buzz-building), for example this response to a wrestling themed party invite: “Hulk Hogan is back in
fashion baby.”
I also looked at references contained in messages, identifying references to location ( of
messages), time (), people (), status () and activity (). Half of all messages contained a
reference of some type. Messages were tagged as a status reference if the sender included information
about their current state or context, for example “Short pub crawl? Exam tmro but i'm sooo bored.”
Status was often included as an ‘excuse’ when declining invitations, or to fill in context for others. Not
surprisingly, activity was often referenced in coordination messages, for example suggesting a
potential event: “I'll be well keen in three hours for drinking and or football.”

127
 Analysis was also done for two other groups, Gamma ( messages) the training group and Delta
( messages) the competitive players group. These two groups were chosen because of their
sustained usage over a long period, and large number of messages. This analysis demonstrates the
difference in usage amongst groups, which will naturally occur when groups have different
Studies & Results compositions and different purposes (Tables -). Generally, all three groups utilised messaging
predominately for coordination. Alpha and Delta had similar source mediums to each other, whilst
Gamma had a higher level of web usage. Alpha appeared to use less referencing in messages, while
Delta almost exclusively referenced time and activity.

Table . Message goals: coordination and chat for the groups Alpha, Gamma and Delta.

Alpha (%) Gamma (%) Delta (%)

Coordination 70 93 98
Chat 30 9 4

Table . Message source channels for the groups Alpha, Gamma and Delta.

Alpha (%) Gamma (%) Delta (%)

Text Messaging 65 48 68
IM 3 0 13
Web 32 52 20

Table . Coordination forms for the groups Alpha, Gamma and Delta.

Alpha (%) Gamma (%) Delta (%)

General 3 6 0
Invitation 28 25 25
Reports 12 10 43
Questions 18 21 30
Directives 6 6 7
Commitments 17 45 7
Buzz-building 4 4 0

128
Table . Message references for the groups Alpha, Gamma and Delta.

Alpha (%) Gamma (%) Delta (%)

Location 25 14 0
Time 24 46 54
People 13 22 0 Prototype
Activity 23 36 29
Presence/status 11 19 4

Fixed versus mobile usage

To understand differences between fixed and mobile usage of group messaging, message content was
analysed with regard to source channel (Figure ) and destination channel (Figure ). Instant
message, email and web messages were grouped as ‘computer’ ( in total) and SMS messages were
grouped as ‘phone’ (). I generalise that messages sent from a computer are likely from a fixed
location rather than mobile. Overall, there is little difference between fixed and mobile-sourced
messages in the occurrence and types of referencing, and levels of coordination and chat. Mobile-
sourced messages however contain less reference to time and activity, perhaps as they are ‘in-context,’
in the midst of activity, whilst fixed-location usage relates more to future activity where time and
location must be defined. Invitations were more likely to be sent using a computer, echoing data
showing initial messages were more often sent using the web (see later discussion). A slightly higher
percentage of confirmation and report coordination messages were sent from a mobile.

129
 Content variation across source channels
Phone (n=325) Computer (n=175)
80%

60%

Studies & Results 40%

20%

0%

Confirmation

Invitation
Status
Activity
Overall

Time

Directive
Location

Person

Overall

Report

Question

Overall
References Coordination Social

Figure . Message contentt across phone (SMS) and computer (IM, email and web) sources.
s Percentages show the
number of messages categoorised out of the total number of analysed messages for that source, such as  of
analysed messages from a p
phone contained a reference to location (n=).

Group instant messsages were processed using a basic algorithm, assembling messages into
conversations based primarily on the temporal difference between subseq
quent messages. Applying
this algorithm on , messages ( weeks of usage) produced  con
nversations. Conversations
tended to happen within
n a single channel () or a pair of channels (), with only  taking place
over three channels and
d no conversations taking place over all four sup
pported channels. This is
probably a reflection on the ubiquity of mobile phone access ( of all messages
m were received via
text messaging). After reeceiving a Rhub message on their phone, users foun
nd little reason to go to a
computer to compose a reply message:  of replies were sent using a p
phone, while only  of
replies were sent using the
t web yet the percentage of initiating messages forr both mediums is similar
(Figure ).

130
 Message sources
Initiating Reply
65%
47% 44%
27%
9% 8%
0% 0%
Prototype
Email IM
M Web Phone

Figure . Initiating and reply message soources.  of all replies were sent using SMS while the web
w was used
(proportionally) more for sending initial m
messages (n=,).

M
Message destinations
84%

1% 3%
% 12%

Web Emaail IM Phone

Figure . How group instant messages were delivered (n=,).

Presence
Rhub allowed people to set their currrent location (either referencing an already defined location, or
using an arbitrary text string) and a sttatus message. Over time, this feature evolved (see discussion
d in
chapter ), becoming more accessible and proactive in notifying others of presence. Usagge over time
(Figure ) shows an increase in acttivity from March , when design refinements were made.
People tended to set their own presencce after noticing other people setting theirs (Figure ),
 however
generally people would set their preseence at the beginning of the day (Figure ), which
h would also
produce a high level of temporal co-occcurrence.

131
 Usage over time

40 Status Location

Usages 30

20
Studies & Results
10

4/1/07

15/2/07

15/3/07

12/4/07
26/4/07

24/5/07
22/6/06
6/7/06
20/7/06
3/8/06
17/8/06

14/9/06
28/9/06
12/10/06
26/10/06

23/11/06
7/12/06
21/12/06

18/1/07
1/2/07

1/3/07

29/3/07

10/5/07
31/8/06

9/11/06
Figure . Setting of status and location over time.

Temporal co-occurrence
Status Location
150

100
Usages

50

0
<1 1 2 3 4 5 6 7 8 9 10 11 12 13 14
Hours after prior setting by another user

Figure . Temporal co-occurrence of status and location setting. Presence was usually set within an hour of
someone else setting his or her presence.

132
 Presence Usage by Hour of Day

Status Location

100

80
Prototype
60
Usage

40

20

0
7 8 9 10 11 12 13 14 15 16 17 18 19 20 21 22 23 0 1 2 3 4 5 6

Figure . Presence usage by hour of the day, showing a spike of usage in the morning.

Summary of results
Concerns about the performance of the prototype meant that for the first six months of the
deployment, the prototype was gathering less data than later, which unfortunately resulted in early
usage not being captured. This concern turned out to be unfounded and the prototype was still
performant with extensive logging. I also increased the specificity of logging when it was realised from
early inspection that useful information was not being captured.
Usage data and observation both show that people primarily used Rhub for messaging, with the
other main features often acting as a supporting role to conversation. For example, an event might be
organised over group messages, and afterwards photos posted to the group. Group messages were
used primarily for coordination rather than chat. Locations defined by users in Rhub were often
referenced in conversation, or formed part of the group’s social tacit knowledge of places. Tagging,
which is a popular and commonly implemented feature in web-based social systems was frequently
used for public information for which a browsing aid would be beneficial. Presence information was
mostly set in the morning, and usage increased as design alterations were made (see the discussion
chapter for further details). Usage was sustained over a long period of time, indicating use was not due
to novelty effects. A quarter of users received messages yet never logged in to the website, and nearly
half of users received messages yet did not send any themselves. Whilst there was little difference in
the messaging characteristics of messages sent from computers versus those sent from mobile phones,
mobile-sourced messages were less likely to contain reference to time and activity. Considering their
proportional usage, conversations were more likely to be started from the website than from a mobile
phone, although most messages were received and sent via text messaging.

133
 7.2.4 DISCUSSION

The exploratory prototype as a method has been discussed in chapter six, so it shall not be repeated
here.

Studies & Results

7.3 Reflective Journal
Throughout the course of the study, I kept a chronologically sequenced reflective journal, recording
notes, observations, thoughts and ideas. The journal assisted the reflective practice advocated by the
action research method. Entries are grouped into fortnightly periods, each one numbered
sequentially. Because I was reflecting openly and frankly on observations, and names were not
anonymised, the journal was kept confidential; however, an edited and anonymised version was
produced for my advisory team.
Setting a goal of a weekly entry was a useful technique to give myself pause to reflect on what had
happened that week. Observations were drawn from the live data as well as ‘in the field’ (I was a
member of the busiest Rhub groups), and were then recorded in the journal. Whilst data was being
logged by the system irrespective of the journaling, recording contextual information about the
situations that led to Rhub being used in a particular way, or triggering a particular design reaction
was important whilst it was still remembered.

7.4 Interviews
Approximately six months after Rhub’s original deployment in July , I began interviewing
participants. Interviews were conducted intermittently over several months, the last conducted in
March .

7.4.1 PARTICIPANTS

Participants were selected based on their availability,  in total. I knew all participants personally,
which assisted in gaining their time however may have had an impact in how they discussed the
prototype. There were no incentives given to participate in the interviews. Those who participated did
so out of their own generosity and curiosity.

134
7.4.2 METHOD

Semi-structured contextual interviews were used to gain an understanding of how participants viewed
the prototype, usage of the prototype and other communication technologies as well. Interviews were
conducted at a place that best suited the interviewee (usually their home). Printed message transcripts
Interviews
and the participants’ own phone and devices were used as scaffolding for the interview. Audio
recordings and ink notes were made using a tablet computer.

7.4.3 RESULTS

Interviews took approximately one hour, however some stretched for as long as two. The printed
message transcripts were useful to have on hand during the interview, and I started the interviews by
asking participants to have a quick look over them. This often prompted spontaneous comment which
led into further discussion before the interview had got underway properly. Participants had their
phones with them, and several produced them to read out a recent message, or to demonstrate some
aspect of their phone, such as how they stored a prior Rhub message as a template for new messages.
Here I provide only some of the themes that emerged from interview data, which are discussed
fully in chapter eight.

Meaning in the channel

Participants thought cross-channel messaging was highly useful, particularly because Rhub managed
the contact details and the sender did not have to send separate messages for different channels. Some
likened it to instant messaging, but thought Rhub was easier because everyone didn’t have to be
online at the same time. One participant noted that he was not sure how messages are sent using
Rhub, which he found unsettling.
Participants also talked about different technology usage within their social group. One participant
described two of his friends who both refused to buy a mobile phone. One had recently relented, and
was keeping it a secret, and not giving out his number to anyone. For the other person, the social
group usually had to negotiate around him not having a mobile. A scenario was recounted to me
(names changed):

“Colin had to ask Johnny via SMS to send an email to Phil because Phil didn’t have a mobile, and
Colin was out and about and couldn’t send an email himself”

135
 Participants mostly considered the immediacy of a message to be the most important determiner for
which type of channel to use, but cost, persistence, importance and expected complexity were other
properties suggested. Participants revealed an awareness of others’ use of technology that influenced
their channel selection.
Studies & Results Face-to-face conversation was considered the best way to reach consensus, but several participants
noted the difficulty in arranging face-to-face time.
Text messaging was often used with a small group, and is useful for short directives or questions.
One participant said they used SMS when “I don’t want to talk to someone, or I want to avoid a long
drawn-out conversation.” For group messaging, one participant said he would send a message to a few
key people, and would trust that they would forward it along to their partners or friends, and word
would spread that way. One participant reported being ‘dumped’ by an SMS. Many expressed
annoyance with text input on mobile phones, preferring a full-size keyboard. People liked the instant
and direct nature of text messaging, as well as the ability for messages to be sent and received “in the
background,” whilst engaged in another activity. Some thought SMS has a better “hit ratio” than other
forms of communication: “[you’re] not aware when people will check [email] – everyone has a phone
though.”
Email was considered a formal type of writing, which required re-reading and editing. People
thought it was less intrusive than other mediums, but was non-timely, as it is never known when the
recipient will check their email. The persistency of email was also raised as an issue, as well as the ease
of sharing files through email exchange.
Instant messaging, predominately MSN Messenger, was commonly used amongst participants. The
medium was considered unreliable – one can send a message yet the person might be away from the
computer, or otherwise ignoring the message. Presence status on IM (such as ‘Away’ or ‘Busy’) was
considered to be used “for effect,” rather than a necessarily accurate reflection on the person’s status.
Like text messaging, instant messaging afforded a “background chatter” conversation of “lower level of
thought” than an email.
Phone calls, for the predominately student-demographic of interviewees, was considered too
expensive to use generally, and as such reserved for urgent or important communication.

Use & Utility

Participants considered Rhub most useful for the organisation of group events, for both organisers,
who valued Rhub’s ability to “get the word out” and also for attendees, to find out when and where
social events were happening. Several interviewees reported that not having to pay for messages sent

136
using Rhub is a benefit, and this obviously has ramifications for usage statistics. Rhub’s instant and
direct communication was considered valuable – “the only way to get a message out [on short notice]”
– and a reason to use Rhub over systems such as email.
When asked how and why they used the prototype, participants frequently cited to keep in touch
with friends. Checking the website became part of some people’s morning routine, to use as a Quiz
“procrastination tool.” For others it was an aid to “getting drunk.” Many participants reported being
aware of certain features, such as locations, tags and presence, but not finding a use for themselves.
Without Rhub, participants said they would use web-forums and email more often, but noted not all
people check email regularly, and forums require effort to check.

7.4.4 DISCUSSION

I considered the interviews a successful method, producing many interesting insights in to what
people thought of the system as well as capturing a number of useful ideas that were incorporated into
later iterations of the design. It was time consuming however to synthesise notes and transcripts into
data useful for reflection. During the later interviews it became clear that there was not a great novelty
in terms of new insight gained, so there was not a great motivation to conduct more. Had more time
been available (for both participants and myself ) it might have been illuminating to conduct follow-up
interviews six months later.

7.5 Quiz
In order to understand the mobile context further, I quizzed users - using Rhub itself - about their
current context. Each run of the quiz program was initiated on a manual basis, at different times and
days over a period of  days. I used the term ‘quiz’ rather than the conventional ‘questionnaire’ to
reflect its low-fidelity, informal character. Rather than a series of questions, a single quiz question
would be delivered on a random basis to participants.

7.5.1 PARTICIPANTS

Originally, any member of Rhub was a potential recipient of a quiz question; however, this was
changed so that only members of three groups (Alpha, Gamma and Digamma) were quizzed because
they were most familiar with Rhub as a research prototype.

137
 7.5.2 METHOD

Questions were sent using Rhub’s in-built messaging system, so they may have been delivered via
email, instant messaging, the web or text messaging. Questions were selected at random from a pool
of  questions (Table ). Participants replied to the questions as they would a normal Rhub message,
Studies & Results
either simply replying with a plain message, or using the console. In some cases, responses were not
sent properly by the participant, and were added to the data set manually. Questions were dispatched
on a manually triggered basis, with each iteration sending  participants a random question each. A
participant Bob might receive a question as the following text message:

Quiz: Where are you?

To: Bob (to reply, txt ‘>Quiz [msg]’)

Table . Quiz questions and number of responses. Questions were asked with equal probability.

Index Question Responses Response

Rate ()
1 Where are you? 13 27

2 What devices have you got at hand? 3 9

3 How many msgs do you have in your SMS and email inboxes right now? 7 15

4 How many messages or emails have you sent so far today? 10 34

5 What kind of place are you at now: cafe, home, work etc..? 4 11

6 Have you re-read an old Rhub message today? 5 11

7 Have you re-read an old email, IM or SMS today? 6 15

8 What communication devices do you have available to you right now? 1 3

9 Right now, would you prefer to get call, SMS, email or IM? 6 24

19 Right now, which would you prefer to use: call, SMS, email or IM? 2 8

11 Are you inside or outside right now? 7 16

12 If 7 is super busy and 0 is not at all busy, how busy are you now? 5 15

13 Who are you with right now? eg friends, workmates, no-one, family etc...? 10 28

14 How did you get alerted about this message: beep, popup etc...? 9 18

15 How many people are in the same space as you right now? 2 7

16 What’s your position: walking, reclining, jumping, sitting etc..? 10 28

Total: Average:
102 16.86

138
7.5.3 RESULTS

In total,  quiz questions were sent to  people yielding  valid responses from  people
(participation rate , response rate ). There was intentionally some overlap in the questions
asked for comparison purposes, such as questions  and . Two responses were removed as outliers in
Quiz
time-related analysis because the participants took an extraordinary long time to reply, thus some
analysis is based on  answers, other .
The quiz questions started to be sent out on the th of April , without prior notification to
participants, as I was interested in participant reaction. On the th of April (denoted by a thin vertical
line in Figure ) an email was sent to participants which introduced the quiz and explained its
purpose. The nine quizzes ran before the introduction have an average response rate of ., the
nine quizzes following . and the overall average for the entire set of  quizzes is .
(n=).
40%

30%
Response rate

20%

10%

0%
1 5 9 13 17 21 25 29 33
Quizzes

Figure . Response rate for each quiz (# the first, # the last, n=). Vertical line indicates when quiz was
introduced to participants via email.

Results from the quiz, like those of cultural probes (B. Gaver et al. ), serve more as illustrations
rather than hard, quantitative data. Some responses were easily quantifiable, such as “ sms in inbox,
 in email inbox” as a reply to question , however many were not, such as “heaps and heaps” sent
by another person for the same question. Because of the low response rate, the study would require a
much larger number of participants – a small population polled at a high frequency might quickly tire
of it – in order to get statistically significant data. However, the difficulty of coding or classifying
responses in a useful manner would remain. A collation of quiz results is given in the appendices.

139
 To inform design, two personas (Cooper ; Cooper et al. ; Grudin and Pruitt ) were
created from quiz data, Diana and Lachlan. These personas were used in the design process to
validate features and other changes in the design.

Diana
Studies & Results
Diana is here for six months from Germany, doing an internship at a science lab at the university. She
works typical office hours, in a relatively solitary fashion, however she likes to be as social as she can
outside of those hours. She is usually in front of a computer during the day reading papers or writing
up results, but her work occasionally requires her to be in the lab setting up experiments. On her
computer, she uses a mail client and instant messaging client that run continuously. In her bag is her
phone which she will occasionally get calls on but is mostly used for texting her friends. When she is
at home, she will use Skype to talk to her friends and family.

Lachlan
Lachlan is a full time university student, doing a business degree. Since he lives nearby, Lachlan is
often at home when there is no class, where he studies or reads random things on the web. At home,
he mostly uses a desktop computer, and on campus a notebook computer. His instant messaging client
always runs when using his computer, but he checks email manually by visiting his web-based mail
provider throughout the day. For reasons of economy, he mostly uses instant messaging or email when
he can, but otherwise will text. He tries to avoid calling at all costs.

7.5.4 DISCUSSION

In order to minimise the disruption of participants with the quizzes, mostly received as a text
message, only users from three groups formed the selection pool. This was as two of the groups used
Rhub most regularly and therefore gained the most from its use and the third was a group of academic
colleagues who were used to helping with research studies. Initially the selection pool was the entire
Rhub user base, however one member complained: the group she was using in Rhub had fallen
dormant  months prior, and when she started receiving quiz questions she thought it was
commercial spam. Thus, the pool was restricted to those who better knew Rhub was a research
prototype, and that such research activities were taking place. Questions were originally sent out to 
people per run of the quiz, but because of the low response rate I increased it to . A balance needed
to be struck between the frequency and quantity of quizzing – thus increasing chances for a response
– and the level of annoyance inflicted on participants.

140
 Questions can be grouped into six topics, and all have a similar response rate except for questions
relating to technology availability (Table ), that is, asking people what devices they currently have
available for use. Perhaps these questions, which had a much lower response rate, were too technical
and required too much effort to complete.
Personas developed from the quiz data were not used to the extent recommended by some Quiz
(Cooper et al. ). They were useful however to encapsulate trends in the data, and to personify
observed usage stereotypes.

Table . Response rate by topic

Topic (question indexes) Response Rate ()

Presence (13, 15) 29
Activity (12, 16) 22
Location (1, 5, 11) 19
Technology Use (3, 4, 6, 7) 17
Technology Preferences (9, 10, 14) 17
Technology Availability (2, 8) 6

Because the quiz attempted to capture current, in-context data, the timeliness of responses is
important. If an answer is received five hours after the question was asked (such as the case for two
responses, see Figure ), what slice of time does the answer represent? Does it tell us about the
context the participant was in when answer actually sent, or is it the participant’s recollection of his or
her context when originally asked? In this study, it is not possible to determine which, and as such
should be considered when analysing results. Nearly two fifths of people () answered within two
minutes, and seven tenths () within ten minutes.

141
 32 32

Number of responses
9
7
Studies & Results 3 4 3 3
2 1 2 2

0:00:30 0:01:00 0:02:00 0:10:00 0:20:00 0:30:00 1:00:00 1:30:00 2:00:00 3:00:00 4:00:00 5:00:00

Time taken to respond (h:mm:ss)

Figure . Response times. Answers grouped by response time (lag between a question and an answer). ::
is  seconds; :: is  hours. Note: horizontal scale is variable. N=

When considered as a research method, the quiz differs from other common approaches. We might
discuss data gathering methods in relation to the researcher (who is asking the question), the context
(the environment in which the questions are asked) and the subject (who is answering). A
questionnaire uses researcher-formulated questions, largely ignores the context, and the subject can
usually only respond within the narrow scope of the question. Situated interviews use flexible
researcher-formulated questions, allowing the context to shape the interview, and the subject is
relatively free to respond as they wish. Ethnographic methods have no strict questions per-se, with the
ideal ethnographer going into the field with few preconceptions, and the data gathered is fully
dependent on the context and the subject’s action. Methods could be placed on a scale with the
true/false questionnaire and ethnography being the extremes (Figure ): one forces the subject to
interpret the researcher’s question with only limited forms of response available, and little regard to
the context; with the other, the researcher is led by the subject and the context itself. The quiz, like
cultural probes upon which it is loosely modelled, permit playful, open responses, with interpretation
happening on the part of the subject as well as researcher.

Subject interpretation Researcher interpretation

Limited response Open response

Context largely irrelevant True/False Quiz Context highly important

Ethnography
Questionnaire

Figure . Scale for three variables with true/false questionnaire, quiz and ethnography plotted.

142
7.6 Workshop
A workshop was run with the aim to understand how participants understood persistent
communication with Rhub, how they conceptualised messaging within Rhub, how they used it for
coordination and other general observations. Four activities were conducted over a course of two
hours. Workshop

7.6.1 PARTICIPANTS

Invitations were sent to participants of the Alpha group. Workshop exercises used actual messages
from prior Rhub activity, so for privacy and logistical reasons, only one group was invited, and four
people attended. No reward for participation was given to participants other than beverages and
snacks.

7.6.2 METHOD

Four exercises were run during the workshop: Operation Nag, Sketching, Time Machine and Snippet
Card Game. Methods were designed to synthesise concepts rather than produce analysable data. This
exploratory approach (as in action research) produces change in participants and researchers alike.
The methods do not presuppose any particular interests, skills or knowledge on the part of
participants, other than related to their own usage of the system. Three of the exercises were of my
own devising to suit the particular needs of the inquiry, the fourth is an adaptation of the Video Card
Game (Buur and Soendergaard ).

Operation Nag
Coordination is the most common use for Rhub, so the Operation Nag exercise was designed so that
semi-realistic coordination could take place within the workshop environment. The scenario
presented to participants was:

"As you can see, there are a few people missing from the workshop. Individually or as a group, conceive
of the best way to get some more people to attend using Rhub, and then actually try it out. Any person
that manages to get another person to attend this afternoon will get their choice of a premium beer or a
packet of Tim-Tams"

143
 Sketching
The second exercise was designed to be a creative ‘warm-up,’ encouraging people to be creative and
free in their expression and to have users illustrate their conceptual models. Sketch ‘dialogs’ have been
shown to be a useful method to solicit reflective, rather than reactive feedback (Tohidi et al. a).
Studies & Results Sheets of paper, glue, pens, pencils, scissors and other stationary were provided. There were two tasks,
in the first, they were asked to draw Rhub; in the second, they were asked to draw how they thought a
message they sent from their phone was delivered to people within a group using Rhub. In both cases,
they were asked to try to use as little or no words as possible. After the two tasks, each participant
described their drawing to others in a group debrief.

Time Machine
To explore the role of message persistency within Rhub, I asked people to annotate prior
conversations and ‘fill in the blanks’ with context or information important or meaningful to the
messages but not adequately captured by the messages themselves. The exercise was introduced as:

“You from the past has discovered a time machine and has used it to meet you today (their future). She
has now turned up on your door step, and you want to get her up to speed with what’s happening in
your social group. To do this, you thought you’d print conversations from Rhub. But wait you realise –
will she be able to make sense of the messages?”

A large quantity of printed group messages were made available, pre-divided by conversation.
Participants were invited to browse and pick several conversations to annotate, ideally ones that they
had participated in.

Snippet Card Game

The final exercise was modelled after the Video Card Game (Buur and Soendergaard ), an
established participatory design exercise. The Snippet Card Game was the most open-ended of all the
exercises run in the workshop, with participants working in pairs to define and document their own
topic of interest.
Prior to the workshop, I printed out a large quantity of screenshots from Rhub’s web interface, the
help wiki as well as group messages. Each page was cut into snippets highlighting particular things, for
example, a print out of a screen might be decomposed according to its interface elements or semantic
meaning. The reasoning behind pre-decomposing elements was so that participants would feel more
at ease with cutting and rearranging the elements – there was not a perfect page to preserve, and to
encourage re-composition – collaging different elements together. Original copies of screens were also

144
available in case of need. Snippets were shuffled and placed into three boxes according to their size, so
that smaller snippets had an equal chance of selection as the larger ones.
Participants were grouped into pairs, given an overview of the exercise, and then provided oral
instruction as they progressed. The steps (from an instructional perspective) were:
. As a pair, pick ten random snippets from each of the boxes. Workshop
. Return to the table and group your snippets into themes, patterns, behaviours or
observations. Try to get two to four groups. It is ok to have left over snippets.
. On an index card, write down a title for each theme and a few words to describe it. Pick a
favourite.
. Introduce each of your themes to the group and show some snippets that support the theme.
. Now that all groups are aware of each other’s categories, see if you can offer a snippet to
someone else to support one of their themes, or ask for one of theirs if you think it would be
useful for your own. You are also free to decline a snippet or keep your own. [At this stage, all
the material in boxes is emptied on the table]. You can also quickly peruse the material on the
desk and select other snippets that may support your favourite theme.
. Using the available materials, construct an A-sized poster to illustrate your theme. You can
cut up, arrange or annotate the snippets as you see fit or use additional materials available on
the desk.
. Present your poster to the group, giving an overview of your theme and the design of the
poster.

7.6.3 RESULTS

Operation Nag
By using a realistic scenario and offering a prize for those that reached the goal, I hoped to stimulate
creativity and competitiveness. While no one managed to entice more people to the workshop, the
exercise did produce two phone calls and several text messages of apology. One participant used SMS,
sending individual messages to people who he thought might be interested in coming, or people he
thought should be attending. Two others sent group messages using Rhub, and the fourth sent several
individual Rhub messages. Participants used a combination of enticement (“there’s beer!”) and guilt
(“come on, this is for Clint’s PhD”) to persuade others. In the post exercise debrief, the person who sent
individual text messages noted that sometimes he was not quite sure what people’s user names on
Rhub were, so he sent texts to those he knew. Both of the people who sent individual text messages

145
 thought it more effective to send personally addressed, individually crafted messages rather than a
group message.

Studies & Results

Figure . Participants during Operation Nag.

Sketching
The first task was specifically left open-ended allowing participants to draw what they thought
important about Rhub, and how to figuratively represent it. Three participants represented Rhub as a
network or conduit between people, technology and places, the fourth drew a diagram representing
how a single message is delivered to everyone. One participant saw Rhub as something that
“smoothed over the ‘unevenness’” of social interaction and facilitated fun. He covered the rear of the
poster with bubble wrap to represent this randomness, and used pieces of felt on the front side to
represent the “crap of life” which Rhub passes through.

Figure . Two graphic answers to 'draw Rhub'.

The second task was more focussed; however, participants still had to decide what they thought
salient about the messaging process and how to represent it. Again, participants, linking technologies

146
and people, used graph-like diagrams. One participant did not have enough time to complete this
task.

Workshop

Figure . Two depictions of how Rhub's messaging works.

Time Machine
Participants approached this exercise by writing the ‘back stories’ of messages. These stories explained
circumstances leading up the messages being sent, and in some cases documenting what was taking
place while a conversation on Rhub was unfolding. For example, one following message was sent to
Alpha at . on a Saturday evening:

“I have the tv guide you fuckers”.

To most of the group, this message did not make much sense, and because the sender was often
responsible for somewhat obscure messages, it is doubtful that many were concerned. In the Time
Machine exercise, one participant explained the back story to this message. A group of four of them
(all members of Alpha) were leaving a venue and came across a newspaper. One of them wanted to
find out when a particular thing was on television the next day, so sought out the television guide. It
turned out this section was missing from the paper however. The group disbanded shortly afterwards
as they headed home, however one member came across the television guide further down the street,
and sent the message to triumphantly tell the others.
The exercise reinforced the rich, situated nature of communication, even that mediated through
text-based messaging. Some of the messages selected by participants for the exercise are completely

147
 unintelligible to those outside of the context within which the message was sent – even those in the
same group.

Studies & Results

Figure . Participant annotating messages.

Snippet Card Game

The exercise is designed to encourage reflection and critical thinking. Like the Video Card Game,
much of the value comes in the trading stage of the game. Themes’ meaning, usually vague at the
beginning, quickly solidifies as pairs declare what does or does not contribute to the theme. When a
snippet is proposed to them, pairs are forced to think critically about their own definition as well as
the meaning they hold for the proposed snippet, with debate often ensuing. In this workshop, there
was not the long extended debate that I have often observed when running the Video Card Game in
larger groups. This is possibly due to the small number of participants and the quantity of snippets,
which reduced their trading value.

148
 Workshop

Figure . Participant preparing a poster.

One pair developed the theme ‘location,’ the other pair developed the theme ‘me.’
Location was seen by one pair as the hub of Rhub activity. As such, they produced a collage of
location-related aspects of the interface such as presence, location editor, maps, location listings and
locality listings. To support location-based events, they identified two further themes: invitations, as
expressed in group messages and ‘who,’ relating to who is invited and who attends social events.

Figure . Location poster (reproduced larger in Appendix C)

The ‘me’ theme centred on how individual action within the system produces a result, such as a party.
They saw this process as a cycle. People get invited to Rhub, and are encouraged to connect to people,

149
 either by establishing contact ties with existing members or inviting new members. The next stage is
joining or creating a group of friends, then setting up how messages are delivered which finally leads
to a social ‘end product,’ such as a dinner party. Socialising from such events then leads to new
connections being made and the cycle continues. The pair placed a user’s profile page as the hub of
Studies & Results the poster – the profile page aggregates various pieces of information such as the person’s contacts,
groups, photos and so on.

Figure . 'Me' poster (reproduced larger in Appendix C)

Composing the poster also demands reflection. How are items to be arranged? What does the
arrangement mean? How should we link or separate things? What annotations are required? How do
we express the meaning of our theme? In the concluding, presentation step, groups made explicit their
design intent of their posters and also talked about their theme and explained their selection of
supporting snippets.

7.6.4 DISCUSSION

Participants were supportive of the exercises, and undertook them with enthusiasm and gusto. Only
one had previously attended a participatory design workshop. From a researcher’s perspective, the
workshop was a success. Insight was gained in how the participants viewed the system, and
participants had a better understanding of how it worked, what it could do and how their peers used
it. In the debrief, participants were positive about the experience, and said they would recommend

150
others attend if another workshop was held. It would have been beneficial to have more participants at
the workshop, but it was still productive with only four people.
In designing the workshop, I intended to ease participants into open and creative thinking, which
culminated in the Snippet Card Game, which was expected to be the most fruitful exercise. All the
exercises produced new insight and understanding in the system and its use for both myself and Conclusion
participants, however the Snippet Card Game proved most valuable. The three prior exercises
required participants to use, draw from their imagination, and annotate an existing artefact. A deeper
insight was gained however through the re-synthesis of concepts and artefacts which took place in the
Snippet Card Game.

7.7 Conclusion
To conclude, four primary studies were conducted: ) development, deployment and analysis of a
prototype; ) situated interviews; ) quizzes; and ) a design workshop. Utilising multiple methods
across the “three paradigms of HCI research” (Harrison et al. ) provide a rich multi-faceted view to
system usage and participants’ understanding.
The exploratory prototype was the major study, and served as a foundation for the other studies. A
large amount of data was produced directly and indirectly through people’s use of the system. Users
participated throughout the study, revealing use was not dependent on its novelty. Users were active
in contributing to the system by way of uploading photographs, defining locations, setting tags and
creating groups. Approximately a quarter of participants never signed in to the website and  of
participants never sent a message, yet in both cases, they were receiving messages. Participants who
did ‘lurk’ still participated in social activities and demonstrated an awareness of activity taking place
within Rhub. Most messages were sent and received using text messaging, however, people were
proportionally more likely to use the website to initiate a new conversation. Messaging was mostly
used for coordination over chat, and half of all messages contained a reference to time, location,
status, people or activity. More people used the presence feature as the design evolved, and people
were more likely to set their presence in the morning.
In-depth situated interviews were conducted to better understand how people perceived Rhub,
and to learn more about how they used technologies for social coordination and communication
generally. It was found that people saw the communication channel as being a meaningful part of the
message, and that selection of the channel was a considered action. Participants thought that Rhub
was particularly useful for organising group activity, and getting a message out to a group quickly and
reliably.

151
 Quizzes were used to understand people’s in-context use of technology and their everyday
environment. Data from the quizzes was used to develop two personas that were later utilised in the
design process. As a method, it seemed successful, with participants replying quickly to questions.
A participatory design workshop was held to synthesise ideas and to understand issues relating to
Studies & Results persistence, coordination and to explore meaning participants held for the prototype. In the
workshop, it was observed how people used a mixture of group messaging and personal messaging to
entice people to an event. In the sketching exercises, participants likened Rhub to a network that links
people in a variety of contexts, for a variety of contexts. When participants were asked to provide the
background information for messages, it was obvious that a large amount of context is missing from
messages, and their understanding is linked to the context within which they were sent. Finally, the
Snippet Card Game provided an opportunity for participants to identify interesting or salient topics
relating to Rhub, with one group developing a theme around location, the other around the individual.
Both themes were merely a focal point or axis to highlight a variety of activities that took place around
location and individuals.

152
8 Discussion

This chapter seeks to provide a thematic discussion of observations and issues relating to Rhub, and
more generally mobile social computing. In the first section, I discuss how the prototype was used and
appropriated into the group, and outline some emergent social benefit and social tensions. The next
section discusses messaging, which was the most used feature of Rhub and allows people to
communicate seamlessly as a group across a variety of channels. The third section explains how and
in what form coordination took place using Rhub, as does a statistical comparison with two other
systems. In the fourth section, a short account is given on how the presence feature evolved over time
using RAID, leading to increased usage. The console, which enables the cross-channel interaction
aspect of the prototype, is the focus of the fifth section, and here aspects of its usability and utility are
discussed. A number of design suggestions and considerations for social system design are provided
throughout this chapter, and in the last section, those that did not naturally fit elsewhere are listed.

8.1 MoSoSo in Action

In this section, I discuss the issues and themes that emerged from the deployment and use of Rhub.
People do not necessarily appropriate a technology in the way the designer intended. There may be a
gap between the designer’s intention and actual use, which might be positive, negative or neutral.
Clusters of usage characteristics might emerge, and these collective styles can be used as a resource
for design. In Rhub for example, two dichotomies emerged: online/offline users and socialite/lurker
users. Once identified and analysed, these styles were kept in consideration when designing.
Awareness of use is also discussed in this section. Users were mostly aware of the research goals of the
system; others saw it as a pragmatic tool that lets them chat with their friends. People were also aware
of not only their own but also others’ use of the system, and this awareness informed their use, for
example if Fabrice knows that Louise doesn’t check the website often, he’ll make sure his message gets
forwarded to her phone. At an individual and group level the system had to be appropriated: it had to
be understood, reflected upon, and then integrated into everyday life. As people came to depend on
Rhub, usage grew, and issues arose relating to the large number of messages people receive, requiring
on-going design efforts to alleviate the problem. People depended on Rhub to carry their messages, to

153
 spread the word of activities they were organising, and to keep in contact with friends. Over time
issues of a social nature arose, for example when social relationships changed but the technological
representation of that relationship did not.

Discussion 8.1.1 STYLES OF USE

There is a division between those who use Rhub online, and those who use it offline. Online users
regularly check the Rhub website, and have linked their instant messaging account to their Rhub
profile. Offline users usually are invited via SMS, do not check the website and receive all messages via
SMS. In the analysis of this divide (chapter )  of users were found to be completely ‘offline’ users,
that is, they have never logged in to the website while  of people logged in up to once every four
days, on average.
There is not feature parity between web and console interfaces, and the user experience is
obviously different. Online, people get a colourful, visual experience with extensive hyperlinking that
makes it easy to explore content and features. Help is easily available, as in-line hints or suggestions,
and links to full-page wiki-based help. Offline use via the console however offers little avenue for
exploration, with the cost of sending SMSes (typically around AUD. per message) also hampering
efforts. It is difficult to keep offline users updated with new features and changes to the site, whereas
online it is easy to draw people’s attention visually.
Many types of user participation are not evident for offline users. Effort that people go to in
creating locations, setting presence and uploading photos is not visible to people who just receive
messages via SMS. This obliviousness becomes evident through social interaction. People realise that
their efforts are not being seen, and reduce them accordingly.
A division also exists between users who actively participate in group messaging, and those who
only receive messages. Nearly half () of users who have received a group message have never sent a
message themselves. Whilst this level of ‘lurking’ may seem alarming, it is important to note lurkers
were not entirely passive. From my observations, most of the lurkers in the Alpha group were actually
keenly aware of what was happening in the group, would attend organised events and discuss Rhub-
based conversations with others. The presence of lurkers is common in social systems (Whittaker et
al. ), and especially given that Rhub lurkers frequently participate in actual events, should not be
a cause for alarm. To some degree use reflected personality. The people I knew on Rhub who were
most active were also those most socially communicative and most often organising events. One

154
interviewee said that sending a group message “puts you in the spotlight,” perhaps a reason why some
prefer to remain silent.
Once styles of use are identified, they can be analysed and explored to assess how widespread they
are and the meaning behind them. They are also useful to feed into the development of personas
(Cooper ; Cooper et al. ), providing them with an empirical foundation. MoSoSo in Action

8.1.2 AWARENESS OF USE

Through interviews and examination of messages, I noted a general awareness amongst participants
as to how they thought others used communication technologies, how communication technologies
should be used, as well as reflections on their own use. This applies to Rhub, as well as other
communication technologies. For example, one participant noted, “during the day, I’ll always email
Therese because she’s at work and reading email. During the evening I’ll text her.”
Participants described noting who was online when they were, who sent messages to the group
and who showed up at events, and in turn using these observations to shape their own behaviour:
“people start to learn who’s in a group [...] and know who’s listening.” For example, if a person was
regularly seen using Rhub, then sending her a Rhub message was seen as a reliable way of contacting
her. If a person frequently sends messages to the group indicating they will come to an event yet do
not show, their response might be disregarded in future. Others’ perceptions can sometimes be made
obvious; one interviewee told us “people think I use it more than I do. They’ll come up to me and say,
‘did you read that thing on Rhub?...’ [when I didn’t]”.
Participants also had an awareness of their use compared to others, for example saying (somewhat
sheepishly) during interviews that “I used the web more” or “others use the console more.” Naturally,
this awareness is afforded largely when system makes action visible to others. In Rhub for example,
users currently browsing the site appear prominently in the home page side bar, and people who have
presence information have a ‘presence gem’ that appears next to their name throughout the site.
Participants were also aware of the system as a research prototype. Consequently, some
participants said they did not invite their friends to the prototype, even though they thought it to be a
good idea, as they did not want to contribute extra burden on the project’s resources.

8.1.3 NEGOTIATION OF USE

As facilitator, I played an active role in developing usage, however wherever possible I tried to allow
participants to work out ‘proper’ usage for themselves, and as a group. For example, I might create a

155
 new sub-group for more focussed messaging, invite the relevant people from the larger group and
send a message to the new group welcoming them and telling them the purpose of the group. Other
participants followed a similar pattern when creating groups.
Users who sent too many messages to a group were publicly reprimanded by others, both in
Discussion person and also using Rhub itself, such as this message sent by Michael to a group which he thought
Sam was sending too many messages to:

“Sam…your Rhub rights have been temporarily revoked…feel free to start again in  months time…”

Occasionally, usage of Rhub would spill over from pre-event coordination and jokes or conversations
would continue during the event itself whilst people were co-located. In one case, someone sent a
message in an effort to stop it:

“If I see another person touch their phone, i am not going to be happy. I am getting rhubrage”

Once “rhub rage” entered the group lexicon, it was often used when referring to annoyance related to
excessive Rhub messaging, such as this person trying to cut short a coordination exchange that was
spiralling into random banter:

“Now Kiddies...think of the RhubRagers before you reply ;)”,

or this message, after a series of messages in quick succession cheering a sports game:

“I'm invoking rhub rage lockdown”

I also observed many cases where participants would discuss usage of Rhub as a group. New features
were discussed, and members asked each other how certain effects were produced, for example asking
how to change a profile photo. Discussion about appropriate use of Alpha group often arose. Some
people preferred sending all messages to the one group, to increase the inclusiveness; others thought
it better to send messages to specific sub-groups depending on the purpose of the message to reduce
the annoyance to others.

8.1.4 APPROPRIATION INTO GROUP

Rhub became appropriated into Alpha’s shared consciousness. Apart from “Rhub rage,” discussed
earlier, people became to understand other Rhub-related terms. When events were being discussed or
organised face-to-face, it was common for Alpha members to say something like “I’ll send out a Rhub

156
about it later,” meaning they would announce a plan using Rhub. People would ask each other if they
“got the Rhub” or “got the Rhub message.”
People decided their own way of pronouncing the name of the system too. Some decided it was “r-
hub,” others “rooo-hb,” but mostly it was “rub,” which was my original intention. Certain participants
created a ‘backronym’ early on in the study for Rhub, meaning “relationship hub.” MoSoSo in Action
One day, several members noted that their phones had several Rhub messages waiting for them in
the morning when they woke up, the artefact of a very early-morning activity between other
members. One member declared that when you wake up and have  unread messages waiting,
“you’ve been rhubbed.” This anecdote is also interesting as it reveals Rhub as group social log. In this
case, several members had gone to sleep, while other group members went out partying. In the
morning, the people who did not go out woke and saw the result of the others’ partying. Later in the
day when an event was happening, members used the shared Rhub record as a basis to discuss what
the members did the night before. Rhub also became part of people’s routine, for example checking
the Rhub website first thing in the morning, and during the day.
Interesting effects happened when a message was sent to a group and if several members of the
group were collocated. Because everyone’s phones would beep one after the other, the group knew it
was a Rhub message. Whose phone beeped first was considered a status symbol, because originally
messages were delivered in order of user id, with newer users receiving messages last. One
interviewee half-jokingly said, “I hate it that my girlfriend receives messages before I do!” To avoid
such conflict, the algorithm was changed to randomise the order of message delivery. Often, one
person would reach for a phone and read the message to the group to save others the trouble of
retrieving their phones. It was also considered acceptable to read the message from another person’s
phone if theirs was within reach, which is not the case for normal text messages (Häkkilä and
Chatfield ). In public places, the group often attracted attention when everyone’s phones beeped
at once.

8.1.5 SOCIAL BENEFIT

Rhub became an essential socialising tool for members of the sporting club, Orange (members of the
Rhub group Alpha). To not be on Rhub would mean missing out on most of the group’s socialising.
For example, one exchange student, who had left before Rhub was first deployed and came back later
to visit Brisbane for a month found it necessary to join during her stay to keep up with social

157
 happenings. For non-Orange members, Rhub was a useful tool, but not essential, because it did not
carry the bulk of the socialising activity.
An important factor behind the usefulness of the prototype for Alpha members is that the entire
social group is using it. For users who are not in that group, or for members of groups that do not
Discussion have a high level of social cohesiveness (such as Digamma), they agree that Rhub would be a useful
system – if only they had people to socialise with.
For Alpha, new foreign exchange members arrived each semester and existing members invited
many to Rhub. These new arrivals reported very positively of their experiences, considering Rhub as
“instrumental in getting integrated into the group,” or that using the system made them feel “definitely
more connected [to the group].” Some fringe group members reported that using the prototype
brought them closer to the group: “I go to the parties [now], never did before.” The theory of
propinquity suggests that the more frequently people interact with each other, the more the degree of
liking increases (Heslin and Patterson ), which might explain how a group messaging system like
Rhub can have a positive social benefit. I suggest that the majority of this benefit does not come from
actual usage of the system, but rather from natural, face-to-face social interactions arranged through
the system.
People enjoyed getting messages forwarded to their phone from their social group, typically
describing them as “fun,” and a “nice surprise.” They also spoke of a feeling of connectedness with the
group, because even when geographically distributed, they can have a conversation together.
Frequently, physically remote group members might send a message using Rhub to the rest of their
group that is collocated, to find out how an event was going, which is not easily afforded by text
messaging because you do not necessarily know who is there.
Occasionally due to technical faults, some users had problems receiving messages, and I was
usually notified quickly when they realised they were missing out, such as this Rhub message I
received from Kate:

“Hey Clint,
was just wondering why I dont receive the rhub messages anymore…
Did u cut me off ;-)? Life is so boring without it…
Cheers, Kate”
August st, 

158
8.1.6 MESSAGING OVERLOAD

Part of the appeal of mobile computing systems like Rhub is availability where traditional desktop-
bound computing is not. This can work to the user’s advantage when they can access supportive
services whilst away from their usual computing resources. It can also be a pervasive annoyance when
MoSoSo in Action
technology (or people acting through technology) can call upon your attention at any moment, in any
place. Many existing mobile technologies such as mobile phones or personal music players are
sometimes characterised as having a negative effect on socialising within a locality: phones can
disrupt the ambiance, music players cut people from social contact.
Clearly mobile computing design must consider not only the direct user of the technology but the
people around her too. Those who happen to be sharing a bus with her, friends she is having coffee
with and office colleagues will all become part of a mobile technology’s sphere of influence when it is
used in these various contexts.
Participants in the largest group spoke of the volume of messages they were receiving (mostly via
SMS and IM), as active periods sometimes produced over  messages per day. The average interviewee
reported receiving  text messages per month prior to Rhub (s=), so there is a considerably larger
quantity of messages that have to be managed by the person. As one participant said, “[My] phone
holds  messages - it’s always getting full after Rhub.” During interviews however, all people noted
that unwanted messages were a natural part of group messaging. Even though they might be annoyed
by messages they were not interested in at the time of receiving them, they might be interested in the
next conversation. Some suggested particular users were at fault for “derailing” conversations, one
participant said that people should “only say something if you have something to say.”
Two interviewees described being woken by Rhub messages during their sleep, with one now
putting his phone on silent overnight while it charges at his bedside. In order to reduce disruption
several participants said they would disable phone notifications when a Rhub discussion started, and
turn it on again when activity died. Participants who received few text messages before joining Rhub
formed new associations with their text message tone, saying: “when I hear my phone beep, I know it’s
Rhub.”

8.1.7 SOCIAL TENSIONS

Social tensions are also evident in social systems. The social environment is fluid and ambiguous, and
not easy quantised to fit a technological representation. Technological social systems require people

159
 to explicitly make and break social relationships, usually resulting in a tangible, observable
representation.
In one case, a participant used Rhub’s ‘message all friends’ feature, using the >> console command,
which ended up being sent to a recently ex-girlfriend, causing embarrassment for both parties. He had
Discussion removed her as a friend, but she still had him as a friend (she did not use the site often). At this stage,
the feature used incoming friend relations as the basis for messaging. That is, if someone calls you a
friend, when you send a message to “all friends” they will receive it, even if you did not have them
tagged as a friend. After this event, this behaviour was changed to use outgoing friend relation links
instead, so now messages only go to people tagged by the user himself as a friend.
Earlier iterations of Rhub’s design unintentionally blurred the lines between social groups. Any
activity on the system, such as new discussions or messages was displayed prominently; even when
there was only a tenuous connection to the viewer, leading one interviewee to note, “sometimes it
feels like someone else’s social group.” In one case, a person saw a discussion about an event she was
interested in, and replied that she would come, realising only later that the discussion was for a group
she was not on, and that she only knew one person in the group. She soon posted a retraction, and
reported being a little embarrassed. After this event, I altered the design so that activity was better
segregated, with activity only made visible when directly related to a person. In a similar case, one
participant reported being unsure if he should join a particular group he was interested in, because he
only knew one person, and not the other six, and he thought it was too ‘cliquey’ to accept an outsider.
There was some tension when certain fringe members were not invited to the prototype earlier by
anyone, as they knew they were missing discussions and social events. Perhaps due to the way social
activity permeates Rhub, two users requested to be removed from Rhub entirely after their
relationship with their respective Rhub-using partners ceased. While it did not happen during our
study, I would expect that forcibly removing someone from a Rhub group would result in significant
social ramifications.
Group messaging was considered less personal than directly addressed messages. Participants also
felt that mass invitations were less personal than individual invitations (even if they were delivered
using the same technology). Rhub groups are inclusive, and it is not possible to selectively message
within a group – it is either a message to the entire group or a message to each person individually.
Natural social tensions arise and there might be events that you do not want everyone invited to, or
you may not want particular people to be privy to the group’s messages. I found that messaging
dynamic subsets of groups was not a common enough scenario to support within Rhub, given the
added complexity required. Participants either manually messaged a set of users, or for less transient

160
sets, established a new group. For example, five offshoot groups were established for sub-interests
within the Alpha group membership alone. Rhub offers privacy and moderation controls, so it is
possible to have secret groups which are invisible to non-members, or public groups that require
invitation to join, for example.
Messaging
8.1.8 CONCLUSION

A variety of issues were discussed in this section, all relating to how Rhub was used in practice. The
issues relate specifically to Rhub as a mobile social software system – issues surrounding the social use
and appropriation of technology. People will use a system differently, and when there are enough
users, patterns of use might emerge, which in turn can be a useful resource for design or potentially
serve as an input to the creation of design personas. For example, rather than creating personas
entirely from imagination, a persona might be created with a particular empirical interaction style as
its foundation. This has the dual benefit of making the data more accessible as part of the design
process, and improving the authenticity of the personas. Participants demonstrated awareness of
others’ use, which in turn forms part of the negotiation of use that took place. As individuals and as a
group, the prototype was examined, used and reflected upon as it was appropriated into use. Rhub
provided a social benefit for many, bringing some people closer together, and reinforcing existing ties.
Whilst deployed, Rhub was a critical tool for socialising within the main user group, and to not be a
member of Rhub meant missing the majority of the group’s socialising and play. While messaging may
have powered this level of coordination, helping participants to deal with the larger flow of messages
was an ongoing concern for the designer. Users developed their own social protocols and practices for
handling messages, and this in turn inspired design. Like all social systems, social tension and anti-
social behaviour can manifest itself.

8.2 Messaging
Participants liked receiving messages via Rhub, characterising them as fun and surprising. To deal
with the increased number of text messages, many reported deleting messages after reading, or
periodically purging their inbox. One participant reported that for him, Rhub had almost completely
supplanted SMS; he thought Rhub was easier and more effective, particularly for group messages.
Interview participants likened Rhub to be something in-between email and text messaging. Email
was deemed a cheap, reliable way of distributing a message to a group of people, but interviewees did
not consider it useful for short-term organisation because many of their friends did not check email

161
 regularly. Text messaging on the other hand was thought to be quick and instant, but unwieldy for
group messages. For interviewees, Rhub was seen as a more robust way of getting a message to a
group, easier than text messaging and more direct than email. Participants discounted instant
messaging for group coordination because of the difficulties in synchronising availability. Most people
Discussion valued Rhub for keeping them “in the loop” of their group’s social events and happenings. When they
had something to say or an event to organise, they found Rhub highly useful for “getting the word out.”

8.2.1 CHANNEL MEANING

Interviews with participants explored how they used communication channels and what they meant
to them, and suggested that there is a rich process that underpins selection of channels. The channel
used for a communiqué is important, and not only governs what form meaning will be expressed in
(for example, text or speech), but also governs the meaning itself. Like many other social acts,
selection of technology is a considered action, aimed at producing a desired response from the
recipient. The initiator uses her knowledge and meaning of the channel as well as what she perceives
the recipients’ meaning to be, as part of this considered action. For example, participants spoke of text
messaging being informal and having a low-importance, phone calls were considered important, and
emails had a higher degree of formality than SMS, IM, or calls.
In the workplace there is evidence of a strong correlation between medium selection and the
complexity of the desired interaction (Allen and Hauptman ), with face-to-face interaction
considered best for complex and or personal interaction. While complexity does have an effect on
social interaction, interviewees suggest that other factors are more pertinent. The major factor
participants considered when deciding which communication medium to use was the immediacy of
the message. Message delivery, whether immediate or delayed, is reliant on the inherent speed of the
medium (e.g. carrier pigeon versus text messaging), and what the anticipated lag time is for a recipient
to be aware of the new message (e.g. how often email is checked). Immediacy can be seen to be a
moderating factor to Dix’s () interactional pace. Messages will migrate to new mediums when
urgency is increased. For example, email invitations to a party may be sent a month in advance, whilst
text messaging will be utilised as a reminder on the day of the party. Also important, as mentioned
explicitly by a few participants, is whether a medium is available between different people. For
example, if a group member wishes to contact their entire group, including fringe members, a
complete set of contact details might not be available to them, a scenario commonly reported by
participants.

162
 The channel also influences how people interact with the system. In one case, a group of relatively
inexperienced users who were receiving Rhub messages via instant messaging replied to them as
though they were instant messages: using short, quick and frequent messages. Two members of the
group who were receiving messages via SMS had to plead to others to slow their messaging, one
sending: “SMS storm. Crazy people.. Stop!” Messaging
Even though there is meaning in the medium (McLuhan ), people were generally happy with
relinquishing control over how their messages get sent. People favoured the pervasiveness of cross-
media messaging over intimacy, whilst retaining control over the content and form of their messages.
Early feedback on this issue led to the provision of increased control over how a message is sent.
Originally, all messages sent using the website were dispatched using any available channel; however,
users noted that they did not always want to interrupt people with their messages, and would prefer to
be able to have some messages remain on the web. This added control however was only ever offered
through the website, and although most people sent Rhub messages using their phone, a large
proportion of messages were initiated via the web. It should also be noted that Rhub was mostly used
for messaging multiple people at once, and thus because the communication was less personal, did
not demand strict control of medium.

8.2.2 PERVASIVE CONTACT

One of the major benefits attributed to Rhub was its ‘pervasive contact’ aspect. When communicating
amongst a group it can often be difficult to negotiate use of technology: some people might check
email regularly, others not, some might use instant messaging during work hours, but never at home,
yet for others the reverse might be true. Rhub smoothes over these differences, by assuring senders
that their message has reached everyone in the group.
It allowed people to quickly and reliably “get the word out,” and “makes people more accessible.”
Participants liked not having to think about how to address a message, or manually selecting address
book entries. Using Rhub, people can send a message to a named group, and the system takes care of
the addressing individual people.
Pervasive contact can also have negative aspects, for example dealing with a large number of
messages or notifications. Participants however reported that the benefits of group messaging
outweighed the negatives. Additionally, the logic behind the messaging system was not perfect. For
example, sometimes Rhub would mistakenly deliver a message to someone’s instant messaging client
when sending it to his or her phone would have been a better option.

163
 8.2.3 PERSISTENT CONVERSATION

Rhub supports persistent conversations directly and indirectly, through its composite messaging
technologies and practice. All messages sent through Rhub are available for perusal on the website
(depending on privacy restrictions), regardless of where the message originated (text message, IM,
Discussion
email or web) and where the message was forwarded to. Thus, Rhub provides a consistent layer of
persistency across mediums which may be lacking, or have irregular persistency characteristics of
their own. Each medium has its own persistency properties that are mediated by their use – for
example, a phone may be able to hold  messages, but a user may habitually delete messages as they
are read.
Additionally, there is a ‘social persistency’ arising from group messaging. When Rhub group
members are collocated, they speak with a shared knowledge of the group’s Rhub messages, and
assume everyone has read the latest. If someone is confused, people will often ask “didn’t you get the
Rhub [message]?” and if it turns out that they missed it for some reason others quickly bring them up
to date.
During interviews, we found that persistency of a channel was often considered when choosing
how to send a message. Some interviewees reported that they often reviewed old correspondence to
extract details. Persistency can also have another side, for example one participant said they were
particularly careful when writing email so they “don’t look like an idiot,” realising that email can be
easily forwarded with a degree of authenticity. This is also supported by other work which suggests
persistency can be a barrier to involvement if people are worried about privacy or possible use of their
old messages against them in some manner (Nonnecke and Preece ). It seems that as the length
and fidelity of a message increases, the greater the demands for the message being complete and well
formed with respect to grammar as well as social protocol. Text messages’ ungainly abbreviations can
be readily forgiven when a sender tries to extract the maximum expressiveness out of one -
character message. Email on the other hand usually requires longer prose, complete with salutations
and other social protocol observations. It is also true that a recipient is often unaware of the sender’s
context when the message was sent. A badly formed SMS message might be more forgivable
considering that the message may have been sent hurriedly whilst grocery shopping with a child.
Of the  quiz questions that were answered by participants, five answered the question ‘Have you
re-read an old email, IM or SMS today?’ Three replied with an affirmative answer, two with a negative
answer, and interviewees also reported keeping and re-reading Rhub messages for details such as
addresses or times. The ‘Time Traveller’ workshop exercise demonstrated that there was a large

164
amount of context missing from messages, without which, the messages would have been difficult to
understand. When messages are received, they can usually be understood easily, as the reader shares
the context of the sender. However after a period it may be difficult to recollect the specifics of the
context, rendering the message hard to understand. I suggest that only short-term persistency is
useful for informal social conversation and coordination because the communication is mostly Messaging
ephemeral, however this aspect of use merits further investigation.

8.2.4 ONGOING DESIGN RESPONSES

Initially, users had little control over how messages were forwarded (that is, if or how they were to be
‘pushed’ to people using IM, SMS and so on). All messages sent using the console were forwarded in
any way possible, and messages sent using the web had a single option to enable or disable forwarding.
This was for user interface simplicity reasons; however, it soon emerged that participants wanted
more control over how messages were forwarded, so additional controls were added to the web
interface.
One participant recounted during an interview session how he was receiving group messages
pertaining to an event being organised for that night. He was working later that night, and could not
attend, so put his phone on silent to reduce the distraction of the messages. He did note however that
under other circumstances he might be interested in the event, and would want to stay abreast of its
organisation. Ideally, he said he would like a way to opt out of a discussion if it was not of interest.
This feedback led to the development of opt-in/out discussions, akin to a dynamic mailing list. Using
the new discussions feature, people initiating a discussion could set a subject for the discussion, and
fill in more detail in the body of the message. They can choose if the discussion is opt-in, opt-out or
neither. If the discussion is opt-in or out, the subject line is forwarded to everyone in the group, and
then they can choose to express interest or dis-interest. Once subscribed to a particular discussion (or
thread), the person is sent subsequent replies, otherwise, messages are only viewable on the website.
This permitted discussions to take place within an interested sub-group, leaving disinterested parties
out. This response seemed very sound and would address the scenario the participant raised, and give
further control to both the sender as well as recipient. It was however, little used. It appeared, from
further feedback, that senders did not want to go to the extra trouble of starting a discussion; they just
wanted to send a message to the group, and users preferred to set their phone to silent than to send an
opt-in or out response.

165
 Further iterations looked at alternative approaches to the problem. Group instant messages are a
stream, with no added metadata or context to determine what they are about, unlike email or
threaded discussions that have subject lines. As such, the ability to control the flow of messages is
limited. During interviews, several participants characterised banter (messages that were purely chat,
Discussion gossip or had no informational or coordination value) as being less valuable than other messages.
They noted that sometimes they would not mind receiving those messages, but often they would like
to be able to tune out, suggesting that senders should have to mark messages as ‘banter’ when they
were sent, so that they could be filtered out. The first response to this concern – per-user filtering of
the message stream – was message tagging. In this system, messages could contain a tag, contained in
curly braces, such as:
“Hi everyone, lets meet up at the pub later {beer}”
People could then set filters, for example to only receive messages tagged with ‘beer’, no messages
tagged with ‘beer’ or some other logical expression with one or more tags. Pre-defined filters were
established as well as shortcut tags such as {*} to represent so-called ‘banter’ messages and {!} for
important messages. This feature was not used because of the dual requirement of senders having to
thoughtfully tag messages, and receivers to set appropriate filters. This feature evolved so that filters
match against the arbitrary contents of messages, rather than specifically tagged messages. For
example, one could set a filter so that messages containing the word ‘pub’ were never forwarded to
them. This way, senders would not have to go to any special effort, yet suitably motivated recipients
could set filters to block certain messages. Because filters worked per-user, per-group, users could
effectively ‘tune out’ of a group’s messages by selecting a pre-defined filter that matched all messages,
yet still be a member of the group and view messages on the web. This implementation proved more
successful, with several users setting basic filters.
When people were away from their friends, they tended to not want to receive group messages, as
they usually related to local events. As a result, the ‘vacation mode’ feature was developed, which
when enabled by a user, stopped all incoming Rhub notifications and messages. To read messages, the
website would have to be visited. This proved useful for participants who were travelling, or who had
returned to their native country. Because users sometimes forgot to turn vacation mode off if they
returned to Brisbane, an alternative blocking mechanism was developed – ‘silencing’ - that
automatically expires after a period. When the silence is set, either using the console or the web
interface, a period can be specified, after which the silence is removed and message delivery resumes.
Both of these features place all the power in the hands of the recipient, but are rather blunt

166
instruments, as all group messages are blocked (for silencing, private messages still get delivered
however).
Several design responses also looked at the challenge of high messaging quantity from the sender
perspective. Many users were unaware when they first started using Rhub that their messages get
distributed across a variety of mediums. Thus, people using Rhub with their instant messaging client Messaging
tended to think that others were receiving their messages via instant messaging. As a result they
tended to send many short messages instead of longer less frequent messages, which caused some
grief for users receiving messages via text message. Additionally, people were often sending messages
via the website without realising that it would cause a disruption to most group members when they
received it via SMS. To address this problem, the web interface was changed so that by default
messages were only forwarded to people via online means, which is less disrupting. Visibility of the
multi-channel functionality of Rhub was increased, for example, when sending a message via instant
message, Rhub’s response told the user what channels the message was sent via. Multiple messages
from users within a short period of time, or messages which had repeated content were also
automatically dropped to prevent users (accidently or otherwise) from flooding the system.

8.2.5 CONCLUSION

Messaging was a critical feature of Rhub, which supported person-to-person, one-to-many and many-
to-many forms of communication. Importantly, messaging could be forwarded, or pushed to people,
by re-appropriating existing channels such as instant messaging, text messaging and email. The
channel forms part of the meaning of the message, and is something people will normally consider
when they decide to interact with someone in a mediated fashion. Although to some extent Rhub
takes away the choice of channel, it was not considered a problem. This was because the system was
used mostly for group communication that is less personal, and the pervasiveness of Rhub-based
communication is a significant benefit. Another issue people consider when selecting a channel is
persistency, which is shaped not only by inherent characteristics of a medium but also through use.
The prototype provides a consistent layer of persistency across differences between people and
technology, as all messages are available on the web (although usually only available to members of the
group) regardless of source channel. It was found however only a short-term persistency is required
for informal group communication, as coordination and chat had an ‘in the moment’ character.
Accessing messages from months prior would not only have little purpose (other than perhaps for
reminiscing), but would be difficult to understand as the greater temporal context of the messages is

167
 not also captured. I also discussed the ongoing design responses made in messaging, with relation
particularly to providing controls so people can manage their incoming Rhub messages.

8.3 Coordination
Discussion Although Rhub was originally designed to support communication (that is, social chat), coordination
and sharing equally, coordination was by far the most used. It appeared that it was much better to use
technology to organise a face-to-face event and allow communication to take place without
technology. As revealed during the workshop, coordination involves other entities, for example
location, people and groups, and may produce new entities, such as photographs from the event.
In this section, I discuss the dominance of coordination over chat, compare Rhub’s usage with two
group messaging systems and discuss microcoordination and half-invites. People preferred Rhub’s
messaging feature to be used for coordination rather than chat, because they perceived chat messages
as relatively insignificant, and not worth the effort to manage, whilst coordination messages were
often useful. This coordination usually happened on an ad-hoc, last-minute basis, an example of
microcoordination (Ling and Yttri ). Participants reported that compared with text messaging
invitations, there was “less pressure, easier to be lazy,” meaning that they felt that if someone proposes
an event on Rhub, there was less of an impetus to provide a message signalling commitment. This
fostered a ‘half-invite’ style of invitation, where, because of the reduced pressure, people sent casual
invitations to the group and did not require commitment messages in reply. Half-invites are typically
used to declare an event was taking place (often mentioning who else was going), and inviting others
along to attend. If others came, they would be welcome, but there is never any expectation.

8.3.1 COORDINATION OVER CHAT

We found that Rhub’s messaging capability was mostly used for coordination (), rather than social
chat () for the Alpha group. Two other groups studied, Gamma and Delta were much higher; 
and  of messages were for coordination, respectively. This was also supported by interviews we
conducted with participants, who saw Rhub as being primarily a tool for coordination, with some
actually suggesting that Rhub be explicitly not used for chat. This result is very similar to the Swarm
(Farnham and Keyani ) group text messaging system ( coordination) suggesting that the
finding might be generalisable across individual social groups. The high level of coordination within
the larger groups in both Rhub and Swarm contrast to the higher level of chat which took place in
Slam (Counts ), which had smaller groups.

168
 Existing handsets are not usuallyy designed for composing, managing or displayingg group text
messages, and usability suffers resultaantly. Additionally, a phone’s message arrival notifi
fication does
not distinguish between group or priivate text messages for systems such as Rhub, whiich makes it
difficult for users to determine the urggency for reading a message. These two design facto
ors—coupled
with the fact that group text messagging increases the quantity of received messages—
—results in a Coordination
higher level of disturbance than direcct messaging. Participants reported the extra quanttity of group
text messages they received was only annoying if the messages were of no value. Coordination
C
messages were acceptable because usu
ually the event was something of interest. Even if th
hey were not
interested, they realised that next tim
me they might be, therefore the annoyance now is tolerable,
considering potentially useful messagees later. As one interviewee stated, “that’s the pricee you pay for
group messaging.” Chat messages on th
he other hand were seen as extraneous and better seent using less
intrusive means such as IM or a web-b
based forum.

8.3.2 COMPARED TO OTHER SYSTEMS

It is instructive to compare our prelim

minary usage statistics with those of Swarm (Farnham
m and Keyani
), another group-based text meessaging system. Data reported by Farnham and Keyani was
generated from seven users’ complete messages, combining for a count of , whereas ou
ur results use
a random sample of  messages sen
nt to a single group from a total of  users. Figuree  shows a
comparison of message goals in Rhub and Swarm.

Goal of Messages
70% 68% Rhub Swarm

50%

30% 28% 28%

%
18% 17%
12% 16%
7% 6% 7% 4%

Total Total Inviitation Report Question Directive Commitment

Bonding Coordination

Figure . Percentage of messages by goal, compared with Swarm.

169
 Total bonding and coord
dination percentages are nearly identical to Swarm (: for Rhub, :
for Swarm). In the breakkdown of coordination messages, there is a relativelly large degree of variance
from the Swarm data. The
T difference in commitment messages ( and 
 for Swarm and Rhub
respectively) can be partially explained by the ad-hoc sporting events Alpha organised using Rhub.
Discussion Because play can only taake place with a requisite number of participants, commitment messages were
important to determine if the event should go ahead and be organised. Social commitment messages
in Rhub have an interessting dual role. Traditionally, invitations are sent to
o people individually, and
responses in the form off RSVPs are sent directly to the host. If you, as an inviitee, want to establish who
else is going, (which maay determine whether you would want to go) it wou
uld involve asking around
your circle of friends or asking
a the host themselves. With Rhub, commitmen
nt messages maintain their
functional role as RSVPs for the organiser, but importantly, signal to others your commitment. These
public RSVPs confirm to
t others who will be attending, and attendancce can be held publicly
accountable, which does not happen with private invitations.

References in Messages
Rhub Swarm
43%

25% 24% 23%

13% 11%
7%
4%

Location Time Person Status Activity

Figure . Referencing in messages for Rhub and Swarm. Data for referencingg of status and activity is
unavailable for Swarm.

Referencing in messagess was also different between the systems (Figure ),, with a much higher level
of location referencing iin Swarm ( of messages versus ). This mayy be because the locations
visited by Swarm users were more diverse, and they therefore had to quaalify location more often.
Rhub on the other haand had a much higher level of time referencin
ng ( versus ) and
commitment, perhaps d
due to the organisation of sport that has a higher d
demand for synchronicity
than everyday socialisingg.
The high level of refeerencing in coordination messages to location, time and activity suggests their
importance as resourcess for group coordination. It might be tempting to seee these as properties that

170
can be explicitly supported in a system. It is important to note however that the way people express
them is highly dynamic, dependant on the context.

8.3.3 MICROCOORDINATION

Coordination
The term “microcoordination,” (Ling ) refers to the fine-grained iterative form of coordination
afforded by modern, direct communication technologies, particularly SMS. Text messaging permits
people to stay in contact in a background, peripheral manner through the ongoing exchange of
messages that have a low level of disruption. Group text messaging is similar, allowing an entire group
to maintain background continuous contact.
Consider the exchange below of an ad-hoc activity (Table ) being organised on Rhub as an
example of microcoordination. Here, one person proposes a small event (message #), approximately
four hours before commencement. Someone () chimes in that they are interested, and the
coordination proceeds. Further people join in (-), and the rest of the lurking group can observe this,
gaining an idea about who will be coming and who will not. () comes from Sally and seems to be an
apology of sorts – I’d like to come, but can’t. This is also a useful update to the rest of the group of
Sally’s current whereabouts (she was using the presence feature for this too). () is an update from the
event originator, letting everyone know it’s still on, and advises of two people he knows are driving in.
() seems to indicate that Gary, who had otherwise planned to have a quiet night will now come on
account of the event’s popularity. There was a -minute interval between message  and , which
then triggered a short burst of three messages, the last message sent . hours before the event was
scheduled to begin.

Table . Microcoordination in action, messages sent to Alpha group. The second column indicates the
cumulative minutes of the interaction.

# Minutes Source Message

 Web Ron: Anyone keen for my Special Pasta pm before swimming to Regatta
Hotel - pre spa drinks?
 SMS Lee: I dig it
 Web Colin: I like the idea of pasta and drinks, but you do realise it is pissing
down rain, right?
 SMS Bubbles: Swimming in the rain is the shit! Pasta i can do without
 SMS Charlie: Swimming in the rain is fun. Pasta would go down a treat. 

171
 Exams i can do without
 SMS Sally: Don't tease me when i'm interstate you [expletive deleted]!
 SMS Ron: Pasta and pool ready call bubbles and charlie for a lift.
 Web Gary: I hate you [expletive deleted], I can never have a quiet day in.
Discussion

8.3.4 HALF-INVITES

We observed a style of off-the-cuff, ad-hoc form of coordination that group mobile messaging
supports particularly well. Unlike traditional invitations that require response, ‘half-invites’ tell a
group of people that an event is taking place and others are welcome to join, or as one interviewee
described, “we’re doing this, come show up”. As group invitations are easily composed, and there is
little pressure on others, participants reported a greater quantity of invitations sent than before using
the prototype. Some participants reported attending more events and feeling more socially connected
than they did before. Half-invites often invite implicitly, for example this message sent on a Sunday
afternoon:

“Sunday night at the pub: because you know you shouldn’t”.

Within the Alpha group, we often observed small groups of two or three people deciding on an event
amongst themselves - such as going to a particular pub - with one of the organisers sending a group
Rhub message to entice others to attend. For these types of informal events, responses are not
required, and thus invitations can be easily ignored if they are of no interest. For small groups that
would not mind additional numbers, sending a mass half-invite is quick to do, and may yield some
extra company.
Half-invites suggest an informal, inclusive style of events where attendance is fluid and invitees
may not be well known. Rhub is particularly useful for this, as contact details do not need to be known
or collated by the inviter – they can just send the invite to the group, and trust Rhub to route the
message appropriately. Whilst it may seem odd that people would want to invite others they do not
have contact information for, we found it was a common case with Alpha group members, as one
interviewee said of the scenario: “I might not know your number but you’re invited.”
As described in §.., messages can be used to signal commitment to the event initiator and
others. In the context of half-invites, these messages can serve to further strengthen or formalise the
event. Occasionally an event would be cancelled if the half-invite did not garner enough attention to

172
warrant it taking place. Typically, the originator would send a message notifying others, lest anyone
not reply, yet still show up at the stated venue.

8.3.5 CONCLUSION

Presence:
Coordination was the primary use participants found for Rhub, even though Rhub never offered Location & Status
explicit functionality for coordination typically found in groupware applications, such as reminders
and schedulers. It was however, a design goal for Rhub to support coordination. People appropriated
group messaging as the main conduit for coordination, favouring it over idle social chat. This result
was found to be similar not only across groups within Rhub, but also with two other group messaging
systems from academia. The system afforded two special forms of coordination: microcoordination
and half-invites. Microcoordination, previously introduced in relation to text messaging, is fine-
grained coordination that often takes place just prior to an event taking place. ‘Half-invites’ were
identified as a form of lightweight, ad-hoc coordination in which group text messaging is particularly
adept for. Unlike normal invitations, half-invites are highly informal, and do not require a response
nor is there an expectation of people coming. They were often used to invite more people to an event
that was already taking place, perhaps with only two or three people.

8.4 Presence: Location & Status

Presence features were actively used ( of console input), but only by  of participants. During our
qualitative interviews, we found that many people knew this functionality existed, having observed
others using it or noticing the interface, but did not see the value in it themselves. I had originally
anticipated that presence information might lead to ‘designed serendipity’ – setting your location as a
symbolic gesture that you may be open to presence observers to join you. While this did happen on
occasion, there was never the density of presence observers to make fine-grained location setting
worthwhile. Setting your presence was seen to be a bit of a chore with little pay off, and as such used
by only a few. A further side effect of few people regularly setting their presence was that related
features also languished, such as messaging everybody at a location. Participants rightly noted that the
presence features were “only worthwhile if people use it,” yet some said they did not see a reason for
setting their own presence or said they would only use it from a computer, instead of sending an SMS
to set presence.
As a designer, I was aware of certain features that can be provided if a culture of presence-
information setting developed amongst users. For example, users can be notified when their friends

173
 are nearby, or the value of a location could be gauged by how many friends frequented it. I have
reservations with automatic detection and disclosure of location and status. I believe there is more
meaning to being ‘at’ a location than being physically located there. For example, waiting for a bus in
front of a pub at .a does not necessarily infer a drinking problem; merely that it is a handy bus
Discussion stop. There is no way to reliably and accurately automatically capture and determine this notion of
being ‘at’ a location. As such, Rhub uses manual disclosure of presence, which permits greater user
control at the expense of greater effort. For referring to a location that exists in the database, people
can use its canonical name or alias; for locations that do not exist, free-form text can be used. Most
users () set locations that were already defined (by either themselves or others),  used arbitrary
text, and  used the in-built ‘home’ alias for their ‘home base’ as set in their profile. Presence was
mostly set to people’s work location and popular nightspots.

8.4.1 ONGOING DESIGN RESPONSES

The presence feature underwent significant design evolution as I attempted to increase its usage
among participants, and thus increase the flow-on benefits of additional data available to the system.
During interviews, participants agreed on the value of presence information to others and several of
their suggestions, such as a prominent prompt for presence information when logging in, were
implemented. Participants however indicated that there was little personal reward for the effort to set
presence and as there were few friends using the feature, the group usage rewards did not eventuate
either.
To counter this, I progressively increased the visibility of presence information, and the feature
generally. Originally a console-only feature (since it was anticipated to be mostly used whilst mobile), I
integrated the feature into the website more fully, allowing people to view others’ presence history, see
who’s at a location when they are viewing it, and show icons next to user names when presence
information is available (Figure ).

174
Figure . Icon indicates presence information is available (left); Presence prompt shown on index page after
logging in (right). Presence:
Location & Status
To further increase the visibility of presence setting, we introduced notifications for when a friend sets
their presence. Generated notifications such as “John is @ Tennis Club,” are sent via SMS and IM to
nearby friends or friends who have recently been to that location, and IM notifications are sent to
remaining friends. Results of enabling notifications are preliminary; however, usage has doubled, and
has been maintained for three months.
I also introduced a feature that provided information on public transport. After setting a location,
for example by sending @work, the user could ask Rhub how to get to another location using a
particular form of transport, or whichever is quickest, for example !bus home or !transport gym.
Rhub would reply with information on route numbers and times for the first three available
departures in ten minutes' time. Users liked the transport feature and as a result, set their presence
more often. However, rather than setting their presence ‘properly’ when they first arrived at a location,
users were setting their location as they were departing the location, just to use the transport feature.
This had flow-on effects, for example, friends might receive a presence notification that someone is at
a particular location, but in reality, they are just leaving the location.
By increasing the visibility of the presence feature using an iterative, user-centred design process
we slowly evolved it to be more useful to the end-user. In a smaller scale study, we might have asked
participants to set their presence regularly; however, this was not possible in the context of our study,
and as a result, we needed to appeal to users’ self-interest. Groups of friends setting presence
information might enable interesting features; however, people naturally want to be able to see some
selfish benefit before investing effort for a possible group benefit. As reported in the previous chapter,
these changes lead to an increase in the frequency of presence setting, particularly location.

8.4.2 CONCLUSION

People (quite rightly) do not want to perform an action for the sake of the system, or other people.
This principle of least effort was identified decades ago by Zipf (), and is commonly encountered
in the computer supported cooperative work field (Grudin ), where for example workers might

175
 reject a shared calendaring system if it requires more work for them, for the benefit of their superiors
alone. The presence feature, which required work on the part of the user, did not originally offer
sufficient benefit, and as such was little used. Over time, the design was changed so that presence
information was more widely disseminated, which increased the end-user benefit and lead to an
Discussion increase in usage. An additional observation is that people used it in ways it was not originally
designed for, such as setting location when leaving a place in order to use the public transport feature.

8.5 Cross-Channel Usability: The Console

Reusing existing communication technologies for our own system has both benefits and challenges.
From a research perspective, it was beneficial to be able to deploy the system for a long time as
participants used their own hardware and software rather than loaned from researchers. As the
system utilised technologies people used on an everyday basis it significantly lowered the barrier for
entry and use.
Rhub was also useful for overcoming disadvantages with particular mediums. For example, many
interviewees considered messaging on mobile phones slow and enjoyed being able to participate using
a computer when one is available. One Rhub member did not own a mobile phone, and using Rhub,
could now stay better up to date with activities within the social group, as coordination was usually
done via SMS.
The primary disadvantage of reuse is that people tend to interact with the system in the manner of
the technology they are using. For example, I observed Rhub users sending rapid short messages when
they were receiving messages via IM, while others receiving messages via SMS preferred less frequent,
longer messages. Originally, the console insisted on a special syntax for sending messages; however,
participants quite naturally tried sending a plain text reply when they received a group message.
Resultantly, the design was altered to accommodate this usage, and now  of group messages are
sent this way, with only  using the full canonical syntax.
Options for a feature are usually not exposed using the console interface for simplicity reasons. In
this case, the system tries to choose a sensible default on the user’s behalf, as opposed to the web
interface that usually chooses safe or minimal options by default, but allows the user to easily override
it. For example when sending messages using the web interface, the default selection is for messages to
not be forwarded to recipient’s phones, IM or email. This is the ‘minimal’ choice in terms of disruption
to others and use of system resources. When sending messages using the console however, the default
is to forward messages using any channel, which is typically what users wish to do. Because users have
taken the time to use the console syntax, the system rewards them the ‘maximal’ choice.

176
8.5.1 ERRORS

Using a text-based syntax allows Rhub to be easily made accessible with alternative systems. While
there are many usability disadvantages with an opaque command-based system, the syntax (the
‘console’) could be used with minimal errors by most users. The average error rate for users for their
Cross-Channel
first  weeks of usage is . Average error rates per user did not depreciably drop over time. I Usability: The
reason this is because most users only used the console for messaging, and because other commands Console

were so infrequently used, difficulty was encountered when they were needed again.

Inheriting norms
In co-opting existing mediums for an alternative purpose, such as using SMS for system interaction
when it is normally used for human to human conversation, we inherit usage norms from the medium
as noted by Schusteritsch (). Originally, the console’s parser was strict: to send a message to a
group using an SMS, the user had to use a precise syntax of >&[group]: [message], such as
>&tennis: Game this afternoon. This was to ensure the correctness of the parser and to avoid mis-
sent messages. Even though all messages sent by Rhub include a postfix hint message “To reply send
>&tennis: [msg]”, we found that many users tended to instinctively reply as they would to a person,
without any special syntax. As a result, we successively made the parser less strict, for example
dropping the requirement for the ampersand to denote groups and the colon to separate group name
from message. Input that cannot be parsed is treated as a message destined for the entity the user last
got a message from, within a three-hour period. Thus, after receiving a group message, the user can
enter some text and reply without having to add special syntax and Rhub will route the message to the
appropriate entity. We return an error message after three hours for unaddressed messages to help
prevent messages being mistakenly sent to the wrong group. By respecting users’ existing conceptual
model of the medium we increased the perceived usability as less errors occur and messaging takes
place as they expect. Nearly half () of messages sent using the console use this plain-text reply
method.

Console less safe

When initiating a conversation using Rhub, some interviewees reported they would turn on their
computer especially to compose a new message - such as to invite people to a party - rather than use
their at-hand mobile phone. Interviewees preferred the visual web interface to the console syntax
because it was easier to use, offered more control and they felt less likely to make an error. New users
found starting a new Rhub conversation using the console syntax difficult. Each attempt at sending a

177
 message using SMS has a financial cost and there is the possibility that an erroneous message might
humiliate the sender if it was accidently broadcast to the wrong group, for example. Several
participants reported keeping old Rhub messages (which include syntax hints) as templates so that
they can easily send a new message when they need to. Thus, using the web was seen as a ‘safer’
Discussion option, which is reflected in the proportionally high level of usage for initiating conversations.

8.5.2 LEARNING THE SYNTAX

To assist mobile users who cannot access the web-based help system, we produced a three-sided card
(Figure  and Figure ) with a list of commonly used commands with examples, which can be
slipped into a wallet or purse. Cards were distributed by the author and occasionally through other
Rhub members who requested batches of cards to give to people they invited. It was also available on
the web to download and print. I observed people using the cards on a number of occasions as a quick
reference for infrequently used commands.
I also observed group members educating each other about how to use the console. A previously
sent message might be called up on a phone and shown to someone as an example of how to send a
message, or some ‘early adopter’ users eagerly demonstrated more advanced features to others.

Figure . Quick-reference fold out card in action

178
 Cross-Channel
Usability: The
Console

Figure . Three panes of the reference card.

Repairing from errors

To help the user repair from errors, the system attempts to provide contextual error responses, such
as providing a list of group-related commands if it looks like they are trying to manipulate a group or
providing example syntax if they are missing a required part of a command. For example, if the user
issues >&mygroup add, the system would reply with a response indicating they should include who to
add to the group, and to try >&mygroup add bob jane mary. After receiving an error response, the
user could alter their command and resend it, which often leads to success, for example,  of
erroneous IM sessions eventually succeed, while only  of erroneous SMS sessions eventually
succeed as they are often prematurely abandoned. A different billing model may result in different
usage characteristics, for example if all messages sent to Rhub were free, we would expect to see more
attempts.
Wherever possible we tried to make error messages constructive so that users could have a good
expectation of performing the command successfully armed with the suggestion. For example, if the
user sent &poker add, omitting who to add to the group, Rhub’s reply would include a contextualised
syntax for the add command along with a full example: Try: &poker add [name 1, name 2], e.g.
&poker add John, Marie. Direct help is also available by sending help, or help [topic or
command], for example, help @.
With text messaging and our user’s mobile networks, every message sent by the user incurs a
financial penalty. We observed a much lower rate of repeat message attempts using this medium,
compared with zero-cost media such as instant messaging (see
Figure ). Over half () of attempts at using the console by SMS were abandoned after one
erroneous message, whereas users made many more attempts with IM – only  of attempts were
abandoned. Over all mediums,  of errors were resolved after one reply from the system. In other

179
 work (Schusteritsch et all. ), participants were reimbursed for costs incu
urred using the system, so
users were free to explorre the SMS help system and to learn through attemp
pting different commands
without any monetary co
ost. Considering the useful ‘economic pressure’ on design
d shortcomings when
costs are incurred, it mayy be beneficial to seek alternative participant reward
d schemes.
Discussion
Console retry attempts per channel
Single Multiple

77% 65% 41%

59%

35%
23%

IM Web SMS

Figure . Percentage of tootal user errors where the command was attempted aga
ain with altered syntax, per
medium. When using IM people were more likely to retry their input, with SMS theyy were more likely to give up
after one attempt.

Flexible parsing
Command parsers shou
uld be as generous as possible. In our early im
mplementation, sending a
command to a group useed the strict syntax of >&[group]: [message], for exxample, >&poker: Anyone
?. The original desire was for the parser to be as detterministic as possible and
want to play tonight?
to prevent messages bein
ng accidently delivered to the wrong destination. By enforcing group messages
to use the group prefix ‘&
&’, and for a colon to appear after the destination w
we can accurately parse the
message. It was howevver, not particularly forgiving. Users would often forget the group prefix,
meaning Rhub would paarse the command as being intended for a person insstead of a group, or would
leave out the colon, cau
using Rhub to parse the entire message as the name
n of the group. After
observing how people were
w using the command, along with interviews wiith users, we softened the
requirements of the com
mmand. Now, the simpler syntax of >[group] [message]
ssage] will also work, but
not universally†.
A similar case also occurred
o with the presence command @. Rhub allow
ws you to set your current
location using @[location]
ion], for example @home. Since Rhub has a data
abase of locations (user-
provided), it can match the
t name and accurately position the person in semaantic as well as geographic

†
If there is a person wiith the same name as the desired group, the message will go to the person
instead

180
sense. People tended to use this feature to let friends know where they are. It was sometimes the case
however, that people would be at a location not already in the database or they would try to set a free-
form message, such as @out enjoying the sun. Rhub would ignore the message and return an error
indicating the location could not be found. After these observations, we changed the design so that
this message could be stored and shown to others much like if it were a real location. If a person sets Cross-Channel
Usability: The
their location to an arbitrary string, it is shown to others as text, while people who set their location to
Console
a defined location will have the hyperlinked name of the location and image appear. Furthermore,
people who use defined locations will appear on the graphical map interface (Figure , p ). This
way we reward the user for making an attempt, even though it was not exactly right.

8.5.3 RE-APPROPRIATING TECHNOLOGIES

Being a system that links several communication technologies together, each with their own norms of
usage and language, there is often a disjunct when reading messages out of context on a non-native
medium. While the system can translate the format of the message and manage the discrepancies
between media, the actual language of the message is not so easily modified. For example, Rhub can
receive a text message wirelessly via the GSM network and then transmit the content of the message as
an email using the SMTP Internet protocol. Text messages - often heavily abbreviated for reasons of
economy of time or length - may need to be deciphered, for instance ‘cu lr’ being read as ‘see you
later’ in the contextual frame of the mobile phone screen within which the cognition takes place. I
would suggest the same message read as an email would be more difficult to make sense of.
Automatically translating prose or simple abbreviation expansion is not viable because it alters the
original character of the message, possibly to the degree that the meaning of the message is lost or
distorted as well. As a compromise, the origin channel is displayed for messages received using email
or viewed via the web so they can be read with respect to how they were sent.
Some media has an invisible interface, such as text messaging, and to a lesser degree, instant
messaging. When interacting with systems using these types of media, the user is interacting with
their device or client application’s message editor interface, not the system itself. The message editor is
a proxy interface and not one designed for interacting with the cross-media system. Most interfaces
have cues, for example to indicate the current state of the system or possible commands that can be
performed. Even command line interfaces like the UNIX shell have features such as command-
completion and prompts to aid use.

181
 Without visible cues, a level of uncertainty is introduced. I observed users sending commands to
Rhub they thought might or should work (even though there was no evidence or documentation to
suggest it may). Another difficulty is that new or changed features cannot be easily advertised using
these media. With the Rhub website, new features are highlighted when people sign in. Because
Discussion Rhub’s development was on-going, it was important to be able to advise users of new features they
would otherwise be unaware of. With some media however, this type of side band is unavailable.
Designing cross-media systems often involves balancing consistency and appropriateness of the
interaction. A graphical web interface cannot simply be re-deployed to work via text messaging and
likewise a text-based command-driven text-messaging interface should not be deployed as a website.
While there is disparity in the interaction media there will likely be inconsistency between interfaces
unless a lowest common-denominator is sought. The middle road, while providing consistency will
not take advantage of the properties of each medium that could enhance usability. Consistency
therefore should be pursued with respect to the medium, with abstract consistency more easily
ported. For example, abstract consistency could be maintained through shared nomenclature,
metaphors and processes.
Not all systems benefit from cross-media interaction, which will bring extra complexity to both the
engineering and user interface. Enabling mobility by way of SMS support may be possible, but is it
required? Our participants, mostly university students, reported that they tended to be “in reach of a
computer,” which is also indicated by Grinter and Eldridge (). One participant said she would
prefer to go to her desk, turn on her computer and to use Rhub via the web instead of sending (and
paying for) an SMS.

8.5.4 CONCLUSION

In this section, I discussed the console, a technique for cross-channel usability. The console was a
robust way to enable interaction with the system from a variety of technologies, yet had several
intrinsic usability flaws. Users were assisted through design changes, such as softening the
requirements of the parser and including usage hints and context-sensitive help. The console syntax
was a universal one – with commands being the same no matter what technology was used to
transmit them; however, it was observed that people used the console differently depending on the
system. For example, people tending to converse more in an instant messaging style when using Rhub
via an instant messaging client. With text messages costing the sender approximately AUD . per
message, there was a financial incentive on users to quickly get the desired effect using a minimal

182
amount of messages. As a result, users would often given up if a command they issued via text
message failed, but for instant messaging would try variations until they achieved success.

8.6 Design Considerations

In this section, I introduce a series of social software design considerations. These considerations have Design
their basis in the experience of the longitudinal deployment of Rhub, and observations of other Considerations

existent social systems. The considerations are meant to be of practical value to designers in the social
software field, and are general enough to be applied to many forms of social computing.

8.6.1 UTILITY IN DESIGN

People often favour utility over other concerns such as privacy (Barkhuus and Dey ) and physical
comfort (Bodine and Gemperle ), yet it is not often discussed as a design attribute. Other work
has demonstrated that perceived utility has a significant correlation with current usage as well as
anticipated future usage, more so than usability (Davis ). Utility here does not equal functionality.
Rather, it is the value that the system provides the user, which may be through rich, complex
functionality, or relatively simple functionality. An artefact which does little in functional terms can
provide immense utility, such as a rubber band. An artefact of immense functionality can provide
relatively little utility, such as for many people, a desktop computer. Utility does not equal usability
either. Usability refers to how easy a system is to use, how learnable it is, how intuitive it appears and
so on. Usability is how well utility is delivered, and does not determine the ultimate utility of a system.
A system such as SMS, which by many measures is not particularly usable, offers great utility, and as
such is used at phenomenal levels around the world. Utility is in many ways dependant on other
properties of a design. For example, the utility potential of a design might be hampered by poor
usability, or poor functionality.
With Rhub’s console feature, utility and accessibility outweighed the usability concerns. People
used it because of the value it offered. The initial syntax of the console was particularly severe - any
symbol out of place would cause the command to fail - yet people still used it because of the benefit of
pervasive communication. An idealised version of Rhub, with perfect cross-channel usability, might
be easier to use, yet would offer little further utility and would be infeasible to build without
significant resources.
I am not suggesting that utility should be the ultimate goal of a design; merely that it is a highly
important aspect of design that appears often overlooked in discussions on user-centred design. User-

183
 centred design processes should not only design usable systems, but systems that offer a high degree
of utility. People are highly adaptable and do very well at appropriating technologies into their lives –
when it is worth their while.
Reflective Agile Iterative Design (discussed in an prior chapter) encourages the development of
Discussion utility-first design insofar as it aims to have participants who want to use the exploratory prototype
because it actually gives them value, rather than being coerced into its use.

8.6.2 NOTIFICATIONS

Notifications are commonly employed by systems to attract a person to activity that is taking place on
the system. Because notifications commonly use ‘push’ communication channels, rather than ‘pull’
communication channels, users do not have to exert much, if any, effort to receive them. Typically, the
person is alerted through a tone, vibration or visual alert, such as with text messaging or email. For
example, a photo-sharing website might email the owner of a photo when it is commented on, or a
social networking site will email people when they receive a message or someone adds them as a
contact.
Notifications are used not only as a service to users, but also as a way of driving activity and
attention back to the system. Some websites for example will send an email notification to someone
when they get a message sent to them, but the message is not provided in the email – they have to go
to the site to read it. Once at the site, the user might also look at other activity, and might be
prompted to contribute or interact themselves. With Rhub, important messages and notifications are
always pushed to people, mostly via text messaging, and thus there is less reason to check the website
frequently, where other user activity such as uploaded photos and new locations are displayed.
Because of lower number of viewers of the website, there was less appeal for people to contribute if
few other people will see it. To counter this, email notifications were sent when photos were uploaded
to a group in which they belonged. Occasional ‘account update’ emails were also sent to people who
haven’t logged in for a period, notifying them of unread messages, unrequited contact links and
reminding them of groups they’ve joined. These emails were useful in returning users to the website,
and thus, making it more attractive for others to contribute.
Notifications, even though they are targeted, can easily be annoying due to their frequency. There
is a growing awareness of the problem with social website-related notification email in particular.
Unlike spam, which is unsolicited bulk email, notifications are usually about something the recipient
might be interested in, however not necessarily interested at the time they are sent. Currently, because

184
notifications are usually mixed in with other email, it requires special effort to filter them so they can
be dealt with when appropriate.
A balance is needed between the needs of the ‘producers’ people who create activity, and desire
others – ‘consumers,’ to observe and participate. Producers want to ensure their activity has an
audience, and consumers usually like to be notified of activity – but on their own terms. Likewise, Design
Considerations
system administrators are motivated to encourage people to use the site, either to propagate network
effects or possibly increase advertising revenues. ‘Feeds,’ using Really Simple Syndication (RSS) or
similar formats, are an alternative method for notifying people without relying on email. This balance
between producers and consumers reframes slightly the awareness versus disruption trade-off
discussed by Hudson and Smith (). It is still true that the level of disruption to consumers is
related to the amount of transmitted ‘awareness’ from producers. In this case, however, awareness is
not a passive by-product of human activity as discussed by Hudson and Smith, but rather a result of
an action which seeks attention.

8.6.3 GREASING THE WHEELS OF SOCIAL NETWORKING

Establishing links with people is a core function for social systems, ranging from telephony to web-
based social sites. If people you want to link to aren’t using the system, you have to invite them, which
web sites typically make easy, but for other social systems might require more effort, such as trying to
have someone start using a mobile phone, for example. Links must be established before the mediated
socialisation can happen, so reducing the effort of this step will in turn make it easier for people to use
the system socially and grow the size of the network.
Establishing links between people may often be important within social systems. Links represent
relationships, and relationships in turn can be leveraged by the system. In a popular photo-sharing
website, recent photos uploaded by contacts are easily browsed. As a result, contact relations are often
used by people to express an affinity or liking for someone else’s work, and because they are bi-
directional, contact relations do not need to be reciprocated. Additionally, contacts can be marked as
being friend or family, and photos or sets of photos can be designated to be only viewable to these
contacts. Some other systems require contact relations to be mutually approved, which leads to more
stringent, selective usage. Artificial barriers on networking, such as limiting the number of contacts
can also place a premium on the contact relationship, and increase its value.
Links between people in a social system alter their experience of the system. Limits placed on
linking and the variety of linking styles can effect what a link between two people is ‘worth’ or what

185
 meaning is held for it by users bound by the link and observers. The designer needs an intent for
contacts – what are they supposed to represent? – which in turn will determine how the relationship
is manifested in the design. If a link between two people affords them a high level of intimacy on a
system, then it follows that links should be designed so that they are mutually approved, and designed
Discussion for low frequency of use, perhaps also with a maximum limit. If a link is supposed to represent some
tenuous connection, or simple liking or admiration, then links might be bi-directional, easy to add and
manage, and with a generous limit, or none at all.
Links should be rich, and supporting different kinds, categories or levels of links allows people to
express additional meaning. For many existent systems, the type of link used is not externally
observable, and in some cases, is only observable by the person who actually set the type.

8.6.4 TECHNOLOGICAL RESPONSES TO SOCIAL PROBLEMS

Traditional software systems were black and white in their correctness: either they produced a correct
result or not, which is straightforward to test. Social software however, has a greyscale of correctness,
and testing can be difficult. Because of the high saturation of user involvement, the system can – and
is – exposed to use as varied as social behaviour. Social behaviour, be it positive, negative, or some
shade in-between, flows through and is enacted by a social system. The designer must not only design
a system that is resilient in terms of functionality-related bugs, but also social bugs. A system that
allows users to spam others with invitations suffers no functional bug, yet suffers a very real social
bug.
While there are certain patterns of usage or behaviour that might be expected from an anti-social
user, such behaviour is emergent, and cannot be entirely anticipated by the designer. Thus, a
reflective, agile and iterative approach is desired so that design responses can be made as the issues
emerge.
It cannot - and should not - be the role of the designer to curb all forms of anti-social behaviour
within a system. There are limits of technological responses to social problems, and ultimately the
designer can only empower users with tools to act individually or as a group to reduce anti-social
behaviour. For example, social systems often offer a ‘block this user’ feature, which prevents that user
from contacting them in future, or people might use moderation points to rate the quality of
someone’s comment in a discussion.

186
8.6.5 MINIMISING PARTICIPATION EFFORT

According to a common stereotype from economics, people are inherently self-centred, and work only
to maximise their selfish reward. It is dangerous then to design social systems that rely on collective
effort to produce a potential benefit. Unless participating in the collective effort provides selfish
Design
reward, there is likely to be little participation, and thus the group benefit will never eventuate. Considerations
This observation was made early and frequently through the Rhub study. Participants reported
that the presence feature would be useful, one participant even foresaw the scenario where he could
see who is on campus so he can arrange a coffee-buddy, yet he, and others, said they would not be
bothered to set their presence. Even though participants often complained about the volume of
messages they had to deal with, few were bothered to use one of the many options available to reduce
messaging, preferring instead to simply delete messages.
I suggest two responses to this problem. ) design everything to provide a selfish benefit to the
user first, the greater group second, and ) make sure every bit of user effort is utilised.
In designing to provide selfish benefit (similarly to the suggestion to maximise the utility of the
design), it is important to remember that benefit that can come in different forms for different people.
Some people seek public recognition or accolade, and will perform tasks, such as moderating a forum,
in order to have influence and status within it. If the user is to go to the trouble of setting their
presence information, the system should provide a reward, such as allowing them to receive localised
public transport information.
There are many ways a system can ensure user effort is most efficiently used. For example, many
web mail systems have a ‘spam’ button that not only deletes the email, but also sends the mail to the
provider to increase the accuracy of spam filtering. Users were often setting presence information
using their instant messaging client’s status feature, so where possible Rhub uses that in lieu of other
presence information. If people went to the effort to try to set their presence using the @ command
syntax, for example @the beach yet ‘the beach’ was not defined, Rhub will try several methods to
resolve a location, before finally just recording the person’s location as at ‘the beach,’ rather than a fully
geo-referenced location. For similar reasons, defaults should be sensible and safe, as people
intentionally or not will often use them, a finding also made in the CSCW field (Bullen and Bennett
).

187
 8.6.6 DISCLOSURE & TRUST

Users must be able to trust that a social system is diligent with how social information is disclosed. A
social system might contain a person’s contact information, personal messages, personal photographs,
and information on who that person talks to or is otherwise interested in. This information might be
Discussion
used internally for benign purposes, such as increasing the visibility of people who a person frequently
contacts, however care must be taken that this information does not ‘leak.’
Liberal disclosure might enable anti-social behaviour such as stalking or harassment.
Embarrassment might occur if it is revealed that someone is often checking the profile of an ex-
partner. On the other hand, disclosure of social information is useful for people to get in contact
through mutual friends, or to find the contact information for a long-lost school friend. People
maintain different fronts, for example, a schoolteacher must maintain a high level of decorum when
teaching, but may be more relaxed when in the staff room, or perhaps even wild when partying with
friends. If traces of these fronts cross the boundaries, considerable embarrassment might result, for
example if a teacher’s students came across photos of her on a drunken night with friends. There have
already been reports of recruiters looking up a job candidate on social websites to see such traces,
which may negatively impact a person’s chances for employment (Finder ).
Before venturing out of the house in the morning, many people have a habit of checking the mirror
to observe how others will see them. In Goffman’s () terms, this allows people to check their
‘front’ or ‘face’, and to ensure that the costume and props are intact to support their performance. For
example, teacher might make efforts to conceal visible signs of her hang over before teaching, or the
cheating spouse might ensure that signs of lipstick and stray hairs are removed. People also maintain
fronts in social systems, and the system needs to adequately support people’s introspection and
control over their fronts. For example, systems should allow people to view themselves from others’
perspectives or at the very least, to see how their profile appears to others generally.
One participant, who was thinking of using Rhub for family-oriented organisation raised the issue
of trust. How does one trust the system? Assurances can be made, but all it takes is a bug, hack
attempt or misjudged design decision and data could be public. For the participant, the number of
users within a system and or the size of the company behind the system was how he judged
trustworthiness. Sillence et al. () suggest a staged model of trust, with the visual design of a
website being a strong indicator for trustworthiness. If a person does not trust a system, they might
limit their involvement, which in turn might limit overall participation.

188
8.6.7 CONCLUSION

In this section I have outlined a number of general design considerations for social software, which
have been formulated out of the practical experience of developing Rhub. Briefly, these are:
Utility in design: don’t forsake utility for other design goals
Design
Notifications: balance needs of producers and consumers Considerations
Grease the wheels of social networking: make it easy to invite and link to people
Technological responses to social problems: realise the limits of a technical response, empower
people
Minimise participation effort: give a selfish reward, and maximise value of any user effort
Disclosure and trust: don’t disclose more than is necessary to support pro-social behaviour

Utility, I believe, is an understated goal for design. The experience with Rhub, and elsewhere in the
literature is that people are willing to put up with various problems if a system provides enough value.
In the pursuit of utility, it is important however to not disregard properties such as usability, as a
system with poor usability will have a diminished potential utility. While it would be ideal to have a
design that offers high utility along with high usability, resource or technical constraints might require
a trade-off between such properties. I suggest that utility should be emphasised in such
circumstances.
Notifications are an essential part of social software, and used so that people can be kept abreast of
others action within the system. People who interact with the system, such as by uploading photos or
leaving messages can thus be assured there is an audience. Notifications which draw a person back to
a system are also useful from a system perspective, as it encourages use and does not require people to
exert effort to check a system. Like the observation made with Rhub’s messaging, people seem happier
to delete an unwanted message than have to exert effort to define what messages they receive.
Notifications, unlike spam, have the advantage of being personal – and are typically used for either
expressing activity of friends, or others activity which is related to you. That said, notifications should
be used with care, and controls should be provided so that users can easily opt-out of all notifications,
or notifications of a particular type.
Without people to interact with, a social system is not particularly social, and perhaps (depending
on the system) not particularly useful. A telephone without people to call is inherently useless, while a
social photo-sharing website still offers utility to people even in the absence of other users. Typically
then it is in the user’s interest as well as that of the system’s, for inviting people and inter-connecting

189
 to be as easy as possible. Once a user has joined a social system, the first required step is to usually
locate and connect to people they know, and many systems make this easy by allowing people to invite
contact lists from email, for example.
Social systems strive for social use, however not all social activity is positive, and the design needs
Discussion to be resilient in the face of anti-social use. While common patterns of anti-social behaviour are
known, and can be kept in consideration during design, such behaviour is emergent, and cannot be
completely anticipated beforehand. This demands an adaptive, agile design method, such as RAID, to
deal with problems as they occur. Technological responses have limits however, and whilst a system
might try to guide a user along a path of least obnoxious or anti-social behaviour, where there is a will,
there is a way. Here, empowering users to protect themselves and the wider community can be
effective. For example disallowing users from messaging each other unless there is a contact relation
between them (such as many instant messaging systems), largely prevents unsolicited messages.
Functions that allow people to report others for bad behaviour allow the user to block that person
from contacting them, and might be used to alert administrators to troublesome users.
Value in social systems is largely determined by active participation by its users, so it follows that
participation should be made as easy as possible. Because people tend to work towards selfish goals,
the designer cannot rely on people to exert effort ‘for the greater good’ and instead must design
features to firstly have a pay-off for the user, secondly have a pay-off for the larger community. There
will be users who actively work to build and nourish a community, and their role is to be supported
and recognised, however they are likely to be few. Other ways of encouraging or simplifying use
include using sensible defaults (or removing options altogether) and maximising the value from user
action – for example if a user frequently messages a person, that information could be used to display
the person as a messaging shortcut.
Trust must be earned from participants otherwise they may limit their interaction with a system
for fear of personal information disclosure, accidental or otherwise. Even though social systems have a
large amount of potentially useful information, care must be taken to examine the effects of disclosing
such information, even in the interests of helping people. It should also be considered how different
people’s activity is expressed to others, if strangers’ activity is too evident, it might be disorientating or
overwhelming.

190
8.7 Conclusion
This discussion chapter encompassed several topics, such as the general use of Rhub, messaging,
coordination, presence, the console, and concludes with a number of design considerations for social
software.
I found that people’s usage could often be characterised as one of a few styles. These interaction Conclusion

styles were found to be useful during design, and can serve as a basis for other design techniques, such
as personas. Participants exhibited an awareness of their own and others use, and used this awareness
to judge their own style and level of participation. Awareness of use was facilitated by observable cues
within the system, such as an indicator when other people are browsing the website. Negotiation of
how to use the system most effectively was played out within the group, with people using a
combination of talk and action to shape group usage norms. The system became appropriated into the
group, evidenced by the new turns of phrase developed, and ways in which social behaviour was
altered because of the prototype. In many cases the prototype had a positive social benefit, bringing
people together and reinforcing social ties, however many users complained about the volume of
messages they received and social tensions were also evident in isolated cases.
I also examined the role of the most used feature in Rhub – messaging, and in particular, group
messaging. Rhub uses cross-channel communication, allowing people to converse seamlessly across
instant messaging, text messaging, email and the web. Although participant interviews revealed that
the channel for communication is important, and something that is normally considered, users were
generally happy to allow Rhub to decide how to message people. This was most likely because
messages were primarily group messages, which had a lower level of intimacy than usual person-to-
person communication. Rhub afforded ‘pervasive contact’ allowing groups to communicate reliably
and instantly across a variety of communication channels. Persistency was also provided through the
website and acted as a consistent layer of persistency that covered the disparity between composite
technologies and practice. As part of the discussion, a section is also provided on the ongoing design
responses made in relation to messaging, with most of the effort going towards how to make
messaging more ‘on target’ and giving people more control over how messages are sent and received.
Coordination primarily took place using the messaging feature of Rhub, however it also involved
other entities and features within Rhub, such as locations, groups, people and photos. In a result that
confirms other research, I found that people primarily used group messaging for coordination. Group
messaging can be difficult to deal with when the volume of messages are high, and so people preferred
messaging be used for coordination, as it had a ‘pay off’ whilst idle chat might only appeal to a few

191
 people. Coordination was typically ad-hoc and last minute, often with an informal ‘half-invite’ style
afforded by group messaging.
People often used presence to indicate they were at work or the place they were going out to that
evening. Changes were made to the presence feature over time to make it more accessible, and to
Discussion increase the reward for use. This lead to higher uptake, although use was not always as intended, for
example users setting their location as they were leaving a location in order to use the public transport
feature.
To support interaction across a number of technologies, or channels, Rhub uses a text-based
command syntax, the console. Like the presence feature, the console was altered significantly over the
course of the study to improve its utility, usability and accessibility. The console has effectively no
interface – text commands are sent, parsed, and a result returned. People cannot easily examine the
interface to see what it can do or how to go about performing a particular function. To help users, an
extensive online compendium of help was developed, as well as a ‘Rhub Card,’ a credit-card sized tri-
fold card with a help on how to use the console. Context-sensitive help was used to help the user
repair from errors, however because users are charged by their carrier to send SMSes, users would
often give up after one attempt. When using the console via other channels, such as instant
messaging, they would retry commands until they reached the correct syntax.
I also suggested a number of design considerations for the social system domain. I suggest that if
faced with a selection between utility and usability, the designer should choose utility, as was the case
with Rhub’s console feature. People are highly adaptable and will learn a system quickly if they gain
high enough utility from it. Notifications are commonly used by social systems to notify people of
friends’ activity and status. ‘Producers,’ people who create activity on a social system, often desire an
audience, and notifications are one way of returning users to a system. I suggest however that the
needs of producers must be balanced with that of ‘consumers,’ people on the receiving end of
notifications. The notifications system should allow people to easily opt out of notifications, or
support alternative, lower-priority notification methods than email, such as RSS. Value within a social
system arises from use, so I highlight the need to minimise the effort required of users to join and
connect to people they know.

192
9 Conclusions

In this final chapter, I put forward the main conclusions and contributions of this thesis. Firstly, I wish
to address the research aims, originally outlined in chapter one, which form the following three
sections. In the fourth section, I conclude with a statement on this dissertation’s contribution to
knowledge.
It is not possible to tease apart entirely the specifics of Rhub and the people who used it from the
general outlined conclusions. A different design or participant pool may have produced a radically
different set of outcomes. However, like other situated accounts, such as those of an ethnographic
nature, there is still significant value for other researchers, designers and practitioners in the field.

9.1 How can we enhance how social groups communicate, coordinate and share?
From the experience of this research, I suggest that informal social groups have less of a need for
communication support than coordination and sharing†. Informal social groups are better served by a
system which brings them together in physical space, after which unmediated, face-to-face social
interaction can take place.
Coordination support needs to be flexible to support the different stages and types of organisation.
Often people don’t have concrete plans, but simply float ideas, and the group will either let the idea
sink, or work to refine it towards a plan. Some social systems treat coordination as an exercise in
calendaring, with events having a stated time, location, number of participants and so forth. These
systems often fail to support the negotiation which takes place within coordination, and are not well
suited to handle on-going changes in plan. Rhub’s lightweight coordination support, facilitated
primarily by persistent group messaging with additional support by the locations and presence
system, works very well for much of an informal social group’s coordination needs. Because of the
pervasive, mobile nature of Rhub’s messaging, coordination can take place on a fine-grained basis.
Situated action theory suggests that people tend to approach goals through an ongoing series of
situated actions in which the context of the action plays a large role in what the next step towards the

†
It can be argued that coordination and sharing is a type of communication, however throughout this
thesis I’ve used ‘communication’ to denote social chat.

193
 goal will be, rather than operating using a static pre-determined plan. Rhub is an example of a tool
which supports this style of ad-hoc coordination, which I suggest is particularly prevalent for informal
social groups.
Sharing within a group can, like coordination, take place over messaging. However, sharing often
Conclusions involves particular kinds of artefacts that should be treated in a manner different to text, such as
photographs. Sharing can be enhanced by supporting the types of things people want to share (for
example, locations, web addresses, videos or favourite shops), making it easy, and ensuring that users
get adequately rewarded for doing so. Reward for some may come about through promotion of their
efforts, such as notifying their friends. Shared items should be browsable in different ways, and allow
people to cooperatively organise them in a bottom-up fashion, such as using tags.

9.2 How do social groups assimilate and use technology for communication,
coordination and sharing?
Rhub offered a number of features for group communication, coordination and sharing, however
participants favoured group instant messaging as the primary conduit for this activity. The primacy of
basic messaging highlights the importance of instant, reliable, pervasive and simple socialising
support. Many participants noted they felt closer to the group through the use of the prototype, by
finding out more about others as well as attending events organised through Rhub that they might
otherwise miss out on.
Assimilation into the group happened in three stages, dawning, experimentation and solidification.
After this, the prototype was used as a largely unremarkable thing - a piece of mundane technology. In
the dawning, the prototype was first deployed within the social group by inviting as many people as
possible to join, a process which needs to be as easy as possible for both the inviter and invitee.
During experimentation, people came to understand the ‘system model’, such as what it can be used
for, how to operate it, and the meaning for terms such as ‘console’ and ‘tags’. This phase was
characterised by frequent mistakes in input, and reflections of how the system worked. For example,
one user on realising the frequent messages he was sending via IM were being sent as text messages,
sent “I hope you’re not getting this as SMS, that’d be really annoying.” Solidification, akin to the
‘norming’ stage of Tuckman’s () four-stage model of team development, is when participants
negotiated ‘proper’ use of the prototype using a combination of talk and action. Talk took place using
the prototype itself, as well as face-to-face discussions apart from the prototype. Through action,
participants demonstrated to others what they thought was best practice.

194
 The prototype was used mostly for the organisation of social events, typically on an ad-hoc, last-
minute basis, such as using ‘half-invites’. People mostly used group messaging for this purpose;
however a number of other features were also utilised, such as locations, presence and photo sharing.
For example, the group might organise an event over the course of the day using messaging, making
reference to locations defined in Rhub. Last-minute details are sent around the group, such as advice How can mobile
social systems be
to avoid using trains because of a strike. During the event, usage of Rhub is minimal for those
effectively
attending, although it is frequently used by people at the event to entice others to come, and by people designed,
not at the event to find out how it is progressing. After the event, someone might upload photos, developed and
studied?
which can then be commented on or tagged by others.

9.3 How can mobile social systems be effectively designed, developed and studied?
Reflective Agile Iterative Design (RAID) is a first step for the effective design, development and research
of mobile social systems. It is the first cohesive framework for this manner of design, however builds
upon well-established theories and methods, such as action research, user-centred design and agile
development. RAID involves three steps: design, feedback and reflection; which take place around a
continuously available exploratory prototype. It also advocates utility as a central element of a design.
Respecting the complex design scenario presented in mobile social software, RAID calls for an
iterative, exploratory approach, which aims to understand the problem space as design and
development progresses. Understanding is not reached simply through blundering towards a design
goal. Rather, RAID uses reflection as a critical process within the framework, which involves digestion
of the available feedback, followed by a thoughtful, measured design response. Feedback from the use
of the system as well as from users themselves is utilised to identify elements of the design that can be
improved, as well as opportunities for innovation.
Development within RAID happens in an agile, minimal manner. Only development that is
necessary for the current requirements is performed, and even then, only enough development to
make it work. This is not to suggest a shoddy ‘quick-fix’ approach to development. Indeed, by using
test-driven development and refactoring the prototype during the iterations, a high quality
implementation can be realised. Because of the requirement of a continuously-available prototype, the
method requires code to be of production quality so that the system is actually useful.
Researchers can also benefit from RAID, as feedback gathered as part of the process is valuable.
Because the exploratory prototype is deployed on a continuous basis, there is opportunity to study
novelty effects, and should it be available for long enough, gives the researcher the ability to observe

195
 how a system becomes appropriated into use. Apart from RAID, the thesis introduces a situated
research tool, the quiz, a useful and effective method to explore participants’ everyday context.

9.4 Contributions of this thesis

Conclusions This thesis makes four major contributions to knowledge: ) a new design framework, ) a description
of a novel mobile social system, ) results and analysis of the usage of a mobile social system over a
long period of time by a large number of users and ) a number of grounded design considerations for
mobile social systems development.
Firstly, I propose a new design framework, Reflective Agile Iterative Design (RAID, chapter six),
which combines elements of action research and agile development to evolve a design in a thoughtful,
responsive manner. RAID is particularly suited to the development of social systems that demand an
exploratory, reflective approach to understanding.
Secondly, I describe a novel exploratory prototype, Rhub (chapter five), which aims to support
group communication, coordination and sharing. The prototype was developed over time using RAID
and was deployed for over . years with over  participants. Because of this ‘real world’
deployment, it was exposed to a variety of uses, personalities, behaviours and situations which would
not happen for a short study, or a study run within narrow parameters. The prototype presents a
method for cross-channel interaction that supports pervasive group messaging, and a flexible
presence awareness system.
Thirdly, I present the analysis of qualitative and quantitative results (chapter seven) from the usage
of the prototype, and a number of other studies. These results show that participants favoured using
the messaging feature for coordination rather than chat, particularly a ‘half-invite’ style of ad-hoc, last-
minute coordination which is afforded by Rhub (§.). I also describe how the prototype was
appropriated by the group through the awareness and negotiation of use, development of norms and
new emergent behaviours (§.). Such data is missing from the literature, as prototypes are typically
deployed for only a short period of time or with a limited number of participants.
Finally, a discussion on the design of social systems (§.), grounded in the experience of
developing and deploying Rhub, provides a number of design considerations for other practitioners
and suggestions for features to support informal group socialising. I argue that utility within design is
underrated, and should be given more prominence as a design goal. I also suggest that the design
should always reward people for participation, and that as much value as possible should be extracted
from a user’s interaction with the system. Anti-social user behaviour can never be entirely prevented

196
in a social system, or it would cease to be a social system, so I suggest the designer empowers users to
protect themselves where possible.
Through the exploration of the research problem, and the resulting four contributions, this thesis
not only provides a better understanding of mobile social computing, but also describes empirical
results and introduces new methods for design. Contributions of
this thesis

197
198
10 Appendices

199
 Appendix A: Social Graph

Appendices

200
Appendix B: Quiz Results

Index Question Response tallies

 Where are you? Home: 
Work: 
Cafe: 
Uni: 
 What devices have you got at hand? Computer: 
Ladline phone: 
Camera: 
Mobile phone: 
MSN: 
 How many msgs do you have in your sms and email SMS: , , , heaps, , , 

inboxes right now? Email: , , , heaps, , s
 How many messages or emails have you sent so far None: 
today? One message: 
Two messages: 
Five messages: 
 What kind of place are you at now: cafe, home, work Home: 
etc..? Work: 
 Have you re-read an old Rhub message today? No: 
Yes: 
 Have you re-read an old email, im or SMS today? Yes: 
No: 
 What communication devices do you have available Landline: 
to you right now? Mobile: 
Computer: 
 Right now, would you prefer to get call, sms, email SMS: 

or IM? Email: 
IM: 

Email or IM: 
Call: 
 Right now, which would you prefer to use: call, sms, IM: 
email or IM? Call: 
 Are you inside or outside right now? Inside: 
Outside: 

201
  If  is super busy and  is not at all busy, how busy Busy rank : 
are you now? Busy rank : 
Busy rank : 
 Who are you with right now? eg friends, workmates, Noone: 
noone, family etc...? Family: 
Appendices
Coworkers: 
Classmates: 
Friends: 
 How did you get alerted about this message: beep, Beep: 
popup etc...? Popup: 
Light (silent): 
Vibration: 
 How many people are in the same space as you right One person: 
now? Two people: 
 What’s your position: walking, reclining, jumping, Relaxing/sitting: 
sitting etc..? At computer: 
Walking: 
Sleeping: 
Dancing: 

202
Appendix C: Workshop Posters
Enlargement of Figure , Page .

203
 Appendix B: Workshop Posters

Enlargement of Figure , page 150.

Appendices

204
11 References

Access Economics (), ‘Australian Mobile Telecommunications Industry: Economic Significance

and State of the Industry’.
Allen, T. J. and Hauptman, O. (), ‘The Influence of Communication Technologies on
Organizational Structure’, Communications Research,  (), -.
Anderson, C. (), ‘The Long Tail’, Wired <http://www.wired.com/wired/archive/./tail.html>,
accessed th November .
Arnowitz, J., Arent, M., and Berger, N. (), Effective Prototyping for Software Makers, eds. Stuart
Card, Jonathan Grudin, and Jakob Nielsen (Interactive Technologies; San Francisco, USA: Morgan
Kaufmann) .
Arthur, L. J. (), Rapid Evolutionary Development: Requirements, Prototyping and Software
Creation, eds. Patrick A. V. Hall, Martyn A. Ould, and William E. Riddie (Software Engineering
Practice; New York: John Wiley & Sons) .
Australian Associated Press (), ‘Technology marches ahead, grammar gets worse’, Sydney Morning
Herald, April , .
Bakken, F. (), ‘SMS Use Among Deaf Teens and Young Adults in Norway’, in Richard Harper,
Leysia Palen, and Alex Taylor (eds.), The Inside Text: Social Cultural And Design Perspectives On
SMS (Dordrecht, The Netherlands: Springer), -.
Ball, L. J. and Ormerod, T. C. (), ‘Applying ethnography in the analysis and support of expertise in
engineering design’, Design Studies,  (), -.
Barkhuus, L. (), ‘Why Everyone Loves to Text Message: Social Management with SMS’, GROUP
(Sanibel Island, FL, USA), -.
Barkhuus, L. and Dey, A. (), ‘Location-Based Services for Mobile Telephony: a study of users’
privacy concerns’, Interact (), -.
Bartunek, J. M. (), ‘Scholarly Dialogues and Participatory Action Research’, Human Relations, 
(), -.
Bauer, M., Heiber, T., Korteum, G., and Segall, Z. (), ‘Collaborative Wearable System with Remote
Sensing’, Second International Symposium on Wearable Computers (ISWC) (IEEE Press), -.
Beck, K. (), Extreme programming explained: embrace change (Reading, MA, USA: Addison-
Wesley).

205
 Beck, K., Beedle, M., Bennekum, A. v., Cockburn, A., Cunningham, W., Fowler, M., Grenning, J.,
Highsmith, J., Hunt, A., Jeffries, R., Kern, J., Marick, B., Martin, R. C., Mellor, S., Schwaber, K.,
Sutherland, J., and Thomas, D. ‘Manifesto for Agile Software Development’,
<http://www.agilemanifesto.org/>, accessed July th .
References Bellotti, V. (), ‘Design for privacy in multimedia computing and communication environments’, in
Philip Agre and Marc Rotenberg (eds.), Technology and Privacy: The new landscape (Cambridge,
MA: MIT Press), -.
Bellotti, V. and Smith, I. (), ‘Informing the design of an information management system with
iterative fieldwork’, Designing Interactive Systems (DIS) (New York: ACM Press), -.
Bellotti, V. and Edwards, K. (), ‘Intelligibility and Accountability: Human Considerations in
Context-Aware Systems’, Human-Computer Interaction, , -.
Bellotti, V., Ducheneaut, N., Howard, M., Smith, I., and Neuwirth, C. (), ‘Innovation in Extremis:
Evolving an Application for the Critical Work of Email and Information Management’, Designing
Information Systems (DIS): ACM Press, -.
Biletzki, A. and Matar, A. ‘“Ludwig Wittgenstein”, The Stanford Encyclopaedia of Philosophy (Winter
 Edition)’ <http://plato.stanford.edu/archives/win/entries/wittgenstein/>.
Billinghurst, M., Weghorst, S., and Furness, T. (), ‘Wearable Computers for Three Dimensional
CSCW’, First International Symposium on Wearable Computers (ISWC) (IEEE Press), -.
Bjerknes, G. and Bratteteig, T. (), ‘User Participation and Democracy: A Discussion of
Scandinavian Research on System Development’, Scandinavian Journal of Information Systems, 
(), -.
Blumer, H. (), Symbolic Interactionism: Perspective and Method (New Jersey, USA: Prentice-Hall).
— (a), ‘Society as Symbolic Interaction’, in Jerome G. Mann and Bernard N. Meltzer (eds.),
Symbolic Interaction - a reader in social psychology (nd edn.; Boston, MA, USA: Allys and Bacon,
Inc.), -.
— (b), ‘Sociological Analysis and the “Variable”’, in Jerome G. Mann and Bernard N. Meltzer
(eds.), Symbolic Interaction - a reader in social psychology (nd edn.; Boston, MA, USA: Allys and
Bacon, Inc.), -.
Bodine, K. and Gemperle, F. (), ‘Effects of Functionality on Perceived Comfort of Wearables’,
Seventh International Symposium on Wearable Computers (ISWC), -.
Boehm, B. W. (), ‘A Spiral Model of Software Development and Enhancement’, Computer,  (),
-.

206
Brooks, F. P. (), The Mythical Man-Month: Essays on Software Engineering (Reading, MA, USA:
Addison-Wesley).
Brown, B. and Randell, R. (), ‘Building a Context Sensitive Telephone: Some Hopes and Pitfalls for
Context Sensitive Computing’, Computer-supported cooperative work (CSCW),  (), -.
Bullen, C. V. and Bennett, J. L. (), ‘Learning from user experience with groupware’, Computer-
supported cooperative work (CSCW) (ACM Press), -.
Button, G. (), ‘The Ethnographic Tradition and Design’, Design Studies,  (), -.
Buur, J. and Soendergaard, A. (), ‘Video card game: An augmented environment for user centred
design discussions’, Designing Augmented Reality Environments (DARE) (Elsinore, Denmark: ACM
Press), -.
Buur, J. and Binder, T. (eds.) (), The practice of User Centred Design In Manufacturing Industry
(Sønderborg, Denmark: Mads Clausen Institute for Product Innovation).
Buxton, W. and Sniderman, R. (), ‘Iteration in the Design of the Human-Computer Interface’, th
Annual Meeting, Human Factors Association of Canada, -.
Carroll, J. (), ‘Completing design in use: closing the appropriation cycle’, in T. Leino, T. Saarinen,
and S. Klein (eds.), th European Conference on Information Systems (ECIS), -.
Chamblis, D. F. and Schutt, R., K. (), Making Sense of the Social World: Methods of Investigation
(California: Sage Publications).
Checkland, P. and Scholes, J. (), Soft Systems Methodology in Action (Chichester, UK: John Wiley &
Sons) .
Choudhury, T. and Pentland, A. (), ‘Sensing and Modelling Human Networks using the
Sociometer’, Seventh International Symposium on Wearable Computers (ISWC) (IEEE Press), - .
Clarkson, B., Pentland, A., and Mase, K. (), ‘Recognizing User Context via Wearable Sensors’,
Fourth International Symposium on Wearable Computing (ISWC) (IEEE Press), -.
Conklin, J. (), ‘Wicked Problems and Social Complexity’, Dialogue Mapping: Building Shared
Understanding of Wicked Problems (New Jersey, NY, USA: Wiley), .
Cooper, A. (), The Inmates are Running the Asylum (Indianapolis, USA: Sams).
Cooper, A., Reimann, R., and Cronin, D. (), About Face : The Essentials of Interaction Design (rd
edn.; Indianapolis, USA: Wiley Publishing) .
Counts, S. (), ‘Group-Based Mobile Messaging In Support of the Social Side of Leisure’,
Computer-supported cooperative work (CSCW),  (), -.
Crabtree, A. (), ‘Design in the absence of practice: breaching experiments’, Designing interactive
systems (DIS) (ACM Press), -.

207
 Davis, F. D. (), ‘Perceived Usefulness, Perceived Ease of Use, and User Acceptance of Information
Technology’, MIS Quarterly,  (), -.
Dix, A. (), ‘Pace and Interaction’, in Andrew Monk, Dan Diaper, and Michael D. Harrison (eds.),
People and Computers VII (Cambridge, UK: Cambridge University Press), -.
References Dobashi, S. (), ‘The Gendered Use of Keitai in Domestic Contexts’, in Mizuko Ito, Daisuke Okabe,
and Misa Matsuda (eds.), Personal, Portable, Pedestrian (Cambridge, MA, USA: MIT Press), -.
Donner, J. (), ‘The rules of beeping: exchanging messages using missed calls on mobile phones in
sub-Saharan Africa’, paper given at Questioning the Dialogue: th Annual Conference of the
International Communication Association, New York.
Dourish, P. (), ‘The Appropriation of Interactive Technologies: Some Lessons from Placeless
Documents’, Computer-supported cooperative work (CSCW),  (), -.
— (), ‘What We Talk About When We Talk About Context’, Personal and Ubiquitous Computing,
 (), -.
— (), ‘Implications for Design’, Human factors in computing systems (CHI), -.
Dryer, D. C., Eisbach, C., and Ark, W. S. (), ‘At what cost pervasive? A social computing view of
mobile computing systems’, IBM Systems Journal,  (), -.
Eagle, N. and Pentland, A. (), ‘Wearables in the Workplace: Sensing Interactions at the Office’,
Seventh International Symposium on Wearable Computers (ISWC) (IEEE Press), - .
Ehn, P. (), ‘Scandinavian Design: On Participation and Skill’, in P. S. Adler and T. A. Winograd
(eds.), Usability: Turning technologies into tools (New York: Oxford University Press), -.
Elwood-Clayton, B. (), ‘Desire and Loathing in the Cyber Philippines’, in Richard Harper, Leysia
Palen, and Alex Taylor (eds.), The Inside Text: Social Cultural And Design Perspectives On SMS
(Dordrecht, The Netherlands: Springer), -.
Farnham, S. D. and Keyani, P. (), ‘Swarm: Hyper Awareness, Micro Coordination, and Smart
Convergence through Mobile Group Text Messaging’, th Annual Hawaii International
Conference on System Sciences (HICSS) (Hawaii, USA: ACM Press).
Finder, A. (), ‘For Some, Online Persona Undermines a Résumé’, New York Times, June th, .
Fresco, A. (), ‘Texting teenagers are proving ‘more literate than ever before', The Times, October
st, .
Friedman, B. (), ‘Value-Sensitive Design’, Interactions,  (), -.
Garfinkel, H. (), ‘Studies of the Routine Grounds of Everyday Activities’, Social Problems,  (),
-.
Garfinkel, S. (), ‘History's Worse Software Bugs’, Wired, th November.

208
Gaver, B., Dunne, T., and Pacenti, E. (), ‘Design: Cultural Probes’, Interactions, -.
Gaver, W. W., Bowers, J., Boucher, A., Gellerson, H., Pennington, S., Schmidt, A., Steed, A., Villars, N.,
and Walker, B. (), ‘The drift table: designing for ludic engagement’, Human factors in
computing systems (CHI), extended abstracts (ACM Press), -.
Gershman, A. V., McCarthy, J. F., and Fano, A. E. (), ‘Situated Computing: Bridging the Gap
between Interaction and Action’, Third International Symposium on Wearable Computers (ISWC)
(IEEE Press), -.
Ghini, V., Pau, G., and Salomoni, P. (), ‘Integrating Notification Services in Computer Network
and Mobile Telephone’, Symposium on Applied Computing (SAV) (ACM Press), -.
Goffman, E. (), The Presentation of Self in Everyday Life (New York: Doubleday Anchor).
— (), Behaviour in Public Places (New York: The Free Press).
— (), Ritual Interaction: Essays on face-to-face behavior (New York: Pantheon).
Greenwood, D. J. (), ‘Action Research: Unfulfilled Promises and Unmet Challenges’, in Bill Cooke
and Julie Wolfram Cox (eds.), Fundamentals of Action Research (-; London: Sage).
Grinter, R. E. and Eldridge, M. A. (), ‘y do tngrs luv  txt msg?' European Computer-supported
cooperative work (ECSCW) (Bonn, Germany: Kluwer), -.
Grinter, R. E. and Palen, L. (), ‘Instant Messaging in Teen Life’, Computer-supported cooperative
work (CSCW) (New Orleans, USA: ACM Press), -.
Grinter, R. E. and Eldridge, M. A. (), ‘Wantlk?: Everyday Text Messaging’, Human factors in
computing systems (CHI) (Ft. Lauderdale, Forida, USA: ACM Press), -.
Grudin, J. (), ‘Groupware and Social Dynamics: Eight Challenges for Developers’,
Communications of the ACM,  (), -.
Grudin, J. and Pruitt, J. (), ‘Personas, Participatory Design and Product Development: An
Infrastructure for Engagement’, Participatory Design Conference (PDC).
Hagen, P., Robertson, T., Kan, M., and Sadler, K. (), ‘Emerging research methods for
understanding mobile technology use’, Australasian Computer-Human Interaction Conference
(OZCHI) (Canberra, ACT, AU: ACM Press), -.
Häkkilä, J. and Chatfield, C. (), ‘“It's Like if you Opened Someone Else’s Letter" - User Perceived
Privacy and Social Practices with SMS Communication’, Seventh international conference on
Human computer interaction with mobile devices & services (MobileHCI) (Salzburg, Austria: ACM
Press), -.
Hammersley, M. (), ‘Deconstructing the qualitative-quantitative divide’, in Julia Brannen (ed.),
Mixing methods: Qualitative and quantitative research (Aldershot, UK: Avebury), –.

209
 Hård af Segerstad, Y. (), ‘Language in SMS - a socio-linguistic view’, in Richard Harper, Leysia
Palen, and Alex Taylor (eds.), The Inside Text: Social Cultural And Design Perspectives On SMS
(Dordrecht, The Netherlands: Springer), -.
Harrison, S., Tatar, D., and Sengers, P. (), ‘The Three Paradigms of HCI’, Human factors in
References computing systems (CHI), alt.chi.
Heslin, R. and Patterson, M. L. (), Nonverbal Behaviour and Social Psychology (New York:
Plenum Books).
Hirsch, T. and Henry, J. (), ‘TXTmob: text messaging for protest swarms’, Human factors in
computing systems (CHI) (Portland, OR, USA: ACM Press), -.
Höflich, J. R. and Gebhardt, J. (), ‘Changing Cultures of Written Communication: Letter - E-mail -
SMS’, in Richard Harper, Leysia Palen, and Alex Taylor (eds.), The Inside Text: Social Cultural And
Design Perspectives On SMS (Dordrecht, The Netherlands: Springer), -.
Honigsbaum, M. (), ‘Concern over rise of “happy slapping” craze’, The Guardian, April th.
Hughes, J. A., Randall, D., and Shapiro, D. (), ‘Faltering from ethnography to design’, Computer-
Supported Cooperative Work (CSCW) (ACM), -.
Hulkko, S., Mattelmäki, T., Virtanen, K., and Keinonen, T. (), ‘Mobile Probes’, Third Nordic
conference on Human-computer interaction (NordiCHI) (Tampere, Finland: ACM Press), -.
Hull, R., Neaves, P., and Bedford-Roberts, J. (), ‘Towards Situated Computing’, First International
Symposium on Wearable Computers (ISWC) (IEEE Press), -.
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’, Human factors in computing systems (CHI), -.
Ishii, H. and Miyake, N. (), ‘Toward an open shared workspace: computer and video fusion
approach of TeamWorkStation’, Communications of the ACM,  (), -.
Ito, M. (), ‘Introduction’, in Mizuko Ito, Daisuke Okabe, and Misa Matsuda (eds.), Personal,
Portable, Pedestrian (Cambridge, MA, USA: MIT Press).
Ito, M. and Okabe, D. (), ‘Technosocial Situations’, in Mizuko Ito, Daisuke Okabe, and Misa
Matsuda (eds.), Personal, Portable, Pedestrian (Cambridge, MA, USA: MIT Press), -.
ITU (), ‘Digital.Life: ITU Internet Report ’, (Geneva, Switzerland).
Jensen, C., Farnham, S. D., Drucker, S. M., and Kollock, P. (), ‘The effect of communication
modality on cooperation in online environments’, Human factors in computing systems (CHI) (The
Hague, The Netherlands: ACM Press), -.

210
Jung, Y., Persson, P., and Blom, J. (), ‘DeDe: Design and Evaluation of a Context-Enhanced Mobile
Messaging System’, Human factors in computing systems (CHI) (Portland, OR, USA: ACM Press), -
.
Kasesniemi, E.-L. and Rautiainen, P. (), ‘Mobile culture of children and teenagers in Finland’, in
James E. Katz and Mark Aakhus (eds.), Perpetual Contact: Mobile communication, private talk,
public performance (Cambridge, UK: Cambridge University Press), -.
Kim, S. D. (), ‘Korea: personal meanings’, in James E. Katz and Mark Aakhus (eds.), Perpetual
Contact: Mobile communication, private talk, public performance (Cambridge, UK: Cambridge
University Press), -.
Kolko, B. E., Rose, E. J., and Johnson, E. (), ‘Communication as Information-Seeking: The Case for
Mobile Social Software for Developing Regions’, WWW  (Banff, Alberta, Canada: ACM Press),
-.
Kopomaa, T. (), ‘The Breakthrough of Text Messaging in Finland’, in Richard Harper, Leysia
Palen, and Alex Taylor (eds.), The Inside Text: Social Cultural And Design Perspectives On SMS
(Dordrecht, The Netherlands: Springer), -.
Korteum, G. and Segall, Z. (), ‘Wearable Communities: Augmenting Social Networks with
Wearable Computers’, Pervasive Computing,  (), -.
Kortuem, G., Schneidern, J., Preuitt, D., Thompson, T. G. C., Fickas, S., and Segall, Z. (), ‘When
Peer-to-Peer comes Face-to-Face: Collaborative Peer-to-Peer Computing in Mobile Ad hoc
Networks’, First International Conference on Peer-to-Peer Computing (PP) (IEEE), -.
Laplante, P. A. and Neill, C. J. (), ‘“The Demise of the Waterfall Model Is Imminent” and Other
Urban Myths’, Queue,  (), -.
Larman, C. and Basili, V. (), ‘Iterative and Incremental Development: A Brief History’, Computer,
 (), -.
Laursen, D. (), ‘Please reply! The replying norm in adolescent SMS communication’, in Richard
Harper, Leysia Palen, and Alex Taylor (eds.), The Inside Text: Social Cultural And Design
Perspectives On SMS (Dordrecht, The Netherlands: Springer), -.
Lee, R. M. (), Unobtrusive Measures in Social Research (Buckingham, UK: Open University Press).
Leuf, B. and Cunningham, W. (), The Wiki way: quick collaboration on the Web (Boston, USA:
Addison-Wesley) .
Lewin, K. (), ‘Action research and minority problems’, Journal of Social Issues,  (), -.

211
 Ling, R. (), ‘“One can talk about common manners!”: The use of mobile telephones in
inappropriate situations’, Technical Report / (Oslo, Norway: Telenor Research and
Development).
— (), The Mobile Connection: The Cell Phone's Impact on Society (San Francisco, CA, USA: Morgan
References Kaufmann Publishers).
— (), ‘The Sociolinguistics of SMS: An Analysis of SMS Use by a Random Sample of Norwegians’,
in Rich Ling and Per E. Pedersen (eds.), Mobile Communications (London: Springer), -.
Ling, R. and Yttri, B. (), ‘Hyper-coordination via mobile phones in Norway’, in J. Katz and M.
Aakhus (eds.), Perpetual Contact: Mobile communication, private talk, public performance
(Cambridge: Cambridge University Press), -.
Ling, R., Julsrud, T., and Ytrri, B. (), ‘Nascent Communication Genres within SMS and MMS’, in
Richard Harper, Leysia Palen, and Alex Taylor (eds.), The Inside Text: Social Cultural And Design
Perspectives On SMS (Dordrecht, The Netherlands: Springer), -.
Maden, A., Caneel, R., and Pentland, A. (), ‘GroupMedia - Using Wearable Devices to
Understand Social Context’, (Boston, MA: MIT Media Laboratory).
Mark, G., Christensen, U., and Shafae, M. (), ‘A Methodology Using a Microcamera for Studying
Mobile IT Usage and Person Mobility’, CHI Workshop on Mobile Communication (CHI) (ACM Press).
Mathes, A. (), ‘Folksonomies-Cooperative Classification and Communication Through Shared
Metadata’, Computer Mediated Communication, LISCMC (Doctoral Seminar), Graduate School of
Library and Information Science, University of Illinois Urbana-Champaign, December.
Matsuda, M. (a), ‘Mobile Communication and Selective Sociality’, in Mizuko Ito, Daisuke Okabe,
and Misa Matsuda (eds.), Personal, Portable, Pedestrian (Cambridge, MA, USA: MIT Press), -.
— (b), ‘Discourses of Keitai in Japan’, in Mizuko Ito, Daisuke Okabe, and Misa Matsuda (eds.),
Personal, Portable, Pedestrian (Cambridge, MA, USA: MIT Press), -.
Matthews, B. (), ‘Studying Design: An interpretive and empirical investigation of design activity
at differing levels of granularity’, PhD Thesis (The University of Queensland).
McLuhan, M. (), Understanding Media: the extensions of man (New York: McGraw-Hill).
McTaggart, R. (), ‘Principles for Participatory Action Research’, Adult Education Quarterly,  (),
-.
Miyata, K., Boase, J., Wellmann, B., and Ikeda, K. i. (), ‘The Mobile-izing Japanese: Connecting to
the Internet by PC and Webphone in Yamanashi’, in Mizuko Ito, Daisuke Okabe, and Misa
Matsuda (eds.), Personal, Portable, Pedestrian (Cambridge, MA, USA: MIT Press), -.
Morville, P. (), Ambient Findability (Sebastopol, California: O'Reilly Media).

212
Naur, P. and Randell, B. (), Software Engineering: Report of a conference sponsored by the NATO
Science Committee, Garmisch, Germany - Oct.  (Brussels: Scientific Affairs Division,
NATO).

Nielsen, J. (), ‘Iterative User Interface Design’, Computer,  (), -.

Nonnecke, B. and Preece, J. (), ‘Persistence and Lurkers in Discussion Lists: A Pilot Study’, rd
Annual Hawaii International Conference on System Sciences (HICSS').
Norman, D. A. (), The Psychology of Everyday Things (New York: Persus).
Okada, T. (), ‘Youth Culture and the Shaping of Japanese Mobile Media: Personalization and the
Keitai Internet as Multimedia’, in Mizuko Ito, Daisuke Okabe, and Misa Matsuda (eds.), Personal,
Portable, Pedestrian (Cambridge, MA, USA: MIT Press), -.
Osman, Z., Maguire, M., and Tarkiainen, M. (), ‘Older Users' Requirements for Location Based
Services and Mobile Phones’, Fifth international conference on Human computer interaction with
mobile devices & services (MobileHCI) (Udine, Italy: Springer), -.
Oulasvirta, A. (), ‘Finding Meaningful Uses for Context-Aware Technologies: The Humanistic
Research Strategy’, Human factors in computing systems (CHI) (Vienna, Austria: ACM Press), -.
Palen, L., Salzman, M., and Youngs, E. (), ‘Discovery and Integration of Mobile Communications
in Everyday Life ‘, Personal and Ubiquitous Computing,  (), -.
Plant, S. (), ‘On the Mobile: The Effects of Mobile Telephones on Social and Individual Life’,
(Motorola).
Puro, J.-P. (), ‘Finland: a mobile culture’, in James E. Katz and Mark Aakhus (eds.), Perpetual
Contact: Mobile communication, private talk, public performance (Cambridge, UK: Cambridge
University Press), -.
Raento, M., Oulasvirta, A., Petit, R., and Toivonen, H. (), ‘ContextPhone: A Prototyping Platform
for Context-Aware Mobile Applications’, Pervasive Computing,  (), -.
Rasmussen, L. B. (), ‘Action Research - Scandinavian experiences’, AI & Society,  (), -.
Rhodes, B. J. (), ‘The Wearable Remembrance Agent: a System for Augmented Memory’, Personal
Technologies,  (), -.
Rittel, H. and Webber, M. (eds.) (), Dilemmas in a General Theory of Planning (Policy Sciences, :
Elsevier Scientific Publishing Company, Inc., Amsterdam) -.
Rivière, A. and Licoppe, C. (), ‘From Voice to Text: continuity and change in the use of mobile
phones in France and Japan’, in Richard Harper, Leysia Palen, and Alex Taylor (eds.), The Inside
Text: Social Cultural And Design Perspectives On SMS (Dordrecht, The Netherlands: Springer),
-.

213
 Robertson, T. and Brereton, M. (), Personal communication.
Royce, W. W. (), ‘Managing the Development of Large Software Systems’, Proceedings of Westcon
(IEEE CS Press), -.
Schön, D. (), The Reflective Practitioner: How Professionals Think in Action (New York: Basic
References Books).
Schusteritsch, R., Rao, S., and Rodden, K. (), ‘Mobile Search with Text Messages: Designing the
User Experience for Google SMS’, Human factors in computing systems (CHI) (Portland, OR, USA:
ACM Press), -.
Schwaber, K. and Beedle, M. (), Agile Software Development with Scrum (Upper Saddle River, NJ,
USA: Prentice Hall) .
Sengers, P., Boehner, K., David, S., and Kaye, J. (), ‘Reflective Design’, Fourth decennial conference
on Critical computing: between sense and sensibility (Aarhus, Denmark: ACM Press), -.
Sharp, H., Rogers, Y., and Preece, J. (), Interaction Design: Beyond Human-Computer Interaction
(nd edn.: John Wiley & Sons) .
Sheridan, J. G., Lafond-Favieres, V., and Newstetter, W. (), ‘Spectators at a Geek Show: An
Enthnographic Inquiry into Wearable Computing’, Fourth International Symposium on Wearable
Computing (ISWC) (IEEE), -.
Sillence, E. and Baber, C. (), ‘Integrated digital communities: combining web-based interaction
with text messaging to develop a system for encouraging group communication and competition’,
Interacting with Computers, , -.
Sillence, E., Briggs, P., Fishwick, L., and Harris, P. (), 'Trust and Mistrust of Online Health Sites',
Human factors in computing systems (CHI') (Vienna, Austria: ACM Press), -.
Smith, I., Consolvo, S., Lamarca, A., Hightower, J., Scott, J., Sohn, T., Hughes, J., Iachello, G., and
Abowd, G. D. (), ‘Social Disclosure of Place: From Location Technology to Communication
Practices’, Pervasive  (Munich, Germany: Springer-Verlag), -.
Suchman, L. A. (), Plans and Situated Actions: The Problem of Human-Machine Communication
(Cambridge, UK: Cambridge University Press).
Svendsen, G. B., Evjemo, B., and Johnsen, J. A. K. (), ‘Use of SMS in Office Environments’, th
Annual Hawaii International Conference on System Sciences (HICSS) (Hawaii, USA).
Tamminen, S., Oulasvirta, A., Toiskallio, K., and Kankainen, A. (), ‘Understanding mobile
contexts’, Personal and Ubiquitous Computing,  (), -.

214
Taylor, A. S. and Harper, R. (), ‘Age-old practices in the ‘new world': a study of gift-giving between
teenage mobile phone users’, Human factors in computing systems (CHI) (Minneapolis, MI, USA:
ACM Press), -.
Tohidi, M., Buxton, W., Baecker, R., and Sellen, A. (a), ‘Getting the Right Design and the Design
Right: Testing Many is Better than One’, Human factors in computing systems (CHI) (ACM Press),
-.
— (b), ‘User Sketches: A Quick, Inexpensive, and Effective way to Elicit More Reflective User
Feedback’, Fourth Nordic conference on Human-computer interaction (NordiCHI) (Oslo, Norway:
ACM Press), -.
Tuckman, B. W. (), ‘Developmental sequence in small groups’, Group Facilitation: A Research and
Applications Journal, (), -.
Väänänen-Vainio-Mattila, K. (), ‘The Future of Mobile Communities: Evolution Towards
Continuous Presence’, SIGCHI Bulletin, (May/June), .
Varbanov, V. (), ‘Bulgaria: mobile phones as post-communist cultural icons’, in James E. Katz and
Mark Aakhus (eds.), Perpetual Contact: Mobile communication, private talk, public performance
(Cambridge, UK: Cambridge University Press), -.
Virzi, R. A., Sokolov, J. L., and Karis, D. (), ‘Usability problem identification using both low- and
high-fidelity prototypes’, Human factors in computing systems (CHI), -.
Vogiazou, Y., Reid, J., Raijmakers, B., and Eisenstadt, M. (), ‘A Research Process for Designing
Ubiquitous Social Experiences’, Fourth Nordic conference on Human-computer interaction
(NordiCHI) (Oslo, Norway: ACM Press), -.
Wajcman, J., Bittman, M., Jones, P., Johnstone, L., and Brown, J. (), ‘The Impact of the Mobile
Phone on Work/Life Balance (Preliminary Report June )’, (Australian Mobile
Telecommunications Association and the Australian National University), .
Walker, M., Takayama, L., and Landay, J. A. (), ‘High-fidelity or low-fidelity, paper or computer?
Choosing attributes when testing web prototypes’, Human Factors and Ergonomics Society th
Annual Meeting, -.
Weilenmann, A. (), ‘Negotiating Use: Making Sense of Mobile Technology’, Personal and
Ubiquitous Computing,  (), -.
Weilenmann, A. and Larsson, C. (), ‘Local Use and Sharing of Mobile Phones’, in Barry Brown,
Nicola Green, and Richard Harper (eds.), Wireless World: Social and Interactional Aspect of the
Mobile Age (London: Springer-Verlag), -.

215
 Weiser, M. (), ‘Some computer science issues in ubiquitous computing’, SIGMOBILE Mobile
Computing and Communications Review,  (), -.
Weiss, R. S. (), Learning From Strangers: The Art and Method of Qualitative Interview (New York:
Free Press).
References Whittaker, S., Terveen, L., Hill, W., and Cherny, L. (), ‘The Dynamics of Mass Interaction’,
Computer-supported cooperative work (CSCW), -.
Whyte, W. F. (), ‘Advancing Scientific Knowledge through Participatory Action Research’,
Sociological Forum,  (), -.
— (), Participatory action research, ed. William Foote Whyte (Newbury Park, California: Sage)
.
Williams, L. and Cockburn, A. (), ‘Agile Software Development: It's about Feedback and Change’,
Computer,  (), -.
Wittgenstein, L. (), Philosophical Investigations (Oxford, UK: Oxford University Press).
Zipf, G. K. (), Human Behaviour and the Principle of Least Effort (New York: Harvard Publishing
Co.).

216