Analysing user confusion in context
aware mobile applications
Karsten Loer & Michael Harrison
1
Focus of Talk
• To support interdisciplinary design and
development of dependable interactive
systems by
– Concerned with a class of human
undependabilities that arise through embedding of
mobile devices
– Particularly interested in notions of context
2
Structure of the talk
• Scenario
• Use of modelling styles to support human
interaction with systems
• Particular concern, modelling “context” – the
context in which the human operator is
involved
• Preliminary study in context of DSTL work
• Possible future directions
3
Process control
•
•
Industrial process.
Control room:
– electronic wall displays providing dynamic plant schematics and trend data
– workflow information relevant to particular members of the crew.
– Commands to control valves and to retrieve further information.
•
Mobile device.
– Personal information about workflow moves to this device.
– Nearby components of the plant, controls and status information accessible
from the mobile device.
– Controls and information may be “saved” explicitly in “buckets”
– Even after the operator has moved on it is still possible to control these
devices.
•
Concern:
– To model context and to analyse confusions that arise through context shifts
4
Sample domain: A processing plant
5
Scenario
•
•
•
•
•
Problem occurs requiring “hands on” inspection and possible action
from one or several operators
Operators take mobile devices as they go to find out what has
happened
Device used to monitor and control valves etc. in situ
Might imagine repairs being made, valves, pumps etc. switched off in
order that repair carried out
Notions of context
–
–
–
–
•
Position
Correct order of actions in order to achieve goals
Other mobile devices in the vicinity
Time available to achieve goals
This example takes a very simple case
6
User confusion
• New situations and new configurations may
serve to confuse users in potentially
disastrous ways. In these scenarios the
change in configuration can have a number of
implications.
– Command that has one meaning in one location,
with one configuration, may have another meaning
in another location (mode confusion).
– A style that may be appropriate for one
configuration may not be appropriate for another
(style incompatibility)
– The way functions are allocated between human
and automation may vary (closure confusion)
7
Mode confusion
• “Collect the controls from the nearest valve and
perform an action” – extends understanding of action
interpretation. Effect not just modified by state of
interaction software, also characteristics of context
• “wait until your colleague has switched off the heater”
– Notions of reference
– Notions of public and private space
– Notions of locality
• Can such systems be modelled so that problems can
be predicted?
• What does this class of problems tell us about mode
confusion analysis?
8
Style compatibility
• Translating a point and click interface on a PDA to an interface
on a telephone
• Same function, different mechanisms for invoking them
• Control room
– Point to valve on schema and produce display of rate of flow and
temperature, modify the temperature through direct manipulation
• PDA
– Pull down attributes of valve when nearby, similar display of flow
and temperature
– Give voice command to change the temperature
• What are these notions of style? How can it be proved that two
commands have the same effect – semantic equivalence? How
do users manage the differences?
9
Closure confusion
• How are functions closed?
– Configuration supply information to aid decision
making
– Configuration induces parameter from situation
– What recovery mechanisms are available
– How do these notions connect with the mode
confusion issues mentioned earlier
• Interaction with levels of automation
10
Analysing the design of the interactive
behaviour of a context aware mobile
application it is necessary to
• have models of configuration, that is the technology
platform which the application currently inhabits to
capture those characteristics of the action that are
affected by the application's move from configuration
to configuration
• develop a rich enough description of the context of
the user and configuration to describe the context
effects of action
• Understand the constraints imposed by the work that
the user will carry out in order to limit the paths that
are relevant for analysis.
11
Model 1: controlled process
12
Model 2: control screen behaviour
13
Model 3: Pucketizer “bucket”
mechanism
14
Model 4: Pucketizer device controls
15
Model 4: Context
16
Analysis: Model validity
Does the model behave as intended?
– “sanity”: deadlock-freedom, state/event reachability
– “goal reachability”:
• Can product C be produced?
• What is the easiest way to produce product C?
• What is the “best” way to produce C under assumptions
a1...an?
• Is it possible to reach unsafe states?
…
system
model
system
property
model checker
17
“TRUE” or
counter-example/
witness traces
a)
b)
c)
Trace comparison1
Goal/Property:
“Reachability
of a state
where end
product C is
released”
a) Control room interface
b) Pucketizer
c) Pucketizer (forgetful
operator)
18
Trace comparison2
19
Aim to extend the work
• Consider a model of context in which other users and
configurations (for example PDAs) may enter or leave
dynamically.
– This multi-agent context has many of the characteristics of case
studies explored using pi calculus
– Such a model could be used as a basis for checking what
information each PDA has in a particular state of the context and
how that changes as the user moves from location to location and
autonomous state changes.
– Use knowledge logics to express what an agent knows in a given
context
• Is it common knowledge that the repair has been completed in
order that all agents can restore the state of the components
they were dealing with to their original states.
• Is it possible that an agent can think that the state of their
component can be restored before it is time to do it.
20
Next stage: pragmatics of modelling
• Can the pi calculus model be translated into model
checking notations without adding a large number of
states?
• Do the models generated of context have generic
characteristics? There may be patterns of models
that can be instantiated in particular applications.
• Can the K-logic formulations be translated readily into
LTL by using conventions for labelling states?
• Are there K-logic templates that will make this
process simpler.
21
Context aware mobile electronic laboratory book
•
•
•
•
•
Notions of context – linking activity to position and to the current stage
of the experiment
Combining in-vivo with in-silico experimentation
Harvesting data from instruments, supporting manual input, sequencing
activities, including web services
Seamless situation aware computing supporting the science
Scenario from human genetics
– Genetic analysis related to Graves’ Disease
22
Ambient information in airports
•
•
•
Kiosks presenting embodied conversational agents – help facilities,
responding to questions
Mobile agents (ghosts) providing relevant information at point of need,
just in time
Semantic network, semantic web – relevant information, information
expressed in a form that satisfies the requirements of the individual
Much more to context than location
System supports an experience of place.
•
Issues
•
•
– Filtering information to point of need
– Service model: conversation and display
– Design for experience – “interior design” metaphor
23