First Year Ph.D. Presentation

Daniel Fitton

Exploring the Design and Use of Messaging and Context Sharing

with Situated Displays

Situated Public Display Appliances

•Deploying and developing in the long term.•Exploring patterns of use

•Patterns that do (or do not) occur•Integration with existing patterns of use

•Dependability•Performing a few simple tasks well•Continual use 24/7

•User involvement during development

Current Work

• Two Case studies

•Hermes (messenger to the gods in Greek Mythology)•Deployed outside offices in computing Department•Provide messaging similar to traditional post-it notes

•SPAM (SMS Public Asynchronous Messaging)•Assist care staff at different locations•Provide additional channel of communication

Hermes

•Enhance current paper based system with digital equivalent.• Typical Scenario:

Working at home today (car troubles), will be checking e-

mail.

Hermes

•Augments current paper based systems•Contrasts with post-it notes/message ‘whilers’..

•Private message left at public device•Security – Harder to remove/change message•Remote Interaction – SMS, Web portal, (MMS)

•Creation of message mirrors creation of paper post-it note

•Draw on touch sensitive screen with pen•Similar yellow colour!

Initial Requirements

•Had to use LV equipment for installation in corridor.•Comply with disabilities legislation.•Easy to deploy

•Self contained, no extra PC (etc) required•Wireless communication

•Security•Dependability

Development

•Phased development process•Feedback from users – Participatory design

Current System Architecture

•Client-Server Design•No information stored at Hermes Client Appliances.•All information stored at the server.•Updates and UI actions involve communication with server.•Uses Java RMI for synchronous communication.

•Problems•Speed of UI dependent on communication with server.•802.11b signal blocked by standing next to device.•Low signal strength means slow/no service.•What to do when communication fails?

SerialLink

WiredEthernet

UserProfiles

CentralServer

WebStorage

Web Portal

HermesClient

Ethernet Backbone

E-Mail Client

GSM NetworkGSM

Terminal

GSMMobilePhone

Wireless Network

Planned System Architecture•Use tuple-space approach to store and distribute data

•Every node contains a tuple-space •Any space can be updated•Updates ‘percolate’ to all other spaces

•Implemented using replicated JavaSpaces with Jini.•JavaSpace at every node•Distributed storage & replication across all nodes

•Improve Dependability•Hermes Appliances far less dependant on server•Network and server failure has less impact on function

CentralServer

HermesClient

JavaSpace

HermesClient

JavaSpace

HermesClient

JavaSpaceJavaSpace

UserUpdate

Update Propagated to other nodes

Patterns of Use

•Initially can only view messages through web portal or Hermes appliance

•Authentication process too time consuming.•Users didn’t bother reading new messages

•Introduced e-mailing of messages to users•Considering other methods

•Initially only a single public message•Cost of changing message (then changing back) too high.

•Users didn’t bother updating messages•Introduced Temporary and Default public messages

•Will allow user to remove and select a temporary message on appliance.