Process and Pitfalls in Writing Information Visualization Research Papers - Information Visualization: Human-Centered Issues and Perspectives - page 148

Deadly Detail Dump: When writing a paper, do not simply dump out all
the details and declare victory. The details are the how of what you did and do
belong at the heart of your paper. But you must first say what you did and why
you did it before the how . This advice holds at multiple levels. For the high-level
paper structure, start with motivation: why should I, the reader, care about
what you've done? Then provide an overview: a big-picture view of what you
did. The algorithmic details can then appear after the stage has been set. At the
section, subsection, and sometimes even paragraph level, stating the what before
the how will make your writing more clear.
Story-Free Captions: Avoid using a single brusque sentence fragment as your
caption text. Caption words are not a precious resource that you should hoard
and spend begrudgingly. Instead, design your paper so that as much of the paper
story as possible is understandable to somebody who flips through looking only
at the figures and captions. Many readers of visualization and graphics papers
do exactly this when skimming, so make your captions as standalone as possible.
My Picture Speaks for Itself: You should talk the reader through how your
visual representation exposes meaningful structure in the dataset, rather than
simply assuming the superiority of your method is obvious to all readers from
unassisted inspection of your result images. Technique and design study papers
usually include images in the results section showing the visual encodings cre-
ated by a technique or system on example datasets. The best way to carry out
this qualitative evaluation is to compare your method side-by-side with repre-
sentations created by competing methods on the same dataset.
Grammar Is Optional: Grammar is not optional; you should use correct
syntax and punctuation for a smooth low-level flow of words. If English is not
your first language, consider having a native speaker check the writing before
submitting a paper for review, and also before the final version of your paper
goes to press. I recommend Dupre's book [4] as an excellent pitfall-oriented
technical writing guide for computer scientists.
Mistakes Were Made: Avoid the passive voice as much as possible. I call
out this particular grammar issue because it directly pertains to making your
research contribution clear. Is the thing under discussion part of your research
contribution, or something that was done or suggested by others? The problem
with the passive voice is its ambiguity: the reader does not have enough infor-
mation to determine who did something. This very ambiguity can be the lure
of the passive voice to a slothful or overly modest writer. I urge you to use the
active voice and make such distinctions explicitly.
Jargon Attack: Avoid jargon as much as possible, and if you must use it then
define it first. Definitions are critical both for unfamiliar terms or acronyms, as
well as for standard English words being used in a specific technical sense.