Creating Decent Graphs

Good graphs help convey your insights about the system you have built and/or measure by providing the information your reader needs and wants.  Bad graphs can leave the reader baffled, squinting, and drawing the wrong conclusions about your work.  While it’s not reasonable to expect astonishing insight from every graph, you  can always make the readable and easy to interpret.

As always when presenting your work, the primary goal is clarity.  Your graphs must be easy to read and interpret, otherwise, your readers are likely to skip over them, or worse, be confused by them and draw the wrong conclusion about your results or just stop reading.

The basics of drawing useful graphs are not difficult but they do take some attention to detail and thought.  If your graphs do all of the following, your graphs will be in decent shape.

1. Always label your axes with both meaningful names and units. The one exception is the horizontal axis for bar graphs in which the bar names make an axis label redundant.
2. Start your axes at zero, unless there’s a good reason not to.  Never adjust the range of your axes to emphasize differences — it is usually misleading.
3. Uses large enough fonts.  Being able to read the text in the graph is almost always more important than seeing the fine detail of your data.  If that’s not the case, make the graph bigger so you can have both.
4. If there is more than one set of bars or line, include a legend.
5. Make sure the names and labels in the legend, bar labels, etc. are meaningful to the reader and that they match what is used in the text.  The complex naming conventions you probably developed your data sets have no place in your graphs.
6. Do not include a title on your graph.  Do include a caption that describes the graph.
7. You should not generally use a log scale unless you are trying to show that something is exponential or you are just interested in orders of magnitude.
8. It can be useful to prototype graphs in excel, but excel is not a great choice for building the graphs that actually go into a paper. It does not provide adequate control over the graph’s layout and it is not scriptable.
9. Think aesthetically about your graph. Does it look good? Good graphs should be pretty and well-organized.  Text should not overlap lines.  Visual elements should not be too crowded.
10. If the same workload (or other measured entity) appears, in multiple graphs, use the same color/pattern to represent it.
11. Make sure you graph is readable in black and white (i.e., printed on a monochrome printer).  The easiest way to do this is to just make it black and white, but if you are careful you can create graphs that are in color while still being readable in black and white.
12. Are you proud of your graph?  Is it the best graph you can draw for its purpose?  No?  Fix it.

You have many choices for tools to draw your graphs.  I usually use ploticus and gnuplot, but all the software is, at some level the same:  You end up fighting the tool a lot to make your graphs look just right.  For that reason, I mostly suggest that you pick one tool (preferably the one the rest of your group uses) and stick with it.  Also, Excel is great for prototyping graphs, but it’s poor choice:  it’s not scriptable, it doesn’t allow for precise control of graph layout, its hard to  reliably create many identical graphs, and exporting nice PDFs is hard.