| |
Contents
Jeffery A. Schroeder
Version 1.2
08.01.06
This is a living document. I am not claiming to have a complete grasp of the English language. Feel free to correct my mistakes too, and then we will all become better communicators for the benefit of readers and listeners everywhere.
Papers
References to have and to read
- Katzoff, S, "Clarity in Technical Reporting," NASA SP-7010, 1964. + Download Reference
- Strunk, W., Jr and White, E.B., The Elements of Style, 4th Edition, Longman Publishing Group, 2000. + Read Online
- Corbett, E.P.J. and Finlke, S.L., The Little English Handbook, 8th Edition, Longman Publishing Group, 1988.
Titles
- Titles should be as simple as possible but no simpler.
- Do not, under any circumstances, put an acronym in the title.
Abstract
- From the abstract alone, a reader should be able to understand the key things you did and found. How many times have you read an abstract that ends with "the results are presented and analyzed"? Give the reader the key, but brief, results instead.
- The abstract is not an introduction. State what you did and what you found. Do not go into what others have done and found. Do not give a long-winded problem statement and justification for what you did. State what you did and what you found.
Introduction
- Read Ref. 1 on how to write an Introduction. If writing your introduction was not the hardest part of writing your paper, then your introduction probably is not very good. It should be the hardest part. A good introduction, in my view, (and Katzoff influenced my view greatly) has about three paragraphs. The first paragraph states the problem and why it is important. Towards that end, you introduce key references in a cogent, logical way that leads the reader to recognize there is a gap in what has been done to date. The second paragraph states how what you are presenting attempts to fill that gap. This places your work in the proper context relative to the literature. The last paragraph tells the reader what is to come. It should be more than just being a robot reciting the paper's outline. Read Katzoff to understand. This will then be a perfect introduction. If you need more space to cover the literature in detail, do that in a separate Background section in your report. At the end of the introduction, I should want to read onwards.
Paragraphs
- Paragraphs have a main idea. Other sentences in that paragraph support that main point. If you introduce a new point, make a new paragraph. Your English teacher was actually on to something.
- Paragraphs should have more than one sentence.
- If you print your paper in double-column, single-spaced format, and you have a paragraph that is over a half-a-column long, you have either violated the "main point" principle, or you have words or sentences that can be deleted.
Punctuation
- When joining two complete thoughts with a conjunction (e.g., and, but, or, so), a comma is placed before the conjunction. If complete thoughts are not on both sides of the conjunction, then a comma is not used. Examples: 1. I went to the store, and I bought some beer. 2. I went to the store and bought some beer.
- Punctuation goes inside quotes (question marks are a special case not covered here). This problem occurs most frequently in the reference list when referring to conference papers.
Conclusions
- This is the take-home message. Reread your conclusions with that in mind. Many people just read the abstract and conclusions to decide whether or not it is worth their time to read the paper.
- Do not introduce a topic for the first time in the Conclusions.
References
- If you have written a good introduction, you will have an ample number of references…unless you are conducting ground-breaking research that no one else is working on.
- While referencing your earlier work and the work of your organization is fine, it is bad form to do so exclusively.
- Using URLs as references is bad form. URLs do not have longevity, and getting "Page Not Found" is frustrating.
- Reference superscripts are placed outside periods and commas. Not this6, but this,7 and this.8
Tips for editing
- Run the spelling and grammar checker in Word. It's not perfect, but it helps.
- Read your abstract, your introduction, and your conclusions. Are these three sections consistent? Are there any logical holes? Have you introduced different terminology in each that could be confusing for the reader?
- Read through it once with "slash and burn" in mind. That is, ruthlessly eliminate unneeded words and phrases. Eliminate vague modifiers like "very."
- Try to use the same terms throughout when you refer to an item. For instance, I just reviewed a paper that said "For simplicity, the flap/gear optimization algorithm will be referred to as the flap algorithm or flap scheduler from this point on." While that was helpful to say that those terms are equivalent, why have different terms at all? Pick a good term and stick with it; otherwise, it confuses the reader.
- Sometimes when I do not like how a paper is reading, I sometimes create a copy of the document and cut out every word in the sentence except for the subject and the verb (in technical writing, you often need to add the object back in so that you have the subject-verb-object left). This does several things. First, it often exposes how boring my verbs are. So, I add better verbs. Second, it allows me to check whether or not the document flows logically from paragraph to paragraph and from section to section. Third, it allows me to see if I have introduced more than one main idea in a particular paragraph.
- When I get tired of reading and re-reading the same paper, I try reading it backwards. I always find something new. And starting with the last conclusion and progressively reading backwards, I often find the end of the paper needs considerable strengthening.
+ Back to Top
Presentations
The best presentations cause the listeners to read the paper. The best presentations also tell listeners a few things that they didn't know before and in a way that they can remember. Those few things should be your conclusions. When you look at your conclusions, ask yourself these three questions:
- Did I support each of these conclusions in the talk? If not, then either support it or eliminate it.
- Would most people already know any of these conclusions without listening to my talk? If so, then pick a better conclusion.
- Were these conclusions presented in a way that I could expect a reasonably attentive listener to remember them (i.e., do I have too many, are they worded simply and to the point)?
Dos and don'ts
- Do "begin with the end in mind." That is, think of the points you want to make in your presentation. Again, those points are your conclusions. It is hard to say exactly how many conclusions is a good number, since that depends on the complexity behind each. But, in general, two is too few, and six is too many. How can you expect people to remember six things? Some think "well, if I give them six, then they should at least remember one." Instead, what usually happens is that they get overwhelmed with the amount of information you are forcing on them, and they shut down. The end result is that they remember none of your conclusions. They just want you to leave the podium now.
- Do have an outline slide, but keep it simple (not ridiculous simple…i.e., Introduction, Background, Description, Results, Conclusions). Sub-bullets can help group similar items in the outline.
- Do make everything legible. If you preface showing something illegible with "I know you can't read this," then why are you putting it up on the screen? If you say "it's for effect," then you're right. You are giving me the effect that you do not know how to make a presentation.
- Do use the available white space on the slide. Big margins reduce legibility.
- Do use pictures. Some of the best talks I have heard use only pictures with few words. That takes practice to pull off though. It focuses the audience on what is being said as you lead them through the picture. I don't need to remind you that bullet-after-bullet on chart-after-chart induces sleep.
- Do make titles, bullets, and sub-bullets have similar font throughout (Helvetica or Ariel seems preferred). It helps even out information presented slide to slide, and it creates the impression of a well-sanded package.
- Do not present everything in the paper. I cannot count how many times someone tries to justify including something in their presentation because it is also in the paper. That is not a justification. You probably have 20 minutes. How can you present everything in the paper? Pick the key points and present those. Tempt the listener to read the paper to find out the rest.
-
Do not assume that good paper figures are good presentation figures. People have time to pore over figures in a paper. They do not have that time in a presentation. You should alter figures for presentations so that
- The y-axis label text is horizontal (stack it, if needed). That is easily done in Powerpoint or Illustrator.
- Legends should be replaced by leaders to the data traces. It is difficult to refer back-and-forth from the legend to the trace in the audience. This is also easy in Powerpoint (Actually, I think leaders are better for papers too, so if you do that, you won't need much of a change for the paper).
- Do not use acronyms or internal project names. It is too hard for others, who have never used the acronym that you use daily, to remember it. This does not necessarily mean you have to spell out "Crew-Vehicle Systems Research Facility" instead of using CVSRF. Instead, you can use everyday English and say "the simulator" after you first introduce it. On internal project names, no one in the audience cares (except for maybe the project manager, and the presentation is not for him or her).
- Do not put logos on all the pages. It takes up space unnecessarily and defocuses the attention on the slide. Put the meatball, etc. on the first page and let it go after that.
+ Back to Top
Email
- Use subject lines that convey meaning. It helps others decide the message's urgency.
- Try to send the message to a single person in the "To:" line. Then, cc the rest. Putting multiple people in the "To:" line, especially when an action is required, makes all of those people coordinate to determine who needs to take the actions. Naturally, there are exceptions to this suggestion, but try your best.
- If I have to use the scroll bar to read your email, then it will probably be awhile before I read it. Be succinct.
- You know this, but always imagine reading your message on the running message at Times Square. With "forwarding" being easy, that is what could happen. So, exercise caution. I have recently been quite surprised at who has read messages I have written.
- When you "Reply to All," think about whether everyone else needs to know if you can also make the meeting. It simply cuts down on volume and saves everyone time if you don't send them something that they really do not need to know.
+ Back to Top
|
|
