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