Ubicomp: From Theory to Play. Matthew Chalmers University of Glasgow

Size: px

Start display at page:

Download "Ubicomp: From Theory to Play. Matthew Chalmers University of Glasgow"

Alison Powell
5 years ago
Views:

1 Ubicomp: From Theory to Play Matthew Chalmers University of Glasgow

2 Plus ça change... Future applications of ubicomp should be driven by both the expressed and observed needs of users. [...] Users control of such systems should be maximised and, given the heterogeneity of likely patterns of use, such systems must also be tailorable by the user. It is not possible to predict the social conventions governing the modes of use of ubiquitous computing that will come into being, so empirical studies of new applications [are] essential. Perceptions and Expectations of Ubiquitous Computing: Experiments with BirdDog, a Prototype Person Locator, O Shea et al., Proc. IEE ITaP, 1991.

3 Opposites... or synergies? Invisible and visible Infrastructure and interface Play and work Subjective and objective Quantitative and qualitative

4 Opposites... or synergies? Invisible and visible Infrastructure and interface Play and work Subjective and objective Quantitative and qualitative

5 Invisibility Ubicomp s design ideal of invisible use is from Heidegger via Mark Weiser A good tool is an invisible tool. By invisible, I mean that the tool does not intrude on your consciousness; you focus on the task, not the tool. Technology that is literally visible, effectively invisible with beautiful seams The humanistic origins of the invisible ideal in post-modernist thought People use, understand and appropriate systems in their own ways People make technology invisible through interaction System designs can help or hinder this process Use is a dynamic, temporal and social process, involving designers and users

6 Invisibility and visibility User studies also detail how technologies appear, disappear and reappear Through interaction over time, people build understanding Sometimes use is visible and analytic Handling breakdown Learning about the system Teaching others how to use it Considering how to act so that the system works better Considering how to present oneself to others through it Working on or adapting the system No system can always be invisible, and yet ubicomp pretends that it can

7 A Problem with Invisibility Weiser s concept of invisibility is only a limited part of Heidegger s Does not treat visible and invisible as interdependent states in the process of use Does not address how a system s invisibility is achieved through design and use New approaches to theory, system design and evaluation Based on the historical process of use, not just one state within this process Understanding different states, but also the transitions and interdependencies between them Being careful about this simple categorisation into discrete states

8 Opposites... or synergies? Invisible and visible Infrastructure and interface Play and work Subjective and objective Quantitative and qualitative

9 Infrastructure as Interface Responding to theoretical and observational findings Where do we persistently see visible use of ubicomp? Positioning accuracy, network availability, software modularity What is infrastructure to designers may be interface to users One design approach is to make the infrastructure seamless Another design approach is to support people in handling seams

10 Seams and Seamful Design Seams Gaps and losses in translation between media designed on assumption of unproblematic combined use Smooth such seams out, ignore them or seamfully design to reveal or take advantage of them Seamful design Selecting infrastructure to reveal as a resource for interaction Support the temporal process of use, not just one state Support users analysis, adaptation and appropriation Build and reuse histories of use, gathered from multiple people, systems & media

11 Seamful Games Using mobile multiplayer games as a lab for ubicomp Fun for players, and useful for researchers work Exploring infrastructure and interaction Three examples Treasure: a network s coverage, and the lack of it, as design resources Feeding Yoshi: wi-fi access points in the city, and their access control Castles: the internal structure of component-based mobile apps

Treasure Two teams of players, Blue and Green Each player has PDA+wi-fi+GPS, finding coins and stealing them from others Revealing where people had used network Taking advantage of being in the

12 Treasure Two teams of players, Blue and Green Each player has PDA+wi-fi+GPS, finding coins and stealing them from others Revealing where people had used network Taking advantage of being in the network Taking advantage of being out of it Accommodation and appropriation Features of the system, the setting and others system use Learning from others, teaching others, handling breakdowns, observing and displaying play, developing tactics and strategies

13 Treasure ipaqs with built-in wi-fi external GPS units Initial version written in Java, but soon changed to C# and.net CF Simple heartbeat broadcast of game state from server Messaging system built on UDP (rather than TCP) Our own wireless driver, sticking to our own network with no popups Instrumented code, creating logs on server and on each PDA

14 Replaying a Game of Treasure Testing and redesigning the system Showing the system and the users did what we said they did Historical data from players PDAs, the game server, video Such replay tools should be integral parts of such systems

16 Tactics and strategies Taking advantage of variation in wi-fi coverage and GPS accuracy Hide behind trees, pickpocket then run outside the network... Most new players were gatherers With experience of games and interaction with others, many became hunters Players learned to love pickpocketing

17 Feeding Yoshi Taking advantage of variation of wi-fi locations, ranges and access controls Gaps, overlaps, passwords, fees, legal constraints... Weaving ubicomp into the fabric of everyday life Use over a long time and a large area Fitting into patterns of work, leisure and home life The unit of design should be social people, in their environment, plus your device First published study of a long term mobile game?

18 Play A player gains points by feeding Yoshis the fruits they want More points for feeding more of a Yoshi s desired fruit in one go At the end of the game time, the team with the most points wins Yoshis and plantations are scattered across the city Yoshis give out seeds, to drop at plantations Plantations grow fruit that players can pick to feed Yoshis or swap Points uploaded to game web site via codes entered by players Game web site shows team and individual high scores

19 Technology ipaqs with built-in , C# under.net Compact Framework Yoshis and plantations are access points Closed APs are Yoshis, open APs are plantations Swapping fruit done directly via mobile ad hoc networks Extended Treasure s network driver with self-discovering spaces

20 The map and Yoshi screens

21 Studying Feeding Yoshi Pilot study: five days Three teams of four people in three cities Diaries, interviews, system logs, field notes The influence of urban character on play Full study: a week Four teams of non-cs people, based in three areas but occasionally travelling further afield A in Derby, B & C in Glasgow, D in Nottingham Diaries, interviews, system logs

22 Overall, a good game to play Fun to play, engaging, worth taking time out for The game is highly addictive when a good spot is found! I think we might have got into trouble at work... Team A won, despite a late fight back from Team B A: B: C: D: 8190

23 Fitting with patterns of everyday life Many short sessions to fit game into daily routines 12 Leaders did this most, as well as occasional focused play Work as resource/constraint Using work s wi-fi Varied ability to take breaks, be late, slip out Tuesday Wednesday Thursday Friday Saturday Sunday Monday Daily average number of plays, per player Team A Team B Team C Team D Time off work was not a good predictor of points

24 Commuting and travelling Journeys were often good for play Building understanding of Yoshis and plantations on routes Carrying seeds to plant in good places, or to trade with others Varying routes: I d take slightly different street routes than I d normally take; initially to see what was there. Once I realised there was good stuff there then I would adjust my route. Drive-by Yoshi

25 Friendship and collaboration Social setting affects coordination and collaboration With other players, and with colleagues, partners, relatives... The more time spent together, the more points Trading fruit and information, and sharing the experience Play as pairs was common within teams A, B and C Play even bridged teams sometimes...

26 I was playing away and then this box popped up saying Norman would like to trade and I thought I don t have a Norman on my team!. Then I saw this guy with a PDA and he was looking around, and then we caught up with each other and we thought hmmm not the same team. But he walked over and he said that he was from [Team C] and could he trade? And well, I was in my prime playing spot so I had all the fruit I needed, so I just thought, okay I would trade with him.

27 The impact of location Crowded streets I kept walking into folk! Distinctive patterns of movement Shuttling back and forth between Yoshis and plantations Standing outside or drifting by suburban homes Discomfort in some industrial and business districts The industrial area over the road from my house... Lots of Yoshis and plantations but too many cameras and security guards Some areas too dangerous to play in Why do you think we have this little black button under the dashboard in our car?

28 Opposites... or synergies? Invisible and visible Infrastructure and interface Play and work Subjective and objective Quantitative and qualitative

29 Castles Taking advantage of variation in assemblies of software modules The software infrastructure that makes up an application A strategy game: build up armies by combining resources Fields, houses, bakeries, iron mines, barracks, knight schools... Battle to win points and also information on new resources to make Adapt your play and adapt your system in order to keep winning Each resource is a software module Modules use is logged to build a history of use for each player A collaborative filtering subsystem uses the logs to make recommendations Modules are spread via MANETs, based on these recommendations

30 Castles

31 Castles

32 Castles

33 Domino A subsystem for handling assemblies of software modules Dynamic sharing via MANET, dependency resolution and integration Communication, recommendation and adaptation Recommendation based on patterns of use, and on classes and dependencies Users express utility or relevance subjectively: in and through their use Designers specify features objectively: module s class and class dependencies Social and technical means for security and privacy Transfer done as part of logged face-to-face game play Certification of modules? Honeypots? Sandboxes? Replay of logs of use?

34 Communication Recommendation Adaptation Physical & IP discovery Get and service history segment requests Get and service module requests Request history segments Merge histories and generate recommendations Log module usage to user s history Start new module Evaluate module s dependencies Add, remove, or replace modules Connect dependencies Record new system state

35 Using History to Reduce Ambiguity in Component Integration First PDA running map tool with pollution layer and GPS layer modules Second PDA running two map tools: one with GPS layer, one with no layer

36 Using History to Reduce Ambiguity in Component Integration First PDA running map tool with pollution layer and GPS layer modules Second PDA running two map tools: one with GPS & pollution layers, one with none

37 Opposites... or synergies? Invisible and visible Infrastructure and interface Play and work Subjective and objective Quantitative and qualitative

38 Replayer An extensible toolkit of components Each Replayer component is a separate process, for Macs and PCs Tools and techniques for combining heterogeneous data... and for combining multiple tools, displays & computers Combining and moving between quantitative and qualitative data Trials happening this month

39 Replaying and annotating... what? Video Audio: field notes and participant audio Post hoc data: field notes, interviews, questionnaires Logs of system data, including participants and observers locations

41 Replayer: a set of linked processes

42 Components: time series

43 Components: event series

44 Maps: Google Earth

45 Histograms and force-directed graphs

46 Statistics: correlation, mutual information...

47 Timeline-based bridge for audio and video

48 Auto-selection of video based on who s in it

walking, still or driving Pilot users diaries matched well with total

50 Analysing accuracy of logs in Shakra Shakra: a collaborative health application for mobile phones GSM cell signals analysed and classified: walking, still or driving Pilot users diaries matched well with total time tagged as walking...but second-by-second comparison suggested very low accuracy

51 Combining views to resolve ambiguity in Shakra

52 Synergies Invisible and visible Infrastructure and interface Play and work Objective and subjective Quantitative and qualitative

53 Conclusion Ubicomp s ideal of invisibility is not always possible New design can sometimes create seamless infrastructure and invisible use But sometimes it just can t Seamful design is another choice Selecting infrastructure to reveal as a resource for interaction Using past activity as a resource for interaction and adaptation Combining subjective and objective in the deep structure of systems Combining qualitative and quantitative in tools for evaluation and analysis

54 Thanks U. Glasgow: Louise Barkhuus, Marek Bell, Barry Brown, Malcolm Hall, Julie Maitland, Alistair Morrison, Scott Sherwood, Paul Tennent U. Nottingham: Steve Benford, Mauricio Capra, Alistair Hampshire, Tom Rodden, Duncan Rowland (now at U. Lincoln) U. Bristol: Henk Muller, Cliff Randell, Ian Anderson UK Engineering and Physical Sciences Research Council

55 Weiser and invisibility Seamful Interweaving: Heterogeneity in the Design and Theory of Interactive Systems, ACM DIS 2004 A Historical View of Context, J. CSCW 2004 Treasure Yoshi Picking Pockets on the Lawn: The Development of Tactics and Strategies in a Mobile Game, Ubicomp 2005 Interweaving Mobile Games With Everyday Life, ACM CHI 2006 Castles/Domino Exploring Mobile Collaborative Software Adaptation, Pervasive 2006

Glasgow eprints Service

Glasgow eprints Service Bell, M. and Chalmers, M. and Barkhuus, L. and Hall, M. and Sherwood, S. and Tennent, P. and Brown, B. and Rowland, D. and Benford, S. and Capra, M. and Hampshire, A. (2006) Interweaving mobile games with