1

CSE 3345

User interface design A software engineering perspective

Chapter 3: Data Presentation

2

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.

3

Fig 3.1A Three gestalt laws

Example A: Law of proximity

Example C:Law of closure

Example D: Law of good continuation

Example B: Mill wheelsLaw of proximity

4

Fig 3.1B Closure versus continuation

Example E:Law of good continuation

Example F: Law of closure?

5

Example G

Law of parallel movement

Law of . . .

Fig 3.1C Law of similarity and other gestalt laws

Example H

6

Example I

(Fig 3.1D) Similar colors create gestalts

Legal moves Dangerous positions

7

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.

8

ED

Fig 3.2B Laws of proximity and closure at work

• Does the Print Range frame in example E improve understandability?

• What does placing the OK button inside of the Print Range frame accomplish?

9

Text Gestalts

10

Fig 3.3A Column gestalts

Introduction & Basic Concepts 7The role of requirements 8Project types 11Contents of the specification 13Problems observed in practice 16Domain level and product level 18The goal–design scale 20Typical project models 24Data requirement styles 30The hotel system example 30The data model 30Data dictionary 37Data expressions 39Virtual windows 42Functional requirement styles 45Human/computer – who does what? 45Context diagrams 46Event list and function list 47

Functional details 85Complex and simple functions 85Tables and decision tables 88Textual process descriptions 90State diagrams 92State-transition matrices 94Activity diagrams 95Class diagrams 98Collaboration diagrams 102Sequence diagrams 103Special Interfaces 107Reports 107Platform requirements 108Product integration – ordinary customers 110Product integration – main contractor 114Technical interfaces 115Quality requirements 117Quality Factors 118

• Which page number goes with which section?• Why is it difficult to tell?• What Gestalt laws are at work here?

11

(Fig 3.3A Cont.)

Introduction & Basic Concepts ------------ 7The role of requirements -------------------------- 8Project types----------------------------------------11Contents of the specification---------------------13Problems observed in practice -------------------16Domain level and product level -----------------18The goal–design scale-----------------------------20Typical project models----------------------------24Data requirement styles ---------------------30The hotel system example------------------------30The data model-------------------------------------30Data dictionary-------------------------------------37Data expressions -----------------------------------39Virtual windows -----------------------------------42Functional requirement styles ------------45Human/computer – who does what?------------45Context diagrams ----------------------------------46Event list and function list------------------------47

Functional details------------------------------85Complex and simple functions ------------------85Tables and decision tables------------------------88Textual process descriptions ---------------------90State diagrams--------------------------------------92State-transition matrices --------------------------94Activity diagrams----------------------------------95Class diagrams -------------------------------------98Collaboration diagrams ------------------------- 102Sequence diagrams ------------------------------ 103Special Interfaces---------------------------- 107Reports -------------------------------------------- 107Platform requirements -------------------------- 108Product integration – ordinary customers---- 110Product integration – main contractor -------- 114Technical interfaces ----------------------------- 115Quality requirements ----------------------- 117Quality 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.3A Cont. 2)

Introduction & Basic Concepts ------------ 7The role of requirements 8Project types 11Contents of the specification 13Problems observed in practice 16Domain level and product level 18The goal–design scale 20Typical project models 24Data requirement styles 30The hotel system example 30The data model 30Data dictionary 37Data expressions 39Virtual windows 42Functional requirement styles 45Human/computer – who does what? 45Context diagrams 46Event list and function list------------------------47

Functional details------------------------------85Complex and simple functions 85Tables and decision tables 88Textual process descriptions 90State diagrams 92State-transition matrices 94Activity diagrams 95Class diagrams 98Collaboration diagrams 102Sequence diagrams 103Special Interfaces 107Reports 107Platform requirements 108Product integration – ordinary customers 110Product integration – main contractor 114Technical interfaces 115Quality requirements 117Quality Factors----------------------------------- 118

• Which page number goes with which section?• Is it difficult to tell? Why not?• What Gestalt laws are at work here?

13

Sales of X-mas trees

There is a strong seasonal variationin the sales of . . .

1 2 3 4 5 6 7 8 9 10 11 12

Picture captionor heading?

Fig 3.3B Heading proximity

Sales of X-mas trees

There is a strong seasonal variationin the sales of . . .

1 2 3 4 5 6 7 8 9 10 11 12

No doubt

• What is Sales of X-mas trees describing?• Is it difficult to tell? Why?

14

This report is intended to provide backgroundinformation which will facilitate the development ofprocedures and tools to improve the tware producers tomanage and control software quality and to demonstratethe achievement of software quality requirements.

The report surveys published work relating to theidentification and specification of software qualitycharacteristics, metrics relating to them, and inferenceswhich can be drawn from the metrics. It does not attempt,however, to evaluate the published work to any greatextent. It notes the ure, and identifies uality Managementproject. In summarising such large works it has not beenpossible to cover all the material, and the serious studentmay need to refer to the originals for further details.

Boehm et al's book entitled "Characteristics ofSoftware Quality" reports on work done in the earlyseventies and is a precursor not only or McCall et al'swork but also of Gilb's. The initial objectives of the studywere to identify a set of characteristics of software quality,and for each characteristic to aimed at measuring thedegree to which a program possesses the characteristic andhence provide an overall software quality assessment.

(Boehm et al soon abandoned the idea of an overallquality since they argued that the quality requirements fora given product will vary with the needs and priorities ofthe user, so there could be no single universally usefulrating of software quality. They concluded that metricswould be best used as anomaly indicators - ie to note thatan item of software differed from the normal pattern in away that might be symptomatic of quality problems.)

1 2

Fig 3.3C Paragraph Gestalts - Body text

This report is intended to provide backgroundinformation which will facilitate the development ofprocedures and tools to improve the ability of softwareproducers to manage and control software quality and todemonstrate the achievement of software qualityrequirements and improve the control software.

The report surveys published work relating to theidentification and specification of software qualitycharacteristics, metrics relating to them, and inferenceswhich can be drawn from the metrics. It does not attempt,however, to evaluate the published work to any greatsummarising such large works it has not been possible tocover all the material, and the serious student may need torefer to the originals for further details defin place.

Boehm et al's book entitled "Characteristics ofSoftware Quality" reports on work done in the earlyseventies and is a precursor not only or McCall et al'swork but also of Gilb's. The initial objectives of the studywere to identify a set of characteristics of software quality,and for each characteristic to identify one or more metricsaimed at measuring the degree to which a programpossesses the characteristic and hence provide an overallsoftware quality assessment.

(Boehm et al soon abandoned the idea of an overallquality since they argued that the quality requirements fora given product will vary with the needs and priorities ofthe user, so there could be no single universally usefulrating of software quality. They concluded that metricswould be best used as anomaly indicators - ie to note thatan item of software differed from the normal pattern in away 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?

15

This report is intended to provide background information which will facilitate thedevelopment of procedures and tools to improve the ability of software producers tomanage and control software quality and to demonstrate the achievement of softwarequality requirements.

The report surveys published work relating to the identification and specification ofsoftware quality characteristics, metrics relating to them, and inferences which can bedrawn from the metrics. It does not attempt, however, to evaluate the published work toany great extent. It notes the existence of relevant software tools referred to in theliterature, and identifies areas of work which might be pursued further within TestingSpecification and Quality Management project. In summarising such large works it hasnot been possible to cover all the material, and the serious student may need to refer tothe originals for further details.

Boehm et al's book entitled "Characteristics of Software Quality" reports on work donein the early seventies and is a precursor not only or McCall et al's work but also ofGilb's. The initial objectives of the study were to identify a set of characteristics ofsoftware quality, and for each characteristic to identify one or more metrics aimed atmeasuring the degree to which a program possesses the characteristic and henceprovide an overall software quality assessment.

(Boehm et al soon abandoned the idea of an overall quality since they argued that thequality requirements for a given product will vary with the needs and priorities of theuser, so there could be no single universally useful rating of software quality. Theyconcluded that metrics would be best used as anomaly indicators - ie to note that anitem of software differed from the normal pattern in a way that might be symptomaticof quality problems.)

3

Clear gestaltsbut lines too long.Annoying to read???

(Fig 3.3C Cont.)

• Discuss the clarity of the gestalts in the example.• What contributes to the gestalt clarity in the example?

16

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

17

Classical rules:Max 12.5 cm line.Max 65 chars/line.

Fig 3.3D Line length, A4 or Letter paper

This report is intended to provide background information which will facilitate thedevelopment of procedures and tools to improve the ability of software producers tomanage and control software quality and to demonstrate the achievement of softwarequality requirements.

The report surveys published work relating to the identification and specification ofsoftware quality characteristics, metrics relating to them, and inferences which canbe drawn from the metrics. It does not attempt, however, to evaluate the publishedwork to any great extent. It notes the existence of relevant software tools referred toin the literature, and identifies areas of work which might be pursued further withinTesting Specification and Quality Management project. In summarising such largeworks it has not been possible to cover all the material, and the serious student mayneed to refer to the originals for further details.

Boehm et al's book entitled "Characteristics of Software Quality" reports on workdone in the early seventies and is a precursor not only or McCall et al's work but alsoof Gilb's. The initial objectives of the study were to identify a set of characteristicsof software quality, and for each characteristic to identify one or more metrics aimedat measuring the degree to which a program possesses the characteristic and henceprovide an overall software quality assessment.

(Boehm et al soon abandoned the idea of an overall quality since they argued that thequality requirements for a given product will vary with the needs and priorities of theuser, so there could be no single universally useful rating of software quality. Theyconcluded that metrics would be best used as anomaly indicators - ie to note that anitem of software differed from the normal pattern in a way that might besymptomatic of quality problems.)

Simple reports:12 point text.3.5 cm margins.

100 pagesThis report is intended to provide background information which will facilitate thedevelopment of procedures and tools to improve the ability of software producers tomanage and control software quality and to demonstrate the achievement ofsoftware quality requirements.

The report surveys published work relating to the identification and specification ofsoftware quality characteristics, metrics relating to them, and inferences which canbe drawn from the metrics. It does not attempt, however, to evaluate the publishedwork to any great extent. It notes the existence of relevant software tools referred toin the literature, and identifies areas of work which might be pursued further withinTesting Specification and Quality Management project. In summarising such largeworks it has not been possible to cover all the material, and the serious student mayneed to refer to the originals for further details.

Boehm et al's book entitled "Characteristics of Software Quality" reports on workdone in the early seventies and is a precursor not only or McCall et al's work butalso of Gilb's. The initial objectives of the study were to identify a set ofcharacteristics of software quality, and for each characteristic to identify one ormore metrics aimed at measuring the degree to which a program possesses thecharacteristic and hence provide an overall software quality assessment.

(Boehm et al soon abandoned the idea of an overall quality since they argued thatthe quality requirements for a given product will vary with the needs and prioritiesof 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 notethat an item of software differed from the normal pattern in a way that might besymptomatic of quality problems.)

Complex reports:10 point text.3.5 + 6 cm margins.

83 pages

This report is intended to provide backgroundinformation which will facilitate the development ofprocedures and tools to improve the ability of softwareproducers to manage and control software quality and todemonstrate the achievement of software qualityrequirements.

The report surveys published work relating to theidentification and specification of software qualitycharacteristics, metrics relating to them, and inferenceswhich can be drawn from the metrics. It does notattempt, however, to evaluate the published work to anygreat extent. It notes the existence of relevant softwaretools referred to in the literature, and identifies areas ofwork which might be pursued further within TestingSpecification and Quality Management project. Insummarising such large works it has not been possible tocover all the material, and the serious student may needto refer to the originals for further details.

Boehm et al's book entitled "Characteristics of SoftwareQuality" reports on work done in the early seventies andis a precursor not only or McCall et al's work but also ofGilb's. The initial objectives of the study were to identifya set of characteristics of software quality, and for eachcharacteristic to identify one or more metrics aimed atmeasuring the degree to which a program possesses thecharacteristic and hence provide an overall softwarequality assessment.

(Boehm et al soon abandoned the idea of an overallquality since they argued that the quality requirements fora given product will vary with the needs and priorities ofthe user, so there could be no single universally usefulrating of software quality. They concluded that metricswould be best used as anomaly indicators - ie to note thatan item of software differed from the normal pattern in away that might be symptomatic of quality problems.)

Tech documents:10 point text.2 cols + 2 cm margins.

64 pages

Which format is best, or does it really mater?

18

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.

19

Form

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

Color or darkness Flash or movement(intense)

Fig 3.4A Using Contrasts to Call Attention to Something

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

Size, thickness, or 3-D

Shape contrasts: o forms a background to x. The many vs. the few.

The many form the backdrop to the few.

20

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?

21

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.

22

Classical “form” format

Fig 3.5A Room data

Room formRoom no. 011 Prices high med low

Beds 2 Normal 88 80 58

Bath full As single 68 60 49

Balcony no

Seaview no Last renovated 20-08-03

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

23

List or table format

Room states from 30-08-03 to 01-09-03

Room Beds Bath State Date011 2 full occ 30-08-03011 2 full occ 31-08-03012 1 toil book 30-08-03012 1 toil book 31-08-03012 1 toil book 01-09-03013 2 toil book 30-08-03013 2 toil repair 31-08-03

Detail windowfor selected item

Prices high med low

Normal 88 80 58

As single 68 60 49

Balcony no

Seaview no

Last renovated 20-08-03

(Fig 3.5A Cont.)

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

24

Room states from 30-08-03 to 01-09-03

Room Beds Bath State Date011 2 full occ 30-08-03011 2 full occ 31-08-03012 1 toil book 30-08-03012 1 toil book 31-08-03012 1 toil book 01-09-03013 2 toil book 30-08-03013 2 toil repair 31-08-03

Details shown inadjoining frame

Prices high med low

Normal 88 80 58

As single 68 60 49

Balcony no

Seaview no

Last renovated 20-08-03

(Fig 3.5A Cont. 2)

• Same as before but with an adjoining detail window.

• Which format is better, pop-up detail window or adjoining detail window?

25

Rooms Prices 7/8 8/8 9/8 10/811 double, bath 80 60 O B12 single, toil 60 O O B B13 double, toil 60 50 B B B

Matrix format

Fig 3.5B Room status

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

26

Fig 3.5B Room status

Map format

011 013

012 014

015 017 019

016 018 020 022 024

Room states from 30-08-03 to 01-09-03

Detail windowfor selected item

Prices high med low

Normal 88 80 58

As single 68 60 49

Beds 2

Bath full

Last renovated 20-08-03

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

27

Fig 3.5C Hierarchy presentationsExplorer tree Detail window

• Good for visualizing whole/part (composition) relationships and managing complexity

• Widely understood format thanks to Windows Explorer

28

E-mail folders Hierarchical menus

(Fig 3.5C Cont.)

29

1996 1997 1998Customer satisfact 7 8 9Employee satisfact 6 4 8Sales 12.5 14.5 15.8Profit 2.7 1.9 0.8. . .

Fig 3.5D Business history (1)

96 97 98

Sales

Cust.

Empl.

Profit

Line graph

9697

98

SalesCust.

Empl.

Profit

3-D surface

Matrix

30

Sales

Cust.

Empl.Profit

98

97

Fig 3.5E Business history (2)

SalesCust. Empl. Profit10 20 10 5

9697

98

Parallelcoor-dinates

Chernofffaces

Sales

Cust.Profit

Empl.1996

19981997

Radarchart

Cust.

Sales10

4

8

5

Bubblediagram

9697

98

31

Current: 62 AAlarm 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

Thesispz 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 showsmost of the doc.

Screen showsa small partof the doc.

TG

KN

AP

AH

BG

DH

RR

Monitoringhigh-speed trains

Fig 3.5F Analog numbers

BelgraveMartin ct

32

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.

33

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

34

Class: ITM 101 Weeks 2-6, 10-16

Mo Tu We Th Fr Sa 1 Progr Org. Progr 2 JS13 * J113 J113 3 Progr Progr tut 4 N4059 *** 5 5-16 6 7 FinAcc 8 J113 910

Room: J113

1 ITM 201 MBA 213 *** ITM 101 ITM 101 2 2-6, 15... 2-17, ... *** 1-16 1-16 3 *** *** MAM 101 4 *** *** *** 2-16 5 *** *** *** MBA 214 6 *** ITM 301 *** *** 9, 10 7 ITM 101 *** *** *** BDA 8 1-4, 7 ... *** ITM 202 *** 14 9 *** ***10 *** ***

Weeks 2-6, 10-16

Mo Tu We Th Fr Sa

Fig 3.7A Planning screens for classroom allocation

Both screens combine overview and detail

Focus is on a single classroom

Focus is on a single class

Line Classactivity

Request Requesthour

Roomhour

Room

Contractperiod

Activity

Class

Classhours

Timetable

User Userauthoriz

Authoriztype

Roomproperty

PropertyPropertywish

Roomwish

Buildingwish

Building

Fig 3.7B Datamodel for classroom allocation

The gray area shows how the classroom data is stored in its raw form

36

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

37

Fig 3.7D Map format, power distribution Courtesy: ABB Network Control

• Allows a few people to monitor a large geographical area

38

Fig 3.7E Shneiderman's Tree Map showing all files in the Windows folder