A Population Approach to Ubicomp Systems Design
0 likes344 views
This document describes a system for dynamically updating a mobile predictions interface. It involves communication between several components: a fixture server that returns fixes, a prediction server that adds and returns predictions, and the interface itself which opens, gets fixes and matches, and returns focus. Numerical values are associated with interactions between components.
A Population Approach to Ubicomp Systems Design
- 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)
- 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
- 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
- 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
- 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