January 18th, 2010 § § permalink
This study investigates which explanations users of context-aware applications wanted to know so that we could target to provide these explanations to maximize user satisfaction. We presented 860 online participants with video scenarios of four prototypical context-aware applications under various circumstances along the dimensions of application behavior appropriateness, situation criticality, goal-supportiveness, recommendation, and number of external dependencies. We elicited and subsequently solicited (validation) what information participants wanted to know under the various circumstances and extracted 11 types of explanations of interest. We also found how the demands for the explanations varied with circumstance (e.g., explanations of all types are highly desired for critical situations, and Why Not explanations are highly desired for goal-supportive applications such as reminders). We presented our results as design recommendations of when context-aware applications should provide certain explanations.
Intelligibility Design Recommendations
We provide a table of recommendation to designers and developers of context-aware applications derived from survey data of participant responses and the resulting analysis [Lim & Dey 2009]. They can use this table to determine which types of intelligibility explanations to include in their applications depending on the circumstances their applications would encounter. For example, if the application is not very accurate, it would have low Appropriateness, and we would recommend the explanation types: Why, Why Not, How, What If, and Control.
Instructions on usage
Select the checkbox or radio buttons as according to how your candidate context-aware application is defined (e.g. whether it has high criticality, etc). This will highlight the respective explanation types recommended for your application. You can mouse over the keywords in the table for the definitions of what they mean.
Select this option for recommendations for context-aware applications, in general.
Whether the application tends to be accurate, or behaves appropriately.
E.g. an accuracy of <80% for recognizing falls may be considered to be of low Appropriateness.
Whether the situation presented is critical.
Situations involving accidents or medical concerns, or maybe work-related urgency can be considered highly critical.
Whether the situation is motivated by a goal the user has.
Whether the application is recommending information for the user to follow or ignore.
Whether the application is perceived to have high external dependencies
(e.g., getting weather information from a weather radio station) vs. being perceived as “self-contained.”
Explanations about the application, what it does, how it works, etc.
What sensors or input sources the application uses/used and what their values are/were.
What outputs, options, alternative actions the application can produce.
E.g. What accidents can the system sense?
Explanations about the conceptual model of the application.
Why the system behaved the way it did for a specific event/action.
E.g. Why did the system report a fall?
Why the system did not behave another way for a specific event/action.
Normally asked when the user’s expectation does not match the system behavior.
E.g. Why did the system not report a fire?
How the application achieves a decision or output action.
This is more general than the Why question.
E.g. How does the system distinguish a between a falling object and person?
Explanations about what would happen if an alternative circumstance or input values were present.
E.g. If an object falls, would the system report a fall?
What else the application has done / is doing other than what has been told.
E.g. Did the system alert emergency services of the accident?
Description of how confident the application is of its decision (recognition, interpretation, etc).
How accurate it is for an action.
How the user can change parameters for more appropriate application behavior, override, etc.
E.g. How can I change settings to control the sensitivity for reports?
Explanations to provide users with more situational awareness,
to get more information about the situation, environment, or people, rather than about the application.
E.g. What was the family member doing before the accident?
Publication
Lim, B. Y., Dey, A. K. 2009.
Assessing Demand for Intelligibility in Context-Aware Applications.
In Proceedings of the 11th international Conference on Ubiquitous Computing (Orlando, Florida, USA, September 30 – October 03, 2009). Ubicomp ’09. ACM, New York, NY, 195-204. DOI=10.1145/1620545.1620576.
January 18th, 2010 § § permalink
We sought to explore how much better participants could understand intelligent, decision-based applications when provided explanations. In particular, we investigated differences in understanding and resulting trust when participants were provided with one of four types of explanations compared to receiving no explanations (None). The four types of explanations are in terms of answers to question types:
- Why did the application do X?
- Why did it not do Y?
- How (under what condition) does it do Y?
- What if there is a change W, what would happen?
We showed participants an online abstracted application with anonymous inputs and outputs and asked them to learn how the application makes decisions after viewing 24 examples of its performance. Of the 158 participants recruited, they were evenly divided into groups where some received one of the four types of explanations and one group received no explanation. We subsequently measured their understanding by testing whether they can predict missing inputs and outputs in 15 test cases, and asking them to explain how they think the application reasons. We also measured their level of trust of the application output.
We found that participants who received Why and Why Not explanations better understood and trusted the application more than How To and What If.
» Read the rest of this entry «
January 17th, 2010 § § permalink
Investigated people’s reaction time to visual stimuli at 7 placements on the body (wrist, upper arm, shoulder, brooch, waist, thigh, foot). We found that people reacted fastest to the wrist, and slowest to the foot. Our findings would inform others who want to deploy wearable displays on various body locations.
» Read the rest of this entry «
January 17th, 2010 § § permalink
Investigated the wearing of a small light emitting, shoe-mounted prototype display to motivate physical activity. It provides a light to the public to leverage real-time, physical social influence to motivate people.
» Read the rest of this entry «
January 17th, 2010 § § permalink
In the Interactive Media Department, I am currently working on a framework to automatically aggregate various services in smart spaces. Users can bring their wireless-enabled mobile devices, and use their web browsers to explore and employ these services.
» Read the rest of this entry «
January 17th, 2010 § § permalink
During Summer 2004, I did an internship at the Context-Aware Systems Department. To enable office staff to control displays in conference rooms with their own PDAs, I developed a Java-based remote control interface to control the mouse and keyboard of the computers there. The work extended from Brad Johanson’s research on EventHeap and PointRight at Stanford.
» Read the rest of this entry «
January 16th, 2010 § § permalink
To provide more automation for feedback during group collaborations, this project incorporates peer and automatic linguistic feedback with a chat interface. As a collaboration between Cornell University and Parsons, New School for Design, this involved engineers from Cornell and designers from Parsons.
I was involved with this project from Spring to Summer 2006. I developed the AOL Instant Messenger (AIM) chat bot to capture conversations from group chats for processing in our system. The bot can also send messages from the administrator. Moreover, I developed the Flash Remoting bridge between the Flash front-end and J2EE back-end.