Successfully reported this slideshow.
We use your LinkedIn profile and activity data to personalize ads and to show you more relevant ads. You can change your ad preferences anytime.

A Population Approach to Ubicomp Systems Design

418 views

Published on

Intro to Populations project and related work for first year undergrads

Published in: Technology
  • Be the first to comment

  • Be the first to like this

A Population Approach to Ubicomp Systems Design

  1. 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. 2. Ubiquitous computingMore than just mobile devices...Systems that fit with context, interaction and activity ...which are varied and dynamic in ways difficult to predictThe 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. 3. Ubiquitous computingA 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. 4. SUMgroup: Social / Ubiquitous / MobileMatthew Chalmers, Alistair Morrison, Marek Bell, ScottSherwood, Don McMillanTheory, user experience and system designUse ‘in the wild’ rather than usability in the lab
  5. 5. A Short History: Treasure
  6. 6. A Short History: Feeding Yoshi
  7. 7. A Short History: EyeSpy
  8. 8. A Short History: Replayer
  9. 9. A Short History: Replayer
  10. 10. A Short History: Replayer
  11. 11. A Short History: Replayer
  12. 12. A Short History: shifting to iPhones
  13. 13. A Short History: shifting to iPhones
  14. 14. Mass participation‘App Store’ model of distribution a huge success More than 10 billion downloads in first 3 yearsUbicomp field trials generally focus on small numbersof usersNow there’s a potential to reach huge numbers ofusers relatively easilyWhat are the challenges: Methodological? Technical? Ethical?
  15. 15. Hungry YoshiOur first study exploring app store recruitment modelComparison with ‘traditional’ ubicomp field trialTook 2005 Windows Mobile application, reimplemented iton iOS in 2009
  16. 16. Yoshi (2005)Scans of WiFi APs‘Carry’ fruit to YoshisMainly qualitative methods, to studyintegration of game into everyday lifeOriginal study was “long-term, wide-area”Played over a week, with16 players inGlasgow, Nottingham and Derby
  17. 17. Yoshi (2009)
  18. 18. Quantitative evaluation
  19. 19. Qualitative evaluationQualitative evaluation at adistanceTask mechanism Many types of ‘task’ Real-time updates
  20. 20. Qualitative evaluationOver 28,000 responsesTokens as motivation Unrewarded: 11% of players Rewarded: 19% of playersPlayers vs. participants
  21. 21. Qualitative evaluationFacebook integrationUse Facebook mail, forums...
  22. 22. Qualitative evaluationTelephone interviews Offered payment A few very keen participants at start, but struggled to get >10 Self-selection biases, language issues
  23. 23. Quantitative evaluation: SGLogA generic logging framework with phone and server partsLog user interactions (button taps, screen changes), anddevice/sensor data (accelerometer, WiFi connections)Write to locally-stored files on device, but opportunisticuploading to SGLog server over Internet‘Real-time’ evaluation/monitoring of trial in progressSGVis: complementary visualisation / analysis desktop tool
  24. 24. Quantitative evaluation: SGVis
  25. 25. Quantitative evaluationHow do we count user numbers for Yoshi?In Windows Mobile trial : 16 users paid for participationIn iOS trial: Download? Register for account? Play for > x minutes/hours/days?
  26. 26. Quantitative evaluationHow 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. 27. Quantitative evaluation: SGVis
  28. 28. Quantitative evaluation: SGVis
  29. 29. SGVis: Categorising users
  30. 30. SGVis: Categorising users
  31. 31. SGVis: Categorising users
  32. 32. SGVis: Categorising usersCalculate centroids of each identified cluster4 categories of users: top players, commuters,static players, beginners
  33. 33. Categorising usersTargeting 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. 34. Categorising users as part of iterative designRelease 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. 35. The software engineering revolutionConventional models of the software development processall claim that “at some point, a product is delivered to auser community, at which point, for that revision of thesoftware, the design process is over.”Paul Dourish
  36. 36. The software engineering revolution“When we look at an interactive system as an evolvingartifact in use, it follows that the process of design doesnot end with the delivery of the system to somecommunity of users. Instead, it continues as they use andadapt the system.”
  37. 37. Concept Demonstrator/EvaluationInitial evaluation via a simple mobile game called CastlesGame chosen because Keeps users motivated In-depth and intense use stresses system Provides an infrastructure suitable for modular architecture
  38. 38. Game OverviewPlayers construct kingdoms Inhabitants Resources Buildings SoldiersPlayers may choose to battlewhen they are in wi-fi range
  39. 39. Game OverviewPlayers start with a set ofcommon modules and a setunique to themWhen players battle: histories are exchanged recommendations are made modules are transferred
  40. 40. Game OverviewAfter a battle, a player willbe informed if there arerecommendations
  41. 41. Game OverviewModule recommendationsintegrated into the buildinglistStars showrecommendation rankGray buildings are newlyreceived modules
  42. 42. FindingsPlayers progressed more rapidly with recommendationsNearly all followed recommendationsModules were spread to and used by others
  43. 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. 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 7Fixture server : FS1 getF ix?◦ 1 0 τ
  45. 45. A population approach to ubicompsystem designBased on mass participation & dynamic software structuresRedefining a fundamental computer science concept: classA new project, officially starting today Two universities, four million pounds, five years, nine people
  46. 46. The population approachMultiple representations of a software class (or type)Tools to use, create or adapt these representationsSocial interactions and practices involving those tools
  47. 47. The traditional representationA 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. 48. The traditional representationTests and changes need only be done on one thing at one time:the class structureWhat’s true for the class is true for the deployed instancesPoor fit with trends such as plug-ins, add-ins, e.g. what is Firefox?Phones often user-adapted, via App Store, Cydia, AndroidMarket...
  49. 49. Borrowing from biology: population thinkingA 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. 50. A new representation: populationA 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. 51. A new representation: a populationMatch between class and each instance may vary The value of a variable may vary... but also which variables, methods and functions make up internal structureVariation and dynamism mean complexity of design andanalysis Probabilistic statements and models instead of simpler discrete ones
  52. 52. Populations: variation and dynamismWhat’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 crashAnalysis results may be different at different times We advertise A and the percentages; a week later only 50% crashResults 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. 53. New tools and new interactionsAnalysis 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. 54. A third representation: ostensionOne or more population members are pointed out asexamplesMany potential ways to make an ostension e.g. a category or cluster selected from a population of instances
  55. 55. SGVis: Categorising users
  56. 56. From observed use patterns to softwarestructureMapTool is usually run along with DGPSLocationStreamUKTrainSchedule is frequently logged as being used in UKlocations tagged as train stationFestivalEvents and FestivalVenues modules are frequently usedwith an unofficial module AlternativeGuideToTheFringe whenthe user is in Edinburgh Fringe Festival venues
  57. 57. System design and structure“An ontology is a formal specification of a sharedconceptualization” Gruber, via SemanticWeb.orgTraditionally, design is about the perfect hierarchicalstructure One structure for all known uses, contexts and people Adaptation is the problem of changing it
  58. 58. System design and structurePopulation 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 processA design requirement for ubicomp
  59. 59. Designing for duality of structureMoving from structure to use is commonplace That’s what happens when you compile code and users run itThe trick is how to move back again Making code for a class from a set of instances and usage historiesA 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. 60. Intension A class, compiled to create an executable shared among usersExtension 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. 61. Scenario: FanPhotoFanPhoto: two core components,for text and photo sharingWe give it out to 100 people and they start using itWe start developing newmodules one for sharing data via Facebook one for fast compression and sharing of text, photos and video via MANETs
  62. 62. Scenario: FanPhotoA few participants areinterested in new modules 97 download them and show off 3 that they are trying them outAnalysts keep track via logdata streaming back start to see a new subcluster forming
  63. 63. Scenario: FanPhoto FanPhoto TextSharingIn the IDE, developers can PhotoSharingsee the FanPhoto class FacebookSharing Modules used by a minority of MANETmodule users are shown in grey
  64. 64. Scenario: FanPhoto 97After some time, 3developers and evaluatorsmeet to play back severalweeks’ use
  65. 65. Scenario: FanPhoto 91After some time, 9developers and evaluatorsmeet to play back severalweeks’ use
  66. 66. Scenario: FanPhoto 26 51After some time, 23developers and evaluatorsmeet to play back severalweeks’ use
  67. 67. Scenario: FanPhoto FanBook 60 5 5After some time,developers and evaluators 30meet to play back severalweeks’ use
  68. 68. Scenario: FanPhoto FanBook 60 5 5After some time,developers and evaluators 30meet to play back severalweeks’ use Zippy
  69. 69. Scenario: FanPhotoA developer sets hisIDE to do automaticupdatesCode defining each FanPhotonew subclass appears labelled with users’ and analysts’ names FanBook Zippy linked to tools to analyse the ostensions that made them
  70. 70. Ostension revisitedMost 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 forLog data allow us to link to the software used Extend previous work that links from video to log data
  71. 71. Iterative design at a large scale1. Development and refinement of tools, infrastructure, statistical methods, formal analysis methods and theoretical frameworks2. Initial apps deployed by us to significant numbers of people: social networking and games3. 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
  72. 72. A population approachA combination of theory, design, evaluation and use Advances in all four needed for successA 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
  73. 73. 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

×