Transcript 24-ensembles

Ensembles
Ubiquitous Computing
Spring 2007
Readings
• Device Ensembles
• By Bill N. Schilit and Uttam Sengupta
– What We Carry (sidebar)
– By Ken Anderson, Michele Chang, and Scott Mainwaring
• User Interfaces When and Where They are Needed:
An Infrastructure for Recombinant Computing
• By Mark W. Newman, Shahram Izadi, Keith Edwards, Jana
Sedivy, and Trevor Smith
Device Ensembles: Overview
• Problem
•
People juggle a multitude of devices
and they don’t interact well.
• Goal
•
Devices should work as an ensemble,
playing effortlessly with each other.
•
• Future Usage
•
In the future, people will have ensembles
with more than just their own personal
devices.
Problem Scenarios
• How do I get my cellular handset to share
phone numbers with my notebook computer?
• How do I shuffle photos from my camera,
when its memory card fills up, to my digital
camcorder?
• How do I check incoming SMS messages on my
game console?
• How do I network my PDA through my cell
phone’s GSM data channel?
Why can’t one device do everything?
•“When one machine does everything, it in some sense
does nothing especially well, although its complexity
increases.” -Don Norman
Standards
•Digital Living Network Alliance providing guidelines
to improve interoperability among home media
devices.
•Made progress in important ensemble usage
scenarios.
•Lots more to do.
Layers of interoperability
• Link layer – low-power, short-range communication
• Network layer – to route IP through the “best
connected” device
• Data layer – to share and sync information
• Application layer – create apps that can span
multiple devices
Link Layer
•Spans both LANs and PANs with properties including
low power, medium to high bandwidth, and always-on
connectivity.
Link Layer examples
– Ubiquitous technologies
•
•
•
Infrared
Universal Serial Bus
Firewire
Link Layer examples
– Current technologies
•
•
Bluetooth
Wi-Fi
Link Layer examples
– Emerging technologies
•
•
•
Ultrawideband
ZigBee
Near Field Communication
Network Layer examples
– Current technologies
•
•
•
Jini
Universal Plug n Play
Personal Mobile Gateway
Data Layer
• Data synchronization: sync mobile devices with
desktop/server computers and other mobile devices
• Data transfer: send info when needed rather than
sync’ing across devices
• Data formats: have to translate data to appropriate
format to handle ensemble interoperability
Data Layer examples
– Data synchronization
• FastSync/SlowSync
• Open Mobile Alliance
• P2P synchronization
• Internet Suspend/Resume
Data Layer examples
– Data transfer
• BlueFS
• Segank
Application Layer
• Ensemble end-user services.
•
E.g. devices that act as user interface
peripherals for another
Application Layer examples
• Clicker application – converts phone into remote
mouse
• Email apps on notebook computer vs. BlackBerry
device
• CrossWeaver system – designers sketch interface
ideas for multiple devices and turn these into working
prototypes
Device Ensembles: Takeaways
• People now have a multitude of devices and move between
them depending on the task.
• Need to clarify usage models to design standards and solutions
for ensembles.
• Highlight: Clear outline of four layers to communicate the
capabilities of ensemble computing. Provided current,
grounded examples of these different layers.
• Questions: Integrate these layers into a single technology?
What We Carry
Study of “technosocial” device ensembles and
usage models
What We Carry: User findings
• People carry: cell phones, laptops, wallets, MP3
players, reading material
• All possessions reflect different aspects of how people
represent themselves
What We Carry: Changes
• Macro changes vs. Micro changes
• There should be easy migration of information and
identity between devices.
What We Carry: Too many devices!
• Every device needs too many supporting devices to
work effectively.
• User need: people want simpler technology that just
works in order to fulfill their tasks
• Example: Wi-Fi – makes life simpler.
What We Carry: Coordination
• Not just sync’ing information.
• “Coordinating information isn’t just an archiving
problem – it’s a practical one that occurs in real time.”
• Users need a seamless way to switch between and
coordinate devices
What We Carry: Takeaways
• People use multiple devices to fulfill a need for bounding
identity and function.
• Mobile devices do not interact as seamless ensembles yet.
• Highlight: Captured user needs within their social context.
• Question: Do users feel the need to maintain multiple devices
so we need to enable that coordination? Can we combine
functionality in some ways?
User Interfaces When and Where They are
Needed: An Infrastructure for Recombinant
Computing
Understanding the spontaneity of using and moving
between different technologies.
What is recombinant computing?
• Recombinant computing: enables devices/services to
recombine without planning.
• Addresses current problems:
– constrained by the difficulties in interconnecting devices and
services
– need to plan in advance to overcome the interoperability
challenges.
Speakeasy
• Infrastructure for recombinant computing. Users can
form new ad hoc combinations to meet their needs.
• Changes how devices discover each other and how
they transfer data between themselves.
Principles of recombinant computing
• Small, fixed set of generic interfaces
• Mobile code to extend behavior to other components
at runtime
• Allowing user to decide when and how components
will interact.
Framework overview
• Application requests
session object from source
• Passes session object copy
to the sink.
• Sink uses session to ask
source for type handler to
transfer data
Speakeasy: Requirement #1
• Component UIs must be able to find their way
across the network to the user that is using
them.
– Interfaces need to be delivered from external
components to a remote client for users
Speakeasy Requirement #2
• Applications should not need to have
specialized knowledge of every other
component.
– Apps should be able to use UIs for components they
have not seen before.
– UI can be downloaded on demand along with
underlying logic
Speakeasy Requirement #3
• Allow for the “push” and “pull” of UIs between
components and clients
– Pull top level per-component UIs
– Push per-connection UIs
Speakeasy Requirement #4
• Both applications and components have to
detect and recover from partial failures.
– Is a remote peer down, just slow at responding, or
momentarily disconnected?
– Need to detect these failures without explicit
disconnection signals
Speakeasy Requirement #5
• Infrastructure should support different UIs,
aggregated from different sources in a
connection.
User Interfaces When and Where They
are Needed: Takeaways
• Standardizing communication protocol is a good way
to enable effective device interaction
• No need to predict interactions – just follows the
push/pull of UIs at runtime.
• Highlight: an actual system framework developed to
facilitate device ensembles.
• Questions: What kind of problems can you foresee
with this framework? Would it work in all use cases?