The document discusses lessons learned from deploying ubiquitous computing systems based on the author's experience. It describes how real-world deployments uncovered unexpected issues like cell signal fluctuations and lack of remote access. This led to systems failing or not working as intended. The author advocates designing systems to be robust to these kinds of issues through strategies like making components stateless and independent, exploiting persistent storage, and enabling remote access for debugging. The overall message is that deploying systems brings to light challenges not anticipated in the lab and informs the design of deployable ubiquitous computing technologies.
Kalyanpur ) Call Girls in Lucknow Finest Escorts Service 🍸 8923113531 🎰 Avail...
Learning from ubicomp deployments keio 2010
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
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
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
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
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
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