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