- Slides: 35
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 Zig. Bee 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 • Fast. Sync/Slow. Sync • Open Mobile Alliance • P 2 P synchronization • Internet Suspend/Resume
Data Layer examples Data transfer • Blue. FS • 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. Black. Berry device • Cross. Weaver 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, MP 3 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?