Learning from ubicomp deployments keio 2010

Learning from Ubicomp Deployments

In roughly 30 minutes

Adrian Friday,[email protected]

http://www.comp.lancs.ac.uk/~adriandigital

ClientNigel Davies, Lancaster UniversitySchool of Computing and Communications

ProjectSchool of Computing and CommunicationsIdentity

Notes

w w w . c y p h e r d i g i t a l . c o . u k

Cypher Digital Imaging Ltd, Bridge End House, Park Road, Milnthorpe, Cumbria. LA7 7AD Tel: 015395 63433 Fax: 015395 63453 Email: [email protected] © 2010 Cypher Digital Imaging Ltd

Date 05.08.10

School of Computing and Communications



Grey text Black text Gray scale

Cypher Proposal Proof sheet Lancaster Uni_Layout 1 05/08/2010 3:32pm Page 2

Tuesday, 30 November 2010

mailto:[email protected]

mailto:[email protected]

http://www.comp.lancs.ac.uk/~adrian

http://www.comp.lancs.ac.uk/~adrian

My background

1990 1995 2000 2005 2010

113

The application employs a straightforward mechanism for dealing with failurewithin the group. Individual modules can inform the group coordinator that a modulethey are in communication with cannot be contacted. Following a failure notification,the group coordinator will purge the specified module’s interfaces based on theassumption that the remote component has failed (and consequently, its interfaces willhave been invalidated, i.e. are now stale). At a later time the group coordinator willrenegotiate with the remote group coordinator to obtain an up-to-date interface for theserver once it has recovered. If catastrophic failure occurs, such as a remote nodepowering down or a detectable system error, then the fallback operation provides anexpedient mechanism for removing that member from the group. More usually, groupoperations 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 figure5.6.

Figure 5.6 - Group coordinator graphical interface

The interface is pictured during a conference (in stand-alone mode the centraldisplay and right hand buttons are not displayed). On the left hand side is a scrollablelist of icons which represent the modules that are currently available (the two shownare the conference manager and geographical information system (GIS), illustrated bya group photograph and a globe respectively). Underneath the list of modules are a setof module action buttons. These actions include: starting, stopping, quitting the entireapplication and, importantly, the cancel operation. The interface is underpinned by astate 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

MobileCollaboration

Mountainrescue

Context-awareGUIDE

Equator: Physical -Digital

Open InteractivePublic Displays


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


Why deploy?


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 community Y’, is it?)

• Increasingly the ‘gold standard’ in major conferences!


Why not deploy?


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

Example 1: GUIDEK. 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.


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-localisationTuesday, 30 November 2010

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!


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


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!!!


e-Campus: ExhibitionStorz, Oliver and Friday, Adrian and Davies, Nigel (2006) Supporting content scheduling on situated public displays. Computers & Graphics, 30 (5). pp. 681-691.


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...’


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?


Building robust Ubicomp Systems


CooltownPeople, 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).


http://web.archive.org/web/20030610072607/cooltown.com/dev/wpapers/webpres/WebPresence.asp

http://web.archive.org/web/20030610072607/cooltown.com/dev/wpapers/webpres/WebPresence.asp

http://www.research.ibm.com/wmcsa2000/call.html

http://www.research.ibm.com/wmcsa2000/call.html

Simple is cleverImage [Kindberg, 2002]

“Make everything as simple as possible, but not simpler”, attrib: Albert Einstein


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!


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.











MountainRescue


Each pipeline stage can recover independently. Exploits persistence (camera, PC104, server)


2. Transfer to server

(wireless hop)

1. Data from device tomobile

Each pipeline stage can recover independently. Exploits persistence (camera, PC104, server)











Context-aware guide


Guide

• ‘Broadcast’ browsing

• Cell servers broadcast to clients in range

• Client’s cache speculatively

• Cache misses propagate upstream











Situateddisplays


eCampus situated display networkrunning for nearly 5 years!


Platform enables many views on eCampus


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

“There’s no place like home”Top tips for going outside


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 siteImage: winesinfrastructure.org/

http://solaris.alasdair.su




What’s next?


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


Thank you for listening.http://www.comp.lancs.ac.uk/~adrian/


http://www.comp.lancs.ac.uk/~adrian/

http://www.comp.lancs.ac.uk/~adrian/

Date post:	20-Jan-2015
Category:	Technology
Upload:	adrian-friday
View:	1,486 times
Download:	0 times

Learning from ubicomp deployments keio 2010

Technology