CSE 3345
User interface design
A software engineering perspective
Chapter 3: Data Presentation
1
Gestalt Laws
• A gestalt …
– is anything we perceive as a unit or an object.
– is a technique the mind uses to manage complexity
• The law of proximity states that pieces that are close
together are perceived as belonging together.
• The law of closure states that the area inside a closed
line is perceived as a shape.
• The law of good continuation states that pieces on a
smooth line are perceived as belonging together.
• The law of similarity states that things that look alike are
perceived as belonging together.
– Colors are often used to signal similarity
• The law of parallel movement states that things that
move in parallel are perceived as belonging together.
2
Fig 3.1A Three gestalt laws
Example A:
Law of proximity
Example C:
Law of closure
Example B: Mill wheels
Law of proximity
Example D:
Law of good continuation
3
Fig 3.1B Closure versus continuation
Example E:
Law of good continuation
Example F:
Law of closure?
4
Fig 3.1C Law of similarity and other gestalt laws
Example G
Example H
Law of parallel movement
Law of . . .
5
(Fig 3.1D) Similar colors create gestalts
Example I
Legal moves
Dangerous positions
6
Fig 3.2A How does the Law of lines apply, or does it?
A
•
•
B
C
A variation on the law of good continuation is known as the law of lines.
The law of lines states that aligned items are perceived as belonging
together.
7
Fig 3.2B Laws of proximity and closure at work
D
E
• Does the Print Range frame in example E improve
understandability?
• What does placing the OK button inside of the Print Range frame
accomplish?
8
Text Gestalts
9
Fig 3.3A Column gestalts
Introduction & Basic Concepts
The role of requirements
Project types
Contents of the specification
Problems observed in practice
Domain level and product level
The goal–design scale
Typical project models
Data requirement styles
The hotel system example
The data model
Data dictionary
Data expressions
Virtual windows
Functional requirement styles
Human/computer – who does what?
Context diagrams
Event list and function list
7
8
11
13
16
18
20
24
30
30
30
37
39
42
45
45
46
47
Functional details
Complex and simple functions
Tables and decision tables
Textual process descriptions
State diagrams
State-transition matrices
Activity diagrams
Class diagrams
Collaboration diagrams
Sequence diagrams
Special Interfaces
Reports
Platform requirements
Product integration – ordinary customers
Product integration – main contractor
Technical interfaces
Quality requirements
Quality Factors
• Which page number goes with which section?
• Why is it difficult to tell?
• What Gestalt laws are at work here?
85
85
88
90
92
94
95
98
102
103
107
107
108
110
114
115
117
118
10
(Fig 3.3A Cont.)
Introduction & Basic Concepts ------------ 7
The role of requirements -------------------------- 8
Project types----------------------------------------11
Contents of the specification---------------------13
Problems observed in practice -------------------16
Domain level and product level -----------------18
The goal–design scale-----------------------------20
Typical project models----------------------------24
Data requirement styles ---------------------30
The hotel system example ------------------------30
The data model-------------------------------------30
Data dictionary-------------------------------------37
Data expressions -----------------------------------39
Virtual windows -----------------------------------42
Functional requirement styles ------------45
Human/computer – who does what?------------45
Context diagrams ----------------------------------46
Event list and function list------------------------47
Functional details------------------------------85
Complex and simple functions ------------------85
Tables and decision tables------------------------88
Textual process descriptions ---------------------90
State diagrams--------------------------------------92
State-transition matrices --------------------------94
Activity diagrams----------------------------------95
Class diagrams -------------------------------------98
Collaboration diagrams ------------------------- 102
Sequence diagrams ------------------------------ 103
Special Interfaces---------------------------- 107
Reports -------------------------------------------- 107
Platform requirements -------------------------- 108
Product integration – ordinary customers---- 110
Product integration – main contractor -------- 114
Technical interfaces ----------------------------- 115
Quality requirements ----------------------- 117
Quality Factors----------------------------------- 118
• Which page number goes with which section?
• Is it difficult to tell? Why not?
• What Gestalt laws are at work here?
11
(Fig 3.3A Cont. 2)
Introduction & Basic Concepts ------------ 7
The role of requirements
8
Project types
11
Contents of the specification
13
Problems observed in practice
16
Domain level and product level
18
The goal–design scale
20
Typical project models
24
Data requirement styles
30
The hotel system example
30
The data model
30
Data dictionary
37
Data expressions
39
Virtual windows
42
Functional requirement styles
45
Human/computer – who does what?
45
Context diagrams
46
Event list and function list------------------------47
Functional details------------------------------85
Complex and simple functions
85
Tables and decision tables
88
Textual process descriptions
90
State diagrams
92
State-transition matrices
94
Activity diagrams
95
Class diagrams
98
Collaboration diagrams
102
Sequence diagrams
103
Special Interfaces
107
Reports
107
Platform requirements
108
Product integration – ordinary customers
110
Product integration – main contractor
114
Technical interfaces
115
Quality requirements
117
Quality Factors----------------------------------- 118
• Which page number goes with which section?
• Is it difficult to tell? Why not?
• What Gestalt laws are at work here?
12
Fig 3.3B Heading proximity
1
2
3
4
5
6
7
8
9 10 11 12
Sales of X-mas trees
There is a strong seasonal variation
in the sales of . . .
Picture caption
or heading?
•
•
1
2
3
4
5
6
7
8
9 10 11 12
Sales of X-mas trees
There is a strong seasonal variation
in the sales of . . .
No doubt
What is Sales of X-mas trees describing?
Is it difficult to tell? Why?
13
Fig 3.3C Paragraph Gestalts - Body text
1
•
•
This report is intended to provide background
information which will facilitate the development of
procedures and tools to improve the tware producers to
manage and control software quality and to demonstrate
the achievement of software quality requirements.
The report surveys published work relating to the
identification and specification of software quality
characteristics, metrics relating to them, and inferences
which can be drawn from the metrics. It does not attempt,
however, to evaluate the published work to any great
extent. It notes the ure, and identifies uality Management
project. In summarising such large works it has not been
possible to cover all the material, and the serious student
may need to refer to the originals for further details.
Boehm et al's book entitled "Characteristics of
Software Quality" reports on work done in the early
seventies and is a precursor not only or McCall et al's
work but also of Gilb's. The initial objectives of the study
were to identify a set of characteristics of software quality,
and for each characteristic to aimed at measuring the
degree to which a program possesses the characteristic and
hence provide an overall software quality assessment.
(Boehm et al soon abandoned the idea of an overall
quality since they argued that the quality requirements for
a given product will vary with the needs and priorities of
the user, so there could be no single universally useful
rating of software quality. They concluded that metrics
would be best used as anomaly indicators - ie to note that
an item of software differed from the normal pattern in a
way that might be symptomatic of quality problems.)
2
This report is intended to provide background
information which will facilitate the development of
procedures and tools to improve the ability of software
producers to manage and control software quality and to
demonstrate the achievement of software quality
requirements and improve the control software.
The report surveys published work relating to the
identification and specification of software quality
characteristics, metrics relating to them, and inferences
which can be drawn from the metrics. It does not attempt,
however, to evaluate the published work to any great
summarising such large works it has not been possible to
cover all the material, and the serious student may need to
refer to the originals for further details defin place.
Boehm et al's book entitled "Characteristics of
Software Quality" reports on work done in the early
seventies and is a precursor not only or McCall et al's
work but also of Gilb's. The initial objectives of the study
were to identify a set of characteristics of software quality,
and for each characteristic to identify one or more metrics
aimed at measuring the degree to which a program
possesses the characteristic and hence provide an overall
software quality assessment.
(Boehm et al soon abandoned the idea of an overall
quality since they argued that the quality requirements for
a given product will vary with the needs and priorities of
the user, so there could be no single universally useful
rating of software quality. They concluded that metrics
would be best used as anomaly indicators - ie to note that
an item of software differed from the normal pattern in a
way that might be symptomatic of quality problems.)
Discuss the clarity of the gestalts in each example.
What contributes to the gestalt clarity or lack of in each example?
14
(Fig 3.3C Cont.)
3
This report is intended to provide background information which will facilitate the
development of procedures and tools to improve the ability of software producers to
manage and control software quality and to demonstrate the achievement of software
quality requirements.
The report surveys published work relating to the identification and specification of
software quality characteristics, metrics relating to them, and inferences which can be
drawn from the metrics. It does not attempt, however, to evaluate the published work to
any great extent. It notes the existence of relevant software tools referred to in the
literature, and identifies areas of work which might be pursued further within Testing
Specification and Quality Management project. In summarising such large works it has
not been possible to cover all the material, and the serious student may need to refer to
the originals for further details.
Boehm et al's book entitled "Characteristics of Software Quality" reports on work done
in the early seventies and is a precursor not only or McCall et al's work but also of
Gilb's. The initial objectives of the study were to identify a set of characteristics of
software quality, and for each characteristic to identify one or more metrics aimed at
measuring the degree to which a program possesses the characteristic and hence
provide an overall software quality assessment.
Clear gestalts
but lines too long.
Annoying to read???
(Boehm et al soon abandoned the idea of an overall quality since they argued that the
quality requirements for a given product will vary with the needs and priorities of the
user, so there could be no single universally useful rating of software quality. They
concluded that metrics would be best used as anomaly indicators - ie to note that an
item of software differed from the normal pattern in a way that might be symptomatic
of quality problems.)
•
•
Discuss the clarity of the gestalts in the example.
What contributes to the gestalt clarity in the example?
15
Line Length
• Retracing is when the eves move back to the beginning
of the next line.
– Long lines have an adverse effect on retracing.
• Saccades is a jump of the eyes across a line that is
being read.
– Words cannot be read during the jump, only after the eyes have
settled.
– Eyes must stop around every 15-20 characters
– The more stops per line the more difficult it is to read
– See Fig 3.3C on the previous slide
• “Modern computer screens have space for very long
lines, and designers are tempted to utilize the space by
means of long lines. This is one of the reasons that
texts are much harder to read on the screen than on
paper.”
16
Fig 3.3D Line length, A4 or Letter paper
Which format is best, or does it really mater?
100 pages
This report is intended to provide background information which will facilitate the
development of procedures and tools to improve the ability of software producers to
manage and control software quality and to demonstrate the achievement of software
quality requirements.
83 pages
This report is intended to provide background information which will facilitate the
development of procedures and tools to improve the ability of software producers to
manage and control software quality and to demonstrate the achievement of
software quality requirements.
The report surveys published work relating to the identification and specification of
software quality characteristics, metrics relating to them, and inferences which can
be drawn from the metrics. It does not attempt, however, to evaluate the published
work to any great extent. It notes the existence of relevant software tools referred to
in the literature, and identifies areas of work which might be pursued further within
Testing Specification and Quality Management project. In summarising such large
works it has not been possible to cover all the material, and the serious student may
need to refer to the originals for further details.
The report surveys published work relating to the identification and specification of
software quality characteristics, metrics relating to them, and inferences which can
be drawn from the metrics. It does not attempt, however, to evaluate the published
work to any great extent. It notes the existence of relevant software tools referred to
in the literature, and identifies areas of work which might be pursued further within
Testing Specification and Quality Management project. In summarising such large
works it has not been possible to cover all the material, and the serious student may
need to refer to the originals for further details.
Boehm et al's book entitled "Characteristics of Software Quality" reports on work
done in the early seventies and is a precursor not only or McCall et al's work but
also of Gilb's. The initial objectives of the study were to identify a set of
characteristics of software quality, and for each characteristic to identify one or
more metrics aimed at measuring the degree to which a program possesses the
characteristic and hence provide an overall software quality assessment.
Boehm et al's book entitled "Characteristics of Software Quality" reports on work
done in the early seventies and is a precursor not only or McCall et al's work but also
of Gilb's. The initial objectives of the study were to identify a set of characteristics
of software quality, and for each characteristic to identify one or more metrics aimed
at measuring the degree to which a program possesses the characteristic and hence
provide an overall software quality assessment.
(Boehm et al soon abandoned the idea of an overall quality since they argued that
the quality requirements for a given product will vary with the needs and priorities
of the user, so there could be no single universally useful rating of software quality.
They concluded that metrics would be best used as anomaly indicators - ie to note
that an item of software differed from the normal pattern in a way that might be
symptomatic of quality problems.)
(Boehm et al soon abandoned the idea of an overall quality since they argued that the
quality requirements for a given product will vary with the needs and priorities of the
user, so there could be no single universally useful rating of software quality. They
concluded that metrics would be best used as anomaly indicators - ie to note that an
item of software differed from the normal pattern in a way that might be
symptomatic of quality problems.)
Simple reports:
12 point text.
3.5 cm margins.
Complex reports:
10 point text.
3.5 + 6 cm margins.
64 pages
This report is intended to provide background
information which will facilitate the development of
procedures and tools to improve the ability of software
producers to manage and control software quality and to
demonstrate the achievement of software quality
requirements.
The report surveys published work relating to the
identification and specification of software quality
characteristics, metrics relating to them, and inferences
which can be drawn from the metrics. It does not
attempt, however, to evaluate the published work to any
great extent. It notes the existence of relevant software
tools referred to in the literature, and identifies areas of
work which might be pursued further within Testing
Specification and Quality Management project. In
summarising such large works it has not been possible to
cover all the material, and the serious student may need
to refer to the originals for further details.
Boehm et al's book entitled "Characteristics of Software
Quality" reports on work done in the early seventies and
is a precursor not only or McCall et al's work but also of
Gilb's. The initial objectives of the study were to identify
a set of characteristics of software quality, and for each
characteristic to identify one or more metrics aimed at
measuring the degree to which a program possesses the
characteristic and hence provide an overall software
quality assessment.
Classical rules:
Max 12.5 cm line.
Max 65 chars/line.
(Boehm et al soon abandoned the idea of an overall
quality since they argued that the quality requirements for
a given product will vary with the needs and priorities of
the user, so there could be no single universally useful
rating of software quality. They concluded that metrics
would be best used as anomaly indicators - ie to note that
an item of software differed from the normal pattern in a
way that might be symptomatic of quality problems.)
Tech documents:
10 point text.
2 cols + 2 cm margins.
17
Contrasts
• Contrasts are used to call attention to something on the
screen.
• Typically we think of using color to create contrasts but
there are other techniques as well.
• The concept of foreground and background are central
to creating contrast.
• The thing in the foreground is what our attention should
be centered on.
• Rule of Thumb: Use contrasts and emphasis sparingly
within a screen or the effect is lost and the screen
becomes too busy.
18
Fig 3.4A Using Contrasts to Call Attention to Something
Form
Size, thickness, or 3-D
mm dmsm sp ab anem a tts, to fmst
saåfprs fer s frfi smfe skf org s fp4et
gsæ fgtær mm dmsm sp ab anem a tts,
to fmst saåfprs fer s frfi smfe skf org s
fp4et gsæ fgtær mm dmsm sp.
ab anem fmst saåfprs fer
Shape contrasts: o
forms a background
to x. The many vs.
the few.
Color or darkness
s frfi smfe skf org s fp4et gsæ fgtær
mm dmsm sp ab anem a tts, to fmst
saåfprs fer s frfi smfe skf org s fp4et
gsæ fgtær mm dmsm sp ab anem a tts,
to fmst saåfprs fer s frfi smfe skf org s
fp4et gsæ fgtær mm dmsm sp ab anem
a tts, to fmst saåfprs fer s frfi smfe skf
org s fp4et gsæ
The many form the
backdrop to the few.
Flash or movement
(intense)
mm dmsm sp ab anem
a tts, to fmst saåfprs
fer s frfi smfe skf org.
Tts to fer s frfi smfe skf
Org s fp4et gsæ fgtær
mm dmsm sp ab anem
a tts, to fmst saåfprs
fer s frfi smfe skf org s
fp4et gsæm dmsm
19
Fig 3.4B How many points earned?
•
The most important piece of
information on the form is
Total Points for use 42700.
•
Is the most important
information also the most
conspicuous? Why or why
not?
20
Presentation Formats
• A particular instance of information may be presented to
the user in a variety of formats.
• The challenge is to choose the format that will best
simplify the users job.
21
Fig 3.5A Room data
Classical “form” format
Room form
Room no.
011
Beds
2
Bath
full
Balcony
no
Seaview
no
Occupied
Prices
high med
low
Normal
88
80
58
As single
68
60
49
Last renovated
20-08-03
21-08-03, 22-08-03, 31-08-03, 01-09-
• Good for showing exact values.
• Easy to understand format. Just like pencil and
paper format
• Not a good way to show massive amounts of data.
22
(Fig 3.5A Cont.)
List or table format
Prices
high med
low
88
80
58
Room states from 30-08-03 to 01-09-03 Normal
As single
68
60
49
Room Beds Bath
State Date
Balcony
no
011
2
full
occ
30-08-03
no
011
2
full
occ
31-08-03 Seaview
012
1
toil
book
30-08-03 Last renovated 20-08-03
012
1
toil
book
31-08-03
012
1
toil
book
01-09-03
Detail window
013
2
toil
book
30-08-03
for selected item
013
2
toil
repair 31-08-03
• Good for showing exact values.
• Good way to show massive amounts of data.
• May optionally drill into selected item for more
detail on a pop-up window.
23
(Fig 3.5A Cont. 2)
Room states from 30-08-03 to 01-09-03
Room Beds
011
2
011
2
012
1
012
1
012
1
013
2
013
2
Bath
full
full
toil
toil
toil
toil
toil
State
occ
occ
book
book
book
book
repair
Date
30-08-03
31-08-03
30-08-03
31-08-03
01-09-03
30-08-03
31-08-03
Prices
high med
low
Normal
88
80
58
As single
68
60
49
Balcony
no
Seaview
no
Last renovated
• Same as before but with an adjoining
detail window.
• Which format is better, pop-up detail
window or adjoining detail window?
20-08-03
Details shown in
adjoining frame
24
Fig 3.5B Room status
Matrix format
Rooms
11 double, bath
12 single, toil
13 double, toil
Prices
80 60
60
60 50
7/8 8/8 9/8 10/8
O B
O O B B
B B B
• Matrix format provides a better overview
of when each room is free
• O = open room
• B = booked room
• Providing scroll bars and an optional
pop-up detail window would be a nice
enhancement.
25
Fig 3.5B Room status
• Map format provides a better way of assigning
rooms in close proximity to each other or some
other part of the motel.
• Effective use of color coding.
Prices
Map format
Room states from 30-08-03 to 01-09-03
011
013
015
017
019
high med
Normal
88
80
58
As single
68
60
49
Beds
2
Bath
full
Last renovated
012 014 016
018
020
022 024
low
20-08-03
Detail window
for selected item
26
Fig 3.5C Hierarchy presentations
Explorer tree
Detail window
• Good for visualizing whole/part (composition) relationships and
managing complexity
• Widely understood format thanks to Windows Explorer
27
(Fig 3.5C Cont.)
E-mail folders
Hierarchical menus
28
Fig 3.5D Business history (1)
Matrix
1996
Customer satisfact
7
Employee satisfact
6
Sales
12.5
Profit
2.7
...
Line graph
1997
8
4
14.5
1.9
1998
9
8
15.8
0.8
3-D surface
Sales
Cust.
Empl.
Profit
96
97
98
29
Fig 3.5E Business history (2)
Cust.
Cust.
98
Sales
Radar
chart
Bubble
diagram
97
Empl.
98
8
97
96
4
Profit
5
10
Sales
Cust.
Cust.
Parallel
coordinates
10
Sales
20
Empl.
10
Profit
Profit
5
Sales
96
97
Empl.
Chernoff
faces
1996
98
1997
1998
30
Fig 3.5F Analog numbers
Current:
62 A
Alarm limit: 80 A
Note on . . .
pz vsv dv sv vc d g s aps gsgp
pg fap af f oa feeg vsæmv
æsdf 9e pzc er f fsdgrg
wsdlfgs g spf jfgdfpg jsdfg
sdp osg sdf sfo psfd sgog
spodg pfg fog psdfg ds
gspggisdgi rsgi spdg segpso
gspgspg pseg spgdsp 0ge
p0sg0 seg0s0ge0s v ek v eeot
s gsdg sg igrtit o s osigisdjg
Belgrave
Martin ct
Screen shows
most of the doc.
BG
Monitoring
high-speed trains
AH
AP
Thesis
TG
KN
DH
RR
pz vsv dv sv vc d g s aps gsgp
pg fap af f oa feeg vsæmv
æsdf 9e pzc er f fsdgrg
wsdlfgs g spf jfgdfpg jsdfg
sdp osg sdf sfo psfd sgog
spodg pfg fog psdfg ds
gspggisdgi rsgi spdg segpso
gspgspg pseg spgdsp 0ge
p0sg0 seg0s0ge0s v ek v eeot
s gsdg sg igrtit o s osigisdjg
Screen shows
a small part
of the doc.
31
Text Form versus Analog Form
• Text format provides detailed information
– Requires our full attention to understand what is being shown
– View specific values
– Controlled Activity: Requires our full attention. For example, we
cannot read and listen to someone speak at the same time.
• Analog format provides general information
–
–
–
–
Analog information can be viewed at a glance
Good for viewing trends over time
Pattern oriented
Automatic Activity: Does not require out full attention. Foe
example, we can listen to music and carry on a conversation at
the same time.
32
Overview of Complex Data
• Large amounts of complex data best represented on a
computer screen by some sort of graphical (analog)
representation
– Essential features of the data can be viewed at a glance
– Observation of detailed information requires a concentrated
effort
33
Fig 3.7A Planning screens for classroom allocation
Class: ITM 101
Mo
Progr
JS13 *
Progr
N4059
Weeks 2-6, 10-16
Tu
1
2
3
4
5
6
7 FinAcc
8 J113
9
10
We
Fr
Progr
J113
Sa
Progr tut
***
5-16
Weeks 2-6, 10-16
Room: J113
Mo
1 ITM 201
2 2-6, 15...
3
4
5 ***
6 ***
7 ITM 101
8 1-4, 7 ...
9
10
Th
Org.
J113
Focus is on a
single
classroom
Tu
MBA 213
2-17, ...
***
***
ITM 301
***
***
We
***
***
***
***
***
***
***
ITM 202
***
***
Th
ITM 101
1-16
***
***
***
***
***
***
***
Fr
Sa
ITM 101
1-16
MAM 101
2-16
MBA 214
9, 10
BDA
14
Both screens
combine
overview and
detail
Focus is on a
single class
34
Fig 3.7B Datamodel for classroom allocation
Activity
Line
Class
activity
Request
Building
wish
Building
Contract
period
Request
hour
Room
hour
Room
Class
Room
wish
Room
property
Class
hours
Property
wish
Property
Time
table
User
User
authoriz
Authoriz
type
The gray area shows how the classroom data is stored in its raw form
Fig 3.7C Gantt-chart for project plan
• Excellent for showing temporal dependency
relationships between activities
• Combines overview and detailed information
• Used in Microsoft Project
36
Fig 3.7D Map format, power distribution
Courtesy: ABB Network Control
• Allows a few people to monitor a large geographical
area
37
Fig 3.7E Shneiderman's Tree Map showing all files in the Windows folder
38