Writing a paper ? Please check these guidelines. First answer the following quiz.

Quiz 1

Q1
  1. My readers will carefully read my paper from the first sentence to the last.
  2. My readers will read the abstract carefully and, if interested, will dive into selected portions of the paper.
  3. No one will read my paper anyhow.
Q2
  1. On page 2, I introduce the variable τ, and I use it again on page 13. My readers will remember what τ is, otherwise, why would they read my paper ?
  2. On page 2, I introduce the variable τ, and I use it again on page 13. Since it is a long way from the definition to the next use, I put a list of variables at the end of the paper.
  3. No one checks the mathematical formulas anyhow.
Q3
  1. The captions of my figures are terse. I assume my reader will look at the figure exactly when my text directs her to do so.
  2. My reader may look at the figures before reading all the text, just to get a feeling for the paper. Therefore I put captions that are as self-contained as possible.
  3. I never put figures. It is a pain to put them into Latex and no one looks at them anyhow.
Now analyze your answers to Quiz 1.

Quick Check-List

You are coming to discuss a paper, slide show or poster draft with me. Before doing so, please check the following list. If some items are not clear, you may want to read the rest of this document.

    For Papers

  1. You support random access
  2. You define concepts once and at the right place.
  3. The abstract (in condensed form) and the introduction (in more details) entirely define what is in the paper (problem solved, limiting assumptions, main features of the solution). The reader will not discover hidden assumptions later in the paper.
  4. The structure of the document is clear from the section, subsections and paragraph titles.
  5. One single concept has a single name (no synonyms)
  6. You use the scientific method to draw conclusions.
  7. All simulation parameters are described and their values are given.
  8. The reference list is up to date
  9. Figures and tables are stand-alone.
  10. You use Latex
  11. Pages and sections are numbered.
  12. You spell-checked the draft and you have an appointment with Holly to hollify the final version.

    For Slides and Posters

  13. You avoid the two big mistakes
  14. You use the right tool
  15. You explain by example
  16. You give a complete view of your solution
  17. Slides are numbered

General Guidelines

You write for human beings

  1. Think about your reader. Who is she ? Is she assumed to be an expert in computer networking or not ?
  2. Help your reader. Even if your reader is an expert in your field, he is NOT an expert in your work. You have spent the last months or years working on this project, but your reader has not. Please help your reader get the overall picture in place quickly. Reading technical papers is hard, is much less fun than reading novels, so please be kind to your reader (who may be your reviewer...).
    Make it easy to understand whether every point you are making is
    • an assumption
    • a review of existing work
    • your invention
  3. Come to the point quickly. Do not spend your and the reader's time about contorted introductions. If you are writing a paper about a congestion control protocol for audio applications, and your target journal is IEEE transactions, do not spend a paragraph explaining why internet telephony is important. But do not forget to explain what your problem is.

Organize the Information you are Delivering

This is the most difficult part -- if you master the two points below, you are in good shape.

  1. Define concepts once and at the right place.

    Readers expect to find things at the right place. System description, review of state of the art, simulation setup, simulation results are all different things. They should appear in well defined sections, and only once. DO NOT define or explain the same thing twice. This gives a non professional look, and is likely to be inconsistent as your paper evolves.
    Don't

    In Section "Simulation Setup": Nodes periodically broadcast HELLO messages in order for nodes to build their ZRW routing tables. When a HELLO message is sent, the HELLO timer is reset. The value of the HELLO timer is 1 s

    Do
    In Section "3.2.2 Description of Protocol": Nodes periodically broadcast HELLO messages in order for nodes to build their ZRW routing tables. When a HELLO message is sent, the HELLO timer is reset.
    In Section "5.1 Simulation Setup": the HELLO timer (see Section 3.2.2) is equal to 1s

    In a subsection called "Solution Overview", do not give general considerations about things you left for further study. In a section called "Numerical Results" do not explain the protocol you are simulating. In Section "Protocol Walkthrough" do not justify why you leave some function out of scope.

  2. Support Random Access.

    Many readers, among them reviewers, will jump from figure to figure, or from section to section. Many will read the captions before reading the sections they are in. Be aware of that.

    Now I hear you say: how can I combine random access without repeating the same thing again and again ? Well, that' s precisely what you shoul target: give enough information for the reader who does random access, but do not repeat the same thing again and again.

    A figure caption should give enough accurate information, to make random access possible and pleasant to the reader. Do not be afraid to have long captions. In the caption, point to precise locations in the paper where the reader can find all details, if necessary.
    Don't

    (caption of Figure 5). Simulation results for a 500 node network with Pause-Time on the x-axis.
    Your reader may misunderstand which network you are simulating here. She needs a precise definition of the network and the parameter Pause-Time. Otherwise, she may understand something completely different than you think; for example: Figure 5 is about the same network as in Figure 3, but with 500 nodes instead of 100. (In this specific example, the networks in Figures 3 and 5 are not the same; this is clear from the full text -- it should also be clear to a reader who jumps from figure to figure).
    Do
    (caption of Figure 5). Simulation results for the network of Figure 4 with 500 nodes. Total throughput versus Pause-Time (defined in Section 6.7.3)

Here are a few observations to hel you reach these two objectives.

Be Scientific

  1. Use the scientific method to draw conclusions. The scientific method means that you do not draw a conclusion before verifying what you are going to say; in short: 
            do
           {define hypothesis; design experiments; validate }
        until (validation is OK)

    Don't
    (In Section "Simulation Results"): The normalized routing load is shown in Figure 4. We see that protocol B has much less overhead than protocol A. Protocol A frequently uses flooding as a means to build or repair broken routes, which causes a large overhead.
    The flaw is that you interpret Figure 4 when you say that protocol A has more overhead because it uses flooding. The only thing the figure says is that protocol A has more overhead. Your interpretation may be right (it might also be wrong, for example the larger overhead might be due to the setting of a Hello timer). The only thing we can say is that the figure leads you to pose as hypothesis that protocol A has large overhead due to flooding. The next step is to design an experiment that will confirm, or infirm that hypothesis.
    Do
    (In Section "Simulation Results"): The normalized routing load is shown in Figure 4. We see that protocol B has much less overhead than protocol A. Protocol A frequently uses flooding as a means to build or repair broken routes. We pose as hypothesis that this might be the cause of this large difference. To test this hypothesis, we designed the following experiment. We measured the performance of protocol A after setting the flooding frequency parameter to a high value. We used a low mobility scenario where route breaks are rare. Figure 5 shows that the routing overhead of A and B are now comparable, which confirms our hypothesis.
  2. All simulation parameters are described and their values are given. It should be possible for an independent researcher to reproduce your results. Put your simulation code on the web.
  3. There are no ambiguities. All graphs and tables have units. If you use the word "billion", say whether is 9 or 12 zeroes.
  4. Make sure you spend enough time to scan the literature and are aware of the state of the art. You must incorporate in your state of the art the findings published in IEEE and ACM journals and conferences -- ignoring a single paper there may be fatal. Also use Citeseer, the Web of Science... and Google.

    Your reference list should be up-to-date. Many reviewers will fist look at your list of references to see if you are up to date. If an important reference is missing, your paper is probably already rejected.

Make an Abstract

The research is done, you now want to finalize your findings in a paper. The first step is to do an abstract. If you succeed, go ahead with writing the paper. Else, you probably want to do some more research.

The abstract should contain the following parts.

  1. What is the problem ?
  2. Why is it a problem ?
  3. Why is it important to solve it ?
  4. Give your main findings, the ones you want people to remember.

Make A Production Plan

The abstract is done, you now want to finalize your paper.
  1. Make a rough time plan. Estimate when you have completed what. This seems magical, and when you do this for the first time, you may find that it is non-sense to make a time plan when everything is so uncertain. But when you have more experience, you will be surprised to see that it is possible to do a time plan. The time plan serves two goals:
    • reduce your stress: By defining smaller pieces, you see progress and you gain confidence.
    • set priorities: With a time plan you become aware of where you spend time and of what you can and cannot achieve.
    A time plan is not a strict schedule. You need to adjust it at least once a week. It evolves as difficulties arise (most frequent case) or when the job is easier than expected (less frequent case). You may wonder: why bother keeping track of a moving time plan ? Well, this is precisely for keeping track. This will help you decide about your paper, rather than let things decide for you.
  2. Emergency costs time. If you have a strict deadline (call for paper) then put some BUFFER in your time plan. Plan to deliver the paper 3 days before the deadline. It is unwise to believe that your paper is more competitive because you worked on it until the last second. Delivering the paper in advance will leave you relaxed, and this will feel in the paper. You will avoid wasting time due to busy FTP server, incompatible fonts, network outages, snow storms, hard disk crashes, last minute emergency with your TA duties, etc.
  3. Plan for a final pass (see below).

Write the Paper

  1. Do a MAP, containing all the ideas and points you want to make
  2. Now write a sketch. It contains the contents of all sections in a few words. Try a structure ( = break the story into several pieces). Do not worry too much about section sizes at this point, you will tune this later.
  3. One section, or part of section, is the state of the art. Be very careful about that one -- a deficient state of the art accounts for a large fraction of rejected papers.
  4. Write the sections. This will take you many days. You will have to iterate on the previous points.
  5. Write the conclusion. The conclusion should not bring any new piece of information about your current work, it should only summarize, or put in a different perspective, some elements which were explained earlier in the paper. You may additionally open up to areas of interest, or related problems that you intend to tackle (but will you really ?).
  6. Write the introduction. The introduction should explain the same points as the abstract, with more details. If the state of the art is not too long, put it in the introduction, else in a section of its own.

Style

Now it is time to think of your writing style.
  1. Introduce one point per sentence, not more. Break sentences into several, if needed.
    Don't
    We prove that, in the limit of infinite power, the fairness index tends to 0. We verify numerically, on a large number of random networks, that unfairness does occur with realistic power constraints, which is a generalization of results from [ZGOMO] saying again that this unfairness property is not a problem of UWB but rather of the performance metric.

    The last sentence makes two points: (1) the unfairness that occurs at the limit also exists in reality (2) the problem reported in [ZGOMO] is explained by this general result. Do
    We prove that, in the limit of infinite power, the fairness index tends to 0. We verify numerically, on a large number of random networks, that unfairness does occur with realistic power constraints. This generalizes the problem reported in [ZGOMO] and shows that is not a problem of UWB but rather of the performance metric.
  2. Streamline your sentences: remove unnecessary words. Replace
    When the ZMRP mechanism is employed, nodes send only one message per round. We have that the cost per round is XY/2.
    by
    With ZMRP, nodes send only one message per round. The cost per round is XY/2.
    Avoid contorted expressions. Replace
    We can observe that protocol B greatly reduces routing overhead compared to protocol A.
    by
    Protocol B has much less routing overhead than protocol A.
  3. Also see Henning's Schulzrinne's recommendations, but do not follow his recommendations on inline enumeration and bullets.

Final Pass: Remove

You have written your paper, or at least you believe so. Well, you now need a final pass. The goal is now to REMOVE things that are not needed.
  1. Be critical, see your work with the eyes of an external reviewer: is everything you are writing in the paper really interesting ?

Slides and Posters

  1. Why do you give a talk ? People can have your paper in the proceedings, so you must add value to reading the paper. At the end of your talk, the audience should have learnt something, even if they never read the paper in detail.
  2. The two big mistakes are In both cases you are boring.
  3. To avoid both mistakes, you have to make a choice of which aspects you want to explain in detail. Then do explain them in detail, and position them with respect to the big picture. Plan your time carefully. In general, count 1.5 - 2 mn per slide.
  4. Explain by example. Human brain is not a Turing machine; we learn by example and imitation. If you have defined a complex, smart protocol, imagine a number of typical scenarios, which can illustrate all the beauty of your concepts, and explain one by one how the mechanisms work on these scenarios.
  5. However, do not explain only by example. Also give the global picture. This gives the audience the warm feeling that there is a global picture.
  6. If you show an equation, make sure the audience will have enough time and information on the slide to understand it. Otherwise, why do you show it ? (do not do mathematical intimidation). Displaying equations in a slide show is like showing love scenes in a movie -- you can do it, but be careful and do not abuse...
  7. You think that since you have defined parameter x in slide 2, the audience will remember at slide 25 what x stands for. Well, you are probably wrong. Do not assume that your audience will have in mind the complete list of parameters that you defined in the paper.
  8. Use the right tool. The tool influences your slide show.

    Make sure you master both Latex and Powerpoint or equivalent. Only then you will be able to decide which tool is the best.

    In general, you tend to not do enough pictures.

    Do not waste your time writing equations in Powerpoint -- instead, cut and paste equations from the pdf or ps of the paper that you have already written (with Latex), or even better, use TexPoint.

Analyze Your Answers to Quiz 1

Back to main text

Quiz 2

Are you a genius ?
  1. Yes
  2. I don't know
  3. No

If your answer is 1, congratulation. Your findings are so great that readers will very carefully read all of your text. You do not need to bother about writing style. This document is not for you.

If your answer is 2 or 3, take Quiz 1 again.
Back to Quiz 1

Credits

Thank you to the many authors who helped me formalize these guidelines. Thank you to Jörg Widmer and Slavisa Sarafijanovic for comments and additions.