Website | Visualisations | Data |
Here you will find all the data visualisations and infographics attached to our articles published on the Observatory website. Each visualisation is published under an open source MIT licence, and you are free to reuse/reproduce/redistribute, with attribution.
We try to follow industry best-practices in data visualisation and try to establish our very own visualisation guidelines for all chart types. You can read about these, as well as the tools we use in πvisualisation guidelines .
In the world of data visualisation (even in the expert academic and professional literature) the expressions of figure, chart, plot, panel, graph, diagram, visualisation (and possibly others) are conflated and used (incorrectly?) interchangeably, sometimes with the same expression referring to completely different graphical objects under various contexts. We believe that this might cause confusion for the reader and therefore, at the Observatory, we strive to maintain the following nomenclature to refer to our graphical representations of data:
- At the Observatory, we publish articles.
- Each article may contain several figures.
- Each figure may contain several charts. Sometimes we call these charts panels. For example, imagine a horizontal figure that contains two line charts, side-by-side. We might call these components Figure 1 chart a and refer to it as Figure 1 panel a, or just simply Figure 1a.
- Each chart may be composed of multiple visualisations. For example, a line chart might also have points highlighting and delimiting its segments. In this case, we would have a line plot and a scatter plot visualisation layered on top of each other, composing the chart. To add to your confusion, we sometimes may call these components simply line chart or scatter chart instead of plot, but in this case we actually refer to the visualisations themselves - as various forms of graphical data representation. We chose to stick with the visualisation name, since not all charts are plots in the classical sense: typically plot is an expression reserved in colloquial speech to refer to a line plot, scatter plot, polar plot or even a box plot, and we typically use chart for maybe a pie chart, bar chart, column chart or even candlestick chart. However, there are also more complex visualisation forms, such as a Sankey diagram, a network graph, a histogram or even beeswarm. Therefore, in order to unequivocally refer to all of these graphical data representation tpyes, we use visualisation.
To summarise:
- Visualisations are chart components.
- plot, graph, diagram (and depending on context chart also) simply translate to visualisation
- Figures are made up of one or more charts (or = panels).
- Articles may contain one of more figures.
- The Observatory has a collection of articles.
Under articles each visualisation has their own folder, and within that folder you will find separate subfolder for the data (in csv
format) , the visualisation (in json
), and in some cases accompanying HTML
, CSS
and JavaScript
. The naming convention for articles is yyyy-mm-dd-<ARTICLE_ID>
. We try to maintain that <ARTICLE_ID>
matches the URL permalink
of the article from the website. We are currently transitioning this scheme to an updated one, where each folder contains a config.json
file, listing all of the respective article's metadata. The <ARTICLE_ID>
cannot contain /
characters.
The articles may contain figures - each composed of one or more charts. Each chart has their own (usually Vega-lite or Vega, but sometimes a D3plus or eCharts) json
specification. For composite figures containing multiple charts, we may produce (depending on the tool used) a separate file for each chart (e.g. fig1
or fig2a
and fig2b
), but sometimes this is handled within the tool and only one file, with the composite figure (fig2
) is produced. We normalize the data and compile the visualisations using the parser.ipynb
Jupyter notebook.
- The automatically generated
README.md
file contains a sneak peek of all the charts included in the article, in the form of static.png
images and their names. - The
raw
folder contains the original data, as we have received it from the author (depending on the circumstances, this might not always be public) - The
data
folder contains the normalised data and it is typically the output of theparser
.ipynb. Usually (unless data is shared between charts) there is a separate data file generated for each chart. - The
visualisation
folder contains multiple folders corresponding to the names of charting tools used (e.g.vega-lite
ord3plus
). Some charts may be replicated over multiple tools. - Each tool folder contains several theme folders (but typically two,
light
anddark
) - Each theme folder contains several aspect folders (but typically two,
desktop
andmobile
) - For some older charts, these subfolders under
visualisation
might be missing. In this case, thevega-lite
tool is assumed to be used as the default, with thelight
theme and thedesktop
aspect. - Each full path under
visualisation
(e.g.visualisation/vega-lite/dark/desktop
) contains:- A
<CHART_ID>.json
(or.js
for the case of D3plus and some other tools) file for each chart (typically one for each figure in the article, but composite figures may be split over multiple charts). This is is what is typically called the chart specification or the chart config. - An automatically generated
<CHART_ID>.HTML
file for direct embedding. This uses additionalJavaScript
code to offer a full-fledgedHTML
page with the data visualisation working out of the box. This is useful in some cases, when problems with directly embedding the chart specification may arise. - Whenever data compatibility issues are likely to arise, or the data cannot be formatted using simple in-memory data manipulation techniques (e.g. Vega data transforms) only, we also generate a file ending in
_local.json
, where all data is stored as a staticJavascript Object
inside the chart specificationjson
file (this is the safest but also the slowest). - The format of the
<CHART_ID>
should follow thefig1a_chart-name-with-space
naming convention (with_local
added at the end, as necessary). The<CHART_ID>
cannot contain/
characters.
- A
config.json
holds the article metadata (this has just been introduced recently, so it may not exist for all articles yet). It has the following keys:uid
: the article's unique identifiername
: the article's name - same as the<ARTICLE_ID>
mentioned aboveversion
: version of the article (1
by default). For update type posts, this is typically larger than1
.previous, next
: the articleuid
s that this article follows/precedestitle
: human readable article title as presented on the Website / Trello (the two should match)url
: the published article's URL on the websitetrello
: link to the Trello card of the articlegithub
: link to article's folder in this repository under/articles
charts
:JSON
list[]
of<CHART_ID>
s included in the article. Can contain just<CHART_ID>
s - then the parent article's path is assumed - or a full path<ARTICLE_ID>/<CHART_ID>
, pointing to another article's chart.
Issues of the ECO magazine behave like articles and can be found under the magazine folder (e.g. magazine/issue-1
).
- You may use any of the chart specifications listed above - the "naked" or the
_local
versions of the<CHART_ID>
s for direct embedding on compatible websites (e.g. Wordpress or Flourish). - You may use the
HTML
files generated to overcome compatibility challenges of more stubborn hosting environments. - Furthermore, we maintain a global
viewer.html
that can take a data source parameters as its URL hash. E.g. visitinghttps://economicsobservatory.github.io/ECOvisualisations/viewer.html#
articles/2021-04-14-a-year-in-the-uk-labour-market-whats-happened-over-the-coronavirus-pandemic/visualisation/fig5_absent_from_work
will open the viewer for Figure 5 of this article (currently, this works for charts under thevega-lite
specification, but we are continuously updating it to include all of our charts, regardless of the tool used to generate it).
Option 3, using the viewer.html
is the recommended way for embedding our data visualisations on other sites. This is is because if we change our repository structure and/or charting API in the future, we can ensure that all backwards compatibility with existing embedded charts is maintained, but the updates (such as a new theme) are reflected on all of our charts instantly.
You may think of this as a form of π¨ ChaaS - chart as a service.
All of our chart data are published under their respective article subfolders, but on top of that we also operate the ECOdataHUB, where you will find a trove of data used in our articles and analyses, as well as interactive visualisation exploration interfaces. Whenever possible, we try to follow a TIDY format. You can read about our data zen in πdata guidelines.
To learn about the technologies used or build a similar charts like this you can follow the instructions on the guidelines page. If you discovered any bugs or have any specific suggestions or feature requests please use the Issues page.
The Economics Observatory is run out of the University of Bristol and you can read more about us here. For any technical or visualization-related questions you may contact DΓ©nes. For economics-related queries and anything else about the site content, or further collaborations, you may contact Charlie.
If you would like to use the site as an information source or any of the visualizations or the data presented, you are free to do so under an MIT licence (you're free to modify anything, as long you as you mention us). Furthermore, the content of all of our articles presented on the Economics Observatory website is shareable under a Creative Commons ShareAlike 4.0 license.
If you would like to refer to it in publications or other scientific works of any kind, please use the following style:
Title of article or chart
, Economics Observatory, 2021,link to article or chart
, published on:publication date
, accessed on:access date