Table Readability
Ron Graham
AIC Probability
Delta IV Atlas V
Trajectory Control Malfunction 1.63E-02 1.60E-02
Attitude Control Malfunction 7.75E-03 6.83E-03
Catastrophic Stage i Liquid Engine Failure 9.41E-03 1.17E-02
GEM (Graphite Epoxy Motor) Failure 4.16E-03 4.42E-03
GEM Inadvertent Separation 9.67E-04 5.97E-04
PLF (Payload Fairing) Failure 5.11E-04 3.63E-05
Structural Failure 1.57E-04 2.11E-06
LV Propellant Tank Failures 1.55E-04 4.28E-07
SV Tank Failure 1.00E-06 1.00E-06
Inadvertent CDS 6.52E-05 9.86E-06
Failure to Stage (stage 1/2) 9.70E-06 4.90E-07
Premature Staging (stages 1/2 and 2/SV) 8.99E-05 8.07E-05
Recontact at Staging (stage 1/2) 1.00E-06 1.00E-06
TOTAL 3.96E-02 3.96E-02

Table 1. Delta IV and Atlas V Accident Initiating Conditions and Probabilities (courtesy Lockheed Martin Astronautics)

Here are some things that could be done to make this table more readable:

  • Define acronyms elsewhere. It shouldn't be necessary to define two of them in this table. Some industries use so many acronyms that a nomenclature section is a must!
  • Spell out column headings. Again, don't depend on acronyms -- defined or not.
  • Simplify the numbers. The probability numbers in columns 2 and 3 are in scientific notation, allowing them to line up -- but it’s possible to make them even simpler to read. There are at least three ways to do this:

    1. Choose units that allow the numbers to be larger (even make them integers if possible), such as probability x 100 (per cent) instead of probability.
    2. Take the smallest entries in the table and lump them together. For instance, the last three entries represent various types of staging failures. What if we presented in the table just a single entry for "staging failures?" And what if a probability much less than one percent were labeled as "small" (<< 1)?
    3. Reduce the number of significant digits in each probability. To do this for presentation does not mean that precision is lost in computation.
  • Don't make all entries bold. What would that buy you? If everything is emphasized, nothing is emphasized.
  • Minimize borders. Tables take up more space if each row has a border. Though longer tables should have borders (or some visual cue) at intervals to prevent the reader from being lost in the numbers, a short table like this one might be improved if borders between cells are eliminated. This is very simple with today’s word processors, and this table was prepared in Microsoft Word.
  • Eliminate redundant categories. In this table, various types of "staging failures" can be lumped together -- and enumerated elsewhere (e.g. in an appendix) if necessary.

    Notice for this case how much of the data is at the "noise level" -- there is so little information gained by including these categories, yet they take up so much space in the chart’s legend, that they actually serve to distract the reader.

How does the next result compare with the original, in terms of readability? Or in terms of your ability to abstract information? Your mileage on this example may vary -- your audience may for some reason need to see each data point, or may need greater precision. Even in that case, however, it’s possible for you to present a simplified version (like this), and have a more comprehensive version available in an appendix, to which you can point anyone interested in seeing more.

Accident Initial Condition Probability, %
Delta IV Atlas V
Trajectory control malfunction
Attitude control malfunction
Liquid engine failure (all stages)
GEM failure
GEM accidental separation
Staging failures (all types)
All others
1.6
0.8
0.9
0.4
0.1
small
0.2
1.6
0.7
1.2
0.4
0.1
small
small
Total 4.0 4.0

[Table of Contents] [Previous] [Next]