class: middle, title background-size: contain <!----- Make a pdf using: decktape generic --key=ArrowRight --load-pause 1800 --slides '1-55' --size '1216x684' --url-load-timeout 80000 --page-load-timeout 40000 "week-07/slides/smi105-week-7.html" week-07/slides/smi105-week-7.pdf -----> <br><br> # Publishing a data visualisation #### EDC101: Week 7 <br><br> **Dr. Calum Webb**<br> Sheffield Methods Institute, the University of Sheffield<br> [c.j.webb@sheffield.ac.uk](mailto:c.j.webb@sheffield.ac.uk)
--- class: middle, inverse # Sign in --- class: middle ## Learning outcomes .panelset[ .panel[.panel-name[What will I learn?] By the end of this week you will know: * How to take the publication medium your data visualisation will feature in into account when exporting and deciding on size, orientation, and so on * How to apply different technical terms from print & design to describe differences in quality, orientation, size (e.g. aspect ratio), and method of reproduction (rasterised versus vectorised) * How to make your data visualisation look good no matter where it's published! ] ] --- class: inverse, middle # That's a nice data visualisation... .tuos_purple[How does it look on your phone?] --- class: inverse, middle # That's a nice data visualisation... .white[How does it look on your phone?] --- class: inverse, middle # That's a nice data visualisation... .white[How does it look on your laptop?] --- class: inverse, middle # That's a nice data visualisation... .white[How does it look projected on the wall?] --- class: inverse, middle # That's a nice data visualisation... .white[How does it look projected in a print newspaper?] --- class: inverse, middle # Rarely is the same data visualisation suitable for everywhere it might be seen. You might need to customise your data visualisation for different mediums, or test how it looks on different publication formats. --- class: inverse ### Don't be the person that puts a screenshot of a dashboard in your report! .pull-left[ .center[ <img src="images/wrong-format-1.png" width="60%" /> ] ] -- .pull-right[ .center[ <img src="images/wrong-format-2.png" width="60%" /> Or worse! ] ] --- class: middle .pull-left-big[ .center[ <img src="images/sankey-website.png" width="100%" /> ] ] .middle-right-small[ * An image of a Sankey plot from my personal website when viewed on a web browser... ] --- class: middle .pull-left-big[ .center[ <img src="images/sankey-phone.jpeg" width="30%" /> ] ] .middle-right-small[ * An image of a Sankey plot from my personal website when viewed on a web browser... * And on my mobile phone. Luckily the same image works fairly well regardless, but maybe the text is a bit too small for phones. ] --- class: middle .pull-left-big[ .center[ <img src="images/diverging-bar-report.png" width="50%" /> ] ] .middle-right-small[ * Here's a graph that's from a research report I've written... ] --- class: middle .pull-left-big[ .center[ <img src="images/diverging-bar-slides.png" width="100%" /> ] ] .middle-right-small[ * Here's a graph that's from a research report I've written... * But here's how it looks when I present it using a slidedeck... ] --- class: middle .pull-left-big[ .center[ <img src="images/diverging-bar-website.png" width="100%" /> ] ] .middle-right-small[ * Here's a graph that's from a research report I've written... * But here's how it looks when I present it using a slidedeck... * And here's how it looks on the website I've changed the aspect ratio so it fits the space better (not trying to squeeze a vertical image on a horizontal space), and on the website changed the theme background to blend in and make it look seamless. ] --- class: middle .pull-left-big[ .center[ <img src="images/map-report.png" width="50%" /> ] ] .middle-right-small[ * Here's a map from the same report in the report ] --- class: middle .pull-left-big[ .center[ <img src="images/map-phone.png" width="50%" /> ] ] .middle-right-small[ * Here's a map from the same report in the report * But here's how it looks on the website on a phone ratio ] --- class: middle .pull-left-big[ .center[ <img src="images/map-presentation.png" width="100%" /> ] ] .middle-right-small[ * Here's a map from the same report in the report * But here's how it looks on the website on a phone ratio * And on my presentation slides Again, the background changes to make it seamless and in the phone and presentation slide versions I have **removed the place names**, because that information could be hidden and only shown on tap/hover/click. I also cut off Scotland and Northern Ireland to maximise the size and give the text the best chance of being readable. ] --- class: inverse, middle # Publishing a data visualisation: Print --- class: middle .pull-left[ ### How do we optimise the publication of data visualisation in print? Things we want to consider: * Layout, aspect ratio and orientation * In-line versus stand-alone (splitting up the page) * Resolution (dpi) * Colour (or lack thereof!) * File types (raster or vector images) All of these sound obvious, but on a big project it can be easy for them to go wrong! **You can have beautiful design, but if it doesn't suit the publication medium, it will look bad!** ] .pull-right[ ] --- class: middle .pull-left[ ### How do we optimise the publication of data visualisation in print? Things we want to consider: * **Layout, aspect ratio and orientation** * In-line versus stand-alone (splitting up the page) * Resolution (dpi) * Colour (or lack thereof!) * File types (raster or vector images) ] .pull-right[ * Portrait * Landscape ] --- class: middle .middle-left[ ### How do we optimise the publication of data visualisation in print? Things we want to consider: * **Layout, aspect ratio and orientation** * In-line versus stand-alone (splitting up the page) * Resolution (dpi) * Colour (or lack thereof!) * File types (raster or vector images) ] .pull-right[ .center[ <img src="smi105-week-7_files/figure-html/unnamed-chunk-12-1.png" width="400" height="550" /> ] ] --- class: middle .middle-left[ ### How do we optimise the publication of data visualisation in print? Things we want to consider: * **Layout, aspect ratio and orientation** * In-line versus stand-alone (splitting up the page) * Resolution (dpi) * Colour (or lack thereof!) * File types (raster or vector images) ] .pull-right[ .center[ <img src="smi105-week-7_files/figure-html/unnamed-chunk-13-1.png" width="550" height="350" /> ] ] --- class: middle .middle-left[ ### How do we optimise the publication of data visualisation in print? Things we want to consider: * Layout, aspect ratio and orientation * **In-line versus stand-alone (splitting up the page)** * Resolution (dpi) * Colour (or lack thereof!) * File types (raster or vector images) ] .pull-right[ .sans-serif[Most attention on the issue has been focused on the spreading of misinformation by unorganised individuals, at the expense of analysing the role that governments play in disseminating misinformation.] .center[ <img src="smi105-week-7_files/figure-html/unnamed-chunk-14-1.png" width="550" height="300" /> ] .sans-serif[Experts are increasingly recognising that a tactic of foreign governments tends to include disseminating false of misleading claims about rival countries through official agencies on social media. Perhaps because social media is seen as a "less formal" means of communication, where intent can often be hard to discern...] ] --- class: middle .middle-left[ ### How do we optimise the publication of data visualisation in print? Things we want to consider: * Layout, aspect ratio and orientation * **In-line versus stand-alone (splitting up the page)** * More complex data visualisations (e.g. facets) showing variation may benefit from being stand-alone on their own page. * Resolution (dpi) * Colour (or lack thereof!) * File types (raster or vector images) ] .pull-right[ .center[ <img src="smi105-week-7_files/figure-html/unnamed-chunk-15-1.png" width="550" height="550" /> ] ] --- class: middle .middle-left[ ### How do we optimise the publication of data visualisation in print? Things we want to consider: * Layout, aspect ratio and orientation * **In-line versus stand-alone (splitting up the page)** * Think about the most appropriate orientation depending on *how much of the page* your data visualisation is taking up. * Resolution (dpi) * Colour (or lack thereof!) * File types (raster or vector images) ] .pull-right[ .center[ <img src="images/iso_paper_size_golden_spiral.png" width="100%" /> ] ] --- class: middle .middle-left[ ### How do we optimise the publication of data visualisation in print? Things we want to consider: * Layout, aspect ratio and orientation * In-line versus stand-alone (splitting up the page) * **Resolution (dpi)** * Refers to the "quality" and detail of the image. On paper there is no loading time, so data visualisations can be as high a resolution (dpi = dots per inch) as the printer allows. Some publishers will have requirements for dpi. * Colour (or lack thereof!) * File types (raster or vector images) ] .pull-right[ .center[ <img src="images/DPI_and_PPI.png" width="100%" /> ] ] --- class: middle .middle-left[ ### How do we optimise the publication of data visualisation in print? Things we want to consider: * Layout, aspect ratio and orientation * In-line versus stand-alone (splitting up the page) * **Resolution (dpi)** * Refers to the "quality" and detail of the image. On paper there is no loading time, so data visualisations can be as high a resolution (dpi = dots per inch) as the printer allows. Some publishers will have requirements for dpi. * Colour (or lack thereof!) * File types (raster or vector images) ] .pull-right[ .center[ <img src="images/ex_plot1_dpi100.png" width="100%" /> Plot at 100dpi (20kb) ] ] --- class: middle .middle-left[ ### How do we optimise the publication of data visualisation in print? Things we want to consider: * Layout, aspect ratio and orientation * In-line versus stand-alone (splitting up the page) * **Resolution (dpi)** * Refers to the "quality" and detail of the image. On paper there is no loading time, so data visualisations can be as high a resolution (dpi = dots per inch) as the printer allows. Some publishers will have requirements for dpi. * Colour (or lack thereof!) * File types (raster or vector images) ] .pull-right[ .center[ <img src="images/ex_plot1_dpi400.png" width="100%" /> Plot at 400dpi (100kb) ] ] --- class: middle .middle-left[ ### How do we optimise the publication of data visualisation in print? Things we want to consider: * Layout, aspect ratio and orientation * In-line versus stand-alone (splitting up the page) * **Resolution (dpi)** * Refers to the "quality" and detail of the image. On paper there is no loading time, so data visualisations can be as high a resolution (dpi = dots per inch) as the printer allows. Some publishers will have requirements for dpi. * Colour (or lack thereof!) * File types (raster or vector images) ] .pull-right[ > "Line artwork should be supplied in tif or eps format, black and white1 (also known as 1- bit), **resolution 1200 dpi at final size**. Combination artwork (line/tone) should be supplied in tif or eps format, grayscale (also known as 8-bit), **resolution: 800 dpi at final size.**" .right[Requirements for authors from the [Journal<br>of Social Policy](https://www.cambridge.org/core/journals/journal-of-social-policy/information/author-instructions/preparing-your-materials) (2024)] ] --- class: middle .middle-left[ ### How do we optimise the publication of data visualisation in print? Things we want to consider: * Layout, aspect ratio and orientation * In-line versus stand-alone (splitting up the page) * Resolution (dpi) * **Colour (or lack thereof!)** * Does the publication allow colour? If so, how much colour? Colour backgrounds? A limited number of colours? * File types (raster or vector images) ] -- .pull-right[ If colour is allowed: * High contrast works better (at least 20% difference between colours) * Avoid white on black for text * Avoid text font sizes smaller than size 6 * Avoid transparency, use low saturation shades that blend into the background instead * **Consider the base colour of the paper it's being printed on** — if it's brilliant white, use a more grey font colour (to avoid the contrast being too high). If it's off-white (e.g. newspaper), use black. ] --- class: middle .middle-left[ ### How do we optimise the publication of data visualisation in print? Things we want to consider: * Layout, aspect ratio and orientation * In-line versus stand-alone (splitting up the page) * Resolution (dpi) * Colour (or lack thereof!) * **File types (raster or vector images)** * Files come in many types: .png, .jpeg/.jpg, .tif/.tiff, .svg, .eps. Some file types are *rasterised* (drawn with pixels/dots), while others are *vectorised* (drawn with maths). Raster files work better when there is a lot of unique elements and colours, vector files work better when there are fewer elements and colours. ] -- .pull-right[ * **.TIFF** files are still popular with print media today because they are lossless (there is no compression to make the file size smaller — remember, we don't need to worry about file size because paper doesn't need to load!) and support more colours (other file formats were designed to be used with the limitations of screens). Saving as .tiff: `ggsave("ex_plot1.tiff"), width = 4, height = 4)` * **.EPS** files are the vectorised file of choice for print media. They store instructions on how to reproduce the shapes on your plot by drawing them, which means the data visualisation can be reproduced with no loss in quality at any size (because the shape is not broken down into pixels). Saving as .eps: `ggsave("ex_plot1.eps"), width = 4, height = 4)` **However, only professionals may have the software required to view these formats. More common formats that everyone can view (e.g. on phones) might be .png or .jpeg** ] --- class: middle .middle-left[ ### How do we optimise the publication of data visualisation in print? Things we want to consider: * Layout, aspect ratio and orientation * In-line versus stand-alone (splitting up the page) * Resolution (dpi) * Colour (or lack thereof!) * **File types (raster or vector images)** * Files come in many types: .png, .jpeg/.jpg, .tif/.tiff, .svg, .eps. Some file types are *rasterised* (drawn with pixels/dots), while others are *vectorised* (drawn with maths). Raster files work better when there is a lot of unique elements and colours, vector files work better when there are fewer elements and colours. ] .pull-right[ <img src="images/raster-vector.png" width="100%" /> .center[ [Another example of a vector and raster image here](https://calumwebb.co.uk/teaching/smi105-content/week-07/slides/images/vector-raster-comparison.pdf) ] ] --- class: inverse, middle # Publishing a data visualisation: Web --- class: middle .middle-left[ Things we want to consider: ### How do we optimise the publication of data visualisation online? * **Device (laptop/desktop, mobile, tablet)** * Common aspect ratios and formats * In-line versus standalone versus dashboard * Interactive or static * File types (raster or vector images) ] -- .pull-right[ **What kind of device is your data visualisation intended to be viewed on?** * Do you need a different version of your data visualisation for **mobile phones**? * Do you need a different version of your data visualisation for **social media**? * Do you need a different version of your data visualisation for **desktop sites**? *More unique versions = more time, but could mean higher engagement and a more professional looking approach*. ] --- class: middle .middle-left[ Things we want to consider: ### How do we optimise the publication of data visualisation online? * Device (laptop/desktop, mobile, tablet) * **Common aspect ratios and formats** * In-line versus standalone versus dashboard * Interactive or static * File types (raster or vector images) ] .pull-right[ Web images tend to have a fixed value of **72ppi** (pixels per inch) — much lower than the 600dpi of print media. Rather, increased quality tends to be linked to **increased resolution** of images, for example: * 1280 pixels (width) x 720 pixels (height), a.k.a. 720p * 1920 x 1080 a.k.a. 1080p * 3840 × 2160 a.k.a. 4k Ultra HD ] --- class: middle .center[ <img src="images/apple-devices-ultimate-resolution-guide.jpg" width="70%" /> ] --- class: middle .center[ <img src="images/Social-Media-Dimensions-2022-2-2-1536x864.png" width="80%" /> ] --- .center[ <img src="images/cheatsheet-1024x576.jpg" width="90%" /> ] --- class: middle .center[ <img src="images/aspect-ratios-typeform.webp" width="100%" /> ] --- class: middle .middle-left[ Things we want to consider: ### How do we optimise the publication of data visualisation online? * Device (laptop/desktop, mobile, tablet) * **Common aspect ratios and formats** * In-line versus standalone versus dashboard * Interactive or static * File types (raster or vector images) ] .pull-right[ **More pixels doesn't always mean better**, the best number of pixels is the *minimum number required to provide a clear, crisp graphic*. Too many pixels means the graphic will take longer to load, which is problematic because: * The probability of someone giving up on the image loading increases by 32% between 1 second and 3 seconds. * Your graphic will take longer to load with excess resolution/file size in countries with poorer internet access * You are trading a clear image for a *bad user experience*. ] --- .center[ <img src="images/ex_plot1_1080p.png" width="80%" /> ] .center[ `ggsave(filename = "ex_plot1_1080p.png", width = 1920, height = 1080, units = "px")` ] .right[1920 x 1080 (Full HD), 16:9 Aspect Ratio] --- .center[ <img src="images/ex_plot1_twitter.png" width="90%" /> ] .center[ `ggsave(filename = "ex_plot1_twitter.png", width = 1400, height = 700, units = "px", scale = 1.3)` ] .right[1400 x 700 (Twitter/Facebook), 2:1 Aspect Ratio] --- .pull-left[ .center[ <img src="images/ex_plot1_mobileportrait.png" width="65%" /> ] ] .middle-right[ .center[ `ggsave(filename = "ex_plot1_mobileportrait.png", width = 640, height = 1136, units = "px", scale = 1.7)` ] .right[640 x 1136 (Phone Portrait), 9:16 Aspect Ratio] ] --- class: middle .middle-left[ Things we want to consider: ### How do we optimise the publication of data visualisation online? * Device (laptop/desktop, mobile, tablet) * Common aspect ratios and formats * **In-line versus standalone versus dashboard** * Interactive or static * File types (raster or vector images) ] .pull-right[ ] --- class: middle .middle-left[ Things we want to consider: ### How do we optimise the publication of data visualisation online? * Device (laptop/desktop, mobile, tablet) * Common aspect ratios and formats * In-line versus standalone versus dashboard * **Interactive or static** * Web platforms allow for interactivity (additional information to be encoded into the data visualisation and displayed on click or hover) * This also includes reactively re-sizing to the screen size — a nice benefit of interactive visualisations! * File types (raster or vector images) ] .pull-right[
] --- class: middle .middle-left[ Things we want to consider: ### How do we optimise the publication of data visualisation online? * Device (laptop/desktop, mobile, tablet) * Common aspect ratios and formats * In-line versus standalone versus dashboard * Interactive or static * **File types (raster or vector images)** ] -- .pull-right[ **.PNG** files are the most common rasterised file format for web graphics (and for a lot of print). They support transparency and usually do not lose as much quality when compressed (file size is reduced to save space). `ggsave("ex_plot1.png")` **.JPG/JPEG** files are also a common rasterised file format, but is now less common than png files. `ggsave("ex_plot1.jpg")` **.SVG** files are the most common vector file format found online, commonly used for text logos and infographics. Like other vectore file formats, SVG files do not support transparency. `ggsave("ex_plot1.svg")` ] --- class: inverse, middle ## Summary * While the idea of taking your data visualisation from R and into publication after applying good graphic design principles may seem straightforward, there are a lot of considerations to make to ensure your data visualisation works *within* a publication. * There are some common formats and standards that you can follow in order to identify how to size, set the quality, and include interaction or other features within your data visualisation. * Key questions to ask yourself: * Print? Digital? Both? * Is there a one-size fits all for your audiences, or do you need some different versions? * How can you balance visual quality and user experience (speed of loading)? * Should your visualisation be viewed in-line with text, or is it standalone? --- class: middle .middle-left[ ## Workshop this week Let’s start drawing **maps**. We’re going to work with some existing data that includes spatial information to draw different kinds of maps, and consider the information that needs to be included when we draw maps. ] .pull-right[ ## Tasks to look at in advance of Week 8 #### Core tasks: **Before lecture**: Find a map in the news that is being used to present some data. Then, share on Blackboard: (i) the map you find, (ii) where it was published (if that’s not obvious) and (iii) one observation about how well, or not, you think it is integrated into the place where it has been published (one sentence will do). **Before lecture**: Read [When maps shouldn’t be maps](http://www.ericson.net/content/2011/10/when-maps-shouldnt-be-maps/) http://www.ericson.net/content/2011/10/when-maps-shouldnt-be-maps/ **Before workshop**: Work through the task at the end of the workshop handout **Supplementary tasks**: * Before workshop: Read chapter 7/Draw maps of the Healy book ]