Your SlideShare is downloading. ×
Learning from ubicomp deployments keio 2010
Upcoming SlideShare
Loading in...5
×

Thanks for flagging this SlideShare!

Oops! An error has occurred.

×
Saving this for later? Get the SlideShare app to save on your phone or tablet. Read anywhere, anytime – even offline.
Text the download link to your phone
Standard text messaging rates apply

Learning from ubicomp deployments keio 2010

1,534
views

Published on

Talk reflecting on past ubicomp and mobile system designs, considering the pitfalls of 'in the wild deployments' and providing some tips to avoid them.

Talk reflecting on past ubicomp and mobile system designs, considering the pitfalls of 'in the wild deployments' and providing some tips to avoid them.

Published in: Technology, Education

0 Comments
0 Likes
Statistics
Notes
  • Be the first to comment

  • Be the first to like this

No Downloads
Views
Total Views
1,534
On Slideshare
0
From Embeds
0
Number of Embeds
1
Actions
Shares
0
Downloads
3
Comments
0
Likes
0
Embeds 0
No embeds

Report content
Flagged as inappropriate Flag as inappropriate
Flag as inappropriate

Select your reason for flagging this presentation as inappropriate.

Cancel
No notes for slide

Transcript

  • 1. Learning from Ubicomp Deployments In roughly 30 minutes Adrian Friday, adrian@comp.lancs.ac.uk http://www.comp.lancs.ac.uk/~adrian digital w w w. c y p h e r d i g i t a l . c o . u k Date 05.08.10 School of Computing andCommunications School of Computing andCommunications School of Computing andCommunications sheet Lancaster Uni_Layout 1 05/08/2010 3:32pm Page 2 Tuesday, 30 November 2010
  • 2. My background 1990 1995 2000 2005 2010The application employs a straightforward mechanism for dealing with failure within the group. Individual modules can inform the group coordinator that a module they are in communication with cannot be contacted. Following a failure notification, the group coordinator will purge the specified module’s interfaces based on the assumption that the remote component has failed (and consequently, its interfaces will have been invalidated, i.e. are now stale). At a later time the group coordinator will renegotiate with the remote group coordinator to obtain an up-to-date interface for the server once it has recovered. If catastrophic failure occurs, such as a remote node powering down or a detectable system error, then the fallback operation provides an expedient mechanism for removing that member from the group. More usually, group operations would not be propagated to that member until such time as they can re- establish communication. 5.3.1.3 User Interface The group coordinator supports a graphical user interface which is shown in figure 5.6. Figure 5.6 - Group coordinator graphical interface The interface is pictured during a conference (in stand-alone mode the central display and right hand buttons are not displayed). On the left hand side is a scrollable list of icons which represent the modules that are currently available (the two shown are the conference manager and geographical information system (GIS), illustrated by a group photograph and a globe respectively). Underneath the list of modules are a set of module action buttons. These actions include: starting, stopping, quitting the entire application and, importantly, the cancel operation. The interface is underpinned by a state machine which guides the user through operations by highlighting and greying- out icons that are available and unavailable respectively according to the given state. For example, if the user is attempting to start a module running, they would click the Mobile Collaboration Mountain rescue Context-aware GUIDE Equator: Physical - Digital Open Interactive Public Displays Tuesday, 30 November 2010
  • 3. Outline 1. Series of examples illustrating ‘unexpected things’ learnt through deployments 2. Some projects that influence my thinking in building systems to be deployed 3. Why did they work or not 4. Top tips for avoiding similar pitfalls with your demos and deployments Tuesday, 30 November 2010
  • 4. Why deploy? Tuesday, 30 November 2010
  • 5. First things first • Why deploy systems at all? • To probe • Ultimate ‘acid test’ of acceptability • Teaches you about Ubicomp ‘for real’ • Naturalistic evaluation (you say ‘it’s good for doing X for communityY’, is it?) • Increasingly the ‘gold standard’ in major conferences! Tuesday, 30 November 2010
  • 6. Why not deploy? Tuesday, 30 November 2010
  • 7. Why so hard? • Uncontrolled environment • Effort (initial, ongoing support) • Remote:“out of sight, out of mind” • Unsupervised • Often built out of COTS hardware not designed for the domain • The unexpected happens! • Is there any easier way to achieve good results (WoZ)? Tuesday, 30 November 2010
  • 8. Example 1: GUIDE K. Cheverst, N. Davies, K. Mitchell, A. Friday, and C. Efstratiou, “Developing a context- aware electronic tourist guide: Some issues and experiences,” CHI 2000, pp. 17–24, 2000. Tuesday, 30 November 2010
  • 9. Challenge - augmenting the city • 10 micro-cell servers in municipal buildings • Clients mostly out of range! (same still true!, e.g. remote areas, sensor networks) • Bonuses: user self-localisation Tuesday, 30 November 2010
  • 10. The Unexpected • Cell ‘breathing’ with weather • Staff changes meant batteries didn’t get charged - it got forgotten • We were there daily during critical field studies! • Tourists actually wanted a simpler guide (preset tours) and didn’t give us their context preferences! • Tourists wanted to talk to people! Tuesday, 30 November 2010
  • 11. Avoiding surprises • And it’s not just GUIDE, it’s every deployment! Project Type Surprise! Flump, 1992 Adaptive display Fire risk eCampus, 2005 Display network Health & Safety Hermes, 2007 Situated displays Equal opportunities Tuesday, 30 November 2010
  • 12. Lesson 1: Understand the environment • Get stakeholders and domain experts involved - early! • How harsh & does it change? (testing in-situ!) • Watch over the deployment regularly • Physical access!!! Tuesday, 30 November 2010
  • 13. e-Campus: Exhibition Storz, Oliver and Friday, Adrian and Davies, Nigel (2006) Supporting content scheduling on situated public displays. Computers & Graphics, 30 (5). pp. 681-691. Tuesday, 30 November 2010
  • 14. The Unexpected: • Content good enough to keep - no permission slip • “it’s broken” phone call • the impact of ADSL asymmetry on our workflow - daily moderation • ‘It was running last night...’, ‘Beginning to regret not automating this...’ Tuesday, 30 November 2010
  • 15. Lesson 2:What would happen if...? • You’re not there to restart it; • The power failed; • the users behaved inappropriately; • what might you want to use the data for; will you need physical access? • What are your ASSUMPTIONS? Tuesday, 30 November 2010
  • 16. Building robust Ubicomp Systems Tuesday, 30 November 2010
  • 17. Cooltown People, Places, Things: Web Presence for the Real World, Tim Kindberg, John Barton, Jeff Morgan, Gene Becker, Ilja Bedner, Debbie Caswell, Phillipe Debaty, Gita Gopal, Marcos Frid, Venky Krishnan, Howard Morris, Celine Pering, John Schettino, Bill Serra, and M. Spasojevic, WMCSA2000. In MONET Vol. 7, No. 5 (October 2002). Tuesday, 30 November 2010
  • 18. Simple is clever Image [Kindberg, 2002] “Make everything as simple as possible, but not simpler”, attrib:Albert Einstein Tuesday, 30 November 2010
  • 19. Lesson 3 - A powerful paradigm •Elegant, simple and a ‘natural fit’ • Choose toolkits carefully! • You also are getting their dependencies and quirks • For long lived projects: • Open-source project liveness, bloat, dependencies, updates! • Remember: a tool’s ‘benefits’ are not necessarily commutative! Tuesday, 30 November 2010
  • 20. What’s worked for us? Network asymmetry and buffering while offline Layer breaking/ adaptive behaviour Battery and network failures Workflow goals based on persistent files (almost stateless application) Limited coverage, walk up and use Hierarchy of caches, multicast ‘disk in the air’, users as sensors Complex distributed system EventHeap/ Pub-sub gives observability & reuse. State is regenerated. Tuesday, 30 November 2010
  • 21. What’s worked for us? Network asymmetry and buffering while offline Layer breaking/ adaptive behaviour Battery and network failures Workflow goals based on persistent files (almost stateless application) Limited coverage, walk up and use Hierarchy of caches, multicast ‘disk in the air’, users as sensors Complex distributed system EventHeap/ Pub-sub gives observability & reuse. State is regenerated. Mountain Rescue Tuesday, 30 November 2010
  • 22. Each pipeline stage can recover independently. Exploits persistence (camera, PC104, server) Tuesday, 30 November 2010
  • 23. 2.Transfer to server (wireless hop) 1. Data from device to mobile Each pipeline stage can recover independently. Exploits persistence (camera, PC104, server) Tuesday, 30 November 2010
  • 24. What’s worked for us? Network asymmetry and buffering while offline Layer breaking/ adaptive behaviour Battery and network failures Workflow goals based on persistent files (almost stateless application) Limited coverage, walk up and use Hierarchy of caches, multicast ‘disk in the air’, users as sensors Complex distributed system EventHeap/ Pub-sub gives observability & reuse. State is regenerated. Context-aware guide Tuesday, 30 November 2010
  • 25. Guide • ‘Broadcast’ browsing • Cell servers broadcast to clients in range • Client’s cache speculatively • Cache misses propagate upstream Tuesday, 30 November 2010
  • 26. What’s worked for us? Network asymmetry and buffering while offline Layer breaking/ adaptive behaviour Battery and network failures Workflow goals based on persistent files (almost stateless application) Limited coverage, walk up and use Hierarchy of caches, multicast ‘disk in the air’, users as sensors Complex distributed system EventHeap/ Pub-sub gives observability & reuse. State is regenerated. Situated displays Tuesday, 30 November 2010
  • 27. eCampus situated display network running for nearly 5 years! Tuesday, 30 November 2010
  • 28. Platform enables many views on eCampus Tuesday, 30 November 2010
  • 29. Lesson 4 - Design for support • Debugging “the invisible computer” • Something we seldom consider (esp. when in a hurry) • Systems may have many/ invisible pieces • Who will make bug reports and how can we help them? (beep, flash, dump, log...) • How can you ‘see’ the state of the system? • Remote access/ telepresence? Tuesday, 30 November 2010
  • 30. “There’s no place like home” Top tips for going outside Tuesday, 30 November 2010
  • 31. Practical Advice • Clean room install and run through • “Quantify the magic”, John Barton (what do you assume?) • Testing in-situ (physical but also network) • Develop a setup script so this tacit knowledge isn’t lost • Don’t forget you won’t/ shouldn’t be there! • Expectation setting on site Image: winesinfrastructure.org/ http://solaris.alasdair.su Tuesday, 30 November 2010
  • 32. What’s next? Tuesday, 30 November 2010
  • 33. Informing Energy Choices & Sustainable Living • Goal: Understanding & informing • personal and community scale energy use • transportation practices • A platform for building sensor driven applications (more in IoT 2010!) SenseTecnic - joint with MAGIC lab, UBC Tuesday, 30 November 2010
  • 34. Thank you for listening. http://www.comp.lancs.ac.uk/~adrian/ Tuesday, 30 November 2010

×