Learning from ubicomp deployments keio 2010

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

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

Outline
1. Series of examples illustrating ‘unexpected
things’ learnt through deployments
2. Some projects that inﬂuence 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 ﬁrst
• 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!

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)?

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.

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

The
Unexpected
• Cell ‘breathing’ with
weather
• Staff changes meant
batteries didn’t get
charged - it got forgotten
• We were there daily
during critical ﬁeld
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: Exhibition
Storz, 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 workﬂow - 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

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

Simple is clever
Image [Kindberg, 2002]
“Make everything as simple as possible, but not
simpler”, attrib:Albert Einstein

Lesson 3 - A powerful
paradigm
•Elegant, simple
and a ‘natural ﬁt’
• 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
‘beneﬁts’ 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.

What’s worked
for us?
Network asymmetry
and buffering while
ofﬂine
behaviour
Battery and network
failures
Limited coverage,
walk up and use
users as sensors
Complex distributed
system
is regenerated.
Mountain
Rescue

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

2.Transfer to
server
(wireless hop)
1. Data from
device to
mobile
Each pipeline stage can recover independently.
Exploits persistence (camera, PC104, server)

What’s worked
for us?
Network asymmetry
and buffering while
ofﬂine
behaviour
Battery and network
failures
Limited coverage,
walk up and use
users as sensors
Complex distributed
system
is regenerated.
Context-aware
guide

Guide
• ‘Broadcast’ browsing
• Cell servers broadcast to clients in range
• Client’s cache speculatively
• Cache misses propagate upstream

What’s worked
for us?
Network asymmetry
and buffering while
ofﬂine
behaviour
Battery and network
failures
Limited coverage,
walk up and use
users as sensors
Complex distributed
system
is regenerated.
Situated
displays

eCampus situated display network
running 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, ﬂash, dump, log...)
• How can you ‘see’ the state of the system?
• Remote access/ telepresence?

“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 site
Image: 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/

Learning from ubicomp deployments keio 2010

Recommended

Recommended

More Related Content

Similar to Learning from ubicomp deployments keio 2010

Similar to Learning from ubicomp deployments keio 2010 (20)

More from Adrian Friday

More from Adrian Friday (20)

Recently uploaded

Recently uploaded (20)

Learning from ubicomp deployments keio 2010