9' Dialog Notations and Design

1
9. Dialog Notations and Design
2

• Computer language
• Lexical level device dependencies, shape of
  icons, the actual keys
• Syntactic level order and structure of inputs
  and outputs
• Semantic level the meaning of the conversation
  in terms of effects on the internal data
  structures and the external world
• Dialog is syntactic level but often includes
  lexical features

3
9.1 Dialog Design Notations

• Intertwining dialog in program code is not a good
  idea
• Separated dialog notation
• Easier to analyse
• Separation of UI elements from actual calculation
• Dialog design possible before a program is
  written
• Allows prototyping

4

• 9.1.1 State transition networks

Click on centre Rubber band
Click on circumference Draw circle
Select circle Highlight circle
Finish
Circle1
Circle2
Start
Menu
Click on first point Rubber band
Line1
Finish
Line2
Select line Highlight line
Double click Draw last line
state
Click on point Draw line and rubber band from new
point
State transition
5

• 9.1.2 Hierarchical state transition networks

Select graphics Pop-up submenu
Select text Pop-up submenu
Main Menu
Select paint Pop-up submenu
Not more powerful, but more simple and flexible
6

• Concurrent Dialogs and State Transition Nets
• Independent toggles
• Bold
• Italic
• Underline
• needs 8 states None, bold only, bold italic,
  bold italic underline,
• In general 2n states for n independent toggles !
• Modern UI are full of independent toggles, option
  switches, style sheets,
• Possible solution
• Only use STN for each interface element
• Needed alternative method to put elements
  together

7

• Escapes and help in State Transition Networks

Click on centre Rubber band
Click on circumference Draw circle
Select circle Highlight circle
Finish
Circle1
Circle2
Press escape key
Start
Menu
Click on first point Rubber band
Line1
Finish
Line2
Select line Highlight line
Double click Draw last line
Arc from each state back to menu Become messy!
Click on point Draw line and rubber band from new
point
8
Select graphics Pop-up submenu
ESC
normal finish
ESC
Select text Pop-up submenu
Main Menu
normal finish
Select paint Pop-up submenu
ESC
normal finish
ESC is active during the whole subdialog
9
Click on centre Rubber band
Click on circumference Draw circle
From Menu
Finish
Circle1
Circle2
Press help button
Press help button
Help submenu
10

• 9.1.3 Petri Nets
• System can be in several states (places) at
  once

Bold on
Italic on
User presses bold
User presses italic
T1
T2
T3
T4
User presses bold
User presses italic
Bold off
Italic off
transition
place
Prohibits firing
counter
Place for user input
11

• 9.1.4 State Charts
• Form of STN but addresses concurrency and escapes

Represent default start state
Standby
H
ON
OFF
RESET
Start state will be Remembered (History)
TV_on
AND
Sound
Channel
1
H
on
SEL
2
MUTE
SEL
SEL
Composite state
3
off
SEL
4
12

• 9.1.5 Flow Charts
• Also suffers from the problems with concurrency
  and escapes
• Well known from programming
• Somewhat old fashion

13

• 9.1.6 JSD diagrams
• Jackson Structured Design
• Useful for basic menu-driven dialogs

system
iteration º optional

transaction
login
logout
º
º
º
º
add
show
delete
change
14

• 9.1.7 Grammars
• BNF notation
• No way to describe concurrent dialogs
• Not easy to deal with help and escapes
• some-clicks click some-clicks
• sequence
• choice
• Iteration by recursion
• Regular expressions
• Similar to BNF but slightly less powerful
• E.g. matching ( and ) cannot be expressed
• iteration is a primitive
• Click
• Only for low-level dialog description

15

• 9.1.8 Production Rules
• if condition then action
• condition Õ action
• condition action
• Order of the rules is not important
• Event-oriented production rules
• Sel-line Õ start-line lthighlight linegt
• C-point start-line Õ rest-line ltrubber band ongt
• C-point rest-line Õ rest-line ltdraw linegt
• D-point rest-line Õ ltdraw linegt ltrubber band offgt
• User events start with upper case
• Internal events start with lower case
• System response events between lt gt
• Events are stored in memory and removed if rule
  fires

16

• State-oriented production rules
• select-line Õ mouse-off start-line
  highlight-line
• click-point start-line Õ mouse-off rest-line
  rubber-band-on
• click-point rest-line Õ mouse-off draw line
• Double-click rest-line Õ mouse-off menu
  draw-line rubber-band-off
• If the rules are fired they set values to
  attributes
• Mouse mouse-off, select-line, click-point,
  double-click
• Line-state menu, start-line, rest-line
• Rubber-band rubber-band-off, rubber-band-on
• Menu highlight-off, highlight-line,
  highlight-circle
• Draw draw-nothing, draw-line
• Value of attribute is changed only if rule sets
  new value

17

• Mixed event- and state-oriented production rules
• event condition Õ action
• Event triggers rule but rule only fires is
  condition is satisfied
• Event is reset by default
• Attributes need to be (re)set by the actions
• Actions may generate events
• Bold off, on
• Italic off, on
• Underline off, on
• Select-bold Boldoff Õ Boldon
• Select-bold Boldon Õ Boldoff
• Select-italic Italicoff Õ Italicon
• Select-italic Italicon Õ Italicoff
• Select-underline Underlineoff Õ Underlineon
• Select-underline Underlineon Õ Underlineoff

n toggles, 2n rules
18

• Production rules
• good for handling concurrency
• not good for sequential dialogs
• State variable needed to keep track of position
  in the sequence, e.g. Line-state

19

• 9.1.9 CSP and event algebra
• Communicating Sequential Processes
• Is able to specify concurrency as well as
  sequence
• Draw-menu ( select-circle? Õ Do-circle
• select-line? Õ Do-line )
• Do-circle click? Õ set-centre Õ click?
• Õ draw-circle Õ skip
• Do-line Start-line Rest-line
• Start-line click? Õ first-point Õ skip
• Rest-line ( click? Õ next-point Õ Rest-line
• double-click? Õ last-point Õ skip )

Õ event sequence process sequence choice
parallel event all lower case Process Initial
upper case
20

• Bold-toggle select-bold? Õ bold-on
• Õ select-bold? Õ bold-off
• Õ Bold-toggle
• Italic-toggle select-italic? Õ italic-on
• Õ select-italic? Õ italic-off
• Õ Italic-toggle
• Under-toggle select-under? Õ under-on
• Õ select-under? Õ under-off
• Õ Under-toggle
• Dialog-box Bold-toggle Italic-toggle
  Under-toggle
• Mouse ( select-circle? Õ int-sel-circle Õ
  Mouse
• select-line? Õ int-sel-line Õ Mouse )
• Keyboard alt-key-down? Õ ( Alt Keyboard )
• Alt ( alt-key-up? Õ skip
• c-key? Õ int-sel-circle Õ Alt
• l-key? Õ int-sel-line Õ Alt )
• Draw-menu ( int-sel-circle Õ Do-circle

21

• 9.1.10 Parameterised and dynamic interleaved
  dialog structure
• Not all dialogs can be described by a finite set
  of dialog states
• E.g. multi-windowed systems windows can be
  created at run time
• Previous notations can only address structurally
  static dialogs
• Dynamic dialog can often be realised by
  parameterisation
• Extended event CSP
• Multi-window-editor new-name(name) Õ
• ( Edit-window(name) Multi-window-editor)

22
9.2 Dialog Analysis

• To discover potential usability problems
• Concerning
• User actions
• e.g.adequate and consistent?
• Dialog states
• e.g. can be reach desirable states
• Presentation and lexical properties

23

• 9.2.1 Analysis of user actions
• Is the dialog description complete ?
• No forgotten events, state/action pair?
• What should the system do in case of unforeseen
  circumstances?
• Is the specification deterministic ?
• Two or more rules for the same event
• By accident
• Deliberated
• There may be a default handling mechanism
• E.g. a precedence between rules
• Is this appropriated for the situation
• Is the specification consistent ?
• Consistency involves semantics
• Same/similar action, same/similar meaning
• Cannot be automated

24

• 9.2.2 Analysis of dialog states
• Reachability
• Can we reach all states
• Are the states fully connected?
• Are there no impasse?
• Can be automated
• Reversability
• Can we go back to the previous state(s)
• How easy is this?
• Not necessarily equal to undo
• E.g. back to menu after a circle has been drawn
• Desired states should be easy to reach
• Dangerous states (e.g. formatting disk) should be
  difficult to reach
• Treatment must be different for the other states
  (to avoid habitual answers)

25

• 9.2.3 Analysis of presentation and lexical
  properties
• Ideally first dialog design, next design of
  visual presentation, key bindings and mouse
  movements
• But in detailed dialog design it is difficult to
  abstract from presentation and lexical binding
  with keys and mouse movement
• enter a point vs. click
• enter last point vs. double click
• Also Different modes may need different
  representations

26

• And different types of interfaces have different
  dialog styles
• Command based interface uses verb-object, e.g
  print f
• Mouse based interface often uses object-verb,
  e.g. select file f, select print from menu
• There may be physical limitations
• For input number of buttons (e.g. a watch),
  keys,
• For output display limitations
• Position of keys on the keyboard/ items on a menu
  may cause dangerous situations
• F1 to save, Esc to abort

Esc
F1
F2
27
9. 3 Window Design

• A set of windows which comprise the interface.
• Each window contains a set of controls and a set
  of window actions on controls
• A window hierarchy diagram
• A window navigation diagram

28

• 9.3.1 Window
• a frame
• one or more panes
• frame contains various controls (e.g menu bar)
• each pane contains various controls

29

• 9.3.2 Control
• Basic functions
• to perform actions
• to see the state of objects
• to enter data
• Examples
• menu, label, text edit, push button, option
  button, check box, scrollable list
• graph controls
• grid controls

30

• 9.3.3 Window action
• action that the user can perform on a control,
  e.g.
• clicking a push-button control
• editing text in a text edit control
• dragging and dropping an icon
• Each window action must be documented in the
  design
• The effect should be in terms of user object
  actions and/or changes to the appearance of the
  windows.
• Window actions may have the same effect

31

• 9.3.4 Window navigation diagram
• Describes how the user opens new windows and
  transfer focus between windows.
• Notation
• Diagram showing windows and navigation paths.
• Standard ways to navigate are not shown (e.g.
  mouse click in window)

Window A
Window B
Navigation
32

• 9.3.5 Window dependencies
• defines how windows behave in response to certain
  actions
• examples
• close of primary window implies close of all
  secondary windows.
• parent, child windows

33
Method

• Define views of user objects
• a view represents the information and
  functionality needed by the user for a particular
  task.
• Consider multiple view if
• Too much information for a single view
• Some information is used frequently in tasks,
  others is not.
• The user object is used in different contexts for
  different tasks.
• Different tasks involve different type of use
  (some views are better for e.g. input, others are
  better for e.g. searching)
• Some information is restricted to particular
  users.

34

• Define windows
• Allocate views to windows.
• Per window
• a single view
• alternative views (never required at the same
  time).
• two or more views (simultaneously in different
  panes).
• only views of different user objects if this is
  more convenient for multi-object task.
• Decide on the type of the windows (from the
  window hierarchy)

35

• Select controls to represent object attributes
  (according to default mapping rules for data
  types).
• Key principles for preventing errors
• discrete set of values drop-down list, set of
  option buttons, multi-choice control.
• specific format format should be enforced by
  control or validated after input.
• value not permitted to change un-editable
  control.
• attribute not valid control should be disabled
  (if not obvious, allow for explanation why
  disabled)
• Define window actions

36

• Define dependencies between windows
• Define window instances of instances open at
  one time
• multiple instance of one user object can be
  viewed
• one at the time in a single window instance
• in multiple window instances
• in one window in a collector (e.g. list)

37

• Express task scenarios as window actions
• Scenario scripts are expressed as sequences of
  window actions. Revise as necessary.
• Define window navigation (between windows and
  between different views of an object)
• Map object actions to window actions
• one to one or one to many
• Define modal windows (window disables access to
  the other windows), e.g. for
• additional input
• transactions
• explicit confirmation or authorization

38
Example Helpline

• Define views for objects
• Customer
• Too much information for one window. Two
  alternative views
• Query view Customer Name, Site, maintenance,
  Previous queries
• Contact information view address, telephone,
  Fax, ..
• Site
• Single view
• Configuration
• Single view
• Query
• Two large pieces of text, the Event History and
  the Technical History. Will be in two alternative
  views
• Problem
• Single view for all information is sufficient
• Second view needed for Problem Identification.
• Advisor
• Single view

39
Example Helpline

• Define initial windows
• Customer
• Primary object window
• fig 10.9 p 199

Query view
40
Example Helpline

• fig 10.10 p 200

Contacts view
Only one Customer window is needed The Customer
window is dependent upon the Helpline system
window
41
Example Helpline

• Site
• Secondary window , dependent on Customer window,
  only one instance
• fig 10.12 p 201

42
Example Helpline

• Configuration
• Secondary window , dependent on Site window,
  only one instance
• fig 10.13 p 201

43
Example Helpline

• Query
• Primary Object window , dependent upon The
  helpline System Window, only one instance, two
  view options Event History and Technical History
• fig 10.14 p 202

44
Example Helpline

• Problem
• Primary Object window for Problem maintenance
  window, dependent upon The helpline System
  Window, only one instance, Separate view for the
  Problem Identification
• fig 10.15 p 203

45
Example Helpline

• Helpline system
• No root object, but several top-level objects
• fig 10.16 p 204

46
Example Helpline

• Define window navigation
• from customer to Customers queries
• from a query to the customer who raised the
  query
• from a query to the problem which caused the
  query
• from a problem to all the queries caused by this
  problem

Customer
Problem
Query
47
Example Helpline

• Express scenarios as window actions
• Resolve customer query -scenario 1
• Window navigation required for the scenario.
• Query window does not support the users task
  goal to identify the problem as quickly as
  possible

Customer
Open customer
Query
Problem Identification
Customer
48
Example Helpline

• Resolve customer query -scenario 1
• Solution we allow the advisor to navigate
  directly to Problem Identification

Customer
Open customer
Problem Identification
Customer
49
Example Helpline

• Resolve customer query -scenario 1 (cont)
• Revised Version of Problem Identification
  window
• fig 10.21 p 208

50
10. Prototyping
51

• Goal
• To identify usability problems and suggestions
  for improvement.
• To provide feedback on the validity of the task
  model, user model and style guide
• No clear boundary between UI design and UI
  prototyping.
• The same person may do both at the same time

52

• Benefits
• Better communication with the user early
  hands-on experience with UI.
• Improved design through feedback and iteration.
• Reduced risk of unsuitable UI.
• Provides training/learning medium.
• Greater user acceptance.

53

• Risks
• Controlling the process.
• How
• the work for an iteration is over when the
  agreed coverage is achieved and the agreed
  usability levels have been met.
• fixed duration for an iteration. Work is over is
  time is over.
• Prototyping must be planned for
• Managing the expectations of the customer.
• Clear examples of the limitations are required
• Success depends on extensive input of the users.
  Requires knowledge, typical end-users.

54

• Method
• 1. Define prototype objectives
• define the objectives of each prototype iteration
• 2. Choose the prototyping tool
• A throwaway prototype should be cheap
• a flipchart/whiteboard and pens
• a presentation package
• 4GL
• specialized prototyping package (e.g. HyperCard)

Preliminary requirements
Build Prototype
Evaluate Prototype
Yes
Final requirements
No
Adequate?
55

• An incremental prototype
• Overall design, but system partitioned into
  independent components

Identify components
Prototype Component
System complete?
Yes
No
...
56

• An evolutionary prototype
• Actual system evolves from a very limited initial
  version
• requires other tools
• the ability to construct production-quality
  systems
• flexibility

Requirements Definition
Build Prototype
Evaluate Prototype
57

• 3. Build prototype.
• 4. Investigate the prototype
• For each problem/change make a note
• what is the problem
• what solution is proposed
• what decision is made (try in current
  iteration, in next iteration, wait, ...)
• what is the rationale for the decision.
• This log prevent developer from reversing
  previously agreed changes.

58

• Techniques for prototyping
• Storyboards
• Requires no computer resources
• Paper and pencil
• Drawing tool
• Presentation package
• Simulations
• Limited functionality
• Prototyping tools (e.g. HyperCard)
• High level programming

59
Example Helpline

• Define prototyping objectives
• Iteration 1
• To validate overall acceptance of the style guide
• To validate the main windows required, and their
  layout
• To validate the main navigation paths between
  windows
• To validate support for various scenarios of the
  central task
• To support evaluation of expert inspection and
  user walktrough of task scenarios
• .
• Iteration 2
• To validate the detailed window content and
  layout
• To explore usability by allowing the user to
  interact with the windows
• To explore support for monitoring
• To support evaluation by fairly realistic users
  testing

60
Example Helpline (2)

• Define prototyping objectives
• Iteration 3
• To confirm that modifications have resolved
  usability problems
• To support informal exercising of all task
  scenarios
• To support realistic user evaluation
• To achieve planned levels for some usability
  requirements

61
Example Helpline

• Choose the prototyping tools
• Iteration 1
• risk of major rework is high
• Pen and wallchart
• Iteration 2
• Microsoft Visual Basic 3.0, no underlying
  database
• It provides rapid turnaround prototyping
  facilities
• Prototype can evolve into production system
• developers are familiar with it.
• old system is build with it and response times
  were acceptable
• Iteration 3
• evolutionary extension based on prototype 2, with
  a small database

62
Example Helpline

• Prototype 1
• FIG 11.6 p 231

63
Example Helpline

• Prototype 1
• One of the designers outlined the GUI design to
  the Helpline advisors.
• Next walking task scenarios through the
  prototype.
• Re-sketches of some windows.
• Changes
• Configuration window collapsed into the Site
  window (to reduce drilling-down from Customer
  to Site to Configuration)
• Need for several accelerators, e.g. from Query
  window to Customer or Problem.

64
Example Helpline

• Prototype 2 - Customer
• FIG 11.8 p 233

65
Example Helpline

• Prototype 2 - Site
• FIG 11.9 p 234

66
Example Helpline

• Prototype 2 - Query
• FIG 11.10 p 234

67
Example Helpline

• Prototype 2 - Problem Identification
• FIG 11.11 p 235

68
Example Helpline

• Prototype 2 - Advisor
• FIG 11.13 p 236
• fig 11.12 p 235
• fig 11.14 p 237

69
Example Helpline

• Prototype 2
• Problems
• Reallocate query causes problems
• Examine workload too laborious
• Transfer a query too clumsy
• No indicator on the availability of an advisor.
• Too many windows.
• Changes
• Adding an Advisor overview window, including
  vertical bar to show the number of queries for an
  advisor.
• Color codes to show the urgency of a query.

70
Example Helpline

• Prototype 2 - Advisor overview
• FIG 11.15 p 239

71
Example Helpline

• Prototype 3
• Changes
• Adding indicator of the advisors availability.
• Just a single instance of Advisor window current
  advisor is selected by clicking on its picture.
• Vertical bar is changed to horizontal (was
  difficult to read).

72
Example Helpline

• Prototype 3 - Advisor overview
• FIG 11.16 p 240