Intro to Populations project and related work for first year undergrads

1. My predictions interface
getF ix!
FanBook
BP (update)?◦ 3 5
rtnF ix?
open?◦ dUI
dUI
60 5 4
5 0 1 2
BP (sob)?◦
rtnf ocus! noMatch
30 6
BP (close)?◦
9 addP red! getMatch
8
closeApp
Zippy 7
Fixture server : FS1
getF ix?◦
1
0
τ
rtnF ix!◦ 2
Prediction Server : PS
addData! getP red?◦
1
2
0
addP red?◦ getData!
rtnP red!◦
3
4
rtnData?
A Population Approach to Ubicomp 1
System Design
Matthew Chalmers

2. Ubiquitous computing
More than just mobile devices...
Systems that fit with context, interaction and activity
...which are varied and dynamic in ways difficult to predict
The system is part of the user’s context
System interactions, and how users are modelled and presented to
others in them, are resources for new user activity

3. Ubiquitous computing
A holistic view spanning technology, use and users
Mark Weiser: The unit of design should be social people, in their
environment, plus your device
Robin Milner: Here we look for synergy between the societal vision on
the one hand, and the development of scientific models and engineering
principles on the other.

4. SUMgroup: Social / Ubiquitous / Mobile
Matthew Chalmers, Alistair Morrison, Marek Bell, Scott
Sherwood, Don McMillan
Theory, user experience and system design
Use ‘in the wild’ rather than usability in the lab

5. A Short History: Treasure

6. A Short History: Feeding Yoshi

7. A Short History: EyeSpy

8. A Short History: Replayer

9. A Short History: Replayer

10. A Short History: Replayer

11. A Short History: Replayer

12. A Short History: shifting to iPhones

13. A Short History: shifting to iPhones

14. Mass participation
‘App Store’ model of distribution a huge success
More than 10 billion downloads in first 3 years
Ubicomp field trials generally focus on small numbers
of users
Now there’s a potential to reach huge numbers of
users relatively easily
What are the challenges:
Methodological? Technical? Ethical?

15. Hungry Yoshi
Our first study exploring app store recruitment model
Comparison with ‘traditional’ ubicomp field trial
Took 2005 Windows Mobile application, reimplemented it
on iOS in 2009

16. Yoshi (2005)
Scans of WiFi APs
‘Carry’ fruit to Yoshis
Mainly qualitative methods, to study
integration of game into everyday life
Original study was “long-term, wide-
area”
Played over a week, with16 players in
Glasgow, Nottingham and Derby

17. Yoshi (2009)

18. Quantitative evaluation

19. Qualitative evaluation
Qualitative evaluation at a
distance
Task mechanism
Many types of ‘task’
Real-time updates

20. Qualitative evaluation
Over 28,000 responses
Tokens as motivation
Unrewarded: 11% of
players
Rewarded: 19% of players
Players vs. participants

21. Qualitative evaluation
Facebook integration
Use Facebook mail, forums...

22. Qualitative evaluation
Telephone interviews
Offered payment
A few very keen participants at start, but struggled to get >10
Self-selection biases, language issues

23. Quantitative evaluation: SGLog
A generic logging framework with phone and server parts
Log user interactions (button taps, screen changes), and
device/sensor data (accelerometer, WiFi connections)
Write to locally-stored files on device, but opportunistic
uploading to SGLog server over Internet
‘Real-time’ evaluation/monitoring of trial in progress
SGVis: complementary visualisation / analysis desktop tool

24. Quantitative evaluation: SGVis

25. Quantitative evaluation
How do we count user numbers for Yoshi?
In Windows Mobile trial : 16 users paid for participation
In iOS trial:
Download?
Register for account?
Play for > x minutes/hours/days?

26. Quantitative evaluation
How do we count user numbers for Yoshi?
Downloads: 182,714
Unique users launching: 98,556
Users registered: 36,169
Score points: 4,134
Played on 5 or more days: 3,080

27. Quantitative evaluation: SGVis

28. Quantitative evaluation: SGVis

29. SGVis: Categorising users

30. SGVis: Categorising users

31. SGVis: Categorising users

32. SGVis: Categorising users
Calculate centroids of each identified cluster
4 categories of users: top players, commuters,
static players, beginners

33. Categorising users
Targeting evaluation to specific categories
More effective or efficient evaluation?
Users’ reactions to categorisation
User feedback may let us understand whether or how it is
meaningful
Users may change their behaviour as a result of being categorised?

34. Categorising users as part of iterative design
Release initial version of app and then loop:
Use tools to observe usage, analyse patterns and categorise users
Release optional modules to support observed and requested usage
of users in specific categories
Sets of modules may be bundled and named as separate apps to
support different observed categories of use

35. The software engineering revolution
Conventional models of the software development process
all claim that “at some point, a product is delivered to a
user community, at which point, for that revision of the
software, the design process is over.”
Paul Dourish

36. The software engineering revolution
“When we look at an interactive system as an evolving
artifact in use, it follows that the process of design does
not end with the delivery of the system to some
community of users. Instead, it continues as they use and
adapt the system.”

37. Concept Demonstrator/Evaluation
Initial evaluation via a simple mobile game called Castles
Game chosen because
Keeps users motivated
In-depth and intense use stresses system
Provides an infrastructure suitable for modular architecture

38. Game Overview
Players construct kingdoms
Inhabitants
Resources
Buildings
Soldiers
Players may choose to battle
when they are in wi-fi range

39. Game Overview
Players start with a set of
common modules and a set
unique to them
When players battle:
histories are exchanged
recommendations are made
modules are transferred

40. Game Overview
After a battle, a player will
be informed if there are
recommendations

41. Game Overview
Module recommendations
integrated into the building
list
Stars show
recommendation rank
Gray buildings are newly
received modules

42. Findings
Players progressed more
rapidly with
recommendations
Nearly all followed
recommendations
Modules were spread to
and used by others

43. FlexBook
Mobile social networking app
Dynamic integration of
software modules at runtime
Shared via our “module store”
server, or ad hoc peer-to-peer
Reviewing and user feedback
Implicit logging of use
Explicit comments and rating
Shown in app and Facebook

44. My predictions interface
getF ix!
BP (update)?◦ 3 5
rtnF ix?
open?◦ dUI
dUI
4
0 1 2
BP (sob)?◦
rtnf ocus! noMatch 6
BP (close)?◦
9 addP red! getMatch
8
closeApp
7
Fixture server : FS1
getF ix?◦
1
0
τ

45. A population approach to ubicomp
system design
Based on mass participation & dynamic software structures
Redefining a fundamental computer science concept: class
A new project, officially starting today
Two universities, four million pounds, five years, nine people

46. The population approach
Multiple representations of a software class (or type)
Tools to use, create or adapt these representations
Social interactions and practices involving those tools

47. The traditional representation
A class is a structure, and all instances conform to it
Data structure: variables or state
Code structure: methods, procedures or functions
These form a structural description of potential behaviour and use
Assumption: exact match between the structure of the class
definition, and the structure of each instance

48. The traditional representation
Tests and changes need only be done on one thing at one time:
the class structure
What’s true for the class is true for the deployed instances
Poor fit with trends such as plug-ins, add-ins, e.g. what is Firefox?
Phones often user-adapted, via App Store, Cydia, Android
Market...

49. Borrowing from biology: population thinking
A species is a varied and changing population of individuals
A species may be described by unifying and defining characteristics
A species is also continually changing and evolving
Each individual member may differ from others, and variation among
individuals is natural and vital to adaptation
The species can also be described by the set of current (or recently
recorded) members: the aggregate of each individual’s DNA, size,
colour, shape, etc.

50. A new representation: population
A class is a varied and changing population of instances
A class may be described by unifying and defining characteristics
A class is also continually changing and evolving
Each individual instance may differ from others, and variation among
individuals is natural and vital to adaptation
The class can also be described by the set of current (or recently
recorded) members: the aggregate of each instance’s structure,
context, use, etc.

51. A new representation: a population
Match between class and each instance may vary
The value of a variable may vary... but also which variables, methods and
functions make up internal structure
Variation and dynamism mean complexity of design and
analysis
Probabilistic statements and models instead of simpler discrete ones

52. Populations: variation and dynamism
What’s true for one instance may not be for another
90% of unmodified instances crash, but those with module A added
don’t crash. Overall, 75% of instances crash
Analysis results may be different at different times
We advertise A and the percentages; a week later only 50% crash
Results for different contexts may differ
News of module A spreads faster in one country than another, so in
Spain 25% crash while in the US 60% crash

53. New tools and new interactions
Analysis of modules, configurations and contexts
Which configurations and contexts are popular? Which are
problematic? How are they used? Are there clusters that should be
separately managed and designed for?
How does my setup compare to my friends’? Are there configurations
like my own that doesn’t crash so much? How are they used?
Access to modules and usage data
May support free dissemination (P2P) or retain a degree of control
‘Lead users’ keen to try out new or specially instrumented versions

54. A third representation: ostension
One or more population members are pointed out as
examples
Many potential ways to make an ostension
e.g. a category or cluster selected from a population of instances

55. SGVis: Categorising users

56. From observed use patterns to software
structure
MapTool is usually run along with DGPSLocationStream
UKTrainSchedule is frequently logged as being used in UK
locations tagged as train station
FestivalEvents and FestivalVenues modules are frequently used
with an unofficial module AlternativeGuideToTheFringe when
the user is in Edinburgh Fringe Festival venues

57. System design and structure
“An ontology is a formal specification of a shared
conceptualization” Gruber, via SemanticWeb.org
Traditionally, design is about the perfect hierarchical
structure
One structure for all known uses, contexts and people
Adaptation is the problem of changing it

58. System design and structure
Population approach couples process and structure
Design process in which structure is a resource for use, and in
which use creates or adapts structure
Giddens’ duality of structure, Heidegger’s hermeneutic circle
Adaptation of a structure to new contexts and uses is part of the
process
A design requirement for ubicomp

59. Designing for duality of structure
Moving from structure to use is commonplace
That’s what happens when you compile code and users run it
The trick is how to move back again
Making code for a class from a set of instances and usage histories
A process that allows for gradual adaptation of a class
Moving between complementary forms of class definition
Each move is (or should be) a social interaction

60. Intension
A class, compiled to create an executable shared among users
Extension
the deployed instances, that are adapted by users and which create
log data shared with evaluators and developers (and other users)
Ostension
a subset of instances selected by one of these people as particularly
interesting or useful, and shared among them for comment and use
analysis to a class signature reflecting ‘family resemblances’ among
the configurations and logs of that subset

61. Scenario: FanPhoto
FanPhoto: two core components,
for text and photo sharing
We give it out to 100 people
and they start using it
We start developing new
modules
one for sharing data via Facebook
one for fast compression and sharing of
text, photos and video via MANETs

62. Scenario: FanPhoto
A few participants are
interested in new modules 97
download them and show off 3
that they are trying them out
Analysts keep track via log
data streaming back
start to see a new subcluster
forming

63. Scenario: FanPhoto
FanPhoto
TextSharing
In the IDE, developers can PhotoSharing
see the FanPhoto class FacebookSharing
Modules used by a minority of MANETmodule
users are shown in grey

64. Scenario: FanPhoto
97
After some time, 3
developers and evaluators
meet to play back several
weeks’ use

65. Scenario: FanPhoto
91
After some time, 9
developers and evaluators
meet to play back several
weeks’ use

66. Scenario: FanPhoto
26 51
After some time, 23
developers and evaluators
meet to play back several
weeks’ use

67. Scenario: FanPhoto
FanBook
60 5
5
After some time,
developers and evaluators 30
meet to play back several
weeks’ use

68. Scenario: FanPhoto
FanBook
60 5
5
After some time,
developers and evaluators 30
meet to play back several
weeks’ use
Zippy

69. Scenario: FanPhoto
A developer sets his
IDE to do automatic
updates
Code defining each FanPhoto
new subclass appears
labelled with users’ and
analysts’ names
FanBook Zippy
linked to tools to analyse
the ostensions that made
them

70. Ostension revisited
Most forms of ‘analysis’ afford ostensive definition
A way to focus on a subset of structures, contexts, uses and users
e.g. an evaluator’s video of particular users from a system trial, a
user’s list of friends on Facebook, a developer choosing a name of a
city to customise design for
Log data allow us to link to the software used
Extend previous work that links from video to log data

72. Iterative design at a large scale
1. Development and refinement of tools,
infrastructure, statistical methods, formal analysis
methods and theoretical frameworks
2. Initial apps deployed by us to significant numbers of
people: social networking and games
3. Larger-scale deployments developed/distributed with
partners: Edinburgh Festivals, Rangers FC and other
football clubs, Glasgow museums...
4. Go back to step 1 and do it better

73. A population approach
A combination of theory, design, evaluation and use
Advances in all four needed for success
A circular process designed for duality of structure
Change and human agency as essential elements of the process
Multiple ways of representing a software class
Tools to use, create or adapt these representations
Users’, evaluators’ and developers’ social interactions and practices
involving those tools... that feed back into low-level representations

74. My predictions interface
getF ix!
FanBook
BP (update)?◦ 3 5
rtnF ix?
open?◦ dUI
dUI
60 5 4
5 0 1 2
BP (sob)?◦
rtnf ocus! noMatch
30 6
BP (close)?◦
9 addP red! getMatch
8
closeApp
Zippy 7
Fixture server : FS1
getF ix?◦
1
0
τ
rtnF ix!◦ 2
Prediction Server : PS
addData! getP red?◦
1
2
0
addP red?◦ getData!
rtnP red!◦
3
4
rtnData?
matthew.chalmers@glasgow.ac.uk 1
www.dcs.gla.ac.uk/~matthew