Analysing user confusion in context aware mobile applications

1
Analysing user confusion in context aware mobile
applications

• Karsten Loer Michael Harrison

2
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

3
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

4
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

5
Sample domain A processing plant
6
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

7
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)

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

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

10
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

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

12
Model 1 controlled process
13
Model 2 control screen behaviour
14
Model 3 Pucketizer bucket mechanism
15
Model 4 Pucketizer device controls
16
Model 4 Context
17
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?

18
Trace comparison1

• Goal/Property Reachability of a state where end
  product C is released

19
Trace comparison2
20
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.

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

22
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

23
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