Exiting the cleanroom: on ecological validity and ubiquitous computing

Exiting the cleanroom: on ecological validity and ubiquitous computing is a paper on prototyping, observation, controlled evaluation and field experiments of Ubicomp. There are three class of ubicomp applications: peripheral displays, mobile applications, and applications that integrate physical and digital interactions. Idiosyncrasies with ubicomp applications are due to the need for applications to be in many places, do many tasks, work across many devices. The authors did fieldwork with 28 ubicomp developers to understand the problems in ubicomp.

Peripheral displays

• Developers said that determining how study participants used the information in the peripheral display is a challenge.
• Developers complained about having to decide between too many design options. (The paper does not explain why peripheral display developers specifically have too many choices)
• There is a need for tools that allow applications to multiple outputs.
• Unobtrusive evaluation is difficult if displays are deployed in real world like homes. Collecting quantitative data is difficult.
• The best way to evaluate the success of a peripheral display is by conducting situated, long-term deployment.
• Context of Use Evaluation of Peripheral Displays (CUEPD) method - captures context of use through user scenario building, enactment, and reflection.

Mobile Applications

• Evaluation is difficult. Literatures examples show the difficulty in understanding how participants use their cell phones.
• Prototypes have to developed in multiple platforms. Not all phones implement Java JSR spec completely.
• Planning field studies involving mobile phones difficult due to many mobile operators, plans, devices.
• In real world scenarios, users are constantly interrupted while using their mobile applications, this is hard to replicate in the lab.
• Researchers have used diary studies and interviews to understand picture sharing usage.

Integrating physical and digital interactions

• This subset refers to ubicomp applications that take the data from sensors like camera and process it.
• Primary challenge is abstracting physical input.
• Paper Prototyping used for exploration by developers.
• Developers expressed need for better tools

Challenges in evaluating ubicomp

• Ambiguity in sensed data and need to mitigate error
• Sparse data. There are too many unique situations which are difficult to evaluate while prototyping
• Critical mass: many applications need critical mass to be successful
• Evaluating obstructively is difficult
• Tools that can support realistic environments

Authors recommend the following techniques to overcome the problem. (I’m just listing them, the paper explains them in depth)

1. Situated techniques
2. Remote evaluators (privacy concerns??)
3. Diary study
4. Lightweight prototypes
   • Paper prototypes
   • Wizard of oz
   • Looks like

Semi-public displays

While I was looking for papers on collaborative  reminder systems, I found the paper titled:  Semi-Public Displays for Small, Co-located Groups. This paper discussed the applications developed by the authors for small collocated groups. The public displays in this setting are meant to be source of ambient information about the group members.

• Reminders - slide show style display of reminders, requests and frequently emailed documents like status reports. Requests were extracted from status reports using a Perl parser
• Collaboration space - allows anyone to enter test in freeform text and images. Supports asynchronous group work.
• Active Portrait - shows a group  photo. The brightness of a group member indicates his/her activity. Less active members are shown as silhouette thereby accentuating their absence.
• Attendance panel - an abstract visualization to depict attendance of upcoming events as a flower. The color of the flowers would indicate the response rate of a event.

I liked the idea of extracting reminders and help requests from the status reports. For my project I can extract requests or event reminders sent to si distribution lists and bounce it off our display.

The authors have completely dodged privacy questions, claiming that the semi-public display acts an quick and accessible source for information available within the group. The  argument doesn’t seem convincing to me. The authors tested the applications in academic labs, that can be secluded, like our SI North. But in a corporate environment small team don’t share a cozy space, hence a system without any privacy control may not be deployable.

Summary: Dey, Anind; Providing Architctural Support for Building Context-Aware Applications

Dey’s doctoral dissertation provides a set of requirements for a context-aware framework, and discusses an implementation of such a framework: the Context Toolkit. (Sorry, didn’t read all of it)

Major contributions (from dissertation):

• identification of a novel design process for building context-aware applications;
• identification of requirements to support the building and evolution of context-aware applications,
  resulting in a conceptual framework that both “lowers the floor” (i.e. makes it easier for designers
  to build applications) and “raises the ceiling” (i.e. increases the ability of designers to build more
  sophisticated applications) in terms of providing this support;
• two programming abstractions to facilitate the design of context-aware applications: the context
  component abstraction (including widgets, aggregators, interpreters and services) and the situation
  abstraction;
• building of a variety of applications that cover a large portion of the design space for context-
  aware computing; and,
• building of the Context Toolkit that supports the above requirements, design process and
  programming abstractions, allowing us and others to use it as a research testbed to investigate new
  problems in context-aware computing such as the situation programming abstraction and dealing
  with ambiguous context and controlling access to context.

Architecture for Privacy-Sensitive Ubicomp - Intro

Another paper on handling privacy in Ubicomp applications.T he objective of Ubiquitous Computing is: Technology should be extended in a fundamental manner that removes any conscious awareness of technology.

With the advancement in technology there is natural push towards developing a Ubiquitous Computing environment. But these technologies are introducing privacy risks faster than the time required to develop legal and social norms, to handle these privacy risks. Consequently many Ubicomp systems are being rejected due to privacy concerns. Example: Active Badges for location sensing for locating nurses in hospital is considered to be a surveillance mechanism, albeit they have some advantages. For similar privacy concerns many Ubicomp apps are not being deployed in spite of having the technical capability to implement them.

Earlier research work in privacy concentrated on providing anonymity and securing the personal data. In Ubicomp environment, users are willing to share their data but need control over what is being shared.

The authors have developed Confab toolkit which is “based on analysis of user needs and interaction design for ubicomp privacy”. It provides foundation for developers to build privacy sensitive applications.

Problems with personal privacy:
* It is hard to analyze privacy needs. The paper presents end user needs gathered from various sources which should help us understand privacy needs.
* UI for privacy: List of pitfalls in designing UI for privacy - that are still being made.
* Implementation of privacy sensitive systems: Design, implementation, and evaluation of confab toolkit

Three layers in Confab toolkit:
* Physical/sensor layer
* Infrastructure layer
* Presentation layer

* Privacy is often thought after the applicaitons are developed
* Privacy is inhibiting deployment of ubicomp technologies
* Little support guidance exists
* Privacy uses are likely to increase from ubicomp technologies

Five Pitfalls: To avoid privacy issues

Users can increase their awareness about the privacy implications of a technical system:

• If they understand the extent of the system’s capabilities
• If they can conduct socially meaningfully actions in the system

Authors have identified five common pitfalls to avoid while designing information system. The pitfalls have been gleaned from the authors’ experience in designing a privacy preferences module for a ubiquitous computing environment called Faces. The five pitfalls have been grouped into two categories as listed below:

Understanding
1. Obscuring personal information flow. Internet Explorer’s privacy control settings of low, medium, high is ambigious. Users can understand what exactly is being conveyed.
2. Obscuring actual information flow. Eg. Browsers hide information collected in cookies. Users are not aware of what is being stored in cookie.
Action
3. Emphasizing configuration. Software like P2P provide plenty of options to control privacy. Users don’t want to waste time configuring their privacy
4. Lacking coarse grained control. Users should have accesible controls for top level privacy decisions like a large button to turn off broadcasting of any personal information
5. Inhibiting established social/technical practice.

Faces, the privacy preference system built by the authors allowed users to specify who can see what information about the user when. It also logged all the disclosures made by the system, so users can review what personal information was revealed.  In spite of correctly applying the design methodologies, Faces was not a success. When the authors analyzed the reasons for failure, they identified these five pitfalls.

Other interesting points I identified in the paper are:

Norman said that the designer’s goal is to design a system such that the mental model of the system envisaged by the user matches the designer’s mental model of the system. Extending this paradigm to  ubiquitous  systems  -  where there is a observer, user and designer. So now the mental model of all three (observer, user and designer) should match.

Designers can’t provide the option to control a privacy variable to the user and leave it to user to find the right value for the variable. The amount of information users are willing to share depends on the identity of the inquirer. But it is difficult for the user to give a privacy setting to all their contacts.

Article Summary: (Ballagas et al, 2005)

Sweep and Point & Shoot: Phonecam-Based
Interactions for Large Public Displays - Ballagas, Rohs, Sheridan, 2005

http://www.vs.inf.ethz.ch/res/papers/Sweep-PointShoot-CHI2005.pdf

This article explores two different methods of interacting with large public displays. The first method involves tagging each area on the display with a visual code (something similar to QR codes), which they call “point and shoot”. The other method developed, which they dubbed “sweep”, uses the mobile phone’s camera as an optical tracking device. The authors then conducted a within-subjects experiment comparing the two new methods with a traditional 5-way joystick found on the Nokia 6600. 10 subjects were used (7 right-handed, 6 male, 5 were 26-35 years of age, 4 were 17-25 years of age, 1 over 45 years of age, 6 were from the UK, 9 were from Europe, 1 non-European).

Point-and-shoot:

The display is divided into different areas, with each area given a visual code, which is initially hidden from the screen. Users select the desired item/area by photographing the desired area of the screen. The codes appear when the user initiates a photo capture on the cell phone (IE. pressing the shutter button); once a successful selection is confirmed by the system, the codes are hidden again.

Advantages:

• the coding system is designed such that the coordinate system is “invariant to perspective distortion”.
• Tests show that P&S is not significantly different from using just the joystick to control a cursor
• visual tags can be on real-world objects as well

Disadvantages:

• flashing the coordinate on the screen whenever a user wishes to select an object makes the system visually unappealing, and currently does not easily scale to support multiple users.
• testing shows that P&S had a significantly higher rate of error than both the joystick and “Sweep” method
• current implementation did not have good “anti-shaking” camera system, so only people with fairly steady hands can accurately use the system
• users must utilize the phone’s screen as a viewfinder

Sweep:

The Sweep method also uses the phone’s camera, but instead of requiring high-resolution images to accurately capture the visual codes, Sweep uses the camera to simply detect motion by sampling successive images, as if the phone was an optical mouse and the entire world was a mousepad ( PRETTY COOL - perry). In their implementation, the system only tracks motion when the 5-way joystick is held down - their idea being that releasing the joystick is analogous to taking the mouse off the mousepad. They characterize the joystick as a “clutch”.

Advantages:

• Sweep is only concerned with relative motion, so it works in 3-dimensions, and can point anywhere in the users’ surroundings
• ability to use it in 3-D also reduces fatigue over long-term use
• users don’t have to look at the phone’s screen, but instead focus on the cursor on the public display

Disadvantages:

• high latency (if the phone is slow)
• significantly higher time to task completion than both P&S and joystick methods
• Student Newman-Keuls analysis showed that error rate is significantly higher than joystick method

Overall findings and observations:

• one of the users commented that one-handed operation of the Nokia 6600 was like “trying to hold onto a bar of soap”
• fatigue we not an important factor, but several subjects complained of painful thumbs
• users rated P&S higher than Sweep in every category of the survey: Overall operation, reliability, response time, and physical effort required for operation
• screen size matters when choosing between Point-and-Shoot and Sweep: P&S good for when they are close to the display, Sweep otherwise
• P&S might be scalable to multiple users if the codes were displayed in a non-visible spectrum such as infrared

Remarks on/related to article:

• would thumbs hurt as much if they reversed the usage for Sweep - press down on the thumbstick only when they want to pause the system? or would that be too unintuitive?
• use of QR codes - can we use QR codes in our registration system for user-initiated bluetooth pairings? the display can embed info like MAC address and a randomly-generated pairing code
• how would Sweep work if the surrounding area as mostly uniform? or are they relying on low framerates of phone cameras to generate motion blurs?
• the Nokia 660 is a GIGANTIC phone…the test results might be very different if they had used a Razr instead

Ambient Agora Homepage

The Ambient Agora project has pretty much died off. But, they have a few more papers on the work at their project website: http://www.ambient-agoras.org/

There is a movie of the system in action at:

http://www.ipsi.fraunhofer.de/ambiente/paper/2004/AmbientAgoras_MPEG2_prante.avi