Database Reference
In-Depth Information
I have chosen a breezy style, following in the footsteps of Levin and Re-
dell [22] and Shewchuk [34]. My intent is serious, but I have tried to invent
catchy - sometimes even snide - titles in hopes of making these pitfalls more
memorable. Guides to writing research papers have been written in several sub-
fields of computer science, including systems [22], software engineering [33], pro-
gramming languages [19], networking [28], and graphics [20]. Many of the pitfalls
in the middle and later project stages apply to research writing in general, not
just information visualization, and have been mentioned in one or many of these
previous papers.
My first pass at providing advice for authors and reviewers in the field of
information visualization, abbreviated as
infovis
, was the creation of the author
guide for the annual conference. When I was Posters Chair of InfoVis 2002, the
IEEE Symposium on Information Visualization, I read the roughly 300 reviews
of the 78 rejected papers in order to decide which to invite as poster submissions.
The experience convinced me that future paper authors would benefit from more
specific guidance. When I became Papers Chair in 2003, with co-chair Stephen
North, we completely rewrote the Call for Papers. We introduced five categories
of papers, with an explicit discussion of the expectations for each, in a guide for
authors that has been kept unchanged through the 2007 conference.
This second pass is motivated by the patterns of mistakes I saw in my two-
year term as InfoVis Papers Co-Chair where I read the over 700 reviews for all 189
submitted papers, and in personally writing nearly 100 reviews in the subsequent
three years. My discussion of paper types below expands considerably on the
previous author guide, and I provide concrete examples of strong papers for each
type. The advice I offer is neither complete nor objective; although I draw on
my experience as a papers chair, my conclusions may be idiosyncratic and reflect
my personal biases. I do not perform any quantitative analysis. Doing so in the
domain of infovis would, no doubt, be fruitful future work, given the interesting
results from software engineering [33] and human-computer interaction [17].
None of these pitfalls are aimed at any particular individual: I have seen
multiple instances of each one. Often a single major pitfall was enough to doom
a paper to rejection, although in some cases I have seen other strengths outweigh
a particular weakness. I hasten to point out that I, myself, have committed some
of the errors listed below, and despite my best efforts I may well fall prey to them
in the future.
2 Initial Stage: Paper Types
A good way to begin a research project is to consider where you want it to end.
That is, what kind of a paper do you intend to produce? That choice should
guide many of your downstream decisions, including the critical issue of how to
validate any claims you might make about your research contribution.
2.1 Validation Approaches
Many possible ways exist to validate the claim that an infovis paper has made
a contribution, including:
Search WWH ::
Custom Search