“There is this scientific convention of: ‘You put the images on one side, then you put the text to decipher it on the other side.’” That’s Jonathan Corum, science graphics editor for the New York Times, politely critiquing one of the ways in which a typical scientific paper creates unnecessary work for the reader, or “cognitive overhead.”
Decipher is the key word above (and a word I’ll use again below). If deciphering is necessary, it will precede understanding, but that doesn’t mean it is necessary. “No one intends to build a product with large cognitive overhead, but it happens if there isn’t forethought and recognition for it.”
How many colours do you need to visualise data scored on a five-point scale?
If you went with the obvious answer of five colours, here’s what you get:
The green and grey figure wins in two ways. First, it tells a story: about a third of respondents view Wikipedia favourably. (Although there are other interpretations of the data shown, a good figure emphasises a single message.) Second, the grey and green version just looks better.
Everything should be made as simple as possible, but no simpler said Einstein. Except, he didn’t. His version of the quote was four times longer.
I’m not surprised that it took a non scientist to paraphrase and create the short, popular version. As scientists, we are not accustomed to brevity. We want to provide every detail. We read papers filled with columns of 10pt text. We construct figures with dozens of lines and colours. We spare no bit of white space when we design posters. And don’t get me started on logos for scientific campaigns (long story short: too many elements, too many colours, and too literal).
We lack minimalism.
You may argue that detail, nuance, and chains of logic—hallmarks of science—are not easily reduced to 280 characters or a sexy soundbite. I don’t disagree. But there are still aspects of minimalism we should embrace.
Web developers and programmers have a lot riding on the quality of their product. If it behaves in an unusual manner, it’ll frustrate users. If it’s unattractive, it won’t attract users. If it’s no good, it will lose users. Users are the primary concern. Consequently, there are fields dedicated to this concern: User Interface (UI) and User Experience (UX).
Because web developers and programmers have a much wider potential audience than scientists, they have a better handle on the importance and behaviour of the end user. Scientists could learn a thing or two about UI/UX.
A computer is a better artist than I am. If I can tell it what to draw, it will produce attractive results. To make a nice schematic, the hardest part is to tell the computer what I want to draw. Fortunately for us so-called left-brain types prevalent throughout the sciences, a familiarity with scientific software can overcome a lack of artistic talent, allow rapid iteration of a design, and even provide creative inspiration.
Invoking my scientific software skills, I am able to produce elegant figures:
My favourite aspect of a Nature paper is the figure captions. Not the paper’s innovative science. Not the paper’s succinct length. The figure captions. Why? Because the journal’s simple act of bolding the first sentence of a figure caption can force authors to clarify the purpose of the figure. This is one of several seemingly minor formatting issues that ultimately improves a paper’s readibility.
Keeping track of scripts used to generate figures is difficult. Before realising that Jupyter Notebooks could solve most of my problems, I would have directories with dozens of scripts with filenames of varying levels of ambiguity. Names that probably meant something to me at the time, but are hardly descriptive months or years later. Names like ISW_plume_plots.m, new_ISW_model_plots.m, and plot_model_behaviour.m. A certain PhD comic springs to mind.
Regardless of whether its Python, R, Julia, Matlab, or pretty much any other type of code, Jupyter Notebooks solve the problem. For example, I use a single notebook to archive the code for all figures in a paper and, more importantly, I can associate each set of code with the figure it generates. Rather than trying to remember what file I want, I need only remember which figure I want. (I say archive because I much prefer to do the bulk of my exploratory analysis in an editor. Alternatively, JupyterLab may work better for you.)
Scientific papers are built by taking existing ideas, applying them in new ways, adapting them to fit new situations, and improving them over time. Yet when it comes to drawing a schematic, many people start from scratch or never even start. Instead, start with an image search, let Inkscape do the hard work, and refine the best parts of other schematics.
Scientific figures are usually messy enough, there’s no need to aggravate the problem by including redundant labels. As with figure captions, problems arise with multi-panel plots. If the panels share axes, there’s no need to label each one.
The little things matter; for example, a typo. In theory, a typo is a minor mistake that makes no difference to the meaning of the writing. In practice, if you’re like me, your opinion of the quality of the rest of the work decreases. Moreover, you may inadvertently seek out further faults.
The same can be said for figures: poor attention to detail will spoil an otherwise perfectly good plot. For this reason, here’s a short list of easily adjustable details that will improve your figures.