Implementing Interaction Techniques and Finite State Machines

1
Finite State Machines

• Implementing Interaction Techniques and Finite
  State Machines

2
Agenda

• Questions
• Respect for 9/11
• HW3, Friday readings
• Describing interaction behavior
• Example line drawing
• Event-driven specification
• Finite state machine notation
• FSM specs for interaction techniques

3
Implementing an interaction technique line
drawing

• Simple (?)
• Specify two endpoints
• Not good
• no affordance
• no feedback

4
Implementing the line drawing better

• Better feedback is to use rubber banding
• stretch out the line as you drag
• at all times, shows where you would end up if you
  let go
• How would we provide better affordance?
• Changing cursor shape is about all we have to
  work with

5
Implementing rubber banding

• Accept the press for endpoint p1
• P2 P1
• Draw line P1-P2
• Repeat
• Erase line P1-P2
• P2 current_position()
• Draw line P1-P2
• Until release event
• Act on line input

6
Whats wrong with this code?

• Accept the press for endpoint p1
• P2 P1
• Draw line P1-P2
• Repeat
• Erase line P1-P2
• P2 current_position()
• Draw line P1-P2
• Until release event
• Act on line input

7
Not event driven

• Not in the basic event / redraw cycle form
• dont want to mix event and sampled
• in many systems, cant ignore events for
  arbitrary lengths of time
• How do we do this in a normal event / redraw
  loop?

8
Event-driven framework for interaction techniques

• Take sets of actions from code and write as
  event-driven form
• We have to maintain state between the events

9
Finite state machine controllers

• One good way to maintain state is to use a
  state machine
• (deterministic) finite state machine
• FSM

10
FSM notation

• Circles represent states

11
FSM notation

• Circles represent states
• arrow for start state

12
FSM notation

• Circles represent states
• arrow for start state
• double circles for final states
• notion of final state is a little off for user
  interfaces (dont ever end)
• but still use this for completed actions
• generally reset to the start state

13
FSM notation

• Transitions represented as arcs
• Labeled with a symbol
• for us an input event (can vary)
• Also optionally labeled with an action

14
FSM Notation

• Means when you are in state A and you see a
  mouse down, do the action (call draw_line), and
  go to state B

15
FSM Notation

• Sometimes also put actions on states
• same as action on all incoming transitions

16
Rubber banding again (cutting up the code)

• Accept the press for endpoint p1
• A P2 P1
• Draw line P1-P2
• Repeat
• B Erase line P1-P2
• P2 current_position()
• Draw line P1-P2
• Until release event
• C Act on line input

17
FSM control for rubber banding
18
Second example button

• Press inside gt highlight
• Move in/out gt change highlight
• Release inside gt act
• Release outside gt do nothing

19
FSM for a button

• A highlight button
• B unhighlight button
• C ltdo nothinggt
• D do button action

20
In general...

• Machine states represent context of interaction
• where you are in control flow
• Transitions indicate how to respond to various
  events
• what to do in each context

21
Guards on transitions

• Sometimes also use guards
• predicate (bool expr) before event
• adds extra conditions requirements to fire
• typical notation pred event / action
• e.g. button.enabled press-inside / A
• (pred event) higher level event
• Note FSM augmented with guards is Turing complete

22
Control flow in event driven systems

• FSM allows (formal or informal) analysis
• are all possible inputs (including errors)
  handled from each state
• what are next legal inputs
• can use to enable / disable
• Can be automated based on higher level
  specification

23
Implementing FSMs

• state start_state
• for ()
• raw_evt wait_for_event()
• evt transform_event(raw_evt)
• state fsm_transition(state, evt)
• This is the basic event loop
• Implementing fsm_transition?

24
Implementing FSMs
25
FSM implementation

• Just a big switch statement making correct
  transitions from current state and input

26
Table driven implementation

• Very stylized code
• Can be replaced with fixed code table that
  represents FSM
• only have to write the fixed code once
• can have a tool that generates table from
  something else
• e.g., from a graphical drawing editor

27
Table driven implementation

• Table consists of array of states
• Table S1, S2, , Sn
• Each state has list of transitions
• TR(Si) TRi1, TRi2, , TRim
• Each transition has
• event match method (guard event)
• list of actions (or action method)
• target state
• TR(Si, j) ltguard, evt, actions, target-stategt

28
Table driven implementation

• Table S1, S2, , Sn
• TR(Si) TRi1, TRi2, , TRim
• TR(Si, j) ltguard, evt, actions, target-stategt
• fsm_transition(state, evt)
• for each transition TR in Tablestate
• if TR.match(evt)
• TR.do_actions()
• state TR.to_state()
• break
• return state

29
Some examples

• Pulldown menu
• Jog Dial