This document started as a way of sharing feedback on paper summaries. It quickly grew into feedback on several forms of technical writing and presentations, as I found myself writing the same comments over and over again. The comments apply to project reports, theses, dissertations, literature reviews, presentations, defenses, talks, etc.
In reading the paper summaries, I find that many students simply do not understand the assignment. The idea of a paper summary is to SUMMARIZE a research paper. I want you to talk about what the paper says in your own words. Imagine that I have not read the paper, and you must describe to me what is important about the paper. If I read your summary, I should learn something.
For a literature review, repeat what you would do with a paper summary, only with more papers. Discuss them one at a time, and tie them all together with your discussion. Go back and revisit a paper that you have already discussed, if another paper brings up a topic that you want to discuss. Use sentences like, "Simpson suggests that the universe may in fact be doughnut shaped [1]. Others agree with this possibility, including Hawking [2]. Syzlak and Gumble apparently were the first to publish such a claim [3], but their research is highly speculative."
I do not want you to report what the paper says. In fact, you should present your summary so that it stands on its own, with the paper you reference as a back-up. You are explaining something, and pointing to your source to re-affirm what you say.
Literature reviews are a bit different. Here, you also want a stand-alone document, but focus on comparing and contrasting what researchers did. Your survey should be a good background on the topic, including motivation, what was tried, what worked, what did not work, and what the open problems are. Ideally, you should include everything relevant. You will find that there are "classic" papers (though not necessarily old) that appear over and over again in reference sections of the papers you collect. You want to include these in your survey.
Refer to the papers in a clear and unambiguous way, such as "Smith, et al. found that ... [4]." Avoid saying "the authors", since it is not clear who you mean. Do you mean the authors of the last paper referenced, or are you talking about yourself? The same thing applies to "paper"; "this paper" could mean the one that you wrote. Here are some examples of what not to do:
Do not tell me that "the paper says this", "the paper has a diagram for that", "the paper is 8 pages long with what appears to be 12-point Times font", "the abstract presents a brief overview of the topic", "the introduction introduces the topic", "A solution to rectify this problem is proposed", etc. I am interested in its content and contribution, not its physical form.
Use Direction and Reflection:
Direct the reader with a good introduction sentence in each paragraph.
At the end of the paragraph, reflect on it with a sentence summarizing
it and pointing to the next idea (paragraph).
Use a complete reference in your citation.
Even if you have the original paper stapled
to your summary, I still want your summary to be complete.
Here is a poor example:
Real-Time Payments for Mobile IP By
Hitesh Tewari and Donal O'Mahony, Trinity College of Dublin.
Here is how it SHOULD look:
[Tewari03] Hitesh Tewari and Donal O'Mahony, "Real-Time Payments for Mobile
IP," IEEE Communications Magazine, February 2003, pages 126-136.
Get the reference correct. Do not leave out authors, pay attention to what should be in italics and what should be in double-quotes, include all info (like page numbers).
Do not use big margins.
In one bad example of a paper summary, the margins accounted for half
the width of the line.
Use italics for any mathematical variables. For example, "let n be the sample index".
Use italics for any extensions, such as "We saved the sound data in a .wav file".
Any other odd text should also appear in a different font, such as programming statements. "For example, a for loop could be used in place of a while loop." You should use something different, but it does not have to be italics. You could use, say, Courier font instead of Times.
If you include code, use a different font, such as single-spaced Courier. (I recommend Courier because it is monospaced, much like what you see in a terminal window). Use whitespace as you would in the program.
Use a binder clip to attach your summary to your original article(s).
I do not care how long the document is,
assuming that it meets the minimum criterion of the assignment.
In fact, often the shorter it is, the better! If the assignment
asks for 2-3 pages, and you give me 8, this does not mean that
you will get a good grade. If your summary is 2 pages, and you decide
to make it 3, your may simply be giving me more things to correct, leading
to a lower grade.
People often ask me what the minimum number of pages for a thesis is. There is no required amount of pages as far as I am aware. I have heard a story (an urban legend, perhaps?) that the shortest thesis was only 15 pages. But this is not normal. If yours is less than 90-100 pages, then you probably are not explaining things adequately.
Do not make a list. Do not use sub-headings, do not use bullets, do not use numbers. Do not turn in an outline of the paper. The paper should FLOW, that is, you should link the ideas expressed. When you talk to a person, you do not jump from one idea to another, so I do not want you to do this in writing, either. Explain why you are talking about topic 1, and say why you will now talk about topic 2. If you have short paragraphs, they should probably be combined to one large paragraph.
Do not use acronyms. I may take off a point for every time you use
an acronym. Why? Because the students who have attempted this
assignment before you simply could not use acronyms appropriately.
You should always first spell out the acronym, and use it only when
you find yourself repeating the same thing over and over (and over
and over) again.
Here are some bad examples:
"We have seen that VHE management requires..." (What VHE stands for
was never mentioned).
"The MN has to get itself registered to the server through HA and FA
in the foreign domain. The security association is between AAAH
(AAA server of Home for MN) and AAAF (AAA server of foreign domain
for MN)."
Here is another example to add to the "hall of shame":
"So the overall PNSR of CZQ-WP is more than CZQ-WV. Hence, CZQ-WP is
efficient both in PNSR and visual quality of an image." Yes, I know
that it should be "PSNR" instead of "PNSR", but apparently the
student did not.
Do not say "we", "I" or "you". (This applies to paper summaries only. It may be acceptable to use "we" in other documents, such as a conference paper. Check with me if you are unsure.)
You need to REFER to your references! Somewhere in your summary, you should indicate where you got your ideas from. I suggest doing this at the end of every paragraph. For example, add "[1]" to the end of any sentence that restates a claim made in your first reference.
Do not mix styles. If you refer to the first reference as "[Smith03]", then you should not refer to the second reference as "[2]".
Make sure your paper LOOKS professional. Here is an example of what NOT to do: "key s teps t o a chieve a global c ontrol". Proofread your paper. Check it for spelling, punctuation, grammar, proper spacing, etc.
Pay attention to details, such as putting commas after a word, but before a space. "In Huffman coding ,the data are..." should be "In Huffman coding, the data are...".
Be careful with the words you choose, and look up definitions if you are not sure. For example, one paper said "If the signal is to be transmitted (or retrieved) and if it takes extremely long time for transmission (or retrieval), it is perverting to the end user." [Italics added]
Be specific, and restate things as appropriate. Here is a poor example: "Conclusion: A method for improving the energy efficiency..." (What method?)
If you include a figure from the paper you summarize, be sure to cite the paper in the caption. Also, be sure to say what the figure is in the caption.
Do not use contractions (such as "don't").
Avoid repeating the same word twice, such as "the scanner scans", or "the software provides a function that provides...". Instead, you could say "the scanner reads" and "the software includes a function that provides...".
Use full justification, even with multiple columns.
Avoid using comparative language unless you have a comparison. For example, "..provides a more accurate..", (More accurate than what?) "The iPAQ costs less." (Costs less than what?)
If you use a word like "their", you should indicate who you mean.
Here is an example of how NOT to use lowercase: "The purpose of this fan is to circulate above the motherboard providing better heat protection for motherboard components such as ram chips and also rotate far enough to reach the north and south bridges of the motherboard." RAM chips are random access memory; "ram chips" are what male sheep leave behind.
Be complete with your story. For example, one paper says "this was our third attempt", but does not explain what happened on attempts 1 and 2. Based on the context, I would assume that the hardware was damaged, but was it burned out because a peripheral device was connected backwards, or did it fall off the back of the author's truck? It would be interesting to know what happened. Otherwise, the reference to the third attempt should be left out.
Computer Scientists (as well as Engineers) are known to have poor communications skills. The lab reports for a class are an opportunity to work on (and improve) writing skills.
Do not assume that your audience knows what acronyms mean. Some may be acceptable, such as PC for Personal Computer, but if you have ANY doubt, it is better to include an explanation the first time that you use it.
Be consistent with names. For example, I have seen "IPAQ", "ipaq", and "Ipaq" in the same paper, while the accepted name is "iPAQ".
Put things in the appendix, if needed. For example, code listings and printouts of web-pages are good to include as appendices.
Use a constant-width font for programming code and any commands.
Include a copy of your program(s).
If you include someone else's work (such as a program), be clear about where it starts and where it ends. A horizontal line before and after the code accomplishes this.
Please repeat the question before writing your answer.
Do not use contractions (such as "don't").
Be careful about units such as KB versus MB, and be sure to include units with any numbers.
Proof-read your paper. Here is an example of what not to do: "a floppy desk containing the source code". Also, check for spelling mistakes.
Be specific. Here is a bad example: "The different test cases used in the experiment are: the various temperatures (Celsius and Fahrenheit) used by the student." What were they? Why were they chosen?
Put webpage links in the references, and cite them. Instead of saying "you can download the code from http://www.website.com/file.html", say "the code can be downloaded from [1]".
If you put the instructor's name in the comments of your code, make sure to indicate that he/she is the instructor, and not one of the authors of your code.
Use a font of at least 10 points.
Use a stapler.
Make sure to follow the directions.
Use italics (or bold or underlining) to highlight commands that are in the text.
Do not be "conversational" in your reports. Avoid saying things that do not add to the report. For example, instead of "Well, next we, like, rebooted the machine, you know?" say "Next, we rebooted the machine."
If you use more than 3 words in a row from the original paper, then you need to re-state it. Your job is to summarize, paraphrase, and present the information in your own words, not copy! Here are some examples of what NOT to do:
A common problem is that graphs, tables, and other figures are not well presented. They may look nice, but the text should guide the reader through the figures. Why is the figure there? What is important for the reader to get from the figure? What about the figure is as you expect? What about the figure is different from what you expected? How were the numbers generated, that is, did you run the experiment once, twice, several times, 100 times, or a million times? Are the numbers from the best case, the worst case, the average, or were the results chosen by you to be representative? If someone else were to run your experiment, how likely will they see the same results (e.g. what is the variation?). How would you expect the results to be if you ran the experiment for more (or fewer) times? Why does the figure show what it shows? (In other words, give an explanation for why the values are what they are. Could the experiment be improved?)
Another common problem is that things are presented as lists, or as seemingly unrelated topics. A well-written document will guide the reader from one idea to the next. It is a good idea to write an introduction paragraph for each chapter, explaining what you are writing about in that chapter, why it is important, and how it relates to the rest of the document. It is also a good idea to write a summary paragraph at the end of each chapter, re-stating the important ideas from the chapter, clarifying the need for that chapter, and setting up the reader for the next chapter.
Be careful about references. If you write several chapters as various times, you may be tempted to label the first reference of each as [1], and label the first figure starting as fig 1, or even fig 1.1. The problem is that you will eventually combine these chapters into the same document. There can be only one figure 1! Also, the references may be difficult to sort out: reference 1 in one chapter may be reference 4 in another, and reference 3 in another. One solution to these problems is to use LaTeX, and it sort out the figure and reference numbers. Internally, they will have an identifier to refer to them, such as \cite{Weste93} or \ref{fig:num_operations}. If you do not use LaTeX, you can still put references like these in your document, such as [Weste93] and "figure [num_operations]". You can leave the paper citations in place (see the ACM format), and you can do a find/replace for the other ones later.
Put numbered equations on separate lines from the text.
If a term is not a standard one, define it briefly. That is, if a term does not appear in the index of the class textbook, you should say what you mean by it.
Our English department has a writing center with people to help you with your papers.
Citations can deflect criticism of your work when it is clear that a controversial claim is made by someone else.
One part of scholarship is evaluating other people's work. Do you agree? Why or why not?
Words that we use in everyday English may very in meaning from use in a technical paper. Briefly describe what you mean by the word, even if it means what you think it should mean. For example, when we use the word "car" in speaking, we may also include light trucks and SUVs. When you are writing, you should be specific. Do not make the reader guess.
I do not want to see a bunch of graphs in a summary. One is acceptable. A paper summary is to make the reader's job easy. Saying in words what the graphs show does help. A good paper will have the graphs and analysis in the text. Many papers (and theses) just throw the graphs together in the end, without explaining them.
It is a good idea to have a paragraph of text for every graph shown.
After your defense, I will give you back your draft. Once you have made the changes, bring a print-out of the new draft, as well as the draft that I gave back to you. This way I can go through and quickly see the changes you made. Have the signature pages ready (on the good paper), and also bring a good ink pen. If your changes are acceptable, I will sign then.
The way you learned to write in school was probably a particular style, such as that of the Modern Language Association (MLA). You should know that other styles exist, too.
No matter which style you use, you may have to break the rules. When writing a technical document, I think that clarity should be one of your top concerns, more so than conformity (especially if you do not know what you are conforming to).