The elements of charting style

You may like to also look at other guidelines documents.

• A graph that goes into a paper must never have a title (as in main=""). The title will be supplied by latex.
• Both axes must always be annotated with units which make physical sense. E.g. it's pointless to say "periods". Say "Months" or "Days". It is generally silly to have a y axis label that says "Price of Infosys (Rupees)": Just say "Rupees" as the y axis label.
  If you omit the units, it's almost always wrong. The only special case is time on the x axis, when I often omit the word "Time" since it's obvious by looking at the legend of the x axis.
• The annotation of the time axis must be sensible. Points should be equally spaced. Even if the data is daily, it's often useful to drop down to (say) month or quarter annotations. The defaults used by R for date objects on the x axis are quite bad. It's often useful to first make a zoo or an xts and then do the graph, under such circumstances, as plot.zoo() and plot.xts() are nice.
• Set the margins of the graph correctly so that you are not wasting whitespace. In base R that is done using par(mai=blah).
• Colour can often be used very effectively to improve communication. But most people only have black & white printers or e-book readers. So avoid colour unless you are very clear that you will only use it in a slideshow and not release the file on the net. Files that go out on the net, and the journals, should cater to a primarily black & white audience.
• Use good english as far as possible. E.g. never use a y axis legend like "lwpi" or "log wpi" or "log.wpi". This means nothing to almost everybody. Use perfect English: say "Log WPI". COMPLETELY remove all notions of computerese when making a graph.
• Make sure the labels on the x and y axes are short enough that they don't spillover beyond the dimensions of the chart itself.
• Use an aspect ratio for the pdf which is sensible when it's put into a document. I.e. under normal circumstances it's got to be wide (e.g. 5-6 inches) and squat (e.g. 2-3 inches).
  Square graphs are often a bad idea since computer screens and page layouts are generally not square.
  However, there are a class of situations where it's natural and logical to have a square graph - e.g. when in a graph the units of both axes are identical and where a 45 degree line is supposed to visually look like a 45 degree line.
• A pie chart is almost never a good idea. Superposing graphs with two different y axis scales is almost never a good idea (You should recoil when someone tries to push one in front of you).
• You should do a line chart when (a) Time is on the x axis and (b) The series has high positive autocorrelations. If time is not on the x axis, generally a line graph is not a good idea. If you are dealing with something closer to white noise (e.g. a time series of returns), it's better to make a bar chart.
• Vector graphics file formats (e.g. .pdf) are nice, but once the file size becomes really large, and your rendering device starts feeling sluggish, you are better off with bitmap file formats like .png.
• Here are some useful settings using par() and mai() with R:

    # For slideshow
    pdf("a.pdf", width=5.6, height=3.8)
    par(mai=c(.4, .8, .3, .2))
  
    # For a Microsoft powerpoint slideshow --
    png("a.png", width=1100,height=746, pointsize=32)
    par(mai=c(1.1, 2.5, .8, .4))
  
    # For a document
    pdf("a.pdf", width=5.6, height=2.4, pointsize=10)
    par(mai=c(.4, .7, .3, .2))
  
    # For a M S Word document --
    png("a.png", width=1100, height=470, pointsize=24)
    par(mai=c(1, 2, .7, .3))
  
    # Small picture for a latex document -- 
    pdf("a.pdf", width=3.5, height=2, pointsize=10)
    par(mai=c(.4, .7, .3, .2))
  
    # For blog insertion
    png("a.png", width=550, pointsize=16)
    par(mai=c(.6, 1.1, .4, .2))
            # .6 is for an x axis where there's no xlab
            # If you want an xlab then that has to also be 1.1
  

• When you make a graph, you're in love with it, and you tend to make it too big. But most documents are well served by having smaller graphs.
• No graph component should touch the legend. If needed, force extra space using things like ylim=c(min(y), 1.2*max(y)).
• It is almost always nicer with legends having no box (bty="n" in base R).
• The font size of strings placed on the chart should be large enough so as to have adequate legibility. Specifically: strings in the graph should have the same font size as footnotesize text in your main document.
• Be careful about the aspect ratio. Sometimes, the insertion of a graph contaminates the aspect ratio and then it looks wrong in the end. Insertion of a graph into a document must never change the aspect ratio.
• In latex, people often say things like \includegraphics[width=0.5\linewidth] where effectively you are using latex to drive down the size of the graph by half. Don't. Get the size of the graph right in the first place. Otherwise, what tends to happen is that when you are developing the graph, you make it look good, but that last halving of the size makes the strings look tiny. When writing R, get the graph to be perfect in its target size, and when writing TeX, don't contaminate the size of the graph.
• Think carefully about whether R default scales are okay, or whether you want to bring 0 into the picture as a minimum. I.e., do you just want to say plot(x, y) or do you want to say plot(x, y, ylim=range(c(0,y)))
• If, for a given axis, all values are positive and max/min > 10, then consider shifting to log scale. This is not hard and fast and you have to have judgment on whether (in the end) it makes sense or not.
• You'll be amazed at the number of readers who skim a paper looking at the graphs and tables, and don't particularly read the text. (Confession: I do a lot of that! When I read a paper I focus on the data description, the estimation strategy, the tables and the graphs, and then I make up a story in my own head). Hence, work hard to fully annotate the graph and ensure that the graph is self-contained and tells it's own story.
• When a figure or table is an example and not central to the main logic of the paper, the caption should always use the word "example". E.g. have a caption like: "The superior productivity of multinational corporations: An example". So the reader is crystal clear that this is not the main argument, it's only an example.

See: How to construct bad charts and graphs by Gary Klass.

Ajay Shah, 2010