How to write a Conference Paper

How to Write a Conference Paper

Dmitry Berenson

In robotics, like in many areas of computer science and electrical engineering, conferences are important places to publish work and schmooze with colleagues in your field. Unlike many other fields where conferences only solicit abstracts or do not peer-review papers, robotics conferences can be very selective and papers are usually reviewed by anywhere from 2 to 5 reviewers. As the number of people involved in robotics has increased, so have the standards of the main conferences, so publishing a conference paper can be quite difficult. This document describes the conference paper structure, writing process, and expectations for robotics conferences. It is intended for beginning academic writers who are looking to get concrete advice about these topics. For a much broader and deeper view on academic writing in general, I highly recommend this video: https://youtu.be/vtIzMaLkCaM.

Format

Most conferences solicit papers between 6 and 8 pages long in IEEE two-column format (latex templates are provided by the conference). Although Word templates are sometimes available, we will not use Word for writing papers.

Timing

It is easy to underestimate the amount of time it will take to produce an acceptable conference paper. After all, it’s only 6-8 pages. That’s probably shorter than essays you had to write for high school! This is an easy mistake to make and it can spell disaster for your paper. A good rule of thumb is to have all experiments and background research (i.e. related work) completely finished at least two weeks before the conference deadline. The writing of the paper will take at least two weeks and will include multiple revisions. I have written a good number of papers with many different people and I have never ever seen a good paper produced without multiple substantial revisions.

You should also budget time to go back and run more experiments because you will often find that unexpected problems come up when you’re trying to explain your method (for instance, you realize it won’t work in a certain situation) and these require time to fix.

Also, don’t underestimate how long it will take to create the figures for your paper. They can be extremely time-consuming! Sloppy or unclear figures drive reviewers crazy and can be grounds for rejection.

So, just in case you haven’t gotten the message already, start early! Plan out how much time you think it will take you, and then double it!

Outline

Unless the conference requires a certain outline, here is a general outline that is applicable for most conference papers (not applicable for a literature review, for instance):

Abstract (1 paragraph)
Introduction (1-1.5 pages)
Related Work (0.5-0.75 pages)
Problem Statement (0.5 -1.0 pages)
[My Method] (2-3 pages) note: this can be split into multiple sections
Results/Example Problems (2 pages)
Discussion (0.5 pages) (optional)
Conclusion (1 paragraph)
Acknowledgements (2 sentences)
References (0.5-1 pages)

The order of these sections creates a paper shaped like a Martini glass: broad language at the top (abstract, introduction, related work), then more specific language in problem statement and [My Method], very specific language and numbers in Results/Example Problems, then a quick broadening-out in discussion and conclusion.

The page allocation above is a rough one, with the [My Method] and Results/Example Problems sections being the roughest. A teacher of mine once said that an essay is like a stomach; its size adjusts to fit what is in it. The same is true of a conference paper, except that there are hard constraints on the maximum size of the stomach.

Writing Order

The above outline is the order the sections will appear in the paper, but you probably shouldn’t write the paper in this order. This is because sections like the introduction and abstract are best written once the message of the method and results sections are clear and it can be hard to envision this message until those sections are written. In fact, the process of writing will almost always force you to clarify your ideas. Thus I recommend this order for writing:

Problem Statement
[My Method]
Results/Example Problems
Related Work
Introduction
Abstract
Everything else

Some of these can be done in parallel; for instance writing the related work while you’re waiting for your computer to churn out some numbers for the results section.

Writing scientifically

When you write your first few papers it can be very difficult to know how to present your work so that it is both accurate and compelling. It can also be hard to decide what details to put in and what to leave out. Both of these issues are spectra I’ve described below. I’ve described the two extremes but your goal should be in the middle of each spectrum.

Spectrum 1: Claims

Grandiose and/or unsupported claims<--------------------------------------------->Boring/irrelevant claims

Grand claims are very exciting but are very rarely justified, while boring or irrelevant claims make reviewers question why the work was done in the first place. Again, your goal should be in the middle between these two, though if you have to err, err on the side of boring. I say this because unsupported claims are probably my #1 reason for rejecting papers as a reviewer. It is crucial that every single claim you make be backed up in your methods and results sections. If you cannot back it up, do not say it. It can be helpful to explicitly list the contributions of your paper in the introduction and then check that each element of the list is both true and something people in the community would care about.

Spectrum 2: Level of Detail

Useless technical detail<------------------------------------------------------->Vague/Incomplete description

This one is tricky. The key is to give the right level of detail at the right time (see description of the Martini glass above). In general, the introduction should be light on technical detail, while the problem statement and methods should be more detailed on a conceptual level. These two sections are where you want to talk about the elements of your algorithm and both how and why they work. Save the parameter values and tweaking until the Results section. In general, no experiments or results should be included in the [My Method] section, but it’s ok to have pointers like “As we will show in Section [Results], this method is effective at handling …”

Finally, every sentence must be true (this can be deceptively obvious). I’m not implying that you would ever intentionally write something you know is untrue, however vague language can be easily misread as false. If a reviewer suspects you are not being truthful, not only will your paper be rejected, your reputation as a researcher will be tarnished. Go through each sentence in the final draft and ask yourself “Is this true?” “Could this be easily misinterpreted?” “Could I say this more clearly to avoid confusion?”

Writing the Sections

Abstract

The goals of this section are to

Give a short overview of the entire paper
Make the reader want to read the paper

Start by motivating the work in one sentence
Describe your approach and, if possible, how it’s different from previous work (2-3 sentences)
Highlight a key result

Introduction

The goals of this section are to

Give a longer overview of the entire paper
Make the reader want to read the paper

An introduction is basically an expanded version of the abstract. A good rule of thumb is to take each sentence in the abstract and build a paragraph around it. Sometimes you might need more than one paragraph.
Make it extremely clear what problem you are trying to solve
Include a list of contributions of the paper
Include an overview figure that shows how the method works and maybe a cool result
End with a brief outline of the structure of the rest of the paper

Related Work

The goals of this section are to

Show that you’ve read and understood relevant work in the area (i.e. establish your expertise)
Carve out a niche for your method that has not been filled by previous work

Describe and cite papers that are relevant to your work
Try to be broad in your citations, it will make you friends
Don’t be harsh in criticism of previous work, focus on what it didn’t address and how it differs from your method

Problem Statement

The goals of this section are to

Describe the problem you are trying to solve as clearly as possible
Establish the notation that will be used throughout the paper

Suggested outline:

Define terms and notation. E.g. “Let P \subset X be a trajectory in state space”
State the problem mathematically; e.g. “Find a P that obeys constraints C” or “Minimize f(x) subject to Ax < b”
State the assumptions you’re making about the problem
Highlight important differences from similar problems in the literature (if any)
Define the relevant metrics for your solution. This is what people in your field care about: e.g. accuracy, computation time, etc.
Say why this problem is difficult to solve.

IMPORTANT: Make sure your notation and terminology is consistent with previous work in the field.
IMPORTANT: DO NOT describe your method in this section, only describe the problem.

[My Method] — This can be split into multiple sections

The goals of this section are to

Describe your method as clearly as possible
Describe why you did it this way
Convince the reader that the method makes sense

Start with a paragraph that describes your method at a high level
If the work is algorithmic, use the algorithm2e package to write out your algorithm. Note: Every function in the algorithm must be discussed in the text (unless it is extremely obvious)
IMPORTANT: First describe why you did something a certain way, then describe the relevant details. Make sure people understand why something is important before describing it in detail.
You can mention a few things you tried that didn’t work (especially if it motivates the method you’re presenting) but keep this brief
Don’t go into detail about parameter tuning here (save it for results)
Any proofs about the correctness/completeness of your method go here

Results/Example Problems

The goals of this section are to

Show that your method works as advertised
Show the generality of the method over a range of problems
Convince the reader that this method is useful on important types of problems

Start with a paragraph that specifies what question(s) you are trying to answer with your experiments
Describe the motivation behind each experiment, why did you choose this particular set-up?
Report BOTH qualitative and quantitative results:

Show figures of the robot doing something using your method.
Provide numbers that justify your claims about the effectiveness of the method.

IMPORTANT: Do NOT assume readers will pore over the numbers in your tables and draw informed conclusions. You need to interpret the numbers for them explicitly. Clearly state how the numbers support your claims.
Wrap up with a short paragraph that answers the question(s) you posed at the beginning of the section

Discussion (optional)

The goal of this section is to take a step back and evaluate the pros and cons of your method from a higher level.

You’ve spent the previous pages showing how amazing your new method is, now it’s time to step back and consider its weaknesses as well. Discuss areas for improvement.
Discuss extensions of your method and potential other problems your method could be applied to.

Conclusion

The goal of this section is to wrap and summarize the paper.

Usually one paragraph long
This is the same as the abstract but in reverse order: Start out with what you have shown specifically, then move to a description of your method, then talk about high-level motivation and how you’ve made progress toward it
End with some ideas for future work

Acknowledgements

List the grant(s) that funded you while you did the work
List people that were particularly helpful in discussions but who are not co-authors

How to make figures

Good figures are essential to a paper. If figures are unclear or misleading, this is grounds for rejection. In general, there are three types of figures that are most common in scientific papers:

Cartoons

These types of figures are used to explain the method (or a part of the method) in a simplified example scenario. They should illustrate an interesting case where you really need a visual representation to show what’s going on because it’s too cumbersome to describe it in text. An example of this is when you’re trying to describe the spatial relationship between a number of objects/vectors/points.

Plots

These are usually used to convey numerical results. You must include error bars on your measurements wherever possible. Don’t make the font on the axes too small! The font used on the axes should be one size smaller than the font of the text. While including plots is great for showing results, plots are completely useless on their own and the “message” of a plot must be discussed in the text. For instance, “Figure X shows that the runtime of the algorithm increases quadratically relative to the value of parameter y.”

Photos/Screenshots

These figures are used to show the method in action in a real or simulated scenario. These figures are very important for convincing people your method works on real-world problems that they may care about. Be very careful selecting the viewing angle so that everything you want to show appears in the frame. Also think about overlaying colors and text on the image to highlight what readers should be looking at. If you use overlays, do it sparingly so that you don’t clutter the image.

Revising

I recommend generating a full draft before revising. After you generate the draft, print it out (do not read it on the screen) and go through it, marking any changes with a colored pen (it’s colored so you don’t miss any small marks when you look at it later). Make sure you go through the paper from the very beginning to the very end, including figure captions and references. Only after you’ve marked everything, go back and make the edits you marked. Going through all the way in one sitting will enable you to gauge the flow of your paper.

It may seem strange in our modern age to make marks with ink on sheets of paper. The reason this helps is that you need to get away from the screen so that you can read the paper with “fresh eyes.” Reading the paper in the same context as you’ve been writing it may make your brain unconsciously skip over parts or tune out (this certainly happens to me). Seeing your words on paper can give your brain the novelty it needs to enable focus.

Plagiarism

You already know not to plagiarize, but the line can be somewhat unclear in science. You are allowed to summarize the findings of a published work in your own words as long as you cite the published paper after the summary and make clear this was not your own work. The same goes for figures as well. Do not copy text from a previously-published work into your paper. Some conferences now have automated checks that will scan your paper for text copied from previous papers. Just don’t do it!