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.
A literature review should not be a "how-to" guide. By this, I mean that you should not explain a concept with an occassional citation thrown in, but instead say specifically what the papers did, how well they did it, what they did differently from other papers, etc.
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.
Wikipedia pages are not appropriate for college-level research papers. Do not use Wikipedia.
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, you 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.
Here are a few actual comments.
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:
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.
It seems like I have this conversation every semester:
me: Why did you cite the reference like that?
student: It's according to the APA.
me: What does APA stand for?
student: (taps on phone or laptop...)
student: American Psychological Association
me: What does that mean?
student: (taps on phone or laptop...)
student: It's a professional society for Psychologists.
me: Aren't there any professional societies for computer science?
Yes; your references should be done according to either IEEE or ACM styles.
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.
Your report is due to your committee at least 1 week before the exam, if not earlier. It should be printed out and delivered to the physical mail box of each person by that time. Some people may prefer an electronic copy, and if you don't know their preference, you could always give both. Also, inform your committeee that you have put the printout in their mailboxes. You might not automatically fail if you are late, however, it gives your committee the impression that you are not prepared. Also, it gives us the impression that your exam time might be available for something else.
Practice your talk. Practice in front of a mirror, in front of a friend, in front of a pet. Get the timing down, and be able to move quickly from one point to the next. Your presentation time will be limited, and you want to get to the interesting stuff before your time runs out.
If you got comments from before, make sure you address them. Don't make the same mistakes a second time. Probably the biggest mistake is to not spend enough time preparing for the exam.
Cover breadth and depth. Don't spend too long on breadth. Probably the biggest problem people have when taking the qualifiers is that they do not know the breadth and the depth well enough, especially the depth. With breadth, you need to be able to talk able the subject matter, and to know the background. You probably don't have enough information in the 2 papers. They probably draw on work of others, and if you don't know anything about the others, the papers will not completely make sense. The "others" are the references they cite. Sometimes these others might draw heavily on other references. Be able to talk at length about the background, but don't do it. By this, I mean you should understand the background well, and be able to talk about any sub-topic that might come up in questions, but you should not spend your limited time presenting the background.
Depth is the specifics of the papers you were assigned. There should be some unique material in each, and you should know what that material is. What is unique about the papers? You should have an answer ready for this.
What is the contribution of the papers? How do the two papers connect? Your job is not to summarize the papers for the committee. For example, a question like "why does the p variable have a bar over it?" should not be met with an answer like "it appears that way in the equation on page 4". That avoids the question. Anyone could read the paper. Your job is to present the work as if it were your own. If the over-bar is not consistently used, you should be able to say with confidence if it is an error, or if p has a meaning like representing a vector in some places and representing a scalar value in others.
There are mistakes in the papers, because there are always mistakes. They might be small, like punctuation or grammar, or they might be large, like in a figure caption or in copying an equation. Things happen in publishing, like you prepare a figure one way, then you realize it would be better in a different way, so you change it. Does the description in the text match the new figure? Does the caption? Did you remember to export the new figure.JPG file from the new figure.fig file? Did you remember to copy the new files so that your co-authors have them, or will one of them undo your changes? Is the figure in color for a black-and-white publication? Et cetera. Did you find any mistakes? What is the meaning of all variables presented, and are they consistent in their usage? Watch out for changes in font, style (e.g. bold), capitalization, and so forth, since these can indicate a change. In signal processing, f might be your function in the time-domain while F is that function in the frequency-domain. If we use f(t) for our time-domain signal, f[n] might be our sampled signal. Transforming it and back, f^[n] might indicate the reconstructed version of f that should be the same, but might not be under certain conditions. In math, f could be a scalar while F might be a vector or matrix. A fancy L might mean Laplacian transform, another L might mean a Lebesgue space, a fancy R might mean the set of real numbers. Is i an index for a loop, an index for a matrix, or the square-root of -1? It could be all 3 in the same paper. If ε appears, do they mean a tiny error amount, or do they define it as a variable? If something is encoded in a proprietary character set (e.g. Windows-1252), how will it appear in the final paper? This is a frustrating problem, since it looks like garbage on computer A while looking normal on computer B.
Each paper should have something unique in it. It will describe some background, it will have a study of something, and it should have something that makes it stand out from the other papers written on the topic. What is that?
If I am your advisor, I will work closely with you and read several drafts of your work. I will let you know when you are ready to make copies for your committee.
If I am on your committee, I will carefully read your draft at least once. Once you have given me the printed copy, do not send me a "new" or "improved" copy. Chances are that I've already carefully read, and critiqued, most of your 100+ page manuscript. If you send me a new copy a few days before your defense, I will not have time to read it. I certainly do not have time to figure out what you've changed, or which of my requested corrections you discovered and fixed on your own. This just tells me that you were not really ready.
Typically, I will make comments in the margin as I read your thesis. 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.
Make sure that your sentences/paragraphs flow together. Imagine that you are talking to someone completely unfamiliar with your equipment/experiment. How would you describe it? You would not just jump from one subject to the next, but have a bit of explanation as to how the pieces fit together.
In speech, you would be sure to explain your terminology, say how things are connected, why things are important, and your explanation would flow together seamlessly from one idea to the next. Think of your thesis as a speech you are writing.
Avoid slang-like language. For example, if you say "a Windows box" I know you are referring to an IBM-compatible PC-type computer running one of the later Microsoft operating systems, and not a wooden construction for flowers hanging off a window ledge on a house. But for a thesis, you should be precise with your language.
If something has a name, try to explain it. Why is a "dt3000" called that? What do the "d" and "t" stand for? Are there 2999 earlier models of this thing?
You can use sub-headings, but they should not detract from your writing. The text show still flow together. A lot of students use sub-headings as a way of saying, "Now I'm going to talk about something completely different". This is not a correct use of sub-headings.
Make sure sub-headings do not make your text seem like an outline! If you have more than one heading/sub-heading per 3 pages of text, then you probably have too many.
Take pictures with a digital camera to add to your explanation.
Comments are OK, but be sure to remove them before giving the draft out. LaTeX is great for comments, since you can include comments within the text with a percent-sign, that do not appear when you print the document. Also, it is a good idea to mark them with something so that you can easily find them again. I use my initials.
Be sure to make an argument for each and every decision. Either:
a. You are an expert, and carefully make the parameter decisions
based upon professional insight after weighing all sides of the
argument.
-or-
b. You have no idea what is going on, but hope that something
magical will happen if you poke blindly at the controls.
You need to convince the reader of a!
Even if your choice is intuitive, writing about it should
help you articulate it.
A typical paragraph should have a topic sentence (or main point), examples, and an explanation for the examples, such as why it is worthy of your attention. Then conclude, and set up the next paragraph.
When talking about someone else's work, indicate whether your work agrees (or disagrees) with theirs. Also be sure to clearly delineate what they did and what you are doing.
Be sure to re-read everything after making changes before giving the next draft to me.
What are your conclusions? What do all of the graphs/figures mean? At the end, have a paragraph (or 2 or 3) explaining what your thesis has demonstrated. You can also summarize the whole work in a paragraph. Then, write (or update) the abstract).
Some people have suggested that using a different color ink would somehow spare the writer's feelings. But red ink stands out well, and grabs your attention. It says "stop, take a look at this". I use it on drafts of my own work.
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).