setop
/
dataviz
1
0
Fork 0
Code Issues Pull Requests Projects Releases Wiki Activity

docs and scripts

This commit is contained in:
Anton 2021-04-11 01:10:25 +03:00
commit a9641468b8
219 changed files with 3655 additions and 0 deletions
Show Stats Download Patch File Download Diff File Expand all files Collapse all files

17
README.md Normal file
View File

@ -0,0 +1,17 @@
# Data Visualization Guide for Presentations, Reports, and Dashboards
Based on [International Business Communication Standards](https://www.ibcs.com/standards/) 1.1 by [IBCS Association](https://www.ibcs.com/), licensed under [CC BY-SA 4.0](https://creativecommons.org/licenses/by-sa/4.0/). Adapted for the web and other formats by [Anton Zhiyanov](https://antonz.org/).
This is a highly practical and example-based guide on visually representing data in reports and dashboards. It is based on the work of authors such as Barbara Minto, Edward Tufte, and Stephen Few.
The guide consists of seven chapters:
1. [Convey a message](docs/01-say.md)
2. [Organize content](docs/02-structure.md)
3. [Choose proper visualization](docs/04-express.md)
4. [Avoid clutter](docs/05-simplify.md)
5. [Increase information density](docs/06-condense.md)
6. [Ensure visual integrity](docs/07-check.md)
7. [Apply semantic notation](docs/09-unify.md)
Applied together, they will help you to design concise, clear, and actionable reports.

9
docs/00-conceptual.md Normal file
View File

@ -0,0 +1,9 @@
# CONCEPTUAL RULES
_Conceptual rules_ help to clearly relay content by using an appropriate
storyline. They comprise the first part of this guide with the rule sets [SAY](01-say.md) and [STRUCTURE](02-structure.md).
The conceptual rules are based on the work of authors such as
Barbara [Minto](https://www.amazon.com/Pyramid-Principle-Logic-Writing-Thinking/dp/0273710516).
Their wide acceptance stems from their scientific, experimental, and practical
experience basis.

211
docs/01-say.md Normal file
View File

@ -0,0 +1,211 @@
# SAY – Convey a message
SAY covers all aspects of conveying messages to the recipients of reports and
presentations.
_Conveying messages_ means that reports and presentations, both as a whole as well
as within their individual components, intend to say something to the recipients.
Messages in this sense can be determinations, explanations, clarifications,
recommendations, and other forms of statements.
This chapter covers introducing, delivering, supporting, and summarizing messages with
respect to the objectives of senders and receivers.
1. [Know objectives](#sa-1-know-objectives)
2. [Introduce message](#sa-2-introduce-message)
3. [Deliver message](#sa-3-deliver-message)
4. [Support message](#sa-4-support-message)
5. [Summarize message](#sa-5-summarize-message)
## SA 1 Know objectives
Good reports (presentations) successfully achieve both the goals of the writer
(speaker) and of the readers (audience).
## SA 1.1 Know own goals
![Figure SA 1.1: Know own goals](img/sa-1.1.png)
Do not start creating a report or presentation without a clear vision of
what to achieve with it. The least goal is to inform about an
interesting detection. A higher goal is to make the reader (audience)
understand a problem by explaining it. The ultimate goal is to get a
decision on a suggestion provided and to cause corresponding actions.
## SA 1.2 Know target audience
![Figure SA 1.2: Know target audience](img/sa-1.2.png)
A good report (presentation) will try to answer the questions of the
readers (audience). So it is important to know the target audience (e.g.
their function, position, network, knowledge, experience, attitude,
behavior, worries, cultural background) and their goals, preferences,
and expectations.  Do they only want to get informed about
interesting detections, or are they looking for an explanation to a
problem? Are they willing to make decisions and to act accordingly? Who
might object to the message and why?
## SA 2 Introduce message
The addressees appreciate an introduction mapping the actual situation followed
by an explanation of the given problem. Raising a question will focus on the
given message.
## SA 2.1 Map situation
![Figure SA 2.1: Map situation](img/sa-2.1.png)
Mapping the situation means compiling and presenting the related facts.
Be sure to cover all relevant aspects and obtain a general consensus
concerning the facts. In general, this means not yet describing the
given problem but presenting facts and goals already known to the reader
or audience. It is advisable to begin with a positive and generally
accepted description of the situation in order to prevent early
contradictions.
## SA 2.2 Explain problem
![Figure SA 2.2: Explain problem](img/sa-2.2.png)
After mapping the situation, introduce the challenge or complication,
affecting the reader or the audience. It should make everyone aware of
an interesting, critical, or even dangerous problem.
## SA 2.3 Raise question
![Figure SA 2.3: Raise question](img/sa-2.3.png)
A good introduction raises the relevant question from the perspective of
the recipient of how to solve the complication in the described
situation. The question at the beginning of each report or presentation
then leads to the message, i.e. the answer to the question.
## SA 3 Deliver message
Delivering the message means answering the question asked at the end of the
introduction. Messages detect, explain, or suggest something the report or
presentation later explains in detail.
## SA 3.1 Detect, explain, or suggest
![Figure SA 3.1: Detect, explain, or suggest](img/sa-3.1.png)
Messages in reports and presentations can detect, evaluate, explain,
warn, complain, threaten, excuse, suggest, or recommend something
interesting. Make sure to deliver these messages in a complete sentence
in order to be understood.
Today, many messages in business reporting are pure _detections_.
Since detections are statements that can be checked whether they are
true or false, they should be formulated as precisely as possible.
Explaining the reasons for a detection (_explanation_) or even
deriving a _suggestion_ on how to solve the problem or at least
on how to further proceed can add value.
![Figure SA 3.1.1: Classification of messages](img/sa-3.1-1.png)
This figure shows a classification of messages with examples
from the business environment (Source: Hichert, R. and Kornwachs, K.)
## SA 3.2 Say message first
![Figure SA 3.2: Say message first](img/sa-3.2.png)
Every report, every presentation, and every single page or exhibit can be
summed up with a clear overall message. This message usually comes first
and is proven afterwards. For the readers or the audience it is more
difficult to follow the storyline if the message comes at the end.
Be cautious applying this rule in presentations (not in reports) with
bad, unexpected, or unpleasant messages (e.g. layoffs) or in a cultural
environment, where directness is considered impolite.
## SA 4 Support message
_Supporting the message_ covers some technical and practical aspects of
message conveyance.
## SA 4.1 Provide evidence
![Figure SA 4.1: Provide evidence](img/sa-4.1.png)
Substantiate the message in order to prove the message by facts and
figures. If possible, a presentation slide should itself explain or
prove the speaker’s message and not – as very often seen in practice –
be explained by the speaker. This can be done by spoken sentences
possibly supported by charts, tables, and pictures.
## SA 4.2 Use precise words
![Figure SA 4.2: Use precise words](img/sa-4.2.png)
The more unambiguous the language, the clearer the message. Only precise
words will be understood. Speaking about “relevant” or “significant” (in
common speech, not as a statistical term) content leads to
misinterpretations and misunderstandings. Speaking about facts and
figures will prevent them.
## SA 4.3 Highlight message
![Figure SA 4.3: Highlight message](img/sa-4.3.png)
Visually highlight messages in the communication objects presented –
namely in charts, tables, graphs, and pictures. This facilitates
comprehension and reduces the time needed to understand complex
situations. In most cases, it should be possible to highlight the
important parts of the content by underlining the most important facts
or emphasizing interesting details. Objects and pages without
highlighting indicators tend to be a statistic rather than a report.
## SA 4.4 Name sources
![Figure SA 4.4: Name sources](img/sa-4.4.png)
Naming sources for the material presented increases the credibility.
Projected slides can omit them but written reports and handouts must
include them.
## SA 4.5 Link comments
![Figure SA 4.5: Link comments](img/sa-4.5.png)
Use comments in written reports and handouts to add explanations,
conclusions, and similar statements. Projected slides in presentations
rarely need any comments because the comments are given by the speaker.
Number comments related to specific parts of a page (e.g. words, numbers,
or visualization elements) and link them to the respective parts. Post
numbered comments in text boxes on free areas of a page. General
comments concerning the whole page are not numbered. Post them as a
footnote at the bottom of a page.
## SA 5 Summarize message
Conclude a presentation with the overall message, including the next steps and an
explanation of the consequences.
## SA 5.1 Repeat message
![Figure SA 5.1: Repeat message](img/sa-5.1.png)
Avoid the phrase “Thank you for your attention” at the end of a
presentation. Instead, presenters should briefly sum up their message
one last time – in one sentence, if possible. At the conclusion of a
successful presentation, the audience will be thanking the presenters
for the information. Repeating the message from the beginning of a
presentation at the end helps the audience check the quality of the
storyline and brings the presentation full circle. In reports, on the
other hand, such repetition is not necessary as the reader can quickly
browse back to the respective summary at the beginning.
## SA 5.2 Explain consequences
![Figure SA 5.2: Explain consequences](img/sa-5.2.png)
Conclude reports and presentations with proposals for decisions to be
taken and an explanation of their consequences. This is the real
objective of a presentation: Convince the audience of both the message
and the suggested steps to be taken next.
[Organize content →](02-structure.md)

213
docs/02-structure.md Normal file
View File

@ -0,0 +1,213 @@
# STRUCTURE – Organize content
STRUCTURE covers all aspects of organizing the content of reports and presentations.
_Organizing the content_ means that reports and presentations follow a logical
structure forming a convincing storyline.
This chapter covers using consistent elements, building non-overlapping elements,
building collectively exhaustive elements, building hierarchical structures, and
visualizing their structure properly.
1. [Use consistent elements](#st-1-use-consistent-elements)
2. [Build non-overlapping elements](#st-2-build-non-overlapping-elements)
3. [Build collectively exhaustive elements](#st-3-build-collectively-exhaustive-elements)
4. [Build hierarchical structures](#st-4-build-hierarchical-structures)
5. [Visualize structure](#st-5-visualize-structure)
## ST 1 Use consistent elements
Listings and groupings of any kind of elements (items, terms, pictures, symbols,
etc.) used to organize content in charts, tables, and texts should contain
consistent elements only. This pertains for example to items, statements,
wordings, and the appearance of symbols and pictures.
## ST 1.1 Use consistent items
![Figure ST 1.1: Use consistent items](img/st-1.1.png)
Items in a group should be of the same type, i.e. consistent. Consistent
items can be different types of cars, houses, traffic signs, or – as
shown in Figure ST 1.1, on the right hand side – different national
flags representing the corresponding nations. The left hand side of this
figure includes other types of items besides national flags, destroying
the consistency.
## ST 1.2 Use consistent types of statements
![Figure ST 1.2: Use consistent types of statements](img/st-1.2.png)
A list of statements will be easier to understand if all statements are
of the same type. The right hand side of Figure ST 1.2 shows four
suggestions. By contrast, on the left-hand side of this figure the third
statement is a detection, not a suggestion.
## ST 1.3 Use consistent wording
![Figure ST 1.3: Use consistent wording](img/st-1.3.png)
Structure all phrases – especially in listed arrangements – in a
grammatically consistent manner to facilitate quicker understanding. The
right hand side of Figure ST 1.3 shows a group of four consistent
suggestions, an imperative verb paired with a noun. By contrast, on the
left hand side of this figure the second suggestion uses verbal
substantive instead of an imperative.
## ST 1.4 Use consistent visualizations
![Figure ST 1.4: Use consistent visualizations](img/st-1.4.png)
Visualizations such as symbols and pictures that are uniform in respect
to their layouts, colors, forms, fonts, etc. – especially in listed
arrangements – facilitate faster and easier comprehension.
## ST 2 Build non-overlapping elements
Elements belonging to a group should not overlap, i.e. they should be disjoint or
mutually exclusive. This concerns practical applications such as report
structures, business measures, or structure dimensions.
## ST 2.1 Build non-overlapping report structures
![Figure ST 2.1: Build non-overlapping report structures](img/st-2.1.png)
Structure reports and presentations in such a way that the parts,
chapters, sections, and paragraphs do not overlap. They should not cover
the same aspects.
In Figure ST 2.1, on the left hand side, the following chapters of a
project description overlap:
- expenses and costs
- schedule, steps, milestones, and calendar
- objective, results, and achievements
At first glance, the six terms on the right hand side of this figure have
no overlap in their logical structure. Of course, a relationship exists
between the _cost_, the _results_, and the
_schedule_ of a project, but in regards to the content of the
chapters this is not an overlap.
## ST 2.2 Build non-overlapping business measures
![Figure ST 2.2: Build non-overlapping business measures](img/st-2.2.png)
Structure a group of business measures in lists or calculations in a way
they do not overlap, i.e. business measures on one hierarchical level
should be disjoint or mutually exclusive.
Looking at Figure ST 2.2, on the left hand side, the following business
measures overlap
- _material costs_ and _costs of goods sold_
- _depreciation_ and _fixed costs_
The calculation scheme on the right hand side has been cleaned up.
## ST 2.3 Build non-overlapping structure dimensions
![Figure ST 2.3: Build non-overlapping structure dimensions](img/st-2.3.png)
The elements of the _structure dimensions_ used in reports and presentations should not overlap, i.e.
the elements of a structure dimension should be disjoint or mutually
exclusive.
Looking at Figure ST 2.3 on the left hand side, the regions _Norway,
Sweden, Denmark,_ and _Finland_ overlap with _Scandinavia_.
## ST 3 Build collectively exhaustive elements
A list of elements is considered to be exhaustive when they cover all aspects of
a superordinate topic. For example, dividing _Europe_ into
_Germany_, _Austria_, _Switzerland_, and _Belgium_
is not exhaustive because other countries also belong to Europe.
Structures with mutually exclusive (ME) and collectively exhaustive (CE) elements
are known as MECE structures.
## ST 3.1 Build exhaustive arguments
![Figure ST 3.1: Build exhaustive arguments](img/st-3.1.png)
If some important arguments relating to a specific question are left out,
the given answer will not be convincing.
Looking at Figure ST 3.1 on the left hand side the option “_old
products, new location_” is missing.
## ST 3.2 Build exhaustive structures in charts and tables
![Figure ST 3.2: Build exhaustive structures in charts and tables](img/st-3.2.png)
The elements of structures presented in charts and tables should also be
exhaustive, in other words, adding up to one hundred percent.
In many practical applications of this kind, adding a remainder element
(“rest of…”) helps to conform to this rule.
## ST 4 Build hierarchical structures
Give reports and presentations a hierarchical structure whenever possible,
resulting in faster comprehension and simplified searching. These rules help to
write and present a good storyline.
## ST 4.1 Use deductive reasoning
![Figure ST 4.1: Use deductive reasoning](img/st-4.1.png)
Exhibiting deductive reasoning (_logical flow_) for a given
message aids in _building_ hierarchical structures. _Logical
flows_ always answer the question “why” following the key
message. They begin with a statement (all men are mortal), continue with
a comment (Socrates is a man), and resolve with a conclusion (Socrates
is mortal) culminating in the message (Socrates will die).
Deductive reasoning can be best applied in controversial discussions for
arguing and demonstrating need for action. However, it forces the
readers or the audience to reproduce the deduction and the whole
argumentation can collapse if any statements are questionable.
## ST 4.2 Use inductive reasoning
![Figure ST 4.2: Use inductive reasoning](img/st-4.2.png)
Exhibiting _inductive_ reasoning (_logical group_) for a
given message aids in understanding hierarchical structures. _Logical
groups_ are homogenous, non-overlapping, and collectively
exhaustive arguments culminating in a message. This results in a
powerful argumentation that satisfies the addressees need for an easily
comprehensible logical structure.
## ST 5 Visualize structure
Having organized the arguments hierarchically, visualize this structure in order
to make the storyline transparent.
## ST 5.1 Visualize structure in reports
![Figure ST 5.1: Visualize structure in reports](img/st-5.1.png)
For easier understanding, underscore the logical structure of reports and
presentations with visual aids (e.g. outlines, dashboards, summaries).
Figure ST 5.1 illustrates this rule showing binder tabs on the right
hand side.
## ST 5.2 Visualize structure in tables
![Figure ST 5.2: Visualize structure in tables](img/st-5.2.png)
Design tables in such a manner that their hierarchical structure can be
recognized in both the columns as well as the rows.
The right hand side of Figure ST 5.2 shows three hierarchical levels of
rows in a table. The base level shows cities, the first summary shows
regions, and the second summary shows the country.
## ST 5.3 Visualize structure in notes
![Figure ST 5.3: Visualize structure in notes](img/st-5.3.png)
Notes are also easier to understand when their structure is shown clearly
(see Figure ST 5.3).
[← Convey a message](01-say.md) | [Choose proper visualization →](04-express.md)

6
docs/03-perceptual.md Normal file
View File

@ -0,0 +1,6 @@
# PERCEPTUAL RULES
_Perceptual rules_ help to clearly relay content by using an appropriate visual design.
They comprise the second part of this guide with the rule sets [EXPRESS](04-express.md), [SIMPLIFY](05-simplify.md), [CONDENSE](06-condense.md), and [CHECK](07-check.md).
The perceptual rules are based on the work of authors such as William [Playfair](https://www.amazon.com/Playfairs-Commercial-Political-Statistical-Breviary/dp/0521855543), Willard Cope [Brinton](https://www.amazon.com/Graphic-Methods-Presenting-Willard-Brinton/dp/1290860955), Gene [Zelazny](https://www.amazon.com/Say-Charts-Executives-Visual-Communication/dp/007136997X), Edward [Tufte](https://www.amazon.com/Visual-Display-Quantitative-Information/dp/1930824130), and Stephen [Few](https://www.amazon.com/Show-Me-Numbers-Designing-Enlighten-dp-0970601972/dp/0970601972/). All of these rules owe wide acceptance to their scientific, experimental, and/or practical experience basis.

974
docs/04-express.md Normal file
View File

@ -0,0 +1,974 @@
# EXPRESS – Choose proper visualization
EXPRESS covers all aspects of choosing the proper visualization in reports and
presentations.
*Proper visualization* means that reports and presentations contain charts
and tables, which convey the desired message along with the underlying facts as quickly
as possible.
This chapter covers utilizing the correct types of charts and tables, replacing
inappropriate visualizations and representations, adding comparisons, and explaining
causes.
1. [Use appropriate object types](#ex-1-use-appropriate-object-types)
2. [Replace inappropriate chart types](#ex-2-replace-inappropriate-chart-types)
3. [Replace inappropriate representations](#ex-3-replace-inappropriate-representations)
4. [Add comparisons](#ex-4-add-comparisons)
5. [Explain causes](#ex-5-explain-causes)
## EX 1 Use appropriate object types
Choosing the appropriate _object type_ is of prime importance for the
comprehension of reports and presentations.
We use tables when looking up data. Tables have a high information density. They
are clear, they are honest, they do not want to highlight, and they typically do
not want to visually convey a certain message. So they do not compete with
charts.
Charts on the opposite are always biased. It is the selection of data, the
selection of the chart type, and the usage of highlighting which makes the
difference. We evaluate charts by asking whether they transfer the intended
message effectively and in a proper way. So charts cannot be replaced by tables.
The following section is about choosing the appropriate types of charts and
tables. It presents in detail different types, layouts, and examples as well as
their proper application.
## EX 1.1 Use appropriate chart types
![Figure EX 1.1: Use appropriate chart types](img/ex-1.1.png)
A _chart_ is a graphical object, in which visualization elements
such as columns, bars, and lines represent data.
This section discusses the types, layout, and examples of _single charts_. _Overlay charts_ _and multiple charts_ are discussed in the CO 4 “[Add elements](06-condense.md#co-4-add-elements)” and CO 5 “[Add objects](06-condense.md#co-5-add-objects)”.
The most important groups of business charts are those showing development over time (charts with horizontal category axes), those showing structural relationships (charts with vertical category axes), and those showing x‑y charts, scatter plots, and bubble charts (charts with two value axes), see Figure EX 1.1.
Other chart types are of lesser interest in business communication and
will be treated in a later version of the standards.
![Figure EX 1.1-1: Chart Types](img/ex-1.1-1.png)
Looking at charts with horizontal and vertical category axes, the chart
selection matrix displayed in the figure aids in selecting
the right chart type for time series and structure analyses.
In the following sections, the correct usage of _charts with horizontal category axes_, _charts with vertical category axes_, and *charts with two value axes* is discussed in greater detail.
**Charts with horizontal category axes**
Charts with horizontal category axes (short: _horizontal charts_) typically display time series. Use the horizontal category axis as a time axis. Vertically, the visualization elements represent the data per time period or point of time (there is no need to show a vertical value axis as the visualization elements carry their own values). Time category axes run from left to right and show characteristics of period types (e.g. months or years) or points of time (dates).
In general, the data series of a _horizontal chart_ is represented by columns (single, stacked, grouped), vertical pins, horizontal waterfalls, or lines. _Vertical pins_ can be considered very thin columns. Because of their importance, they are dealt with in a separate section.
Here follows the grouping of _horizontal chart types_:
**Single column charts**
![Figure EX 1.1-2: Single column charts](img/ex-1.1-2.png)
In general, _single column charts_ (short: single columns) are used to display the temporal evolvement of one data series.
Single columns consist of:
- **Horizontal category axis:** The _horizontal category axis_ represents with its labels the respective time periods or points of time. The part on “Semantic rules” suggests to use the category width (see width A in the figure) for identifying the period type (see UN 3.3 “[Unify time periods](09-unify.md#un-33-unify-time-periods-and-points-of-time)”).
- **Columns**: One _column_ per time period or point of time extends from the category axis in accordance with the respective value. Columns are displayed in the foreground of the category axis, so that the length of the column is not hidden. The part on “Semantic rules” suggests that the ratio of column width to category width (see ratio B/A in the figure) represents information about the measure type (see UN 3.1 “[Unify measures](09-unify.md#un-31-unify-measures)”).
- **Legends**: As there is only one data series, the legend (name of the data series) is part of the chart title.
- **Data labels**: _Data labels_ name the values of the data series corresponding to the length of the respective columns. Position the labels of positive values above their respective columns, the labels of negative values below.
**Stacked column charts**
![Figure EX 1.1-3: Stacked column charts](img/ex-1.1-3.png)
_Stacked column charts_ (short: stacked columns)
represent more than one data series (e.g. multiple
products, countries, or divisions), see the figure on
the left.
Stacked columns consist of:
- **Horizontal category axis:** See single column charts.
- **Columns**: The columns (see single column charts) are divided into segments (Excel names them “data points”) representing the data series (stacked columns).
- **Legends**: Legends (names of the data series) are positioned either on the far left side with right-aligned text or on the far right side with left-aligned text. The column segments define their vertical position, centered vertically with the data labels of the respective column segment. If a segment at the far left or far right is missing or has a very small size, its legends might need assisting lines.
- **Data labels**: _Data labels_ name the values of the data series corresponding to the length of the respective column segments. If the sum of the column segments of a category is positive (column pointing upward), the label of the sum is positioned above the respective column, if negative (column pointing downward), it is positioned below.
It must be pointed out that stacked columns should only
be used if all chart values are either positive or
negative.
This chart type might also not be a good choice if the
values of each data series vary too much. The maximum
number of data series (segments of a stacked column) to
be shown depends on the range of how much the values of
each data series vary: More than 5 data series will only
work well in the case of little variations.
Position the data series of central importance or
interest directly on the axis in order to best see its
development over time.
**Grouped column charts**
![Figure EX 1.1-4: Grouped column charts](img/ex-1.1-4.png)
_Grouped column charts_ (short: grouped columns) show, in general, time series for a primary scenario (e.g. AC or FC) in comparison with a reference scenario (e.g. PY or PL). Two columns per category (_grouped columns_) represent these two scenarios.
The columns of the primary scenario and the reference scenario overlap, the reference scenario placed behind the primary scenario – either to the left or right of the primary scenario (see bottom chart of the figure as well as the paragraph on ”Scenario comparisons” in UN 4.1 “[Unify scenario analyses](09-unify.md#un-41-unify-scenario-analyses)”). A third scenario could be displayed using a _reference scenario triangle_. All other elements of a grouped column chart are identical to single column charts.
Instead of using grouped columns, the primary scenario
can be represented with a single column with the
reference scenario represented by reference scenario
triangles (see top chart of the figure).
**Horizontal pin charts**
![Figure EX 1.1-5: Horizontal pin charts](img/ex-1.1-5.png)
_Horizontal pin charts_ (short: horizontal pins) are used for the visualization of relative variances in a time series analysis.
Horizontal pins consist of:
- **Horizontal category axis:** see _single column chart_.
- **Pins**: One _pin_ per time period or point of time extends from the category axis to the respective length. The pin has the size of a very thin column. Color the pin green or red corresponding with positive or negative relative variances respectively. The fill of the pinhead represents the primary scenario (see the paragraph on “Scenario comparisons” in UN 4.1 “[Unify scenario analyses](09-unify.md#un-41-unify-scenario-analyses)”). Display the pin in the foreground, so that the length of the pin (see length X in the figure) is not hidden.
- **Legends**: As there is only one data series, the legend (name of the data series) is part of the chart title.
- **Data labels**: _Data labels_ name the values of the data series consistent with the length of the respective pins. Position the labels of positive values above the respective pins, labels of negative values below.
**Horizontal waterfall charts**
_Horizontal waterfall charts_ (short: _horizontal waterfalls_ or _column waterfalls_) analyze root causes, over time, for the change or variance between two or more statuses. Accordingly, horizontal waterfalls consist of two or more _base columns and totals columns_. In between a base column and a totals column there are _contribution columns_ demonstrating what led to the difference between these two columns. The _contribution columns_ start at the end value, i.e. the height, of the preceding column, and show the positive or negative contribution as well as the accumulated contribution of all columns up to the respective point of time.
There are two types of horizontal waterfalls:
![Figure EX 1.1-6: Growth waterfalls](img/ex-1.1-6.png)
**Growth waterfalls**: In _growth waterfalls_, base columns and totals columns represent a stock measure (e.g. headcount, accounts receivable) at different points in time (e.g. end of Q4 2012, 2013 and 2014). The contribution columns in between represent the changes (increases and decreases) over time of this stock measure.
(There is no vertical equivalent to the horizontal _growth waterfall_.)
![Figure EX 1.1-7: Horizontal variance waterfalls](img/ex-1.1-7.png)
**Horizontal variance waterfalls**: In _horizontal variance waterfalls_, base columns and totals columns represent a flow measure (e.g. sales) at different periods in time (e.g. 2015 and 2016) and/or regarding different scenarios (e.g. PL and AC). The contribution columns in between represent the periodical variances between the different time periods and/or scenarios.
The elements of a horizontal waterfall chart are the same as the elements of single column charts. In addition, _assisting lines_ connect the end of a column to the beginning of the succeeding column.
**Line charts**
![Figure EX 1.1-8: Line chart](img/ex-1.1-8.png)
In general, _line charts_ are used for the display
of the temporal evolvement of data series with many data
points.
![Figure EX 1.1-9: Line chart with selective data labels](img/ex-1.1-9.png)
Many data points lead to small category widths. The advantage of line charts over column charts is the simplified display of data (better _data-ink-ratio_). In addition, they can better represent positive and negative values of more than one data series than columns. On the other hand, lines tend to imply a continuous timeline – practically non-existent in business communication. Therefore lines should not be used for the presentation of data series with only a few values.
Line charts cannot be “stacked” in order to show structure like in stacked column charts. In the place of line charts for “stacked data”, *area charts*offer a good solution (there is no layout concept for area charts in this version of the guide yet).
Line charts with more than three intersecting lines tend to be confusing. Instead, several smaller charts with one line each could be placed next to one another (small multiples), particularly when the general trends of the lines are to be analyzed – not the direct comparison of two data series (e.g. in comparing seasonal developments of several years), see also EX 2.4 “[Replace spaghetti charts](04-express.md#ex-24-replace-spaghetti-charts)”.
Line charts consist of:
- **Horizontal category axis:** See _single column chart_. The semantic rules in part 3 suggest to use the category width (see width A in the first figure) for identifying the period type (see UN 3.3 “[Unify time periods](09-unify.md#un-33-unify-time-periods-and-points-of-time)”).
- **Lines**: One or more _lines_ with _line markers_ represent the values of the respective data series. Use line thickness, line color, and line markers for meaning, see part “Semantic rules”.
- **Legends**: _Legends_ label the data series. If the line chart shows only one data series, include the legend in the chart title. If the line chart shows two or more data series, the legend should be positioned to the right of the far right data point (left-aligned text, see first figure) or the left of the far left data point (right-aligned text, see second figure). Alternatively position legends close to the lines at any other place in the chart.
- **Data labels**: _Data labels_ name the values of the respective data points. If possible, label maximum values (peaks) above the line markers and minimum values (valleys) below the line markers. In many practical applications it is not necessary to clutter the line chart by labeling every data point, see second figure on the left and SI 5.3 “[Avoid unnecessary labels](05-simplify.md#si-53-avoid-unnecessary-labels)”.
**Other horizontal charts**
Other chart types with horizontal category axes are *boxplot charts* (range charts) and _area charts_. There is no specific notation concept for these chart types yet however it can be easily derived from the notation concept of column and line charts.
**Charts with vertical category axes**
Charts with vertical category axes (_vertical charts_)
typically show structural data. In general, present structural
data of one period or one point of time in the form of
_bars_.
Use the vertical category as a structure axis. Horizontally, the visualization elements represent the data per structure element (there is no need for a horizontal value axis as the visualization elements carry their own values). Structure axes run from top to bottom and show characteristics of structures (e.g. products or countries). The sequence of these elements depends on the intended analysis; see the UNIFY section about “Structure analyses”.
In general, the data series of a vertical chart is represented by
(horizontal) _bars_ (single, stacked, grouped), by
_horizontal pins_, or by _waterfall bars_. Do not
use lines in vertical charts as they could be interpreted as
trends or developments, which do not exist in structure
analyses.
_Horizontal pins_ can be considered very thin bars, but
because of their importance are dealt with in a
separate section. A chart with horizontal pins is called a
_vertical pin chart_.
Here follows the grouping of _vertical chart types_:
**Single bar charts**
![Figure EX 1.1-10: Single bar charts](img/ex-1.1-10.png)
In general, _single bar charts_ (short: single
bars) are used for the structural analysis of one data
series (e.g., products, countries, or divisions) for one
period or one point in time.
Single bar charts consist of:
- **Vertical category axis:** The
_vertical category axis_ with its labels
represents the respective structure elements such as
countries, products, etc. The category width (see
width A in figure) should be the same
for corresponding analyses.
- **Bars**: One _bar_ per structure element extends from the category axis to the length representing the respective value. Display the bars in the foreground of the category axis, so that the length of the bar is not hidden. The part on “Semantic rules” suggests that the ratio of bar width to category width (see ratio B/A in figure) represents information about the measure type (see UN 3.1 “[Unify measures](09-unify.md#un-31-unify-measures)”).
- **Legends**: As there is only one data
series, the legend (name of the data series) is part
of the chart title.
- **Data labels**: _Data labels_
name the values of the data series consistent with
the length of the respective bars. Position the
labels of positive values at the right hand side of
the respective bars, the labels of negative values
at the left hand side.
**Stacked bar charts**
![Figure EX 1.1-11: Stacked bar charts](img/ex-1.1-11.png)
Stacked bar charts (short: stacked bars) represent more
than one data series (e.g., products, countries, or
divisions) for one period or one point in time.
Stacked bar charts consist of:
- Vertical category axis: See single bar charts.
- **Bars**: The bars (see single bar
charts) are divided into segments (Excel names them
“data points”) representing the data series (stacked
bars).
- **Legends**: Legends (names of the data
series) are positioned either above the top stacked
bar or below the bottom stacked bar, with the bar
segments defining their horizontal position: they
are horizontally centered with the data labels of
the respective bar segment. If a segment at the top
or bottom is missing or has a very small size, its
legend might need assisting lines.
- **Data labels**: _Data labels_
name the values of the data series corresponding to
the length of the respective bar segment. If the sum
of the bar segments of a category is positive (bar
pointing to the right), the label of the sum is
positioned to the right hand side of the respective
bar. If the sum is negative (bar pointing to the
left), the label of the sum is positioned to the
left hand side of the respective bar.
It must be pointed out that stacked bars should only be
used if all chart values are either positive or
negative.
This chart type might also not be a good choice if the
values of each data series vary too much. The maximum
number of data series (segments of a stacked bars) to be
shown depends on the range of how much the values of
each data series vary: More than 5 data series will only
work well in the case of little variations.
Position the data series of central interest directly at
the axis in order to best see its structure.
**Grouped bar charts**
![Figure EX 1.1-12: Grouped bar charts](img/ex-1.1-12.png)
In general, _grouped bar charts_ (short: grouped
bars) show structure analyses for a primary scenario
(e.g. AC or FC) in comparison to a reference scenario
(e.g. PY or PL). Two bars per category (_grouped
bars)_ represent _these_ two scenarios.
The bars of the primary scenario and the reference scenario overlap, the reference scenario placed behind the primary scenario – either above or below (see the bottom chart of the figure as well as the paragraph on “Scenario comparisons” in UN 4.1 “[Unify scenario analyses](09-unify.md#un-41-unify-scenario-analyses)”).
A third scenario could be displayed using a _reference scenario triangle_. All other elements of a grouped bar chart are identical to a single bar chart.
Alternatively, instead of grouped bars, the primary
scenario can be represented with a single bar and the
reference scenario by reference scenario triangles (see
top chart of figure).
**Vertical pin charts**
![Figure EX 1.1-13: Vertical pin charts](img/ex-1.1-13.png)
_Vertical pin charts_ (short: vertical pins) are used for the visualization of relative variances in a structure analysis.
Vertical pins consist of:
- Vertical category axis: see _single bar chart_.
- **Pins**: One _pin_ per structure element extends from the category axis to the respective length. The pin has the size of a very thin bar. It is colored green or red when representing positive or negative relative variances respectively. The fill of the pinhead represents the primary scenario (see the paragraph on “Scenario comparisons” in UN 4.1 “[Unify scenario analyses](09-unify.md#un-41-unify-scenario-analyses)”). Display pins in the foreground, so that the length of the pin (see length X in the figure) is not hidden.
- **Legends**: As there is only one data series, the legend (name of the data series) is part of the chart title.
**Data labels**: _Data labels_ name
the values of the data series corresponding to the
length of the respective pins. Position the labels of
positive values at the right hand side of the respective
pins, the labels of negative values at the left hand
side.
**Vertical waterfall charts**
_Vertical waterfalls charts_ (in short: _vertical waterfalls_ or _bar waterfalls_) analyze structural root causes for the difference between two or more statuses. Accordingly, vertical waterfalls consist of two or more _base bars_ and _totals bars_. In between a base bar and a totals bar there are _contribution bars_ representing the contribution to the difference between these two bars. Starting from the top base bar, _contribution bars_ always start at the end of the preceding bar, showing positive or negative individual contributions of the respective structure element as well as the accumulated contribution resulting in the next totals bar.
There are two types of vertical waterfalls:
![Figure EX 1.1-14: Calculation waterfalls](img/ex-1.1-14.png)
**Calculation waterfalls**: In _calculation waterfalls_, base bars and totals bars represent base and result measures (e.g. sales and EBIT) whereas the contribution bars in between represent the additions and subtractions of other measures (e.g. financial income and direct cost) in a calculation scheme. More complex calculation schemes (e.g. profit and loss calculation) can have intermediate subtotals bars.
(There is no horizontal correspondence to the vertical
_calculation waterfall_.)
![Figure EX 1.1-15: Vertical variance waterfalls](img/ex-1.1-15.png)
**Vertical variance waterfalls**: In _vertical variance waterfalls_, base bars and totals bars represent values at different periods or points in time (e.g. January 1, 2013 and January 1, 2014) and/or different scenarios (e.g. PY and AC). The contribution bars in between represent the variances in structure between the different times and/or scenarios.
The elements of vertical waterfalls are the same as the elements of single bar charts. In addition, _assisting lines_ connect the end of a bar with the beginning of the succeeding bar.
**Remainder bar**
![Figure EX 1.1-16: Remainder bar](img/ex-1.1-16.png)
If a large number of elements need to be presented, then
only the most important elements can be displayed in one
chart or on one page. In order to make the analyses
exhaustive, sort the elements by descending size,
accumulating the smallest elements, which cannot be
depicted, in a _remainder bar_ (“rest of…”). Separate the remainder bar from the
other bars by a wider gap (see gap C in the figure on
the left).
Note: This remainder bar has to be excluded from some Structure analyses such as averaging, ranking, and selecting.
**Other vertical charts**
Other chart types with vertical category axes are
_vertical boxplot charts_ (range charts). There
is no specific notation concept for this chart type yet
however it can be derived from the notation of the
standard bar charts.
In general, do not use lines and areas in vertical charts
as they might underline a continuum of data non-existent
in business communication.
**Charts with two values axes**
![Figure EX 1.1-17: Charts with two values axes](img/ex-1.1-17.png)
_Charts with two value axes_ show two-dimensional
positioning of visualization elements, which can provide new and
interesting insights. *Scattergrams* arrange points
in a two-dimensional coordinate system.
![Figure EX 1.1-18: Bubble charts](img/ex-1.1-18.png)
*Bubble charts* (portfolio charts) have bubbles
instead of points and use the bubble area to show a third
dimension. A fourth dimension could be
presented via pie segments within the bubbles (bubble pie
charts).
Besides _scattergrams_ and _bubble charts_ there
are other chart types with two value axes, e.g. charts with
horizontal axes representing a continuous timeline (instead of
fixed time categories) and charts with columns or bars of
variable width.
There are no specific notation rules for charts with two value axes yet. An appropriate notation concept for these chart types can be derived from the notation of column charts, bar charts and line charts with their data visualization elements, legends, data labels, and axes.
## EX 1.2 Use appropriate table types
A *table* is a communication object in which data is arranged
in two dimensions, i.e. (vertical) _columns and_ (horizontal)
_rows_. The _row header_ (row name) describes the content
of a row, the _column header_ (column name) the content of a
column. The data are positioned at the intersections of rows and columns
called _table cells_.
“One-dimensional tables” (tables with one or more columns but without row
headers) are called _lists_ and are not covered here.
_Table types_ are defined by a set of _columns_ and a set
of _rows_ in order to fulfill specific analytic and/or reporting
purposes.
**Column types**
Column types are columns with similar content falling under
similar column headers. Typical column types are _time
columns_ (with monthly or yearly data), _scenario
columns_ (with actual or plan data) and _variance
columns_ (ΔPL or ΔPY).
The following layout principles apply to all column types:
- **Width**: Columns belonging to a certain
column type should have an identical width. This column
width should not depend on the text length of the respective
column header.
- **Orientation**: Right-align columns with
numerical data. Left-align columns with non-numerical data
(e.g. texts or product names). _Column headers_ have
the same orientation as the rest of the column. Headers for
combined columns can be centered or even left-aligned to
increase legibility.
- **Vertical lines and gaps**: Vertical lines
separating different columns should be very light or even
omitted. Use white vertical lines or white vertical gaps to
mark the columns. In the following figures, different widths
of these white lines resp. gaps are being used to separate
and group columns. Separate columns of the same type by a
narrow gap (see gap B1 in the figure in section “Scenario columns” et seq.). Use a
wider gap to separate a group of similar columns from the
next group (see gap B2 in the figure in section “Row header columns” et seq.).
Additional layout principals depend on the _column types_
described below.
**Row header columns**
![Figure EX 1.2-1: Row header columns](img/ex-1.2-1.png)
Row header columns contain the header texts of the rows.
Often, these columns are positioned at the very left of
a table. In most cases, row header columns are much
wider than other column types.
Keep the texts of the row headers short by using
abbreviations or footnotes in order to omit too wide
tables.
Use a wider gap (see width B2 in the figure)
to separate the _row header column_ from columns
with numbers.
**Scenario columns**
![Figure EX 1.2-2: Scenario columns](img/ex-1.2-2.png)
_Scenario columns_ show data for scenarios
(e.g. previous year, plan, actual). Use the same width
for all scenario columns (depending on the number of
digits).
For the sequence of scenario columns see
UN 4.1 “[Unify scenario ana­lyses](09-unify.md#un-41-unify-scenario-analyses)”.
**Variance columns**
![Figure EX 1.2-3: Variance columns](img/ex-1.2-3.png)
_Variance columns_ show data of absolute variances (e.g. ΔPL, ΔPY) or relative variances (e.g. ΔPL%, ΔPY%).
**Time columns**
![Figure EX 1.2-4: Time columns](img/ex-1.2-4.png)
_Time columns_ show _time periods_ (for
flow measures) or _points of time_ (for stock
measures).
Use a temporal order – from left to right – for the
sequence of the time columns (e.g. Jan, Feb, Mar, or
2013, 2014, 2015).
**Measure columns**
![Figure EX 1.2-5: Measure columns](img/ex-1.2-5.png)
_Measure columns_ show measures
such as sales, headcount, or equity.
Displaying long measure names in column headers can be
challenging. As the column width should not depend on
the length of the measure name, use the abbreviations
defined in the glossary instead.
Use a wider gap after intermediate results to expose the
calculation scheme (see width B2 in the figure on the
left).
**Structure columns**
![Figure EX 1.2-6: Structure columns](img/ex-1.2-6.png)
_Structure columns_ show the elements of a structure dimension (e.g. countries or products).
**“Thereof” columns**
![Figure EX 1.2-7: “Thereof” columns](img/ex-1.2-7.png)
If details of an aggregated column are shown in one or
more column not totaling to the aggregated column, these
columns are called “thereof” columns.
The design of the _thereof columns_ should differ
from other columns. E.g. use a smaller font (see X in
the figure) to expose a _thereof
column_ and do not separate it from the mother
column (see columns _AL3_ and _AL3.1_ in
the figure) in order to show that it is part
of it. A _thereof column_ is positioned at the
right hand side of the mother column.
**Remainder columns**
![Figure EX 1.2-8: Remainder columns](img/ex-1.2-8.png)
If the set to be presented in the columns has too many
elements, accumulate the less important or smaller
elements in a _remainder_ column (e.g. 10 columns
for the top 10 countries and a remainder column titled
“Rest of world” or “RoW”).
In the figure, the _remainder column_ “Other cost” has the same vertical gaps B1 as the
other measure columns.
**“Percent of” columns**
![Figure EX 1.2-9: “Percent of” columns](img/ex-1.2-9.png)
Use “_Percent of”_ columns to present important
data of another column as shares of a given total. A
typical example for a “_percent of_” column is
data of a profit and loss statement as a percentage of
sales.
“Percent of” columns have a smaller font size (see X)
than the other columns.
**Totals columns**
![Figure EX 1.2-10: Totals columns](img/ex-1.2-10.png)
Position columns displaying _totals of a group of
columns_ (e.g. quarters totaling in years or
products totaling in product groups) at the right hand
side of the columns belonging to this group. The design
of the _totals columns_ should differ from other
columns, e.g. highlighted by bold fonts or by light gray
background.
The column types described before refer to
_single_ columns. The following paragraphs
present _combined_ columns i.e.
_hierarchical_ and _nested_ columns.
**Hierarchical columns**
![Figure EX 1.2-11: Hierarchical columns](img/ex-1.2-11.png)
Hierarchies in dimensions may call for columns showing
multiple levels. If possible, the sibling elements
belonging to the same parent element of a dimension
should be homogenous, mutually exclusive, and
collectively exhaustive.
Separate parents by appropriate means, e.g. wider gaps. Display the parent columns at the right hand side of their child _columns (like totals columns)._
In the figure, a wider gap B2
separates the two years (with four quarters each)
from each other.
**Nested columns**
![Figure EX 1.2-12: Nested columns](img/ex-1.2-12.png)
In _nested columns_, two column types are combined
in such a way that the columns of one type repeat
iteratively within every column of the other type.
Separate the resulting groups of columns by appropriate
means, e.g. wider gaps.
In the figure, wider gaps B2
separate the four years (with AC and PL data each)
from each other.
**Row types**
_Row types_ are rows with similar content falling under
similar row headers. Typical row types are _measure rows_
(e.g. sales, cost, profit) or _structure rows_ (e.g.
Italy, France, UK).
The following layout principles apply to all row types:
- **Height**: Rows belonging to a row type should
have an identical height (see height A in the figure in
section “measure rows” et seq.).
- **Horizontal lines**: Separating rows by light
horizontal lines will increase the legibility.
Additional layout principals depend on the row types described
below.
_Time periods and points of time_, _scenarios_,
and _variances_ should be displayed in columns rather
than in rows.
**Column header rows**
![Figure EX 1.2-13: Column header rows](img/ex-1.2-13.png)
Column header rows contain the header texts of the
columns. In most cases, these rows are positioned at the
very top of a table. In order to group columns two and
more column header rows might be necessary. If
necessary, abbreviate column header texts in order to
fit in the preferred column width. Alternatively keep
column headers short by using footnotes.
In the figure the _column header row_
uses two lines in order to fit the column header texts
in the narrow columns.
**Measure rows**
![Figure EX 1.2-14: Measure rows](img/ex-1.2-14.png)
_Measure rows_ show measures
such as sales, headcount, or equity.
Separate rows showing final or intermediate results of a
calculation scheme (_results rows_ _or totals
rows_) by solid lines. Display results rows in
bold font or highlight them with light gray background.
An additional gap B below a results row will increase
legibility.
**Structure rows**
![Figure EX 1.2-15: Structure rows](img/ex-1.2-15.png)
Structure rows show elements of a structure dimension (e.g. countries or products).
**“Thereof” rows**
![Figure EX 1.2-16: “Thereof” rows](img/ex-1.2-16.png)
If details of an aggregated row are shown in one or more
rows not totaling to the aggregated row, these rows are
called “thereof” rows. Place the aggregated
_above_ the “thereof” rows (in contrast to the
_totals_ _row_ positioned _below_
the rows of its group).
The design of the _thereof rows_ should differ
from other rows. E.g. in the figure, the
_thereof row_ is of smaller height, written in a
smaller font (see X), not separated by a horizontal
line, and has a right-aligned row header.
**Remainder rows**
![Figure EX 1.2-17: Remainder rows](img/ex-1.2-17.png)
If the structure dimension to be presented in the rows
outline has too many elements, accumulate the less
important or smaller elements in a _remainder row_ (e.g. 7 rows for the top 7 countries and a
remainder titled “Rest of world”).
Exclude remainder rows from some of the Structure analyses such as averaging, ranking, and
selecting.
In the figure, the _remainder row_ has
the same row height A as the other structure rows of
this table example.
**“Percent of” rows**
![Figure EX 1.2-18: “Percent of” rows](img/ex-1.2-18.png)
Use “_Percent of”_ rows to present important data
of another row as shares of a given total. A typical
example for a “_percent of_” row is gross profit
as a percentage of sales.
“Percent of” rows have a smaller font size (see X) than
the other rows.
**Totals rows**
![Figure EX 1.2-19: Totals rows](img/ex-1.2-19.png)
Place rows displaying _totals of a group of rows_ (e.g. countries totaling in regions or products
totaling in product groups) below the rows of this group
and separated them by solid lines.
The design of the _totals rows_ should differ from
other rows, e.g. highlighted by bold fonts or by light
gray background.
The row types described before refer to _single_
rows. The following paragraphs present _combined_
rows i.e. _hierarchical_ and _nested_
rows.
**Hierarchical rows**
![Figure EX 1.2-20: Hierarchical rows](img/ex-1.2-20.png)
Hierarchies in dimensions may call for rows showing
multiple levels. If possible, the sibling elements
belonging to the same parent element of a dimension
should be homogenous, mutually exclusive, and
collectively exhaustive.
Separate parents by appropriate means, e.g. wider gaps
(see additional gap B in the figure).
Display the parent rows _below_ their child
rows (like _totals rows_).
**Nested rows**
![Figure EX 1.2-21: Nested rows](img/ex-1.2-21.png)
In _nested rows_, two types of rows are combined
in such a way that the rows of one type repeat
iteratively within every row of the other row type.
Separate the resulting groups of rows by appropriate
means, e.g. wider gaps (see additional gap B in the
figure).
**Table types**
![Figure EX 1.2: Table types](img/ex-1.2.png)
Table types are distinguished by their analytic purpose in time series tables, variance tables and cross tables. Tables serving more than one analytic purpose are called combined tables.
**Time series tables**
![Figure EX 1.2-22: Time series tables](img/ex-1.2-22.png)
_Time series tables_ are used for time series analyses, combining time columns with measure rows or structure rows.
A typical example for a _time series table_ is a
sales analysis by countries (rows) and years (columns).
**Variance tables**
![Figure EX 1.2-23: Variance tables](img/ex-1.2-23.png)
_Variance tables_ are used for scenario analyses, combining scenario columns and variance columns with measure rows or structure rows.
A typical example for a _variance table_ is a
sales analysis by countries (rows) showing different
scenarios and different variances (columns).
**Cross tables**
![Figure EX 1.2-24: Cross tables](img/ex-1.2-24.png)
_Cross tables_ are used for Structure analyses, combining structure columns with structure rows.
A typical example of a _cross table_ is a sales
table with countries in rows and products in columns.
**Combined tables**
![Figure EX 1.2-25: Combined table 1](img/ex-1.2-25.png)
_Combined tables_ are used for multiple analyses. A combined table uses more than one _column type_ and/or more than one _row type_ presented either side by side or nested.
The first figure shows a hierarchical
structure of countries on three levels in the rows. The
columns are nested: scenarios and variances are the same
for both time periods _November_ and
_January_November_.
![Figure EX 1.2-26: Combined table 2](img/ex-1.2-26.png)
The second figure shows the measures of a
calculation scheme in the rows. The columns are nested:
The four quarters and the annual total are the same for
both years.
![Figure EX 1.2-27: Combined table 3](img/ex-1.2-27.png)
The third figure shows the same rows as the
second one (measures of a calculation scheme). The
nested columns now show PY and AC data as well as
absolute and relative variances for two markets.
## EX 2 Replace inappropriate chart types
Inappropriate charts make it hard to perceive the message. Knowing the correct
usage of chart types helps in replacing inappropriate visualizations, such as
pie charts, speedometer visualizations, radar charts, and spaghetti charts, with
those chart types better suited.
## EX 2.1 Replace pie and ring charts
![Figure EX 2.1: Replace pie and ring charts](img/ex-2.1.png)
_Pie_ and _ring charts_ are [circular charts](http://en.wikipedia.org/wiki/Circle) dividing some total into [sectors](http://en.wikipedia.org/wiki/Circular_sector) of relative proportion, but there are better ways to illustrate the numerical proportions of segments, e.g. bar charts or charts with stacked columns, see Figure EX 2.1.
_Pie charts_ allow for one-dimensional analyses only, and therefore seldom convey revealing insights. However, some useful applications for pie charts exist, for example when market sizes and/or market shares for one period need to be allocated to certain regions on a map (see CH 3.3 “[Avoid misleading colored areas in maps](07-check.md#ch-33-avoid-misleading-colored-areas-in-maps)”). As opposed to column or bar charts, pie charts can be positioned on a specific point on a map.
## EX 2.2 Replace gauges, speedometers
![Figure EX 2.2: Replace gauges, speedometers](img/ex-2.2.png)
Often found as part of a so-called dashboard, _speedometers_ are
probably one of the most useless visualizations out there. They take up
way too much space and have often confusing color coding and scaling. In
general, bar charts showing the respective structures or columns charts
showing the respective development over time are better choices, see
Figure EX 2.2.
## EX 2.3 Replace radar and funnel charts
![Figure EX 2.3: Replace radar and funnel charts](img/ex-2.3.png)
So-called _radar charts_ (also called _net charts_ or
_spider charts_) are frequently used for evaluating
purposes. Having no advantage over bar charts and having, actually, many
weaknesses, use them only for two-dimensional analyses (e.g. comparing
young-old with rich-poor). Willard C. Brinton wrote almost 100 years
ago: “This type of chart should
be banished to the scrap heap. Charts on rectangular ruling are easier
to draw and easier to understand.”
Of course, if the circular arrangement has meaning (such as the compass
direction), this kind of chart can be very valuable, but these types of
analysis are not typical in business reporting.
_Funnel charts_ are misleading when the size of the area displayed
does not correspond to the respective numerical values – an issue
applying also to other artificial chart forms (e.g. spheres) in which
the length, area, or volume do not correspond to the numerical values.
## EX 2.4 Replace spaghetti charts
![Figure EX 2.4: Replace spaghetti charts](img/ex-2.4.png)
A chart with more than three or four intersecting lines (“spaghetti chart”) can be more confusing than several smaller charts with one line each placed next to one another (small multiples), particularly when evaluating the shape or the trend of the lines, see Figure EX 2.4.
However, when needing to compare exactly the height of data points of
several lines, spaghetti charts cannot be avoided.
## EX 2.5 Replace traffic lights
![Figure EX 2.5: Replace traffic lights](img/ex-2.5.png)
“Traffic lights” with green, red, and yellow areas are a popular form of
visualization but contain little information per area used. However,
they can be used for analyses showing “yes or no” decisions or
situations similar to real traffic lights. In all other cases replace
them with more suitable means of (analog) representation such as bar
charts, see Figure EX 2.5.
## EX 3 Replace inappropriate representations
From a perceptual perspective, avoid all visual representations requiring time
consuming analyses or additional explanations, particularly the popular use of
merely conceptual representations and all forms of texts, including bullet
lists.
## EX 3.1 Prefer quantitative representations
![Figure EX 3.1: Prefer quantitative representations](img/ex-3.1.png)
Due to the time constraints usually involved with presentations,
conceptual graphs prove less suitable than charts, photos, maps, etc.
For a one-hour presentation, do not use more than three or four
conceptual representations. Do this only if they are absolutely
essential for comprehension. The audience will understand charts and
pictures (photos, drawings, etc.) better and faster, see Figure EX
3.1.
## EX 3.2 Avoid text slides in presentations
![Figure EX 3.2: Avoid text slides in presentations](img/ex-3.2.png)
Avoid all forms of text slides in presentations. Texts should either be
recited or written in a handout. A few exceptions to this rule are
specific texts being discussed such as definitions, quotes, etc. In
general, all forms of lists (bullet points) should appear only in the
written handout, not projected on the screen. True, if someone sees and
hears something simultaneously, he remembers it better than when he just
hears it, but bear in mind texts are not considered something merely to
be seen – they must be read and understood, see Figure EX 3.2.
## EX 4 Add comparisons
Visual perception is strongly based on setting one perceived object in relation
to another. Adding meaningful comparisons helps the eye evaluate faster, the
main purpose of charts.
## EX 4.1 Add scenarios
![Figure EX 4.1: Add scenarios](img/ex-4.1.png)
Scenarios such as “plan” and “previous year” are the most common references for comparison purposes. Add them whenever available. Use a standardized scenario notation for faster comprehension, see Figure EX 4.1.
## EX 4.2 Add variances
![Figure EX 4.2: Add variances](img/ex-4.2.png)
Having added scenarios for comparison purposes, the visualization of variances makes it easier to evaluate the situation. Use a standardized notation of variances for faster comprehension, see Figure EX 4.2.
## EX 5 Explain causes
Present data more understandable by showing interrelations, i.e. causes and dependencies. Seeing the entire context, especially extreme values and deviant values, helps to explain causes. Details increase not only the level of credibility but also comprehension. Use charts to prove, explain, and render something plausible, not to serve merely as decoration. This section focuses on the explanation of causes by using tree structures, clusters, and correlations. A more structured approach to increasing information density is discussed in the chapter “CONDENSE – Increase information density”.
## EX 5.1 Show tree structures
![Figure EX 5.1: Show tree structures](img/ex-5.1.png)
The presentation of the assumptions or basic data upon which a business analysis is based, results not only in better understanding, but also makes it more convincing. A good choice is the display of calculated measures in a tree structure, see Figure EX 5.1 (see also CO 5.2 “[Show related charts on one page](06-condense.md#co-52-show-related-charts-on-one-page)”).
## EX 5.2 Show clusters
![Figure EX 5.2: Show clusters](img/ex-5.2.png)
With the help of clusters in two-dimensional and three-dimensional forms,
large amounts of data very often can provide interesting and new
insights, see Figure EX 5.2.
## EX 5.3 Show correlations
![Figure EX 5.3: Show correlations](img/ex-5.3.png)
When comparing several data series, correlations are often sought in
order to better understand the interrelations. Suitable rankings and
comparisons can facilitate the understanding of patterns,
see Figure EX 5.3.
[← Organize content](02-structure.md) | [Avoid Clutter →](05-simplify.md)

165
docs/05-simplify.md Normal file
View File

@ -0,0 +1,165 @@
# SIMPLIFY – Avoid Clutter
SIMPLIFY covers all aspects of avoiding clutter in reports and presentations.
_Avoiding clutter_ means that reports and presentations avoid all components and
characteristics, which are too complicated, redundant, distracting or merely decorative.
This chapter covers avoiding unnecessary and decorative components and replacing them
with cleaner layouts, avoiding redundancies and distracting details.
1. [Avoid unnecessary components](#si-1-avoid-unnecessary-components)
2. [Avoid decorative styles](#si-2-avoid-decorative-styles)
3. [Replace with cleaner layout](#si-3-replace-with-cleaner-layout)
4. [Avoid redundancies](#si-4-avoid-redundancies)
5. [Avoid distracting details](#si-5-avoid-distracting-details)
## SI 1 Avoid unnecessary components
Completely avoid components, such as pictures, backgrounds, and logos, not
contributing to the comprehension of a report or presentation.
## SI 1.1 Avoid cluttered layouts
![Figure SI 1.1: Avoid cluttered layouts](img/si-1.1.png)
Layout concepts often contain elements that lack meaning but merely
conform to corporate design or personal taste. Avoid all these elements,
see Figure SI 1.1.
## SI 1.2 Avoid colored or filled backgrounds
![Figure SI 1.2: Avoid colored or filled backgrounds](img/si-1.2.png)
Numbers and labels are easiest to read when depicted in black on a white
background. Any type of background color or pattern makes something
harder to read, see Figure SI 1.2.
## SI 1.3 Avoid animation and transition effects
![Figure SI 1.3: Avoid animation and transition effects](img/si-1.3.png)
Animated _PowerPoint_ slides are not useful if the animation has
no meaning and does not support the message, see Figure SI 1.3. They
merely distract and confuse. Only the “appear” function is recommended
to be used for the gradual development of a slide.
## SI 2 Avoid decorative styles
Simplify complicated visualizations in order to facilitate and accelerate their comprehension. Whereas the section “Avoid unnecessary components” involves omitting entire layout elements, the aim here is to find the most suitable and simplest possible style of visualization elements.
## SI 2.1 Avoid borders, shades, and pseudo-3D
![Figure SI 2.1: Avoid borders, shades, and pseudo-3D](img/si-2.1.png)
In general, borders, shades, and pseudo-3D convey no meaning and make
comprehension more difficult. Shades and pseudo-3D might even give a
false visual impression. Avoid them because they do not add value,
see Figure SI 2.1.
## SI 2.2 Avoid decorative colors
![Figure SI 2.2: Avoid decorative colors](img/si-2.2.png)
If colors serve merely decorative purpose in one instance, using them for
meaning in another instance (e.g. for highlighting) becomes difficult.
Therefore use colors only if they convey meaning, see Figure SI 2.2.
## SI 2.3 Avoid decorative fonts
![Figure SI 2.3: Avoid decorative fonts](img/si-2.3.png)
A normal typeface and clear fonts increase legibility. Save bold and
cursive fonts for making distinctions, see Figure SI 2.3.
## SI 3 Replace with cleaner layout
Using a cleaner method of visualization decreases the amount of ink necessary to
convey a message.
## SI 3.1 Replace grid lines and value axes with data labels
![Figure SI 3.1: Replace grid lines and value axes with data labels](img/si-3.1.png)
Using integrated data labels can make value axes, tick marks, and
gridlines superfluous, see Figure SI 3.1. Gridlines, however, can
be useful in charts with missing reference points as might be the case
in charts with many data series and data points, or in small charts
(e.g. small multiples).
## SI 3.2 Avoid vertical lines by right-aligning data
![Figure SI 3.2: Avoid vertical lines by right-aligning data](img/si-3.2.png)
Omit all avoidable elements to make tables more straightforward. Avoid
vertical lines by right-aligning numerical values and the corresponding
column headers, see Figure SI 3.2.
## SI 4 Avoid redundancies
Avoiding redundant terms usually increases the legibility of charts and tables.
In some cases, a certain amount of redundancy can be helpful like when the time
period named in the chart title also appears in said chart. But unnecessary
redundancy impedes comprehension like when naming the year twelve times in a
chart with twelve monthly category labels.
## SI 4.1 Avoid superfluous extra words
![Figure SI 4.1: Avoid superfluous extra words](img/si-4.1.png)
Extra words such as “sum” and “total” are redundant because they add no
value to the meaning of the term they accompany. No difference exists
between “Europe” and “Sum of Europe”. Extra words make it harder to read
text elements, see Figure SI 4.1.
## SI 4.2 Avoid obvious terms
![Figure SI 4.2: Avoid obvious terms](img/si-4.2.png)
Terms such as “chart analysis”, “development”, or “comment” are redundant
because they name something already shown, see Figure SI 4.2. Other
obvious terms in charts and tables are “table”, “statistics”, “report”,
“visualization”, “structure”, or “trend”.
## SI 4.3 Avoid repeated words
![Figure SI 4.3: Avoid repeated words](img/si-4.3.png)
Repeated words in legends, axis labels, row headers, etc. such as
“division” in “division A”, “division B”, etc. or “2017” in “Q1 2017”,
“Q2 2017”, etc. should be avoided, see Figure SI 4.3. Omitting repeated
words usually increases the degree of legibility.
## SI 5 Avoid distracting details
In addition to avoiding noise and redundancy, omitting nonessential, distracting
information details facilitates comprehension. Examples include unnecessarily
large numbers and disproportionately detailed information in project or product
overviews.
## SI 5.1 Avoid labels for small values
![Figure SI 5.1: Avoid labels for small values](img/si-5.1.png)
Labels of small values are often hard to position and rarely contribute
to the comprehension of the message. Therefore they can be avoided in
most cases, see Figure SI 5.1. However, add them when special reference
is made to them. If it is necessary to label these small values or small
visualization elements, _assisting lines_ might be necessary.
## SI 5.2 Avoid long numbers
![Figure SI 5.2: Avoid long numbers](img/si-5.2.png)
Numbers with more than three digits in charts and four digits in tables
are hard to read; moreover, such precision is seldom necessary to
understand the message, see Figure SI 5.2.
## SI 5.3 Avoid unnecessary labels
![Figure SI 5.3: Avoid unnecessary labels](img/si-5.3.png)
Omit labels for data points that do not represent extreme values or
values of special importance, see Figure SI 5.3.
[← Choose proper visualization](04-express.md) | [Increase information density →](06-condense.md)

327
docs/06-condense.md Normal file
View File

@ -0,0 +1,327 @@
# CONDENSE – Increase information density
CONDENSE covers all aspects of increasing information density in reports and
presentations.
_Increasing information density_ means that all reports and presentations include
all information that is necessary to understand the respective message on one page.
This chapter covers using small components, utilizing space, as well as adding data,
elements, and objects.
1. [Use small components](#co-1-use-small-components)
2. [Maximize use of space](#co-2-maximize-use-of-space)
3. [Add data](#co-3-add-data)
4. [Add elements](#co-4-add-elements)
5. [Add objects](#co-5-add-objects)
## CO 1 Use small components
The need for a higher level of information density requires to display all
objects, elements, and signs as small as possible, while still being legible.
Different technical parameters apply to printed material, screen displays, and
projected slides.
## CO 1.1 Use small fonts
![Figure CO 1.1: Use small fonts](img/co-1.1.png)
In general, avoid oversize fonts. They needlessly waste space,
see Figure CO 1.1.
## CO 1.2 Use small elements
![Figure CO 1.2: Use small elements](img/co-1.2.png)
Small elements increase clarity. Large-scale symbols and highlights are
not more suitable than smaller symbols and highlights, see Figure
CO 1.2.
## CO 1.3 Use small objects
![Figure CO 1.3: Use small objects](img/co-1.3.png)
The size of charts and tables in reports and presentations should not be
as large as possible, rather as small as possible – yet only so small so
that the objects and all its details and labels can be read easily. This
provides room for more information and therefore better understanding of
the context, see Figure CO 1.3.
## CO 2 Maximize use of space
Utilizing free space is the fastest and easiest way to increase information
density. Make better use of needlessly wide margins and frames, or blank or
little used pages by filling them with helpful data pertaining to the context.
## CO 2.1 Use narrow page margins
![Figure CO 2.1: Use narrow page margins](img/co-2.1.png)
The page layout is often dominated by corporate design standards not made
for high information density but for attractive design, sacrificing
valuable space to layout elements such as extra wide page margins,
see Figure CO 2.1.
## CO 2.2 Reduce empty space
![Figure CO 2.2: Reduce empty space](img/co-2.2.png)
Reduce empty space to increase information density. This applies not only
to the page layout (see Figure CO 2.1) but
also to the layout of report objects such as charts and
tables (see Figure CO 2.2).
## CO 3 Add data
Adding more data to an existing visualization increases information density and
helps better understand the context.
## CO 3.1 Add data points
![Figure CO 3.1: Add data points](img/co-3.1.png)
Displaying more data points does not jeopardize the comprehension of
numerical data. For example, a monthly statistic of staff numbers over
twelve months in a year would be understood just as quickly as for the
same data series with twelve months for each of the last three years –
in other words, a total of 36 data points instead of twelve. Usually,
interesting relationships are only detected with an increased number of
elements in a data series (see Figure CO 3.1).
## CO 3.2 Add dimensions
![Figure CO 3.2: Add dimensions](img/co-3.2.png)
A very useful way to increase information density is to show more than
two dimensions of a business situation. A chart with only one dimension
(such as in a pie chart), visualizes only mundane things easily stated
in a simple sentence. Already charts with two dimensions can yield very
interesting relationships – yet those charts with three and more
dimensions yield structures leading to completely new insights (see
Figure CO 3.2).
## CO 4 Add elements
It is often appropriate to use two or more basic chart types (either horizontal
or vertical) to build _combined charts_ with a higher information
density. _Combined charts_ are treated as one entity as opposed to multiple charts. _Combined charts_ can be built both out from horizontal or vertical charts.
There are three types of combined charts depending on their type of combination:
_Overlay charts_, _multi-tier charts_, and _extended charts_. Additionally, chart elements can be embedded in tables and explanations can be integrated.
## CO 4.1 Show overlay charts
![Figure CO 4.1: Show overlay charts](img/co-4.1.png)
In an _overlay chart_, two or more basic charts overlap. These
overlapping charts always use the same category axis.
_Overlay charts_ can facilitate comprehension such as in the
combination of the development of sales (a series of columns) and the
return on sales in percent (a line). However, this approach can only be
used for a few chart combinations, see Figure CO 4.1.
![Figure CO 4.1-1: Overlay chart with lines and columns using different value axes](img/co-4.1-1.png)
_Overlay charts_ frequently use different value axes. A _column chart_ representing a measure (e.g. sales) combined with a _line chart_ representing another measure (e.g. employees) is a typical example.
![Figure CO 4.1-2: Overlay chart with columns and lines using the same value axis](img/co-4.1-2.png)
Sometimes, the same value axis is used as well. A _column chart_ representing a measure (e.g. sales) combined with a _line chart_ representing the same measure (e.g. industry average) is a typical example for such an _overlay chart_.
![Figure CO 4.1-3: Overlay column chart with integrated variances](img/co-4.1-3.png)
Column or bar charts with _integrated variances_ (variances displayed within the columns or bars) are other typical example for _overlay charts_ using the same value axis (see the last two figures).
Compared to two-tier charts, this presentation of two data series uses much less space. The disadvantages, though, are twofold: First, it is difficult to label the data of both the primary and secondary chart. Second, the development over time (horizontal axis) respectively the structure (vertical axis) of the primary chart is difficult to see.
![Figure CO 4.1-4: Overlay bar chart with integrated variances](img/co-4.1-4.png)
Suggestion: If there is enough space, use multi-tier charts instead.
## CO 4.2 Show multi-tier charts
![Figure CO 4.2: Show multi-tier charts](img/co-4.2.png)
_Use multi-tier charts_ to increase information density by adding
additional tiers to the same category axis for analyses on the same
basic data. Multi-tier charts are most frequently used for displaying
variances along with the basic values, see Figure CO 4.2.
![Figure CO 4.2-1: Horizontal multi-tier charts](img/co-4.2-1.png)
In a _two-tier chart_, a _secondary chart_ is shifted in parallel to the category axis of the _primary chart_. For horizontal charts the secondary chart appears above the primary chart, for vertical charts the secondary chart appears _to the right of_ the primary chart.
In both cases, the _category axes_ of the primary charts are
reduplicated in the secondary charts, usually having a different semantic
scenario design.
![Figure CO 4.2-2: Vertical multi-tier chart](img/co-4.2-2.png)
Both the primary and the secondary charts have their own value axes.
Value axes showing the same currency or the same physical unit should be
scaled identically.
In a _three-tier chart_ a third chart appears above a horizontal
or to the right of a vertical two-tier chart. In special cases, more
than three tiers can be combined.
Improve the interpretation of a primary chart showing grouped bars for
actual and plan data by adding variances. In the second and third
figure a secondary chart with absolute variances and a
tertiary pin chart with relative variances are combined.
## CO 4.3 Show extended charts
![Figure CO 4.3: Show extended charts](img/co-4.3.png)
An _extended chart_, arranges additional charts _next_ to
the primary chart by virtually extending the category axis. This way of
increasing information density often is used when displaying context
information such as market averages or competitor figures, see Figure CO
4.3.
![Figure CO 4.3-1: Horizontal extended chart](img/co-4.3-1.png)
For horizontal charts, additional charts appear to the left or right of the primary chart, for vertical charts, above or below. In both cases, position the _category axes_ of the additional charts on a virtual extension of the category axes of the primary chart.
In an extended chart, use the same value axis for both the primary and
the additional charts.
Improve the interpretation of a primary chart by adding extended charts
showing the same values from a different perspective. In the figure on
the left, a secondary _grouped column chart_ at the right hand
side shows the monthly average.
## CO 4.4 Embed chart elements in tables
![Figure CO 4.4: Embed chart elements in tables](img/co-4.4.png)
Increase the information density of tables by using _chart
elements_, see Figure CO 4.4. Bars, warning dots, sparklines,
and traffic lights are the predominant chart element types in tables.
**Table bars**
_Table bars_ are bar charts integrated into tables. The categories of these bar charts must correspond to the rows of a table. Both single bar charts with single bars or pins and waterfall bar charts are powerful means to visualize the absolute figures and variances in tables. Most recommendations concerning vertical chart types can be applied to _table bars_.
**Warning dots**
Not to be confused with _traffic lights, warning dots_ can
be a good solution in highlighting important negative, positive,
or questionable parts of a table. It is important to use only
very few warning dots in one table.
**Sparklines**
Omit _sparklines_ if not scaled properly. Individually
scaled sparklines can be misleading because small fluctuations
in a series of other small fluctuations look the same as big
fluctuations in a series of big fluctuations. However,
sparklines with proper scaling (e.g. indexed) can be helpful.
**Traffic lights**
_Traffic lights_ contain little information, as they
represent no more than three (red, green, yellow) states. Use
them only if there is no more information to be conveyed than
those two or three states (e.g. “yes” or “no”). In all other
cases, replace traffic lights with more suitable means of
representation, such as _table bars_.
## CO 4.5 Embed explanations
![Figure CO 4.5: Embed explanations](img/co-4.5.png)
Both the density of information and the level of comprehension increase
when explanations are embedded into charts and tables (this applies to
written reports and handouts only). When the explanation refers directly
to the visual presentation in question, it helps to establish a
connection and speeds up comprehension, see Figure CO 4.5.
## CO 5 Add objects
Reports and presentation material consist of one or more _pages_. The
content of one page can be viewed together without referring to other content,
e.g. flipping to other pages.
Reports and presentation material often arrange more than one chart on one page.
While this increases information density and fosters a higher level of
comparability, it presents a design challenge: A uniform notation concept and
consistent scaling are even more important than on pages with single charts.
The most important types of pages with multiple objects are small multiples and
multi-charts (including _ratio trees_).
## CO 5.1 Show small multiples
![Figure CO 5.1: Show small multiples](img/co-5.1.png)
Substantially improve the comprehension of complex relationships by
displaying charts of the same type and the same scale on the same page.
These charts are called _small multiples_, see Figure CO 5.1.
Typical applications are charts with different countries, products, or
projects placed next to each other. Of course, there is an upper limit
to the number of charts on one page, depending mainly on the page- and
font-size used.
![Figure CO 5.1-1: Screen page with small multiples](img/co-5.1-1.png)
Showing _small multiples_ is a good way to compare a set of up to
around 25 charts. Instead of exceeding this number on one page, a new
chart called “Others” containing the accumulation of all other elements
could be a solution.
As mentioned in the chapter “CHECK – Ensure visual integrity”, all small multiples must use the identical scale.
Working with _small multiples_ can be difficult if certain charts
show significantly bigger values than others. Using a different scale
for a chart with bigger values is not a feasible option, increase the
size of this chart instead.
## CO 5.2 Show related charts on one page
![Figure CO 5.2: Show related charts on one page](img/co-5.2.png)
Different from small multiples, _related charts cover different topics (different measures) on one page._ They mostly use different scales, too. This arrangement of charts on one page is sometimes called _multi-charts_. But the term *multi-charts* fails to underline the fact that these charts must have a useful relationship. It does not make sense to arrange several, completely unrelated charts on one page.
This approach offers high data density and a higher level of
comparability – but it can be a demanding visual and technical challenge
as a uniform notation concept, clear terms, and an understandable
scaling prove even more important (see Figure CO 5.2).
![Figure CO 5.2-1: Page showing a ratio tree](img/co-5.2-1.png)
Consistent scaling of _multi-charts_ can be difficult. Sometimes different scales for the same unit or measure are inevitable. In this case, clearly indicate the use of a different scale by an appropriate mean, e.g. scaling indicators.
*Ratio trees* are multi-charts showing root causes. Use ratio
trees to prove or explain a specific issue. Pointing out the assumptions
and root causes of variances or temporal evolvements improves
understanding and is more convincing, too. In general, the
_ratio_ is broken down into its components (mostly from left to
right). Thus individual charts, preferably identical size, are arranged
in a tree shape structure.
Consistent scaling of _ratio trees_ can be difficult. Sometimes different scales for the same unit or measure are inevitable. In this case, clearly indicate the use of a different scale by an appropriate mean, e.g. scaling indicators.
A typical example of a page showing a _ratio tree_ is the “Return
on asset” tree.
## CO 5.3 Show chart-table combinations
Combining charts and tables on a page is not to be confused with the integration of chart elements in tables.
_Chart-table combinations_ cover situations where a separate chart is added to a page with a table or vice versa. In general, such a combination is very useful if both objects display supplementary data. Tables simply listing the numbers of a chart are superfluous in most cases (see also UN 2.3 “[Unify the position of legends and labels](09-unify.md#un-23-unify-the-position-of-legends-and-labels”).
## CO 5.4 Show charts and tables in text pages
Embedding illuminating charts and tables in the text of a written report
helps the reader understanding the message.
Always position charts and tables in close proximity to the phrase
carrying the message, which the chart or table supports.
Text pages should contain a title element like other pages. Also use a title – and, if possible, a message – for every chart and table embedded in a text page.
[← Avoid Clutter](05-simplify.md) | [Ensure visual integrity →](07-check.md)

182
docs/07-check.md Normal file
View File

@ -0,0 +1,182 @@
# CHECK – Ensure visual integrity
CHECK covers all aspects of ensuring visual integrity in reports and presentations.
_Ensuring visual integrity_ means that reports and presentations present
information in the most truthful and the most easily understood way by avoiding
misleading visuals.
This chapter covers avoiding manipulated axes and visualization elements, using the
same scales, and showing data adjustments.
1. [Avoid manipulated axes](#ch-1-avoid-manipulated-axes)
2. [Avoid manipulated visualization elements](#ch-2-avoid-manipulated-visualization-elements)
3. [Avoid misleading representations](#ch-3-avoid-misleading-representations)
4. [Use the same scales](#ch-4-use-the-same-scales)
5. [Show data adjustments](#ch-5-show-data-adjustments)
## CH 1 Avoid manipulated axes
Charts serve as a means to visually compare numerical values. Manipulated axes
defeat this purpose of explaining actual interrelations.
## CH 1.1 Avoid truncated axes
![Figure CH 1.1: Avoid truncated axes](img/ch-1.1.png)
Charts with value axes not starting at zero (“cut” axes) are not “wrong”
in and of themselves, but the message to be visually conveyed then does
not correspond to the numerical values upon which the chart is based.
Therefore, value axes should generally start at zero, see Figure CH 1.1.
One exception to this rule exists: charts with indexed data (e.g. if the value for the index period is set to 100%) with only small variances from 100%. Here “zooming in” on the variances could be of greater value than indicating the absolute values (starting at zero). In this case, position the category labels at the 100% line in order to avoid misinterpretations.
## CH 1.2 Avoid logarithmic axes
![Figure CH 1.2: Avoid logarithmic axes](img/ch-1.2.png)
_Avoid logarithmic scales_ because they do not allow the visual
comparison of values, see Figure CH 1.2. In business, very few
applications for logarithmic axes exist (e.g. comparing growth rates of
different stocks in percent).
## CH 1.3 Avoid different class sizes
![Figure CH 1.3: Avoid different class sizes](img/ch-1.3.png)
If the categories represent ordered classes of elements (e.g. age
classes) as used for the visualization of distributions in histograms,
use class sizes of identical width (e.g. ten years). Otherwise, true
visual comparability is impossible, see Figure CH 1.3.
## CH 2 Avoid manipulated visualization elements
Displaying values differing by orders of magnitude can be challenging. Use
creative solutions instead of clipping visualization elements or cutting value
axes.
## CH 2.1 Avoid clipped visualization elements
![Figure CH 2.1: Avoid clipped visualization elements](img/ch-2.1.png)
Similar to “cut” axes, clipped visualization elements such as broken
columns make visual comparisons impossible, see Figure CH 2.1.
## CH 2.2 Use creative solutions for challenging scaling issues
![Figure CH 2.2: Use creative solutions for challenging scaling issues](img/ch-2.2.png)
Creative visualization elements can be used to compare extreme values,
e.g., displaying data in two-dimensional or even three-dimensional
visualization elements allows the comparison of values differing by
orders of magnitude, see Figure CH 2.2.
This rule must be clearly separated from the rules of section CH 3 “[Avoid misleading representations](07-check.md#ch-3-avoid-misleading-representations)” where area and volume visualizations are used improperly.
## CH 3 Avoid misleading representations
Graphical representations are misleading if the visual impression for the
observer differs from the underlying values.
## CH 3.1 Use correct area comparisons, prefer linear ones
![Figure CH 3.1: Use correct area comparisons, prefer linear ones](img/ch-3.1.png)
Using two-dimensional representations (areas of circles, icons, or
emblems) for the visualization of data is only valid, if the size of
these areas corresponds to the underlying values. The visual perception
will be misleading if the diameters of circles or the heights of icons
represent the values, see Figure CH 3.1.
## CH 3.2 Use correct volume comparisons, prefer linear ones
![Figure CH 3.2: Use correct volume comparisons, prefer linear ones](img/ch-3.2.png)
Similar to areas, the visual perception will be misleading, if the
(one-dimensional) diameters or the (two-dimensional) areas of
three-dimensional visualization elements (spheres, cubes, etc.)
represent the values, see Figure CH 3.2. Even if their volumes represent
the values, it is hard to perceive them properly. Prefer linear
comparisons instead.
## CH 3.3 Avoid misleading colored areas in maps
![Figure CH 3.3: Avoid misleading colored areas in maps](img/ch-3.3.png)
Different colored areas can be helpful to visualize the precipitation per
square meter or the population density. However, do not use colored
areas for the visualization of non-area-related figures such as market
shares or return on sales. Position columns or bars of identical scale
in maps instead. By the way, pie charts also work well here (an
exception to the EX 2.1 “[Replace pie…”](04-express.md#ex-21-replace-pie-and-ring-charts) because they can be placed precisely at one point, like a
city (see Figure CH 3.3).
## CH 4 Use the same scales
Proper visual comparison requires the usage of identical scales for identical
measure units, or – if this is not possible – a clear indication of the
difference. If possible, use a consistent scaling concept for the complete
report or presentation material.
## CH 4.1 Use identical scale for the same unit
![Figure CH 4.1: Use identical scale for the same unit](img/ch-4.1.png)
If presenting more than one chart of the same unit on one page, use the
identical scale for these charts, see Figure CH 4.1. In extreme
situations identical scales might not be desirable. In these exceptional
cases the use of scaling indicators (see [CH 4.3](07-check.md#ch-43-use-scaling-indicators-if-necessary)
and [UN 5.2](09-unify.md#un-52-unify-scaling-indicators)) can be helpful.
## CH 4.2 Size charts to given data
![Figure CH 4.2: Size charts to given data](img/ch-4.2.png)
Using identical scales in multiple charts can be demanding if the values
in the charts differ by orders of magnitude. A good solution is adapting
the chart size to the given data, see Figure CH 4.2.
## CH 4.3 Use scaling indicators if necessary
![Figure CH 4.3: Use scaling indicators if necessary](img/ch-4.3.png)
There are several ways to overcome challenging scaling problems. _Scaling indicators_, such as *scaling lines* and *scaling areas* indicating the same numerical height (typically a power of 10) in all charts are helpful to assist in comparing multiple charts (of the same unit) with different scales, see Figure CH 4.3.
This guide suggests a _semantic design_ for scaling lines and scaling areas, see UN 5.2 “[Unify scaling indicators](09-unify.md#un-52-unify-scaling-indicators)”.
## CH 4.4 Use outlier indicators if necessary
![Figure CH 4.4: Use outlier indicators if necessary](img/ch-4.4.png)
Certain values that are very big in comparison to other values are called
outliers. If an outlier is not important for business, e.g. a big
relative variance of a small value, then it is not appropriate to scale
the whole chart to this outlier. Therefore, use _outlier
indicators_ for unimportant outliers, see Figure CH 4.4.
This guide suggests a _semantic design_ for outlier indicators, see UN 5.3 “[Unify outlier indicators](09-unify.md#un-53-unify-outlier-indicators)”.
## CH 4.5 Use magnifying glasses
Another way to assist in scaling problems is to use “_magnifying glasses_” for zooming in on a part of a chart with a bigger scale. Use an appropriate visualization element to mark the part of a chart to be zoomed in and to link it to a second chart displaying the zoomed part on a bigger scale.
## CH 5 Show data adjustments
For longer time series, currency and inflationary effects can bias the visual
impression, hiding the real development of business.
## CH 5.1 Show the impact of inflation
![Figure CH 5.1: Show the impact of inflation](img/ch-5.1.png)
Making inflation effects transparent helps avoid misinterpretations of
time series visualizations, see Figure CH 5.1.
## CH 5.2 Show the currency impact
![Figure CH 5.2: Show the currency impact](img/ch-5.2.png)
Similar to inflation effects, the adjustment of currency effects can help
to avoid misinterpretations, see Figure CH 5.2.
[← Increase information density](06-condense.md) | [Apply semantic notation →](09-unify.md)

5
docs/08-semantic.md Normal file
View File

@ -0,0 +1,5 @@
# SEMANTIC RULES
_Semantic rules_ help to clearly relay content by using a uniform notation. They comprise the third part of this guide with the rule set [UNIFY](09-unify.md).
The semantic rules are based on the work of Rolf [Hichert](https://www.ibcs.com/consultant/rolf-hichert/) and other contributors of the [IBCS Association](https://www.ibcs.com/ibcs-association/). As they are manifested by convention, semantic rules must first be more widely accepted to become a standard.

1203
docs/09-unify.md Normal file
View File

File diff suppressed because it is too large Load Diff

3
docs/epilogue.md Normal file
View File

@ -0,0 +1,3 @@
# That's all, folks
Thanks for reading! Follow @[ohmypy](https://twitter.com/ohmypy) on Twitter to keep up with new stuff 🚀

121
docs/epub.css Normal file
View File

@ -0,0 +1,121 @@
/* This defines styles and classes used in the book */
body {
margin: 5%;
font-family: system-ui, -apple-system, BlinkMacSystemFont, "Segoe UI",
Roboto, Oxygen, Ubuntu, Cantarell, "PT Sans", "Open Sans", "Fira Sans",
"Droid Sans", "Helvetica Neue", Helvetica, Arial, sans-serif;
font-size: medium;
}
code {
font-family: Consolas, "Lucida Console", Monaco, monospace;
}
h1 {
text-align: left;
}
h2 {
text-align: left;
}
h3 {
text-align: left;
}
h4 {
text-align: left;
}
h5 {
text-align: left;
}
h6 {
text-align: left;
}
/* For title, author, and date on the cover page */
h1.title {
}
p.author {
}
p.date {
}
nav#toc ol,
nav#landmarks ol {
padding: 0;
margin-left: 1em;
}
nav#toc ol li,
nav#landmarks ol li {
list-style-type: none;
margin: 0;
padding: 0;
}
a.footnote-ref {
vertical-align: super;
}
em,
em em em,
em em em em em {
font-style: italic;
}
em em,
em em em em {
font-style: normal;
}
pre {
overflow-x: auto;
padding: 1em;
background: #f5f5f5;
}
code {
white-space: pre-wrap;
font-size: 0.8em;
}
span.smallcaps {
font-variant: small-caps;
}
span.underline {
text-decoration: underline;
}
q {
quotes: "“" "”" "‘" "’";
}
div.column {
display: inline-block;
vertical-align: top;
width: 50%;
}
div.hanging-indent {
margin-left: 1.5em;
text-indent: -1.5em;
}
table {
display: inline-block;
border: 1px solid #e5e5e5;
border-spacing: 0;
border-collapse: collapse;
overflow-x: auto;
max-width: 100%;
text-align: left;
vertical-align: top;
}
table caption {
font-size: 0.9em;
}
table td,
table th {
padding: 0.35em 0.75em;
vertical-align: top;
font-size: 0.9em;
border-bottom: 1px solid #e5e5e5;
}
table th {
line-height: 1.2;
}
table tr:last-child td {
border-bottom: none;
}
@media screen {
/* Workaround for iBooks issue; see #6242 */
.sourceCode {
overflow: visible !important;
white-space: pre-wrap !important;
}
}

BIN
docs/img/ch-1.1.png Normal file
View File

Binary file not shown.
Side by Side

After

Width:  |  Height:  |  Size: 26 KiB

BIN
docs/img/ch-1.2.png Normal file
View File

Binary file not shown.
Side by Side

After

Width:  |  Height:  |  Size: 38 KiB

BIN
docs/img/ch-1.3.png Normal file
View File

Binary file not shown.
Side by Side

After

Width:  |  Height:  |  Size: 43 KiB

BIN
docs/img/ch-2.1.png Normal file
View File

Binary file not shown.
Side by Side

After

Width:  |  Height:  |  Size: 18 KiB

BIN
docs/img/ch-2.2.png Normal file
View File

Binary file not shown.
Side by Side

After

Width:  |  Height:  |  Size: 29 KiB

BIN
docs/img/ch-3.1.png Normal file
View File

Binary file not shown.
Side by Side

After

Width:  |  Height:  |  Size: 46 KiB

BIN
docs/img/ch-3.2.png Normal file
View File

Binary file not shown.
Side by Side

After

Width:  |  Height:  |  Size: 96 KiB

BIN
docs/img/ch-3.3.png Normal file
View File

Binary file not shown.
Side by Side

After

Width:  |  Height:  |  Size: 88 KiB

BIN
docs/img/ch-4.1.png Normal file
View File

Binary file not shown.
Side by Side

After

Width:  |  Height:  |  Size: 29 KiB

BIN
docs/img/ch-4.2.png Normal file
View File

Binary file not shown.
Side by Side

After

Width:  |  Height:  |  Size: 22 KiB

BIN
docs/img/ch-4.3.png Normal file
View File

Binary file not shown.
Side by Side

After

Width:  |  Height:  |  Size: 36 KiB

BIN
docs/img/ch-4.4.png Normal file
View File

Binary file not shown.
Side by Side

After

Width:  |  Height:  |  Size: 43 KiB

BIN
docs/img/ch-5.1.png Normal file
View File

Binary file not shown.
Side by Side

After

Width:  |  Height:  |  Size: 18 KiB

BIN
docs/img/ch-5.2.png Normal file
View File

Binary file not shown.
Side by Side

After

Width:  |  Height:  |  Size: 36 KiB

BIN
docs/img/co-1.1.png Normal file
View File

Binary file not shown.
Side by Side

After

Width:  |  Height:  |  Size: 55 KiB

BIN
docs/img/co-1.2.png Normal file
View File

Binary file not shown.
Side by Side

After

Width:  |  Height:  |  Size: 74 KiB

BIN
docs/img/co-1.3.png Normal file
View File

Binary file not shown.
Side by Side

After

Width:  |  Height:  |  Size: 30 KiB

BIN
docs/img/co-2.1.png Normal file
View File

Binary file not shown.
Side by Side

After

Width:  |  Height:  |  Size: 28 KiB

BIN
docs/img/co-2.2.png Normal file
View File

Binary file not shown.
Side by Side

After

Width:  |  Height:  |  Size: 61 KiB

BIN
docs/img/co-3.1.png Normal file
View File

Binary file not shown.
Side by Side

After

Width:  |  Height:  |  Size: 16 KiB

BIN
docs/img/co-3.2.png Normal file
View File

Binary file not shown.
Side by Side

After

Width:  |  Height:  |  Size: 53 KiB

BIN
docs/img/co-4.1-1.png Normal file
View File

Binary file not shown.
Side by Side

After

Width:  |  Height:  |  Size: 35 KiB

BIN
docs/img/co-4.1-2.png Normal file
View File

Binary file not shown.
Side by Side

After

Width:  |  Height:  |  Size: 44 KiB

BIN
docs/img/co-4.1-3.png Normal file
View File

Binary file not shown.
Side by Side

After

Width:  |  Height:  |  Size: 42 KiB

BIN
docs/img/co-4.1-4.png Normal file
View File

Binary file not shown.
Side by Side

After

Width:  |  Height:  |  Size: 34 KiB

BIN
docs/img/co-4.1.png Normal file
View File

Binary file not shown.
Side by Side

After

Width:  |  Height:  |  Size: 28 KiB

BIN
docs/img/co-4.2-1.png Normal file
View File

Binary file not shown.
Side by Side

After

Width:  |  Height:  |  Size: 71 KiB

BIN
docs/img/co-4.2-2.png Normal file
View File

Binary file not shown.
Side by Side

After

Width:  |  Height:  |  Size: 41 KiB

BIN
docs/img/co-4.2.png Normal file
View File

Binary file not shown.
Side by Side

After

Width:  |  Height:  |  Size: 44 KiB

BIN
docs/img/co-4.3-1.png Normal file
View File

Binary file not shown.
Side by Side

After

Width:  |  Height:  |  Size: 171 KiB

BIN
docs/img/co-4.3.png Normal file
View File

Binary file not shown.
Side by Side

After

Width:  |  Height:  |  Size: 33 KiB

BIN
docs/img/co-4.4.png Normal file
View File

Binary file not shown.
Side by Side

After

Width:  |  Height:  |  Size: 63 KiB

BIN
docs/img/co-4.5.png Normal file
View File

Binary file not shown.
Side by Side

After

Width:  |  Height:  |  Size: 29 KiB

BIN
docs/img/co-5.1-1.png Normal file
View File

Binary file not shown.
Side by Side

After

Width:  |  Height:  |  Size: 69 KiB

BIN
docs/img/co-5.1.png Normal file
View File

Binary file not shown.
Side by Side

After

Width:  |  Height:  |  Size: 36 KiB

BIN
docs/img/co-5.2-1.png Normal file
View File

Binary file not shown.
Side by Side

After

Width:  |  Height:  |  Size: 67 KiB

BIN
docs/img/co-5.2.png Normal file
View File

Binary file not shown.
Side by Side

After

Width:  |  Height:  |  Size: 40 KiB

BIN
docs/img/ex-1.1-1.png Normal file
View File

Binary file not shown.
Side by Side

After

Width:  |  Height:  |  Size: 44 KiB

BIN
docs/img/ex-1.1-10.png Normal file
View File

Binary file not shown.
Side by Side

After

Width:  |  Height:  |  Size: 30 KiB

BIN
docs/img/ex-1.1-11.png Normal file
View File

Binary file not shown.
Side by Side

After

Width:  |  Height:  |  Size: 42 KiB

BIN
docs/img/ex-1.1-12.png Normal file
View File

Binary file not shown.
Side by Side

After

Width:  |  Height:  |  Size: 27 KiB

BIN
docs/img/ex-1.1-13.png Normal file
View File

Binary file not shown.
Side by Side

After

Width:  |  Height:  |  Size: 30 KiB

BIN
docs/img/ex-1.1-14.png Normal file
View File

Binary file not shown.
Side by Side

After

Width:  |  Height:  |  Size: 40 KiB

BIN
docs/img/ex-1.1-15.png Normal file
View File

Binary file not shown.
Side by Side

After

Width:  |  Height:  |  Size: 112 KiB

BIN
docs/img/ex-1.1-16.png Normal file
View File

Binary file not shown.
Side by Side

After

Width:  |  Height:  |  Size: 23 KiB

BIN
docs/img/ex-1.1-17.png Normal file
View File

Binary file not shown.
Side by Side

After

Width:  |  Height:  |  Size: 50 KiB

BIN
docs/img/ex-1.1-18.png Normal file
View File

Binary file not shown.
Side by Side

After

Width:  |  Height:  |  Size: 61 KiB

BIN
docs/img/ex-1.1-2.png Normal file
View File

Binary file not shown.
Side by Side

After

Width:  |  Height:  |  Size: 44 KiB

BIN
docs/img/ex-1.1-3.png Normal file
View File

Binary file not shown.
Side by Side

After

Width:  |  Height:  |  Size: 52 KiB

BIN
docs/img/ex-1.1-4.png Normal file
View File

Binary file not shown.
Side by Side

After

Width:  |  Height:  |  Size: 43 KiB

BIN
docs/img/ex-1.1-5.png Normal file
View File

Binary file not shown.
Side by Side

After

Width:  |  Height:  |  Size: 37 KiB

BIN
docs/img/ex-1.1-6.png Normal file
View File

Binary file not shown.
Side by Side

After

Width:  |  Height:  |  Size: 37 KiB

BIN
docs/img/ex-1.1-7.png Normal file
View File

Binary file not shown.
Side by Side

After

Width:  |  Height:  |  Size: 24 KiB

BIN
docs/img/ex-1.1-8.png Normal file
View File

Binary file not shown.
Side by Side

After

Width:  |  Height:  |  Size: 41 KiB

BIN
docs/img/ex-1.1-9.png Normal file
View File

Binary file not shown.
Side by Side

After

Width:  |  Height:  |  Size: 61 KiB

BIN
docs/img/ex-1.1.png Normal file
View File

Binary file not shown.
Side by Side

After

Width:  |  Height:  |  Size: 47 KiB

BIN
docs/img/ex-1.2-1.png Normal file
View File

Binary file not shown.
Side by Side

After

Width:  |  Height:  |  Size: 66 KiB

BIN
docs/img/ex-1.2-10.png Normal file
View File

Binary file not shown.
Side by Side

After

Width:  |  Height:  |  Size: 80 KiB

BIN
docs/img/ex-1.2-11.png Normal file
View File

Binary file not shown.
Side by Side

After

Width:  |  Height:  |  Size: 83 KiB

BIN
docs/img/ex-1.2-12.png Normal file
View File

Binary file not shown.
Side by Side

After

Width:  |  Height:  |  Size: 74 KiB

BIN
docs/img/ex-1.2-13.png Normal file
View File

Binary file not shown.
Side by Side

After

Width:  |  Height:  |  Size: 65 KiB

BIN
docs/img/ex-1.2-14.png Normal file
View File

Binary file not shown.
Side by Side

After

Width:  |  Height:  |  Size: 72 KiB

BIN
docs/img/ex-1.2-15.png Normal file
View File

Binary file not shown.
Side by Side

After

Width:  |  Height:  |  Size: 73 KiB

BIN
docs/img/ex-1.2-16.png Normal file
View File

Binary file not shown.
Side by Side

After

Width:  |  Height:  |  Size: 66 KiB

BIN
docs/img/ex-1.2-17.png Normal file
View File

Binary file not shown.
Side by Side

After

Width:  |  Height:  |  Size: 61 KiB

BIN
docs/img/ex-1.2-18.png Normal file
View File

Binary file not shown.
Side by Side

After

Width:  |  Height:  |  Size: 52 KiB

BIN
docs/img/ex-1.2-19.png Normal file
View File

Binary file not shown.
Side by Side

After

Width:  |  Height:  |  Size: 60 KiB

BIN
docs/img/ex-1.2-2.png Normal file
View File

Binary file not shown.
Side by Side

After

Width:  |  Height:  |  Size: 78 KiB

BIN
docs/img/ex-1.2-20.png Normal file
View File

Binary file not shown.
Side by Side

After

Width:  |  Height:  |  Size: 97 KiB

BIN
docs/img/ex-1.2-21.png Normal file
View File

Binary file not shown.
Side by Side

After

Width:  |  Height:  |  Size: 100 KiB

BIN
docs/img/ex-1.2-22.png Normal file
View File

Binary file not shown.
Side by Side

After

Width:  |  Height:  |  Size: 49 KiB

BIN
docs/img/ex-1.2-23.png Normal file
View File

Binary file not shown.
Side by Side

After

Width:  |  Height:  |  Size: 50 KiB

BIN
docs/img/ex-1.2-24.png Normal file
View File

Binary file not shown.
Side by Side

After

Width:  |  Height:  |  Size: 51 KiB

BIN
docs/img/ex-1.2-25.png Normal file
View File

Binary file not shown.
Side by Side

After

Width:  |  Height:  |  Size: 84 KiB

BIN
docs/img/ex-1.2-26.png Normal file
View File

Binary file not shown.
Side by Side

After

Width:  |  Height:  |  Size: 55 KiB

BIN
docs/img/ex-1.2-27.png Normal file
View File

Binary file not shown.
Side by Side

After

Width:  |  Height:  |  Size: 63 KiB

BIN
docs/img/ex-1.2-3.png Normal file
View File

Binary file not shown.
Side by Side

After

Width:  |  Height:  |  Size: 74 KiB

BIN
docs/img/ex-1.2-4.png Normal file
View File

Binary file not shown.
Side by Side

After

Width:  |  Height:  |  Size: 76 KiB

BIN
docs/img/ex-1.2-5.png Normal file
View File

Binary file not shown.
Side by Side

After

Width:  |  Height:  |  Size: 91 KiB

BIN
docs/img/ex-1.2-6.png Normal file
View File

Binary file not shown.
Side by Side

After

Width:  |  Height:  |  Size: 76 KiB

BIN
docs/img/ex-1.2-7.png Normal file
View File

Binary file not shown.
Side by Side

After

Width:  |  Height:  |  Size: 78 KiB

BIN
docs/img/ex-1.2-8.png Normal file
View File

Binary file not shown.
Side by Side

After

Width:  |  Height:  |  Size: 79 KiB

BIN
docs/img/ex-1.2-9.png Normal file
View File

Binary file not shown.
Side by Side

After

Width:  |  Height:  |  Size: 54 KiB

BIN
docs/img/ex-1.2.png Normal file
View File

Binary file not shown.
Side by Side

After

Width:  |  Height:  |  Size: 35 KiB

BIN
docs/img/ex-2.1.png Normal file
View File

Binary file not shown.
Side by Side

After

Width:  |  Height:  |  Size: 36 KiB

BIN
docs/img/ex-2.2.png Normal file
View File

Binary file not shown.
Side by Side

After

Width:  |  Height:  |  Size: 71 KiB

BIN
docs/img/ex-2.3.png Normal file
View File

Binary file not shown.
Side by Side

After

Width:  |  Height:  |  Size: 65 KiB

Some files were not shown because too many files have changed in this diff Show More