mobile social software

MOBILE SOCIAL SOFTWARE

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

Clint HeyerB.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.

i

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

iii

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, ..

v

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.

vii

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

viii

. 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

ix

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.

x

. 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.

xi

. 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.

xii

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.

1

1 I n t r o d u c t i o n

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 H O W C A N W E E N H A N C E H O W S O C I A L G R O U P S C O M M U N I C A T E ,C O O R D I N A T E A N D S H A R E ?

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

2

Introduction

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

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 H O W D O S O C I A L G R O U P S A S S I M I L A T E A N D U S E T E C H N O L O G Y F O RC O M M U N I C A T I O N , C O O R D I N A T I O N A N D S H A R I N G ?

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 H O W C A N M O B I L E S O C I A L S Y S T E M S B E E F F E C T I V E L Y D E S I G N E D ,

D E V E L O P E D A N D S T U D I E D ?

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.

3

Background

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,

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 S O C I A L S Y S T E M S

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.

4

Introduction

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

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 A U S T R A L I A N M O B I L E P H O N E M A R K E T

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 ).

5

Background

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.

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 S O C I A L C O N T E X T

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

6

Introduction

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,

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

7

Background

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

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

8

Introduction

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,

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.

9

Thesis Outline

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

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.

c

10

Introduction

11

2 M o b i l e S o c i a l C o m p u t i n g

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

12

Mobile SocialComputing

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

their leisure. Although mediated, the social connection afforded by mobiles is meaningful to people;

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 W E A R A B L E C O M P U T I N G

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

13

Mobile Phones &Text Messaging

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

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 W O R L D P E R S P E C T I V E

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 ).

14


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.

Language Name Signifies

Arabic telephone sayaar / makhmul

Portable / wireless telephone

Mobility/technology

Chinese - Mandarin sho ji

Hand machine

Personal enablement/technology

English - American Cellular phone / cell Technology

English - British Mobile phone / mobile Mobility/technology

Finnish Kanny

Extension of the hand

Personal enablement

French le portable

Portable

Mobility/technology

German Handy

Handy

Personal enablement

Japanese keitai denwa (keitai)

Carried telephone

Mobility/technology

Spanish et movil

Mobile

Mobility

Table . Names given to mobile phones around the world (adapted from Plant, ; Ito, ).

Figure . Mobile and fixed line penetration

Table . Average subscribers per inhato fixed line subscribers.

Region Mobile subscribers Fix

Africa 21.59 3

Americas 61.95 32

Asia 29.28 15

Europe 94.29 39

Oceania 72.57 36

2 . 1 . 3 T E X T M E S S A G I N G

“There's actually quite a lot [of] text

or on the way to have a cup of coff

( year old female respondent quote

Text messaging is typically used for i

conversations (Kopomaa ). Alth

synchronise as its low threshold of u

(Table ). Svendsen et al. () found

its private, personal and informal char

as chatting, coordination (discussed la

with several studies demonstrating co

al. ).

0

50

100

Mobile and fixed telepMobile subscribers per 100 inhabi

n (ITU )

abitants for world regions. Africa has a high ratio of mobi

xed line subscribers Ratio Mobile to Fixed

.10 6.96

2.43 1.91

5.81 1.85

9.71 2.37

6.57 1.98

messages flying about. You can say you're moving to the n

ffee or something. It's like a kind of unnoticed continuo

ed by Kopomaa :)

informal lightweight notifications and background,

hough SMS is an asynchronous medium, people

use and low costs permits sending a large number

d that SMS was little used in business communication

racteristics. Practically, SMS is used for a variety of pu

ater), play and information-sharing (such as birthday

ordination being most used (Grinter and Eldridge

phone subscription rates, itants Subscriber lines per 100 inhabitants

15


ile subscribers

next bar,

us use."

, continuous

can tightly

of messages

n because of

urposes such

y reminders)

; Ling et

16


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

recipient necessarily judging the sender. The text medium also allows people to conduct word games,

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. :.

17


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

most useful when synchronous communication and quick resolution is desired (Höflich and Gebhardt

; 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

).

18


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

Consulting about their worries 25.1 26

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

19


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 P R I V A C Y

"The thing is that nowadays nobody likes to give their phone into someone else's hands. Text messages,

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 E N A B L E R O F M U L T I P L E F R O N T S

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 noticesdelivered via SMS however

20


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.

2 . 1 . 8 D I S R U P T O R O F S O C I A L O R D E R

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

21


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

messaging).

2 . 1 . 9 S O C I A L C O N N E C T I O N

“Interviewer: When do you call or send a message?

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 . 1 0 C O O R D I N A T I O N

“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

22


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

directly to a person, irrespective of their location†, and synchronous or asynchronous communication

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 . 1 1 I N T E R A C T I O N C U E S

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

23

Context inComputerScience

b). In sub-Saharan Africa a proportionally very low amount of calls was explained when

researchers discovered highly sophisticated ‘beeping’ practice (Donner ).

2 . 1 . 1 2 C O N C L U S I O N

It can be easily argued that mobile telephones represent the most successful example of personal

ubiquitous computing or wearable computing ever developed. Modern day handsets usually feature

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

24


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:

“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.

25

Mobile SocialSoftware

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

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

26


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

application usually requires user intervention to install, maintain and configure it.

2 . 3 . 1 U S A B I L I T Y C H A L L E N G E S

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 C O N T E X T - O R I E N T E D

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

27


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

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

28


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

notifications might be irritating.

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 G R O U P M E S S A G I N G

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.

29


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.

2 . 3 . 4 C R O S S - M E D I A C O M M U N I C A T I O N

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

30


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

People tend not to be very good at predicting how they will use a new technology, which has

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’.

31

Conclusion

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

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

Demonstrate application’s collective and indirect benefits, reduce work

required by non-beneficiaries of create benefit for all

Critical mass and the Prisoner’s Dilemma

problems

Reduce disincentive, increase incentives for use

Social, political and motivational factors Avoid the common assumption of a ‘rational’ work environment; work

with representative users

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)

Learn how work is actually done

Designing for infrequently used features Infrequently used features should not obstruct more frequently used

features

The underestimated difficulty of evaluating

groupware

Longitudinal, qualitative evaluation required

The breakdown of intuitive decision-making 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

32


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.

Extensive research on mobile telephone usage has given us a good understanding of how mobiles

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

33

Conclusion

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

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.

c

34


35

3 D e s i g n M e t h o d s

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

36

Design Methods

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

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

37

Goal-DrivenStrategies

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

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, howeverthis suggestion was largely lost on practitioners.

38

Design Methods

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

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 I T E R A T I V E M E T H O D S

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

39

User-Centred &ParticipatoryDesign

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

specific work practices to be conducted, such as writing test code before implementation and

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

40

Design Methods

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

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

41

User-Centred &ParticipatoryDesign

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

could be considered perspectives to bring to particular problems when necessary. It would not be

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

42

Design Methods

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,

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.

c

43

4 R e s e a r c h M e t h o d o l o g y

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

44

ResearchMethodology

4.1 Background

4 . 1 . 1 P H I L O S O P H I C A L P O S I T I O N

“If we had to name anything which is the life of the sign, we should say that it was its use”

(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 §..

45

Background

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

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)

46

ResearchMethodology

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

between action research and participatory design (§).

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

47

The MobileContext

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

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.

48

ResearchMethodology

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 E X P L O R A T O R Y I N Q U I R Y

"For symbolic interactionism the nature of the empirical social world is to be discovered, to be dug out

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

49

Rhub: anExploratoryPrototype

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.

While a “continuously usable prototype” (Bellotti et al. ) has the benefit of being subjected to

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 P R O T O T Y P E O R P R O B E

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.

50

ResearchMethodology

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.

4 . 3 . 2 I N T H E W I L D

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 N E T W O R K E F F E C T S

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

51

Rhub: anExploratoryPrototype

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

designs, for example by boot-strapping the user’s learning process, however the meaning a user has

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 E X P E R I M E N T A L P L A T F O R M

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.

52

ResearchMethodology

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

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 -US ING 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.

53

Conclusion

. ‘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

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

54

ResearchMethodology

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

applications with which they are familiar. In turn, this reduces the level of technical understanding or

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.

c

55

5 R h u b

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 DES IGN

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

56

Rhub

five top-level command

“breadcrumb” navigation

contains shortcut links to

Figure . Page sections.

5 . 2 . 2 HEADER

The header (Figure ), w

The ‘Rhub’ logotype is h

mapping, contacts, grou

brightens when a new m

right of the mail icon, a

start a new session.

Figure . Header section.

Four top-level options (c

which allows the user t

clicking the correspondin

after a short period has

functionality is containe

the pages of people they

and the locations menu l

ds, a sign-out link and mail indicator. Within

n trail and the text for the page. The sidebar app

o items relevant to the content and usage hints.

which appears at the top of every page, serves as a

yperlinked to the index hub page, and there are link

ups, locations, personal settings and items, and mai

message is received, and is hyperlinked to take the u

link allows users to forcibly end their session, or if

contacts, groups, locations and me!) also have a dr

to select sub-features or relevant items quickly. M

ng downward-facing arrow, and are dismissed after

elapsed. Because people might easily overlook drop

ed within them, merely shortcuts. The ‘contacts’ me

y frequently contact, the ‘groups’ menu displays fr

lists recently added locations.

Body S

Header

Side

the body section is a

pears on most pages and

visual and logical anchor.

ks to six top-level features:

il. An icon of an envelope

user to their inbox. To the

they are not logged in, to

op-down menu (Figure )

Menus can be activated by

either selecting an item or

p-down menus, no critical

enu allows users to access

requently accessed groups

idebarebar

Figure . Drop-down menus for contacts, gcontacts, groups and locations are determi

5 . 2 . 3 BODY

The main content area of the page,

elements, such as the breadcrumb

navigation allows users to gauge their

navigation hierarchy (Figure ).

Figure . Breadcrumb navigation trail allo

The two characters on the left of the tr

(Figure ). Clicking the hash brings

commands the same way they would

brings up a small search dialog that

designed to be quick short cuts for ad

new page to be loaded. The features a

labelled more verbosely but does not a

groups, locations and ‘me!’ Items listed below the horizontined on a per-user basis.

the body also uses a uniform internal design fo

and header and footer buttons and links. The

location within the site, and easily jump to a higher

ows for backwards traversal.

rail, the hash (#) and question mark both serve a spe

up the console interface which allows users to en

from their instant messaging client or SMS. The qu

enables quick searching of content. Both of these

vanced users, and are displayed in-page, rather than

are also available from the bottom footer links (Figu

appear in a consistent position on screen.

57

Website

tal divider for

r navigation

breadcrumb

point in the

ecial purpose

nter console

uestion mark

features are

n requiring a

ure ) and is

58

RhubFigure . Console and searc

Figure . Footer links that a

When actions or functio

line as a collection of bu

the page.

Figure . Action buttons av

5 . 2 . 4 S IDEBAR

The sidebar appears on

example, when viewing a

the index page (Figure

and site features, user’s m

ch dialogs, summoned by clicking their respective breadcru

appear after content.

ons are available for the page, they are generally ava

uttons (Figure ), with commonly used functions also

vailable when viewing a person.

most pages and lists related links and information

a person’s page, the groups they are on and tags the

), the side bar is used to collect shortcut links to fr

messages and an overview of who else is viewing the

umb symbols.

ailable under a horizontal

o available near the top of

for the current page. For

y have used are listed. On

requently accessed groups

site.

Figure . The index page’s sidebar (appea

5 . 2 . 5 HELP

A wiki (Leuf and Cunningham ) w

and organised into categories, with an

registered user of the prototype can ed

Table . Top ten viewed wiki pages.

Rank Topic H

1 Help index 1

2 Getting started 9

3 Messaging 8

4 MSN 7

5 Console 7

6 Tags 6

7 Console message commands 5

8 Presence: location 5

9 Home base 5

10 Using your mobile phone 5

ars on far right of screen).

was deployed to host help content. Over topics w

n average of of views per page (including web s

dit the wiki pages, however this was not utilised by an

Hits

,624

46

11

99

28

14

90

72

72

43

59

Website

were written

spiders). Any

nyone.

60

Rhub

Wiki topics are integrate

appears at the bottom o

page. Additional links ar

such as in Figure , whi

web invitation interface

hovered over an interface

Figure . Links to help topi

5.3 Console

The “console” is a langu

offers a subset of the fun

speed or directness is de

a supported system to a

messaging system), whi

returned via the proxy e

which the user can dire

which can typically be st

ed into the website using a contextual help system.

of all Rhub pages automatically takes the user to t

re often employed in introductory paragraphs to pro

ich direct users to a topic on the invite console com

e. Short hints are also provided as ‘tooltips’ whe

e element.

ics integrated into pages.

age, or syntax, rather than a visible part of the inte

nctionality exposed through the web interface. It is d

esired or when the web is unavailable, such as whilst

Rhub proxy entity on that system (for example, a ‘Rh

ch is routed to the Rhub web server, parsed, exe

ntity (Figure ). All of the console channels require

ect input, for example a telephone number or an i

ored by the client software or system as a contact.

The ‘Help’ hyperlink that

he most appropriate help

ovide further information,

mmand when they use the

n the mouse cursor was

erface. It is text-based and

designed to be used when

t mobile. Text is sent from

hub’ contact on an instant

ecuted, and the response

e some form of address to

nstant messaging address

61

Console

Figure . Schematic view of console access. User communication indicated using dashed lines, internalcommunication 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.

62

Rhub

Table . Commonly used console commands.

Symbol Metaphor Examples

> Send to >Clint: Hello!Sends message to Clint

>&tennis: Hello! 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 @librarySets location to library

@cafe? Finds out who is at the cafe

! Action! !info CarstenReturns Carsten’s contact information

!invite Michael 555-123 Invites Michael, specifying his mobile phone number

& And &tennis add MichaelAdds 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

instant messaging but allows people t

many supports group communication

many messaging allows a single user t

to the sender, not back to the group ag

Table . Messaging forms.

Type One-to-one Many

Private messages •

Group messages •

Discussions •

Locations

Friend broadcasts

5 . 4 . 1 PR IVATE MESSAGES

Messages can be sent person-to-perso

>[user]: [msg], for example >Bob: Hello

recipient’s Rhub username, while the w

The default view for messages is a

message. Clicking on a sender or the t

aggregates messages to and from th

Figure . Message inbox (left) and convers

o converse across different communication channel

ns, with messages going to everyone within the gro

to broadcast a message to a group of people, but rep

gain.

y-to-many One-to-many

•

•

on with the web interface or by using the console, in

Hello. Using the console requires the sender t

web interface supports browsing and higher-fidelity s

a combined inbox that shows the sender and the co

text of a message takes the user to the conversation

he sender and permits replying or deletion of ol

sation view (right).

63

Messaging

ls. Many-to-

oup. One-to-

plies only go

n the form of

to know the

search.

ontent of the

view, which

ld messages.

64

Rhub

New conversations ar

icon of someone the use

Alternatively, when view

Another method of start

elsewhere) and address t

Figure . Composing a new

When sending private m

when received, but other

email however this is

automatically forwards m

5 . 4 . 2 GROUP MESS

Group messages are des

using the console syntax

from a group’s page on th

re initiated in several ways. From the messages page

er frequently contacts can be clicked to start a new

wing a user’s profile page, clicking ‘Send an IM’ p

ting a conversation is to select ‘Send a message’ fro

the message.

w message.

messages using the web, a subject can be specified. T

rwise has little meaning. The user can opt to forwar

deselected by default. When sending messages

messages using all available mediums.

AGES

signed to support short, quick messaging to a grou

x >&[group]: [message], for example >&tennis: Hello

he web.

e (Figure ), the name or

w conversation with them.

produces the same effect.

om the messages page (or

This appears in larger type

rd the message using IM or

using the console, Rhub

up. Messages can be sent

Hello, or by clicking ‘Post’

Figure . New group message interface.

The web allows users to specify how th

forwarding (the message only appears

Sending messages using the console ho

When composing messages on th

entry box (the number ‘’ in Figure

reaches characters, indicating the

soft limit of characters is in place

suffixes, and still be within the hard lim

Group messages are readable by

messages forwarded to them via email

on which members can send message

forwarded, messages start with the sen

group the message was sent to. For ex

SMS like this:

Bob: Hello To: &tennis {to reply, txt ‘>&tennis

Table . Group IM forwarding options.

Option SMS IM

Don’t forward

Online IM •

Offline IM • •

Any • •

Only online •

he message should be forwarded (Table ), with a d

to those that check the website or subscribe to parti

owever defaults to forwarding using any channel pos

e web, a character count indicator to the right of t

) increments with each letter typed. It flashes red if

e message will be truncated if dispatched via a text

so that the message has room for the system-added

mit of characters.

all members using the web, and typically, all m

l, SMS or IM. It is possible for the group owner to set

es to the group or which channels they can opt to

nder’s name followed by the message and finally, the

xample, ‘hello’ sent to the group ‘tennis’ from Bob ap

&tennis [msg]’}

Email

•

•

65

Messaging

default of no

icular feeds).

ssible.

the message

the message

t message. A

prefixes and

members get

t restrictions

o use. When

name of the

ppears as an

66

Rhub

5 . 4 . 3 DISCUSS IONS

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.

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.

Figure . Discussions interface displaying

Figure . Discussions interface displaying

5 . 4 . 4 LOCATIONS

Messages can be sent to people at, or n

console - there is no web interface t

everyone at the library:

g threads and the reply panel.

g messages in a thread.

nearby, a particular location. This feature is only exp

to achieve the same effect. For example to send a

67

Messaging

posed via the

message to

68

Rhub

>@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.

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.

Figure . Message delivery is governed by

Figure . Message forwarding and notifica

5.5 Presence

The prototype’s presence functionality

status. Location can ‘place’ someone

named location, and status allows a

friends (by default).

six major factors.

ation user preferences.

y captures two main aspects of a person’s context – l

at a particular geographical coordinate or arbitra

person to set any kind of message which is then

69

Presence

location and

arily defined

displayed to

70

Rhub

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

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 NOTIF ICATION 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:

@soho: Shopping away!

Laurie, his friend, might receive:

Fry is @soho: Shopping away!

In order to minimise disturbance, p

priority notifications are those destin

have recently set their own location t

priority notifications are those destine

receive these types of notifications if

notification by unchecking a box whe

underscore, for example @soho_.

When logging in, a user sees all h

wherever their username appears on

‘presence gem’ that appears next to the

which lists aggregate presence infor

associated presence log, which displa

presence information is also integr

appearing at their set physical location

Figure . Presence overview seen on index

Figure . 'Presence gem' displays informa

way!

presence notifications are assigned a high or a low p

ed for friends currently at the same location, in th

to the same place. These are dispatched using SMS

ed for all other friends and only use IM. People can

they wish (Figure ) or the sender may opt to no

en using the web, or suffixing their presence comm

is or her friends’ presence information (Figure ).

the website, presence information is displayed as a

eir name (Figure ). There is also the presence page

rmation for all friends, and additionally, each u

ays recent presence history, should the user enabl

ated into Rhub’s map interface, with people’s p

n (Figure ).

x page.

tion when the mouse cursor hovers over it.

71

Presence

riority. High

he vicinity or

S or IM. Low

opt to never

ot generate a

mand with an

In addition,

a tooltip to a

e (Figure ),

user has an

le it. Finally,

profile icons

72

Rhub

Figure . Presence as displ

Figure . People are depicoordinates. Clicking theirmap displays a pop-up win

layed on the presence page. Note IM status is also displaye

icted on the map interface when their location is set toname from the top right pans the map to their location,

ndow.

ed.

o a location with address oror clicking their icon on the

5.6 Profile, Settings&Contac

5 . 6 . 1 PR IVACY

Privacy is naturally important to cons

has a variety of user-definable privacy

other users can interact with a person

by other people on the system could

‘friend,’ which is the most exclusive l

from granting everyone access, only co

Everyone

Contacts

Friends

No-one

Figure . Levels of privacy access. ‘Everyo

Figure . Relations used to determine acc

Privacy restrictions can be applied to

such as presence (Figure ), limiting

who have not logged in cannot see any

ts

sider in the design of social systems. To this end, th

y controls, to govern the exposure of information an

n. Friends’ activity on the system was emphasised, w

go by generally unnoticed. Contacts by default are

level of relation. Relation levels allow for fine-grai

ontacts, only friends to no-one at all (Figure ).

ne’ is anyone who has an account on Rhub.

cess to presence information.

o the various properties of a person’s profile and ga

g which people can see the information. Viewers of

y profiles.

73

Profile, Settings &Contacts

he prototype

nd limit how

whilst activity

tagged with

ned control,

athered data,

f the website

74

Rhub

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

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

[email protected] 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.

Figure . Web interface for a system invit

5.7 User-Generated Content

People can contribute to Rhub in a va

also that of others. There are five main

photos and bookmarks.

5 . 7 . 1 GROUPS

Anyone can create a group on Rhub, w

can have associated instant messages,

automatically creates a ‘short name’

originally sets, for example ‘Tennis Cl

the group’s URL, (for example, http://rh

the group via the console. The shor

te.

ariety of ways, which helps to improve their own exp

n types of entities users can create: groups, tags, set

which acts as a hub around which activity can take pl

sets of photos or bookmarks, tags and discussions.

for the group on the basis of the title of the gro

lub’ might become ‘TennisClub.’ This short name fo

hub.net/groups/TennisClub/) and is also used when

rt name is changeable during the group creation

75

User-GeneratedContent

perience and

ts, locations,

lace. Groups

. The system

oup the user

orms part of

n referencing

process, so

76

Rhub

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

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 ).

Figure . Browsing objects by a particular

5 . 7 . 3 SETS

Sets within Rhub are generic conta

anything, in practice they hold photos

– typically a group or person. When vi

in turn can reveal objects ‘inside’ them

through the images one by one, or a

created and shared with others. When

set, the set becomes an aggregator for

latest news posts from a related blog.

The creator of a set can establish a

items. When a set is associated with a

the creator of a set might only allo

registered Rhub user viewing permissi

Sets also aggregate tags and com

number of sort orderings. Larger sets

r tag (top), tag cloud for locations (below).

ainers for objects. Although they could theoretic

, bookmarks and feeds. Sets are always associated w

iewing a group or user’s page, associated sets are list

m. A set of photos functions like a photo album. A u

as a set of thumbnails. Collections of bookmarks

n an address of a feed (an RSS/Atom data source) is a

r the feed items. For example, a group might use th

access controls, such as who can view it and who ca

group, permissions depend on group membership. F

w group members to add new images, but migh

ion.

ments of objects contained within and can be vie

s can be navigated using a simple pagination meth

77


cally contain

ith an object

ted, and they

ser can page

can also be

added to the

his to display

n contribute

For example,

ht allow any

ewed with a

hod that lets

78

Rhub

people navigate forward

of a set are also exposed

desktop newsreader so sh

5 . 7 . 4 LOCATIONS

Locations can be created

and location information

edited, referenced, tagge

Figure . Location page.

Locations can also be br

allowing users to drill-do

suburb Taringa from the

or backward, jump to the beginning, end or a part

d using feeds, so someone might subscribe to her fr

he is notified when new photos are uploaded.

d or edited by any registered user. A location has as

n as well as a description and image. Once created, th

d, discussed and aliased by others.

owsed by locality or tags. Localities offer a hierarcha

own to a more specific area, or up to a broader one.

location shown above lists other locations in the sam

ticular page. The contents

iend’s photo set using her

ssociated contact, address

he location can be viewed,

al geographical navigation

. For example, clicking the

me suburb:

Figure . Browsing locations by locality.Using the breadcrumb navigation trai

example by selecting Brisbane (Figure

a typeface size proportional to their l

larger (Figure ).

Figure . Locality hierarchy can be traver

A map interface (Figure ), develop

locations. The map interface re-uses

toolkit, such as click and drag to pan,

hand side of the page, people can sele

repositions the map so that the object

nearby to the current view, and chang

other controls are offered. The first, ‘G

il at the top of the page, it is possible to broaden t

). When a locality has sub-localities, they are disp

level of representation, with more frequent localitie

rsed to zoom in or out.

ped using the Google Maps API, was also availabl

the map navigation paradigm provided by the G

mouse-wheel zooming, and icons to switch views. O

ect a user who has set their presence or a location,

is in the centre. The list of places shows locations t

ges as the user pans around. Underneath the map, a

Go to’ allows people to jump to other user’s defined “h

79


the view, for

played using

es appearing

e to browse

Google Maps

On the right-

, which then

that are in or

a number of

home bases”

80

Rhub

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

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

81

Implementation

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.

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 WEBS ITE

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.

82

Rhub

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.

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/

83

Implementation

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

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

84

Rhub

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

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.

85

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.

c

86

Rhub

87

6 R e f l e c t i v e A g i l e I t e r a t 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.

88

Reflective AgileIterative Design

. Design Planning & Implementation

. Feedback Hunting & Gathering

. Reflection Digestion & Response

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

Exploratory PrototypeDesign

Reflection

Feedback

89

Method

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

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 R E L A T E D W O R K

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.

90


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

its core. Significantly, the method largely ignores use or emergent social behaviour as part of the

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.

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.

Choose the ‘right’ work Gather requirements

Create prototype

Evaluate

Improve

Deliver working system

Figure . Rapid Evolutionary Development (adapted from Arthur :).

91

Method

6 . 1 . 2 S T E P 1 . D E S I G N : P L A N N I N G & I M P L E M E N T A T I O N

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.

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

92


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

refactoring (Beck ) might be required. Test cases can be written before implementation to judge

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 S T E P 2 . F E E D B A C K : H U N T I N G & G A T H E R I N G

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.

93

Method

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 ).

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.

94


6 . 1 . 4 S T E P 3 . R E F L E C T I O N : D I G E S T I O N A N D R E S P O N S E

"[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 : )

Reflection is a critical part of RAID, much like in action research, upon which RAID is based. It is in this

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

95

Results

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

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.

96


6 . 2 . 1 C A S E S T U D Y : C O N S O L E

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

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

97

Results

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

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

deployment

Syntax Example Description

>[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 qualifier] [msg]

>tennis Hello Ampersand to qualify entity as a group

can be omitted

>[full person name or user]: [msg]

>John Doe: Hello Only contacts could be messaged

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.

98


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

it is required). Typically, these people would directly ask me to help them, or for those that didn’t

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

99

Results

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 C A S E S T U D Y : M E S S A G I N G

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.

100


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

usage norms to develop naturally. Feedback from participants often negatively referred to the volume

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.

101

Results

6 . 2 . 3 C A S E S T U D Y : I N V I T A T I O N S

The process through which people joined Rhub and groups was facilitated by invitations, which could

be sent from one person to another.

Design

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

102


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

positively by participants.

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 C A S E S T U D Y : P R E S E N C E

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.

103

Discussion

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.

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.

104


6 . 3 . 1 C O M M U N I C A T I N G C H A N G E

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

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.

105

Discussion

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

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 F E E D B A C K T H R O U G H U S E

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.

106


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

and so on. As RAID advocates a minimal approach to implementation, it may be that such deficiencies

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 L O W D I S R U P T I O N F E E D B A C K

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

107

Discussion

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

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 searchresults.

108


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

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.

109

Discussion

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.

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 S T O P P I N G C A S E

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.

110


6 . 3 . 7 A P P L I C A B I L I T Y O F T H E M E T H O D

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

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 B U G S

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.

111

Discussion

6 . 3 . 9 S O U R C E C O D E M A N A G E M E N T

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

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.

112


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

0

20

40

60

80

100

120

140

0

10

20

30

40

50

Jun 06

Jul 06

Aug 06

Sep 06

Oct 06

Nov 06

Dec 06

Jan 07

Feb 07

Mar 07

Apr 07

May 07

Jun 07

Jul 07

Aug 07

Sep 07

Source Code Respository Activity

Commits LOC ('000)

113

Conclusion

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.

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.

c

114


115

7 S t u d i e s & R e s u l t 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

116

Studies & Results

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,

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 P A R T I C I P A N T S

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.

Figure . Invitation graph as of October inviter, myself, denoted here as . Reprodu

7 . 2 . 2 M E T H O D

As discussed in chapter , the prototyp

run or probes deployed. The system w

messages sent and received, objects

relational database and plain text files

(weekly) and long- (monthly) term tr

from users (and the system’s respons

typically continuously – through office

Much of the data gathered is of a

also analysed messages qualitatively. T

was analysed using an ontology adapt

expanded to include categories not pr

or more labels were used to describe t

noting of references contained within

external researchers was not performe

hampered because they were little use

. Random numbers are used in place of user names,uced larger in the Appendix A.

pe was designed as a platform on which smaller expe

was instrumented to collect data from participants’ us

accessed, sign-ins and console accesses. Data was

s. Scripts were written so I could get a representati

rends in usage. The error log, which recorded erro

e) as well as internal errors, was monitored on a d

e hours.

quantitative nature, and analysis is straightforward

The content of random group messages from a

ted from Farnham and Keyani (). The ontology

resent in the original ontology yet represented in th

the intent of the message, such as coordination or ch

n messages, such as time or location. Verification of

ed for privacy reasons. Comparison with other grou

ed, and there are few messages to analyse. However,

117

Prototype

with the root

eriments are

sage, such as

logged to a

ion of short-

oneous input

daily basis –

d, however I

single group

y was slightly

he data. One

hat as well as

f labelling by

ups’ usage is

analysis was

118

Studies & Results

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

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 R E S U L T S

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 ).

Figure . Number of registered users over time.

020406080

100120140160

01.0

6

02.0

6

03.0

6

04.0

6

05.0

6

06.0

6

07.0

6

08.0

6

09.0

6

10.0

6

11.0

6

12.0

6

01.0

7

02.0

7

03.0

7

04.0

7

05.0

7

06.0

7

07.0

7

08.0

7

Number of registered users over time

119

Prototype

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

(incl. author)

Total

(excl. author)

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.

120

Studies & Results

Figure . Logins/day frequ

Figure . Usage of IM, SM

A large number of users

were receiving them. Wh

users being responsible f

The lurking factor is

peoples’ group messagin

act upon them, for ex

messaging, the frequenc

message sent might resu

of conversations within

lurking by how often a us

33

76

9

0 0.25 0.5

Freq

uenc

y

0

100

200

300

0 1 2

Acc

umul

ated

usag

e

uency. people have never logged in yet receive messages.

MS and Web by hour of the day.

s ( of sample) sent no messages (a lurk factor o

hen plotted (Figure ), a reverse Zipf curve is eviden

for a bulk of the sent messages.

not a proper representation of actual social lurking

ng behaviour on Rhub. People who do not send me

xample, by attending social events. Because this

cy is invariably skewed toward the low end of th

lt in tens of messages received. Future work might lo

group message streams rather than message tot

ser participated in group conversations.

9 4 3 2 0 0 0 0

.5 0.75 1 1.25 1.5 1.75 2 2.25

Average number of logins/day

Average logins/day frequency

2 3 4 5 6 7 8 9 10 11 12 13 14 15 16 17Hour

Channel Use by Hour

IM SMS Web

. (n=)

of , Figures and ), yet

nt, with a small number of

g. Rather it only indicates

ssages still read them and

analysis looks at group

he scale because a single

ook at lurking on the basis

als, for example defining

1

25 2.5

7 18 19 20 21 22 23

Figure . Frequency of different of lurkimessages (n=).

Figure . Lurking frequencies plotted (n=users with a medium lurk factor, C represe

Photos

Photos were often uploaded after a gro

profile picture), they uploaded an ave

within a particular group, and photos

own photos, or leave comments. Peop

the scene or characterise the photo in

previously used a group email to distr

was quicker to do, gave his pictures a w

2 1 0 0 1

0 0.1 0.2 0.3 0.4

Freq

uenc

y

Lurk fact

Lurkin

0

0.2

0.4

0.6

0.8

1

1 7 13 19 25 31 37

Lurk

Fact

or

Lurking fac

ba

ing factors. people have never sent a group message

=). Region A represents users with a low lurk factor,ents users with a maximum lurk factor.

oup activity. Of the users who uploaded photos (b

erage of four photos each. A set (or ‘gallery’) would

s uploaded. Other people might contribute to the se

ple tagged photos, typically using them to describe

n a humorous manner. One of the more prolific phot

ribute photos he had taken. He preferred using Rhu

wider audience, and allowed others to leave commen

2 2 0 513

42

60

0.5 0.6 0.7 0.8 0.9 <1 1

tor (1=complete lurker)

ng Frequency

43 49 55 61 67 73 79 85 91 97 103 109 115 121 127Users

ctor across user population

c

121

Prototype

e yet received

, B represents

besides their

d be created

et with their

who was in

to uploaders

ub because it

nts.

122

Studies & Results

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

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

tags

Number of

objects

Tags-to-

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

123

Prototype

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

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.

124

Studies & Results

Gamma: Created by

sporting club.

Delta: As membersh

focussed on sport, rathe

game organisation and d

members of Alpha.

Epsilon: This group

discuss organisation of th

members of Delta.

Digamma: Members

low level of social cohesi

Figure . Average weekly m

Figure . Group size and a

18.216.1

5.53.1

1 2 3 4

Mes

sage

ssen

tper

wee

k

0

5

10

15

20

25

30

alpha beta

y an Alpha member, Gamma was for a particular t

hip of Alpha grew, it became apparent that a new gr

r than social activity. Thus, I created Delta, which w

discussion of competitive events. The majority of D

was created for the executive (or management) of t

he club. All members of Epsilon were members of A

s of the research group I belong to were invited to t

on, members did not use it to an appreciable degree

messaging activity for the most active groups.

average messaging for the top six groups (Alpha to Digamm

1 1.8 1.3 1.3 1.2 1.1 0.8 0.7 0.7 0.6 0.5 0.5 0.3

5 6 7 8 9 10 11 12 13 14 15 16

Groups

gamma delta epsilon diagamma

Members Avg msgs/wk

training group within the

roup was needed that was

was used for spontaneous

Delta members were also

the sporting club to use to

Alpha, and most were also

this group. Because of the

.

ma).

3 0.2 0.2 0.2 0.2

6 17 18 19 20

125

Prototype

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

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 ).

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 byweek . ‘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

0%

10%

20%

30%

40%

50%

60%

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

126

Studies & Results

how a group with existi

study, averaged messa

for all groups was (sta

(Figure ), with a spike

day that Alpha has wee

afternoon, and taper off l

Figure . Messaging by day

Figure . Messaging by ho

Messages could be sent

such as instant messagin

message to recipients,

via email and via t

Message goals

Participants utilised mes

the group Alpha shows t

9%12%

Sun Mon

0%

6%

12%

0 1 2 3 4 5

ng social ties can use a mobile social system. Alph

ages per week with an average of members. The m

andard deviation .). Messaging throughout the w

e evident on Thursday, which is a popular night for

kly events. During the day, messaging appears to

late at night (Figure ).

y of the week.

ur of the day.

to Rhub for distribution to others by any channel s

ng, text messaging, email or the web. When it comes

of messages were delivered via text messaging,

the web.

ssaging in several ways within Rhub. Analysis of

hat participants mostly sent messages for coordinati

12% 13%

23%

13%18%

Tue Wed Thur Fri Sat

6 7 8 9 10 11 12 13 14 15 16 17 18 19 20 21 22

ha, over the course of the

mean weekly message rate

week was relatively similar

students to go out, and a

rise to a peak during the

supported by the console,

to actually forwarding the

via instant messaging,

random messages sent to

ion (Table ).

23

127

Prototype

Table . Content analysis for random messages from group Alpha.

Family Categories

Coordination (70%) Invitations (28%)

Questions (18%)

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.”

128

Studies & Results

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

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.


Text Messaging 65 48 68

IM 3 0 13

Web 32 52 20

Table . Coordination forms for the groups Alpha, Gamma and 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

129

Prototype

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

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.


Location 25 14 0

Time 24 46 54

People 13 22 0

Activity 23 36 29

Presence/status 11 19 4

130

Studies & Results

Figure . Message contentnumber of messages categoanalysed messages from a p

Group instant mess

conversations based pri

this algorithm on ,

tended to happen within

over three channels and

probably a reflection on

text messaging). After re

computer to compose a

replies were sent using t

(Figure ).

0%

20%

40%

60%

80%

Overall

Location

t across phone (SMS) and computer (IM, email and web) sorised out of the total number of analysed messages forphone contained a reference to location (n=).

sages were processed using a basic algorithm, a

marily on the temporal difference between subseq

messages ( weeks of usage) produced con

n a single channel () or a pair of channels (),

d no conversations taking place over all four sup

the ubiquity of mobile phone access ( of all m

eceiving a Rhub message on their phone, users foun

a reply message: of replies were sent using a p

the web yet the percentage of initiating messages for

Time

Activity

Person

Status

Overall

Confirmation

Invitation

Report

References Coordination

Content variation across source channelsPhone (n=325) Computer (n=175)

sources. Percentages show thethat source, such as of

ssembling messages into

quent messages. Applying

nversations. Conversations

with only taking place

pported channels. This is

messages were received via

nd little reason to go to a

phone, while only of

r both mediums is similar

Directive

Question

Overall

Social

Figure . Initiating and reply message so(proportionally) more for sending initial m

Figure . How group instant messages we

Presence

Rhub allowed people to set their curr

using an arbitrary text string) and a st

chapter ), becoming more accessible

(Figure ) shows an increase in act

People tended to set their own presenc

generally people would set their prese

produce a high level of temporal co-oc

0% 9%0%

Email IM

1% 3%

Web Ema

M

ources. of all replies were sent using SMS while the wmessages (n=,).

re delivered (n=,).

rent location (either referencing an already defined

tatus message. Over time, this feature evolved (see d

and proactive in notifying others of presence. Usag

tivity from March , when design refinements

ce after noticing other people setting theirs (Figure

ence at the beginning of the day (Figure ), which

ccurrence.

47% 44%

8%27%

65%

M Web Phone

Message sourcesInitiating Reply

% 12%

84%

ail IM Phone

Message destinations

131

Prototype

web was used

location, or

discussion in

ge over time

were made.

), however

h would also

132

Studies & Results

Figure . Setting of status and location over time.

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

0

10

20

30

40

22/6

/06

6/7/

06

20/7

/06

3/8/

06

17/8

/06

31/8

/06

14/9

/06

28/9

/06

12/1

0/06

26/1

0/06

9/11

/06

23/1

1/06

7/12

/06

21/1

2/06

4/1/

07

18/1

/07

1/2/

07

15/2

/07

1/3/

07

15/3

/07

29/3

/07

12/4

/07

26/4

/07

10/5

/07

24/5

/07

Usa

ges

Usage over time

Status Location

0

50

100

150

<1 1 2 3 4 5 6 7 8 9 10 11 12 13 14

Usa

ges

Hours after prior setting by another user

Temporal co-occurrenceStatus Location

133

Prototype

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.

0

20

40

60

80

100

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

Usage

Presence Usage by Hour of Day

Status Location

134

Studies & Results

7 . 2 . 4 D I S C U S S I O N

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

here.

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 P A R T I C I P A N T S

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.

135

Interviews

7 . 4 . 2 M E T H O D

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

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 R E S U L T S

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”

136

Studies & Results

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.

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

137

Quiz

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

“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 DISCUSS ION

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.

138

Studies & Results

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,

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:

102

Average:

16.86

139

Quiz

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

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=).

Figure . Response rate for each quiz (# the first, # the last, n=). Vertical line indicates when quiz wasintroduced 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.

0%

10%

20%

30%

40%

1 5 9 13 17 21 25 29 33

Resp

onse

rate

Quizzes

140

Studies & Results

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

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 DISCUSS ION

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.

141

Quiz

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

(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.

142

Studies & Results

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.

2 3

32 32

7

1

94 3 3 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

Num

bero

fres

pons

es

Time taken to respond (h:mm:ss)

True/False

Questionnaire

Ethnography

Subject interpretation Researcher interpretation

Open responseLimited response

Context largely irrelevant Context highly importantQuiz

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

143

Workshop

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.

7 . 6 . 1 P A R T I C I P A N T S

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 M E T H O D

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"

144

Studies & Results

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).

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

145

Workshop

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.

. 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 R E S U L T S

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

146

Studies & Results

thought it more effective to send personally addressed, individually crafted messages rather than a

group message.

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

147

Workshop

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

task.

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

148

Studies & Results

unintelligible to those outside of the context within which the message was sent – even those in the

same group.

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.

149

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,

150

Studies & Results

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

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 D I S C U S S I O N

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

151

Conclusion

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

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.

152

Studies & Results

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

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.

c

153

8 D i s c u s s i o n

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

154

Discussion

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.

8 . 1 . 1 S T Y L E S O F U S E

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

155

MoSoSo in Action

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.

8 . 1 . 2 A W A R E N E S S O F U S E

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 N E G O T I A T I O N O F U S E

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

156

Discussion

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

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 A P P R O P R I A T I O N I N T O G R O U P

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

157

MoSoSo in Action

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.”

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

158

Discussion

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

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,

159

MoSoSo in Action

8 . 1 . 6 M E S S A G I N G O V E R L O A D

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

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 S O C I A L T E N S I O N S

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

160

Discussion

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

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

161

Messaging

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.

8 . 1 . 8 C O N C L U S I O N

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

162

Discussion

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

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 C H A N N E L M E A N I N G

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.

163

Messaging

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!”

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 P E R V A S I V E C O N T A C T

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.

164

Discussion

8 . 2 . 3 P E R S I S T E N T C O N V E R S A T I O N

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,

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

165

Messaging

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

ephemeral, however this aspect of use merits further investigation.

8 . 2 . 4 O N G O I N G D E S I G N R E S P O N S E S

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.

166

Discussion

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,

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

167

Messaging

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

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.


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

168

Discussion

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

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 C O O R D I N A T I O N O V E R C H A T

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.

Existing handsets are not usually

messages, and usability suffers resulta

not distinguish between group or pri

difficult for users to determine the urg

with the fact that group text messag

higher level of disturbance than direc

text messages they received was on

messages were acceptable because usu

interested, they realised that next tim

considering potentially useful message

group messaging.” Chat messages on th

intrusive means such as IM or a web-b

8 . 3 . 2 C O M P A R E D T O O T H E R S

It is instructive to compare our prelim

), another group-based text me

generated from seven users’ complete

a random sample of messages sen

comparison of message goals in Rhub

Figure . Percentage of messages by goal,

30%

70%

28%28%

68%

Total Total Invi

Bonding

y designed for composing, managing or displaying

antly. Additionally, a phone’s message arrival notifi

ivate text messages for systems such as Rhub, whi

gency for reading a message. These two design facto

ging increases the quantity of received messages—

ct messaging. Participants reported the extra quant

ly annoying if the messages were of no value. C

ually the event was something of interest. Even if th

me they might be, therefore the annoyance now

es later. As one interviewee stated, “that’s the price

he other hand were seen as extraneous and better se

based forum.

S Y S T E M S

minary usage statistics with those of Swarm (Farnham

essaging system. Data reported by Farnham and

messages, combining for a count of , whereas ou

nt to a single group from a total of users. Figure

and Swarm.

compared with Swarm.

%

12% 18%6%

50%

16%7% 7%

itation Report Question Directive

Coordination

Goal of Messages

Rhub Swarm

169

Coordination

g group text

fication does

ich makes it

ors—coupled

—results in a

tity of group

Coordination

hey were not

is tolerable,

e you pay for

ent using less

m and Keyani

Keyani was

ur results use

e shows a

17%4%

Commitment

170

Discussion

Total bonding and coord

for Swarm). In the break

from the Swarm data. T

respectively) can be par

Because play can only ta

important to determine

in Rhub have an interes

responses in the form of

else is going, (which ma

your circle of friends or a

functional role as RSVPs

public RSVPs confirm t

accountable, which does

Figure . Referencing inunavailable for Swarm.

Referencing in messages

of location referencing i

visited by Swarm users

Rhub on the other ha

commitment, perhaps d

than everyday socialising

The high level of refe

importance as resources

25%

43%

Location

dination percentages are nearly identical to Swarm

kdown of coordination messages, there is a relativel

The difference in commitment messages ( and

tially explained by the ad-hoc sporting events Alp

ake place with a requisite number of participants, co

if the event should go ahead and be organised. Soc

sting dual role. Traditionally, invitations are sent to

f RSVPs are sent directly to the host. If you, as an invi

ay determine whether you would want to go) it wou

asking the host themselves. With Rhub, commitmen

for the organiser, but importantly, signal to others

to others who will be attending, and attendanc

not happen with private invitations.

messages for Rhub and Swarm. Data for referencing

s was also different between the systems (Figure ),

in Swarm ( of messages versus ). This may

were more diverse, and they therefore had to qua

and had a much higher level of time referencin

due to the organisation of sport that has a higher d

g.

erencing in coordination messages to location, time

s for group coordination. It might be tempting to se

24%

13% 11%4% 7%

Time Person Status

References in Messages

Rhub Swarm

(: for Rhub, :

ly large degree of variance

for Swarm and Rhub

ha organised using Rhub.

mmitment messages were

ial commitment messages

o people individually, and

itee, want to establish who

uld involve asking around

nt messages maintain their

your commitment. These

ce can be held publicly

g of status and activity is

, with a much higher level

y be because the locations

alify location more often.

ng ( versus ) and

demand for synchronicity

and activity suggests their

ee these as properties that

23%

Activity

171

Coordination

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 M I C R O C O O R D I N A T I O N

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 thecumulative 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.

172

Discussion

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.

8 . 3 . 4 H A L F - I N V I T E S

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

173

Presence:Location & Status

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.


Coordination was the primary use participants found for Rhub, even though Rhub never offered

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

174

Discussion

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

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 O N G O I N G D E S I G N R E S P O N S E S

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 ).

175

Presence:Location & Status

Figure . Icon indicates presence information is available (left); Presence prompt shown on index page afterlogging in (right).

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 C O N C L U S I O N

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

176

Discussion

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

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.

177

Cross-ChannelUsability: TheConsole

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

first weeks of usage is . Average error rates per user did not depreciably drop over time. I

reason this is because most users only used the console for messaging, and because other commands

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

178

Discussion

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’

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

179


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

180

Discussion

work (Schusteritsch et al

users were free to explor

without any monetary co

costs are incurred, it may

Figure . Percentage of tomedium. When using IM pafter one attempt.

Flexible parsing

Command parsers shou

command to a group use

want to play tonight?

to prevent messages bein

to use the group prefix ‘&

message. It was howev

meaning Rhub would pa

leave out the colon, cau

observing how people w

requirements of the com

not universally†.

A similar case also o

location using @[location]

provided), it can match t

† If there is a person wiinstead

23%

77%

IM

l. ), participants were reimbursed for costs incu

re the SMS help system and to learn through attemp

ost. Considering the useful ‘economic pressure’ on d

y be beneficial to seek alternative participant reward

otal user errors where the command was attempted agaeople were more likely to retry their input, with SMS they

uld be as generous as possible. In our early im

ed the strict syntax of >&[group]: [message], for ex

?. The original desire was for the parser to be as det

ng accidently delivered to the wrong destination. By

&’, and for a colon to appear after the destination w

ver, not particularly forgiving. Users would often

arse the command as being intended for a person ins

using Rhub to parse the entire message as the n

were using the command, along with interviews wi

mmand. Now, the simpler syntax of >[group] [message]

occurred with the presence command @. Rhub allow

ion], for example @home. Since Rhub has a data

the name and accurately position the person in sema

ith the same name as the desired group, the mess

35%

59%

65% 41%

Web SMS

Console retry attempts per channelSingle Multiple

urred using the system, so

pting different commands

design shortcomings when

d schemes.

ain with altered syntax, pery were more likely to give up

mplementation, sending a

xample, >&poker: Anyone

terministic as possible and

enforcing group messages

we can accurately parse the

forget the group prefix,

stead of a group, or would

name of the group. After

ith users, we softened the

ssage] will also work, but

ws you to set your current

abase of locations (user-

antic as well as geographic

age will go to the person

181


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

their location to an arbitrary string, it is shown to others as text, while people who set their location to

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 lr’ 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.

182

Discussion

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

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.


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

183

DesignConsiderations

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

their basis in the experience of the longitudinal deployment of Rhub, and observations of other

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 U T I L I T Y I N D E S I G N

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-

184

Discussion

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

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 N O T I F I C A T I O N S

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

185


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,

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 G R E A S I N G T H E W H E E L S O F S O C I A L N E T W O R K I N G

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

186

Discussion

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

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 T E C H N O L O G I C A L R E S P O N S E S T O S O C I A L P R O B L E M S

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.

187


8 . 6 . 5 MINIMIS ING 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

reward, there is likely to be little participation, and thus the group benefit will never eventuate.

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

).

188

Discussion

8 . 6 . 6 D I S C L O S U R E & T R U S T

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

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.

189


8 . 6 . 7 C O N C L U S I O N

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

� Notifications: balance needs of producers and consumers

� 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

190

Discussion

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

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.

191

Conclusion

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

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

192

Discussion

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

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.

193

9 C o n c l u s i o n s

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 thisthesis I’ve used ‘communication’ to denote social chat.

194

Conclusions

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

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.

195

How can mobilesocial systems beeffectivelydesigned,developed andstudied?

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

to avoid using trains because of a strike. During the event, usage of Rhub is minimal for those

attending, although it is frequently used by people at the event to entice others to come, and by people

not at the event to find out how it is progressing. After the event, someone might upload photos,

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

196

Conclusions

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

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

197

Contributions ofthis thesis

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.

c

199

1 0 A p p e n d i c e s

200

Appendices

Appendix A: Social GGraph

201

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

inboxes right now?

SMS: , , , heaps, , ,

Email: , , , heaps, , s

How many messages or emails have you sent so far

today?

None:

One message:

Two messages:

Five messages:

What kind of place are you at now: cafe, home, work

etc..?

Home:

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

to you right now?

Landline:

Mobile:

Computer:

Right now, would you prefer to get call, sms, email

or IM?

SMS:

Email:

IM:

Email or IM:

Call:

Right now, which would you prefer to use: call, sms,

email or IM?

IM:

Call:

Are you inside or outside right now? Inside:

Outside:

202

Appendices

If is super busy and is not at all busy, how busy

are you now?

Busy rank :

Busy rank :

Busy rank :

Who are you with right now? eg friends, workmates,

noone, family etc...?

Noone:

Family:

Coworkers:

Classmates:

Friends:

How did you get alerted about this message: beep,

popup etc...?

Beep:

Popup:

Light (silent):

Vibration:

How many people are in the same space as you right

now?

One person:

Two people:

What’s your position: walking, reclining, jumping,

sitting etc..?

Relaxing/sitting:

At computer:

Walking:

Sleeping:

Dancing:

203

Appendix C: Workshop Posters

Enlargement of Figure , Page .

204

Appendices

Appendix B: Workshop Posters

Enlargement of Figure , page 150.

205

1 1 R e f e r e n c e s

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).

206

References

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 .

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, (),

-.

207

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), -.

208

References

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), -.

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.

209

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. (), ‘Wantlk?: 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), –.

210

References

Hård af Segerstad, Y. (), ‘Language in SMS - a socio-linguistic view’, in Richard Harper, Leysia



Harrison, S., Tatar, D., and Sengers, P. (), ‘The Three Paradigms of HCI’, Human factors in

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), -.

211

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



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 (PP) (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, (), -.

212

References

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

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, LISCMC (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).

213

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),

-.

214

References

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

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, (), -.

215

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), -.

216

References

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).

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.).

c