Module – 5

COLLABORATION AND COMMUNICATION

1. Face-to-face Communication

2. Group Working

3. Dialog Design Notation

4. Dialog Semantics

1
Dialogue Notations and Design
• Dialog is the syntactic level of human–computer
interaction; it is rather like the script of a play, except
the user, and sometimes the computer, has more
choices.

• Dialogue Notations
– Diagrammatic
• state transition networks, JSD diagrams, flow charts
– Textual
• formal grammars, production rules, CSP

• Dialogue linked to
– the semantics of the system – what it does
– the presentation of the system – how it looks

• Formal descriptions can be analysed

– for inconsistent actions
– for difficult to reverse actions
– for missing actions
– for potential miskeying errors
what is dialogue?

• conversation between two or more parties

– usually cooperative

• in user interfaces
– refers to the structure of the interaction
– syntactic level of human–computer ‘conversation’

• levels
– lexical – shape of icons, actual keys pressed (lowest
level)
– syntactic – order of inputs and outputs (grammar of
sentence construction)
– semantic – effect on internal application/data
structured human dialogue

• human-computer dialogue very constrained

• some human-human dialogue formal too …

Minister: do you man’s name take this woman …

Man: I do
Minister: do you woman’s name take this man …
Woman: I do
Man: With this ring I thee wed
(places ring on womans finger)
Woman: With this ring I thee wed (places ring ..)
Minister: I now pronounce you man and wife
lessons about dialogue

• wedding service
– sort of script for three parties
– specifies order
– some contributions fixed – “I do”
– others variable – “do you man’s name …”
– instructions for ring
concurrent with saying words “with this ring …”

• if you say these words are you married?

– only if in the right place, with marriage licence
– syntax not semantics
… and more

• what if woman says “I don’t”?

• real dialogues often have alternatives:

Judge: How do you plead guilty or not guilty?

Defendant: either Guilty or Not guilty

– the process of the trial depends on the defendants

response
dialogue design notations

• dialogue gets buried in the program

• in a big system can we:
– analyse the dialogue:
• can the user always get to see current shopping basket
– change platforms (e.g. Windows/Mac)
– dialogue notations helps us to
• analyse systems
• separate lexical from semantic
• … and before the system is built
– notations help us understand proposed designs
 graphical notations

state-transition nets (STN)

Textual notations
Petri nets
Harel’s state charts
Traditional flow charts
JSD diagrams
State transition networks
(STN)
• It assumes that a dialog essentially refers to a
progression from one state of the system to
the next in the system state space
• The syntax of an STN is simple and consists of
the following two entities
• Circles: a circle in a STN refers to a state of
the system, which is labeled (state name)
• Arcs: the circles are connected with arcs, each
of which refers to the action/event
(represented by arc labels) that results in the
system making a transition from the state
where the arc originates to the state where it
terminates
State transition networks
(STN)
Example:
• Let’s illustrate the idea with an example.
Suppose, we are using a drawing interface
that allows us to draw lines and circles, by
choosing appropriate menu item. To draw a
circle, we need to select a center and
circumference. A line can be drawn by
selecting points on the line. How can we model
this dialog using an STN?
State transition networks
(STN)
• We shall have a “start” state
• From this “start” state, we shall go to a “menu”
state, where we are shown the menu options. If
we select the circle option, we go to a “circle”
state. Otherwise, we select the “line” option and
go to the “line” state
• While at the “circle” state, we select a point as
the circle center (through mouse click, say),
which takes us to the “center” state
• In the “center” state, we select the circle
periphery (through mouse movement, say) and
double click to indicate the end of input (the
“finish” state). At this stage, the circle is
displayed
State transition networks
(STN)
• While at the “line” state, we select a point as the
beginning of the line (through mouse click, say)
• Then, we select another point to denote the last
point on the line and transit to “point 2”. At this
stage, a line is displayed between the two points
• We can select another point, while at “point 2”
to draw another line segment between this point
and the point last selected. We can actually
repeat this as many times as we want, to draw
line of arbitrary shape and size
• When we perform a double click, it indicates the
end of input and the dialog comes to the “finish”
stage
State transition networks
(STN)
• circles - states
• arcs - actions/events
State transition networks -
events
• arc labels a bit cramped because:
– notation is `state heavy‘
– the events require most detail

click on
click on centre circumference
Circle 1 Circle 2 Finish
rubber band draw circle
se lect 'circle'

Start Menu

se lect 'line' click on

first point double click
Line 1 Line 2 Finish
rubber band draw last
line

click on point
draw a line
State transition networks -
states
• labels in circles a bit uninformative:
– states are hard to name
– but easier to visualise

click on
click on centre circumference
Circle 1 Circle 2 Finish
rubber band draw circle
select 'circle'

Star t Men u

select 'line'
... ... ...
Hierarchical STNs

Example:
• Suppose we want to model the dialog for a
menu-based system. There are three menu
items, first one for Graphical system, second
one for a text system and the other for a
paint-like system. Each of these systems has
its own dialog. For example, the paint system
may have the dialog shown in the previous
example. We can model the overall dialog as a
hierarchical STN
Hierarchical STNs

• managing complex dialogues

• named sub-dialogues
Graphics Submenu
select ‘graphics’

Text Submenu
select ‘text’
Main
Menu

Paint Submenu

select ‘paint’
Concurrent dialogues - I
simple dialogue box

Text Style
bold
example italic
underline
Concurrent dialogues - II
three toggles - individual STNs

click on ‘bold’
NO
bold
bold bold

click on ‘italic’
NO
italic
italic italic

click on ‘underline’
NO u’line
u’line underline
Concurrent dialogues - III
bold and italic combined
Text Style
bold
NO click on ‘bold’ bold example italic
style only underline

click click
on on
‘italic’ ‘italic’

italic click on ‘bold’ bold

only italic
Concurrent dialogues - IV
all together - combinatorial explosion
Text Style
NO ‘bold’ bold bold
style only example italic
‘underline’ ‘underline’ underline
‘italic’ ‘italic’
u’line ‘bold’ bold
only u’line

‘italic’ ‘italic’
italic ‘bold’ bold
only italic
‘underline’ ‘underline’

bold
italic ‘bold’ italic
u’line u’line
escapes

• ‘back’ in web, escape/cancel keys

– similar behaviour everywhere
– end up with spaghetti of identical behaviours
• try to avoid this Graphics Submenu ESC
select ‘graphics’
normal
e.g. on high level diagram finish

‘normal’ exit for Text Submenu ESC

each submenu Main
select ‘text’

Menu normal
plus separate finish
escape arc active
‘everywhere’ in submenu Paint Submenu ESC

select ‘paint’ normal

finish
help menus

• similar problems
– nearly the same everywhere
– but return to same point in dialogue
– could specify on STN … but very messy
– usually best added at a ‘meta’ level

click on centre click on circumference

from
Circle 1 Circle 2 Finish
Menu rubber band draw circle

press HELP press HELP

button button

Help Subsystem Help Subsystem

Petri nets
• The formalism was first proposed by Carl Adam Petri
(1962, PhD thesis)
• It is a simple model of dynamic behaviour
• one of the oldest notations in computing!
• flow graph:
– places – a bit like STN states
– transitions – a bit like STN arcs
– counters – sit on places (current state)
• several counters allowed
– concurrent dialogue states
• used for UI specification (ICO at Toulouse)
– tool support – Petshop
Petri nets
A place in a PN can represent the following
• A type of communication medium, like a telephone line,
a middleman, or a communication network

• A buffer: for example, a depot, a queue or a post bin

• A geographical location, like a place in a warehouse,

office or hospital

• A possible state or state condition: for example, the

floor where an elevator is, or the condition that a
specialist is available
Petri nets
Tokens can play the following roles
• A physical object, for example a product, a part, a drug,
a person

• An information object, for example a message, a signal,

a report

• A collection of objects, for example a truck with

products, a warehouse with parts, or an address file

• An indicator of a state, for example the indicator of the

state in which a process is, or the state of an object

• An indicator of a condition: the presence of a token

indicates whether a certain condition is fulfilled
Petri nets
A transition can be used to represent things such as
• An event (e.g., starting an operation, the switching of a
traffic light from red to green)

• A transformation of an object, like adapting a product,

updating a database, or updating a document

• A transport of an object: for example, transporting

goods, or sending a file
Petri nets
• Connections are directed

• No connections between two places or two transitions is

allowed

• Places may hold zero or more tokens

• A transition is enabled if each of its input places

contains at least one token

• An enabled transition can fire (i.e., it occurs)

• When it fires it consumes a token from each input place

and produces a token for each output place
Typical Petrinet Structures
Typical Petrinet Structures
Typical Petrinet Structures
Typical Petrinet Structures
Typical Petrinet Structures
Typical Petrinet Structures
Typical Petrinet Structures
Typical Petrinet Structures
Petri net Example: Two Traffic
Lights
Petri net Example: Two Traffic
Lights
Petri net example
 Petri net Practice Assignment
Construct a petri net model based on the following specification:

There are four philosophers sitting around a round table. There

are forks on the table, one between each pair of philosophers.
The philosophers want to eat spaghetti from a large bowl in the
center of the table. Unfortunately the spaghetti is of a
particularly slippery type, and a philosopher needs both forks in
order to eat it. The philosophers have agreed on the following
protocol to obtain the forks:

Initially philosophers think about philosophy, when they get

hungry they do the following: (1) take the left fork, (2) take the
right fork and start eating, (3) return both forks simultaneously,
and repeat from the beginning
Petri net Practice Assignment
State charts

• used in UML
• extension to STN
– hierarchy
Standby

– concurrent sub-nets ON OFF

– escapes
RESET

• OFF always active Sound Channel

– history 1
H
• link marked H On SEL

goes back to last

2
MUTE
SEL
state on re-entering
SEL
Off 3
subdialogue SEL

4
Flowcharts

• Flowcharts are schematic representations of

the interactive flow of a program.
• All possible user interaction pathways,
expressed through labelled boxes and
directional arrows, are traced through any
hierarchical menu tree structures and along
various screen branches.
• Gives shape and structure to the content so
people can get a sense of how the real product
might work
Flowcharts

• Three forces drive the design of the flowchart:

– Content: The organisation and structure
mapped out for the information
– Usability: The topic categories and access
routes the audience will expect to find
– Simplicity: The need to keep the design
clear and focused, to control production
time & costs
 Flowcharts
• Preferred Interaction
Model (PIM ) - “A PIM
is a type of flow
diagram that represents
the user’s probable
decisions, cognitive
processes, and
actions.”
• PIM for a phone
number retrieval
interface of a contact
database application
Flowcharts
Delete D1
Please enter
employee no.: ____

• familiar to C1
read record

programmers
• boxes Delete D2 Delete D3

- process/event
Name: Alan Dix Name: Alan Dix
Dept: Computing Dept: Computing
delete? (Y/N): _ delete? (Y/N): _

- not state
Please enter Y or N

• use for dialogue answer?

C2 other

(not internal algorithm)

Y N Finish
C3
delete record

Finish
it works!

• formal notations – too much work?

• COBOL transaction processing
– event-driven – like web interfaces
– programs structure
Delete D1

Please enter
employee no.: ____

≠ dialogue structure
• used dialogue flow charts
C1
read record

– discuss with clients Delete

Name: Alan Dix
D2 Delete D3

delete? (Y/N): _

– transform to code
Dept: Computing Please enter Y or N
delete? (Y/N): _

– systematic testing answer?

C2

other

– 1000% productivity gain Y N Finish

C3

• formalism saves time!! delete record

Finish
JSD diagrams
• Jackson structured design (JSD), while not as
old as flow charts.

• The JSD diagram, which has been used for

various aspects of task analysis and dialog
design.

• A JSD diagram for the top-level structure of an

employee personnel system.

• The system allows the user to update the

personnel record in various ways: adding new
employees, displaying, altering and removing
existing ones.
JSD diagrams

• for tree structured dialogues

– less expressive
Personnel
– greater clarity Record
System

login transaction
* logout

add change display delete

employee employee employee employee
record record record record
JSD diagrams
• Look at the top of the diagram, the personnel
system is decomposed into three parts: login,
transactions and logout.
• The login and logout are assumed to be quite
simple, so the diagram only expands the
transaction node.
• Under this are listed the various transaction
types: add, change, display and delete.
• Some of the boxes have a little asterisk or
‘o’ in their top right-hand corner. Without
these decorations the diagram would
represent a system which allowed you to log
in, then add, change, display and delete once
each in that order, and then logout.
JSD diagrams
• The asterisk represents iteration – any
number of repetitions, i.e., the dialog can
consist of a login followed by any number of
transactions before the logout.
• The little ‘o’ represents optional elements.
That is, a transaction may be any one of the
four options.
• Taking the decorations into account, the
diagram describes a login followed by any
number of add, change, display or delete
transactions, and finally a logout.
• The class of dialogs which can be represented
by simple JSD diagrams is rather limited, but
includes many basic menu-driven information
 textual notations

grammars
production rules
CSP and event algebras
Textual - Grammars

• Regular expressions
sel-line click click* dble-click
• compare with JSD
• same computational model
• different notation
• BNF (Backus-Naur Form)
expr ::= empty
| atom expr
| '(' expr ')' expr
• more powerful than regular exp. or STNs
• Still NO concurrent dialogue
Production rules

• Unordered list of rules:

if condition then action

– condition based on state or pending events
– every rule always potentially active

• Good for concurrency

• Bad for sequence
Event based production rules

Sel-line  first
C-point first  rest
C-point rest  rest
D-point rest  < draw line >

• Note:
– events added to list of pending events
– ‘first’ and ‘rest’ are internally generated events
• Bad at state!
Prepositional Production System
Prepositional Production System

• The first attribute, Mouse, is set automatically whenever the user

performs the relevant action; the second attribute is used by the dialog
to keep track of its state, and the last three are for controlling system
responses.

• The rules are executed again, when the condition matches the state,
but, this time, the attributes are not changed by this alone. Only when a
new value is set for a particular attribute is the old value lost.
• For example, in the second rule, the action ‘rest-line’ sets the Line-
state attribute, thus removing the previous value of ‘startline’.
• Notice, that in the third rule, the value ‘rest-line’ of the attribute Line-
state need not be mentioned in the action as it was in the event-based
rules.
Grammers
Event Algebra / Process Calculi
CSP and process algebras

• used in Alexander's SPI, and Agent notation

• good for sequential dialogues
Bold-tog = select-bold?  bold-on  select-bold? 
bold-off  Bold-tog
Italic-tog = . . .
Under-tog = . . .

• and concurrent dialogue

Dialogue-box = Bold-tog || Italic-tog || Under-tog

• but causality unclear

Dialogue Notations -
Summary
• Diagrammatic
• STN, JSD, Flow charts
• Textual
• grammars, production rules, CSP
• Issues
• event base vs. state based
• power vs. clarity
• model vs. notation
• sequential vs. concurrent
Semantics Alexander SPI (i)

• Two part specication:

• EventCSP - pure dialogue order
• EventISL - target dependent semantics

• dialogue description - centralised

• syntactic/semantic trade-off - tollerable

• The description is built using four symbols

– ‘=’ meaning definition,
– ‘→’ event sequence (or guard),
– ‘;’ process sequence and
– [] choice.
 Semantics Alexander SPI (ii)
• EventCSP
Login = login-mess -> get-name -> Passwd
Passwd = passwd-mess -> (invalid -> Login [] valid -> Session)

• EventISL
event: login-mess
prompt: true
out: “Login:”
event: get-name
uses: input
set: user-id = input
event: valid
uses: input, user-id, passwd-db
wgen: passwd-id = passwd-db(user-id)
 Semantics Alexander SPI (ii)
• The CSP description is as follows:
Draw-menu = ( select-circle? → Do-circle []
select-line? → Do-line )
Do-circle = click? → set-center → 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 )
 Semantics Alexander SPI (ii)
• The CSP description is as follows:
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
Semantics - raw code

• event loop for word processor

switch ( ev.type ) {
case button_down:
• dialogue description if ( in_text ( ev.pos ) ) {
- very distributed mode = selecting;
mark_selection_start(ev.pos);
}
• syntactic/semantic trade-off ...
case button_up:
- terrible! if ( in_text ( ev.pos )
&& mode == selecting ) {
mode = normal;
mark_selection_end(ev.pos);
}
...
case mouse_move:
if (mode == selecting ) {
extend_selection(ev.pos);
}
...
} /* end of switch */
Action properties

• completeness
• missed arcs
• unforeseen circumstances
• determinism
• several arcs for one action
• deliberate: application decision
• accident: production rules
• nested escapes
• consistency
• same action, same effect?
• modes and visibility
Checking properties (i)

• completeness
– double-click in circle states?
double
?
click
click on
click on centre circumference
Circle 1 Circle 2 Finish
rubber band draw circle
se lect 'circle'

Start Menu

se lect 'line' click on

first point double click
Line 1 Line 2 Finish
rubber band draw last
line

click on point
draw a line
Checking properties (ii)
select 'circle'
... ... ...
Start Menu

select 'line' click on

• Reversibility: first point double click

Line 1 Line 2 Finish
rubber band draw last
line
– to reverse select `line' click on point
draw a line

Graphics Sub-menu
select 'graphics'

Main
Menu
select 'text' ... ... ...
... ... ...
select 'paint'
Checking properties (ii)
select 'circle'
... ... ...
Start Menu

select 'line' click on

• Reversibility: first point double click

Line 1 Line 2 Finish
rubber band draw last
line
– to reverse select `line' click on point
draw a line
– click

Graphics Sub-menu
select 'graphics'

Main
Menu
select 'text' ... ... ...
... ... ...
select 'paint'
Checking properties (ii)
select 'circle'
... ... ...
Start Menu

select 'line' click on

• Reversibility: first point double click

Line 1 Line 2 Finish
rubber band draw last
line
– to reverse select `line' click on point
draw a line
– click - double click

Graphics Sub-menu
select 'graphics'

Main
Menu
select 'text' ... ... ...
... ... ...
select 'paint'
Checking properties (ii)
select 'circle'
... ... ...
Start Menu

select 'line' click on

• Reversibility: first point double click

Line 1 Line 2 Finish
rubber band draw last
line
– to reverse select `line' click on point
draw a line
– click - double click - select `graphics'
– (3 actions)
Graphics Sub-menu
• N.B. not undo select 'graphics'

Main
Menu
select 'text' ... ... ...
... ... ...
select 'paint'
State properties

• reachability
• can you get anywhere from anywhere?
• and how easily

• reversibility
• can you get to the previous state?
• but NOT undo

• dangerous states
• some states you don't want to get to
Dangerous States

• word processor: two modes and exit

F1 - changes mode
F2 - exit (and save)
Esc - no mode change

Esc

F1 F2
edit menu exit

but ... Esc resets autosave

Dangerous States (ii)
• exit with/without save  dangerous states
• duplicate states - semantic distinction

F1 F2
edit menu exit

any Esc
update

F1 F2
edit menu exit
F1-F2 - exit with save
F1-Esc-F2 - exit with no save Esc
Lexical Issues

• visibility
• differentiate modes and states
• annotations to dialogue
• style
• command - verb noun
• mouse based - noun verb
• layout
• not just appearance ...
layout matters

• word processor - dangerous states

F1 F2
edit menu exit

any Esc
update

• old keyboard - OK F1 F2
edit menu exit

Esc
Esc 1

tab ...
F1 F2
...
F3 F4
... ...
layout matters

• new keyboard layout

Esc F1 F2 F3 ...
intend F1-F2 (save) F1 F2
edit menu exit

finger catches Esc

any Esc
update

F1 F2
edit menu exit

Esc
layout matters

• new keyboard layout

Esc F1 F2 F3 ...
intend F1-F2 (save) F1 F2
edit menu exit

finger catches Esc

any Esc
update
F1-Esc-F2 - disaster! F1 F2
edit menu exit

Esc
Dialogue Analysis - Summary

• Semantics and dialogue

• attaching semantics
• distributed/centralised dialogue description
• maximising syntactic description

• Properties of dialogue
• action properties: completeness, determinism,
consistency
• state properties: reachability, reversibility, dangerous
states

• Presentation and lexical issues

• visibility, style, layout
• N.B. not independent of dialogue
Dialogue Analysis - Summary

• Semantics and dialogue

• attaching semantics
• distributed/centralised dialogue description
• maximising syntactic description

• Properties of dialogue
• action properties: completeness, determinism,
consistency
• state properties: reachability, reversibility, dangerous
states

• Presentation and lexical issues

• visibility, style, layout
• N.B. not independent of dialogue
Digital watch – User
Instructions
Time display Stop watch

S MT W T F S S MT W T F S

• two main modes A STP

• limited interface
- 3 buttons Depress
button A
A A for 2 seconds

• button A
changes mode
S MT W T F S S MT W T F S

SET A ALM

AM

Time setting Alarm setting

Digital watch – User
Instructions
Time display Stop watch

S MT W T F S S MT W T F S

• dangerous states A STP

• guarded
… by two second hold
Depress
button A
A A
• completeness for 2 seconds

• distinguish depress A S MT W T F S S MT W T F S

and release A SET A ALM

• what do they do AM

in all modes? Time setting Alarm setting

Digital watch – Designers
instructions Time display Stop watch

S MT W T F S S MT W T F S

STP

and ... Depress A

Release A Release A

that’s just
S MT W T F S S MT W T F S

STP

one button

Depress A 2 seconds 2 seconds

S MT W T F S S MT W T F S
Release A Release A
SET Depress A ALM

AM

Time setting Alarm setting

Practice Question

• Draw a “state chart diagram” for the scenario given below:

In an online shopping website the customer browses the
catalog and selects items he wants to buy. Customer goes to
check out the items based on the price. Customer enter the
shipping information where need to be delivered. Customer can
choose the payment mode (Debit Card/Credit Card/Net
banking/eWallet) and purchase the items. The system would
authorize the purchase. Then, system confirms the sale of
chosen item immediately. Finally system sends the confirmation
email to a customer.
Practice Question
• Draw a JSD for the below specification:
– Link: https://vtopbeta.vit.ac.in/vtop/
– If the credentials are valid, the user will be able to access the
account
– But if the user forgets the password he/she can click “forgot”
which will lead to the following chain of events( Ignore other
options on the page)
– User is asked to enter id number or email address. On clicking
next,
– User is asked to enter OTP /barcode on his/her id card.
– On clicking next, a text message will be send to user, which
contains the password reset code. User has to enter the password
reset code received, new password and confirm new password by
re-entering it.
– On clicking next, it goes to login page for new login.
Practice Question
• Create a textual dialog notation using regular expression for
(i) drawing a polygon
(ii) validating a password as weak, average and strong (fix your own
password constraints)