Green Book Fall 2013 Version - Web Access for Home - Manhattan ...
Green Book Fall 2013 Version - Web Access for Home - Manhattan ...
Green Book Fall 2013 Version - Web Access for Home - Manhattan ...
Create successful ePaper yourself
Turn your PDF publications into a flip-book with our unique Google optimized e-Paper software.
MANHATTAN COLLEGE<br />
MECHANICAL ENGINEERING DEPARTMENT<br />
A GUIDE TO TECHNICAL COMMUNICATION<br />
(FORMERLY THE REPORT AND PRESENTATION<br />
PREPARATION MANUAL)<br />
FALL <strong>2013</strong>
A Guide to Technical Communication<br />
Copyright © 2011-<strong>2013</strong> by the Mechanical Engineering Department<br />
of <strong>Manhattan</strong> College.<br />
All Rights Reserved.<br />
Last Updated 8/22/<strong>2013</strong><br />
Page i
A Guide to Technical Communication<br />
Cite as: A Guide to Technical Communication, <strong>Fall</strong> <strong>2013</strong>. Mechanical Engineering<br />
Department, <strong>Manhattan</strong> College, Riverdale, NY. Downloaded on [DD Month YYYY].<br />
Last Updated 8/22/<strong>2013</strong><br />
Page ii
A Guide to Technical Communication<br />
Table of Contents<br />
Acknowledgments............................................................................................................... v<br />
Preface to the <strong>Fall</strong> <strong>2013</strong> Edition......................................................................................... vi<br />
Preface to the <strong>Fall</strong> 2011 Edition........................................................................................ vii<br />
Introduction ......................................................................................................................... 1<br />
What Makes Technical Writing Different? ......................................................................... 2<br />
How to Communicate Effectively ...................................................................................... 3<br />
Structure of an Effective Report ..................................................................................... 3<br />
Report Preparation .......................................................................................................... 4<br />
Layout, Grammar, and Usage ......................................................................................... 4<br />
Making a Report “Read Well” ........................................................................................ 4<br />
Numbers, Calculations, Units, and Equations ................................................................ 5<br />
Figures and Tables .......................................................................................................... 7<br />
Proofreading: You Still Need To Do It! ......................................................................... 7<br />
Organization and Archival .............................................................................................. 8<br />
Presentation of Graphical and Tabulated Data ................................................................... 9<br />
Placement ........................................................................................................................ 9<br />
Captions .......................................................................................................................... 9<br />
Photographs..................................................................................................................... 9<br />
Drawings ....................................................................................................................... 10<br />
Graphs ........................................................................................................................... 10<br />
Tables ............................................................................................................................ 15<br />
Guidelines <strong>for</strong> References ................................................................................................. 17<br />
Referencing of Works in a Document .......................................................................... 17<br />
Formats <strong>for</strong> References ................................................................................................. 17<br />
Laboratory and Technical Reports .................................................................................... 21<br />
Cover Page .................................................................................................................... 21<br />
Abstract ......................................................................................................................... 21<br />
Table of Contents .......................................................................................................... 22<br />
Introduction and Analysis ............................................................................................. 22<br />
Experimental Apparatus and Procedure ........................................................................ 23<br />
Results and Discussion ................................................................................................. 24<br />
Conclusions ................................................................................................................... 25<br />
References ..................................................................................................................... 25<br />
Appendices .................................................................................................................... 25<br />
Optional Sections .......................................................................................................... 26<br />
Format <strong>for</strong> Short Laboratory Reports ............................................................................... 28<br />
Design Project Reports - General Instructions .................................................................. 29<br />
Format <strong>for</strong> Design Project Proposals ................................................................................ 30<br />
Cover Page .................................................................................................................... 30<br />
Table of Contents .......................................................................................................... 30<br />
Introduction ................................................................................................................... 30<br />
Proposal......................................................................................................................... 30<br />
Schedule ........................................................................................................................ 30<br />
Format <strong>for</strong> Design Project Progress Reports .................................................................... 31<br />
Last Updated 8/22/<strong>2013</strong><br />
Page iii
A Guide to Technical Communication<br />
Cover Page .................................................................................................................... 31<br />
Table of Contents .......................................................................................................... 31<br />
Introduction ................................................................................................................... 31<br />
Progress to Date ............................................................................................................ 31<br />
Schedule ........................................................................................................................ 31<br />
Calculations (If necessary) ............................................................................................ 31<br />
Format <strong>for</strong> Design Project Final Reports .......................................................................... 32<br />
Cover Page .................................................................................................................... 32<br />
Table of Contents .......................................................................................................... 32<br />
Executive Summary ...................................................................................................... 32<br />
[Your Project Title] ....................................................................................................... 32<br />
Reflections .................................................................................................................... 32<br />
Calculations................................................................................................................... 32<br />
Acknowledgments......................................................................................................... 32<br />
References ..................................................................................................................... 33<br />
Appendices .................................................................................................................... 33<br />
General Guidelines <strong>for</strong> Oral Presentations ....................................................................... 34<br />
Initial Considerations .................................................................................................... 34<br />
Preparation Guidelines .................................................................................................. 34<br />
Slide Design and Creation ............................................................................................ 35<br />
To Outline or Not to Outline? That is the Question ...................................................... 35<br />
Use of Graphics ............................................................................................................. 36<br />
Presentation Issues ........................................................................................................ 36<br />
General Guidelines <strong>for</strong> Electronic Mail ............................................................................ 38<br />
Just Because It’s Fast Doesn’t Mean It Should Be In<strong>for</strong>mal ........................................ 38<br />
Who Will Be Reading Your Email? ............................................................................. 39<br />
Subject Line .................................................................................................................. 39<br />
Keep the Length Appropriate ........................................................................................ 40<br />
Format ........................................................................................................................... 40<br />
Write an Initial Draft, Then Revise! ............................................................................. 40<br />
Attachments .................................................................................................................. 40<br />
Proofreading, You Still STILL Need to Do It! ............................................................. 40<br />
Don’t Hit Send in Anger ............................................................................................... 41<br />
Closing and Signatures ................................................................................................. 41<br />
Emails versus SMS (Text) Messages ............................................................................ 42<br />
General Guidelines <strong>for</strong> Voicemail .................................................................................... 43<br />
References ......................................................................................................................... 44<br />
Appendix A: Format <strong>for</strong> Cover Sheets ............................................................................. 45<br />
Appendix B: Sample Presentations ................................................................................... 50<br />
Experimental Study Slides ............................................................................................ 51<br />
Design Study Slides ...................................................................................................... 55<br />
Last Updated 8/22/<strong>2013</strong><br />
Page iv
A Guide to Technical Communication<br />
Acknowledgments<br />
A guide like this is not a single-person ef<strong>for</strong>t. While I have been heading up the<br />
updates and revisions to this guide, it would be the height of pretense to claim that I have<br />
done this on my own. Many people, whether they realize it or not, have been instrumental<br />
in making this document what it is. First, the Mechanical Engineering faculty, past and<br />
present, have been responsible <strong>for</strong> putting together the original version of the <strong>Green</strong><br />
<strong>Book</strong>, as well as offering edits and advice <strong>for</strong> this new, enhanced version. Second, other<br />
faculty members outside the department have expressed interest, and conversations with<br />
them have given me ideas on enhancements. Third, the alumni and students of this<br />
department, the ultimate beneficiaries of this work, have been instrumental <strong>for</strong> shaping<br />
this guide. Through watching what aspects of technical communication they find most<br />
challenging and listening to their suggestions, I have attempted to mold this guide to suit<br />
their needs. Finally, I must thank the College administration, which has been generous<br />
with summer grants and stipends to fund this ef<strong>for</strong>t.<br />
John C. Leylegian<br />
June <strong>2013</strong><br />
Last Updated 8/22/<strong>2013</strong><br />
Page v
A Guide to Technical Communication<br />
Preface to the <strong>Fall</strong> <strong>2013</strong> Edition<br />
This manual can improve your career.<br />
This sounds like a far-fetched claim, doesn’t it? Don’t dismiss it outright.<br />
When I first read this manual, it was a guide <strong>for</strong> the correct <strong>for</strong>mat <strong>for</strong> reports to be<br />
written by the students of the Mechanical Engineering Department at <strong>Manhattan</strong> College.<br />
However, after reading my first batch of reports while teaching the Thermal-Fluids<br />
Laboratory, I realized that knowing the correct <strong>for</strong>mat <strong>for</strong> a report means precious little if<br />
a student doesn’t know what constitutes good technical writing.<br />
My path as an engineer has taken me through many different environments in many<br />
different institutions since I began my undergraduate engineering studies. My motivation<br />
<strong>for</strong> the “reboot” of the <strong>Green</strong> <strong>Book</strong> was to take the experiences I have had when it comes<br />
to some of the “soft skills” in engineering, particularly communication, and present them<br />
in a manner which could benefit you by improving your own communication skills<br />
The first edition of this new <strong>Green</strong> <strong>Book</strong> was released <strong>for</strong> the <strong>Fall</strong> 2011 semester, and<br />
thanks to the useful feedback from the faculty and students of this department, I have<br />
fine-tuned this guide, adding more new material wherever possible without obscuring the<br />
main idea of the guide: that a good, organized story is all you need to be able to<br />
communicate your ideas to your peers, managers, customers, the public, or anyone else<br />
who is counting on those ideas.<br />
The <strong>Fall</strong> <strong>2013</strong> Edition features new sections on email communications and voicemails.<br />
Based on my own experiences, as well as comments made by recent graduates, it is my<br />
belief that in<strong>for</strong>mation like this would be useful, and my hope is that students will agree.<br />
So back to my grandiose claim. Why do I think that this pdf can improve your career?<br />
When I listen to the Consultors Committee at their semi-annual meetings, I rarely hear<br />
them say, “I wish students here got more Heat Transfer,” or “Why don’t your graduates<br />
know the difference between Pappas’ Theorem and Stokes’ Theorem?” What I do hear<br />
them say is, “New hires need to work on their writing skills,” or “Our newest engineers<br />
have to work on their presentation skills.” Just like any other skill, communication takes<br />
time and practice to cultivate. If you work on it be<strong>for</strong>e you finish your studies, you will<br />
have an advantage when looking <strong>for</strong> a job. If you continue to work on it after you leave<br />
here, you will have an advantage as you try to advance your career.<br />
Take this guide, read it, apply the lessons it provides, and give feedback on it. It will<br />
be worth it.<br />
John C. Leylegian<br />
June <strong>2013</strong><br />
Last Updated 8/22/<strong>2013</strong><br />
Page vi
A Guide to Technical Communication<br />
Preface to the <strong>Fall</strong> 2011 Edition<br />
In my two decades in the engineering field, I have learned that there is an “engineer’s<br />
myth.” This myth is that engineers are these people who sit in cubicles day in and day<br />
out, and don’t do much beyond crunching numbers, writing code, and running<br />
experiments. I quickly learned (even be<strong>for</strong>e I completed my bachelor’s degree) that a<br />
huge part of an engineer’s time is spent in communication. Whether it is in writing<br />
reports, assembling and delivering presentations, or even crafting proper e-mail<br />
correspondence, if an engineer is unable to communicate what he or she sees on the<br />
screen, in the experimental results, or on the scratch pad, those nuggets of wisdom will<br />
stay there.<br />
I must admit that this scared me a little bit. I never liked writing, and I hated getting in<br />
front of a group of people and speaking. However, I found that when I was writing and<br />
talking about stuff I liked, it wasn’t nearly as difficult. It became easier <strong>for</strong> me to do, but I<br />
still needed work. I got plenty of practice in graduate school, since writing and presenting<br />
are large parts of the graduate experience. It was there that my skills improved markedly,<br />
mostly because I was given the key to effective writing and speaking.<br />
When I started working in industry. I was routinely tasked to write reports, make<br />
presentations, and even proofread others’ work, in addition to my technical duties. I<br />
strongly believe that my ability to communicate, just as much as my technical prowess,<br />
was instrumental to not only my advancement, but also to my ability to take on side<br />
work, and to finally make the transition back to academia.<br />
If all of this doesn’t convince you of the importance of good communication skills, let<br />
me tell you the story of Dr. John Houbolt. Dr. Houbolt was an aerospace engineer<br />
working <strong>for</strong> NASA back in the early days of manned space exploration. He was an expert<br />
in rendezvous, the maneuvering of two spacecraft such that they arrive in the same orbit<br />
and within visual contact. He led committees exploring and studying the different types<br />
of rendezvous, specifically applied to its usefulness in a manned lunar mission. He and<br />
his colleagues determined that Lunar Orbit Rendezvous, or LOR (the meeting of two<br />
spacecraft in lunar orbit) would decrease the required liftoff weight of a lunar mission by<br />
roughly 50 percent.<br />
What did Houbolt do? He talked about his discovery, to anyone who would listen. He<br />
gave several briefings to engineers at NASA and the U. S. Air Force. However, there was<br />
significant resistance. In addition to the skepticism surrounding the weight savings,<br />
rendezvous was an issue. While rendezvous in space is something we take <strong>for</strong> granted<br />
today, in 1960 it had never been done. In fact, the United States had not even launched a<br />
human into space yet! If rendezvous in lunar orbit failed, astronauts could be stranded.<br />
Un<strong>for</strong>tunately, the skeptics were not even going to check the calculations and see if the<br />
concept had any merit. It looked like there was enough prejudice against LOR that it<br />
would be dismissed outright.<br />
Houbolt was determined to let LOR get a fair shake, and he knew that to do it he<br />
would have to share the idea with the NASA leadership. In two letters written to the<br />
NASA Associate Administrator and a two-volume technical report, Houbolt thoroughly<br />
explained the concept and how it would be able to meet the deadline set by President<br />
Last Updated 8/22/<strong>2013</strong><br />
Page vii
A Guide to Technical Communication<br />
Kennedy (they had less than a decade to land a man on the moon). It was risky – Houbolt<br />
knew that going over as many heads as he did could cost him his job. It did pay off<br />
though, and LOR was given a chance to compete against other types of lunar missions.<br />
With further presentations and reports, LOR was chosen as the model <strong>for</strong> the Project<br />
Apollo missions.<br />
In the end, it didn’t matter that LOR was the best way to get men to the moon. It did<br />
matter that the main champion of the concept was able to communicate the idea to the<br />
right people in order <strong>for</strong> it to be considered, even in the face of seemingly impossible<br />
opposition. I hope that this story illustrates the value of good communication skills to all<br />
of you.<br />
John C. Leylegian<br />
August 2011<br />
Last Updated 8/22/<strong>2013</strong><br />
Page viii
A Guide to Technical Communication<br />
Introduction<br />
Written and oral communication skills are very important in our society. In particular,<br />
an engineer is frequently called upon to explain his or her work to an audience. The<br />
audience may be wide-ranging, such as radio or television, a room full of people, or just<br />
the boss. The ability to write and speak well in these situations often accounts <strong>for</strong> who<br />
advances in an organization. Professional presentation needs to be developed in addition<br />
to proper grammar and fluency of style. Development of professional presentation ability<br />
is the purpose of this manual.<br />
In the undergraduate curriculum, instructors regularly require written or oral reports in<br />
a style that is more <strong>for</strong>mal than the typical homework assignments, tests and class<br />
participation <strong>for</strong>mat. This manual serves as a guide <strong>for</strong> the preparation of such reports in<br />
courses offered by the Mechanical Engineering Department. Previous versions of report<br />
writing manuals were developed <strong>for</strong> the types of reports and presentations a student may<br />
be expected to deliver in a given class. However, one important item has been left out:<br />
how does one write or speak in the proper manner <strong>for</strong> technical reports and presentations?<br />
There<strong>for</strong>e, this manual not only addresses the proper structure <strong>for</strong> reports and<br />
presentations, but also how to write and speak properly.<br />
Your instructor will expect you to follow the <strong>for</strong>mat indicated <strong>for</strong> reports in all courses<br />
that require report writing and presentation unless he or she indicates otherwise. Keep<br />
this manual <strong>for</strong> reference throughout your undergraduate program, but note that this<br />
manual is a work in progress (as it should be). Any input, comments or suggestions are<br />
always welcome. Remember that this manual is to serve you, the student, to introduce<br />
you to proper technical communication.<br />
When you commence your working career, pay close attention to the <strong>for</strong>mat expected<br />
of you in a new environment. Know what is expected of you, but hopefully the lessons<br />
learned here will give you an edge.<br />
Last Updated 8/22/<strong>2013</strong><br />
Page 1
A Guide to Technical Communication<br />
What Makes Technical Writing Different?<br />
No doubt, by this time you have written many papers, essays and reports <strong>for</strong> different<br />
teachers and professors, both in high school and college. However, this is technical<br />
writing, and technical writing is a VERY different undertaking than what you have<br />
probably done to date. The main difference between what you have done in the past and<br />
good technical writing is that you must be clear, concise, and complete in your reports.<br />
In industry you will often be called upon to give written and oral reports. Employers<br />
of engineering graduates around the country fault graduates not <strong>for</strong> their technical<br />
knowledge, but <strong>for</strong> their poor communication skills. If you opt <strong>for</strong> graduate school and a<br />
possible career in academia, you will definitely need to know how to write and how to<br />
speak. Reports, theses, papers, articles, lectures, talks at conferences… you’ll need to do<br />
them all not to mention a thesis or dissertation and the associated defense.<br />
There are very important reasons <strong>for</strong> this style, which no doubt runs counter to what<br />
you have done in the past. The first reason is that the audience <strong>for</strong> technical reports is<br />
very different. In a literature class, <strong>for</strong> example, the professor is the only one reading your<br />
paper, and he or she will most likely read it from cover to cover, poring over every word.<br />
In an engineering firm, on the other hand, several people may be reading what you write,<br />
and most of them will not read the entire work. 1 Sometimes it is because they only need<br />
to read the parts most essential to their work. Sometimes it is because they just don’t have<br />
the time to read every page of every report they need to review. 2 In any event, the<br />
technical literature reader needs to identify the in<strong>for</strong>mation most important to them as<br />
quickly as possible. They need to be able to understand the point you are trying to get<br />
across, without trying to interpret your data <strong>for</strong> themselves, they need to do so in<br />
language they can readily understand, and they need to find the in<strong>for</strong>mation they need<br />
where they expect it to be in the report. Put simply; don’t make the reader work harder<br />
than necessary to get the story you’re trying to tell. An important item that should be<br />
given a serious consideration in any technical writing is the focus of the report. A<br />
technical report conveys a point or some points to readers, e.g., make conclusions <strong>for</strong> a<br />
lab result or present some analytical model. All arguments in the report should be related<br />
to the point(s) of the report. The author may go a little off track by discussing some<br />
related topic but must be careful not to discuss them to the extent that dominates the<br />
report. For example, if a report is written about results related to the cooling channel in an<br />
engine the author might write some general description of the engine but this description<br />
should not overwhelm the focus of the report, which is cooling channels.<br />
Now think about the textbooks you have read <strong>for</strong> your various science and engineering<br />
courses. Do you read them cover to cover, or do you pick and choose the passages you<br />
need to read? Are the best textbooks written in obscure, obtuse language, or are they<br />
written plainly and simply? Strive <strong>for</strong> that level of clarity in your writing. It’s not easy,<br />
and it takes time, but with ef<strong>for</strong>t it is possible.<br />
Last Updated 8/22/<strong>2013</strong><br />
Page 2
A Guide to Technical Communication<br />
How to Communicate Effectively<br />
Here are a few suggestions <strong>for</strong> writing. These tips will help your reports look<br />
professional, and make them easy to read and understand.<br />
Structure of an Effective Report<br />
You must always remember that the key to good technical writing is to tell a good,<br />
coherent story. The different sections of a report just provide a framework, so that a<br />
reader can get to the parts most important to him or her in a hurry. The organization of<br />
these sections grows out of the need to tell a story in order, not the other way around.<br />
Later on in this manual the details of different types of reports will be discussed.<br />
However, regardless of the type of report, the order of the story will not change. The<br />
body of the report (excluding abstract, table of contents, references and appendices – but<br />
more on those later) will follow this order: 2<br />
Introduce the Problem<br />
Your report will most likely address some engineering problem; it can be collection<br />
and analysis of some experimental data, or possibly the generation of a new design based<br />
on an objective subject to some constraints. In either event, describing the problem is the<br />
first thing that needs to be done. Depending on the type of report, you should be<br />
answering one or more of the following questions:<br />
Why are these data useful?<br />
What is your proposed design supposed to do?<br />
What have other researchers/engineers done in the past to try to solve this problem?<br />
Is there any underlying theory to better frame and describe the challenges of the<br />
problem?<br />
Describe Your Solution<br />
Now that the problem is framed, tell the reader how you solved it. If it is an<br />
experimental study, what apparatus did you use? What data did you collect? If it is an<br />
analytical study, what theory did you develop or utilize to describe the phenomenon? If it<br />
is a design project, explain the design you developed.<br />
Tell What You Learned<br />
This section is an interesting part of a report. Now that you have presented your<br />
experimental data, you can talk about what they mean. How do they relate to other<br />
studies per<strong>for</strong>med in the past? Did you see anything unusual? What do you recommend<br />
<strong>for</strong> future work in this field? If it’s a design project, what would you have done<br />
differently based on what you know now?<br />
Don’t Let Your Story “Bleed”<br />
We’ve established the parts of a report. It is important that this order be respected. In<br />
other words, make sure that in<strong>for</strong>mation that should be in one part of a report doesn’t<br />
“bleed” into another part. This will disrupt the flow of the story, and could lose the<br />
reader. In addition, if someone is looking <strong>for</strong> specific in<strong>for</strong>mation, having it in the wrong<br />
part of the report, the reader might not find it.<br />
Last Updated 8/22/<strong>2013</strong><br />
Page 3
A Guide to Technical Communication<br />
Report Preparation<br />
All laboratory reports are to be produced using computer software, mainly word<br />
processors and drawing software – no handwriting or hand drawing is permitted. This<br />
shouldn’t be a problem, since everybody has a computer, or access to one. Write your<br />
reports as professional reports (not school exercises); pretend that the work was done to<br />
examine a specific phenomenon <strong>for</strong> a customer and write it accordingly.<br />
When writing any kind of report, unless a style sheet tells you otherwise, start each<br />
section on a new page, with a clear, e.g., bold, heading title.<br />
Layout, Grammar, and Usage<br />
When possible, use templates <strong>for</strong> ease of <strong>for</strong>matting. However, if a template is not<br />
provided, type single spaced, and use an easy-to-read font type and size. Commonly used<br />
fonts are Times New Roman (serif font) and Arial (sans serif font). Font sizes of 10-12<br />
points are most appropriate. Number all pages, except the title page. Pages be<strong>for</strong>e the<br />
body of the report (e.g. Abstract, Table of Contents) should be numbered using Roman<br />
numerals; all other pages should be numbered using Arabic numerals.<br />
Neatness and clarity, as well as the proper use of the English language, are essential.<br />
Reports should be correctly assembled be<strong>for</strong>e submittal, and the entire report should be<br />
identically <strong>for</strong>matted, even though different people may have written different parts.<br />
Correct spelling is important. Read aloud your report when completed. This may help<br />
you to correct a passage that is not as clear as it seemed when you wrote it. Do not use<br />
contractions in a technical report. They are fine in other, less <strong>for</strong>mal documents (e.g.<br />
this guide).<br />
Making a Report “Read Well”<br />
Editing <strong>for</strong> style is something that some authors prefer to do towards the end of the<br />
writing process; others are constantly editing <strong>for</strong> style. Whichever way you prefer,<br />
remember that a large portion of where many students’ reports fall short is <strong>for</strong> style. Style<br />
is one of the things that make a report readable. Here are some things you can do to<br />
improve style: 1<br />
Avoid Unnecessary Words<br />
One of the most common issues seen in technical writing is the use of unnecessary<br />
words. It’s as if people think that more words automatically mean better technical<br />
writing! More often than not, the opposite is true. One way to remove unnecessary words<br />
is to avoid redundancies:<br />
• Change “the woman had a set of twins” to “the woman had twins.”<br />
• Change “the fuel-rich flame was green in color” to “the fuel-rich flame was green.”<br />
• Change “acids tend to be sour tasting” to “acids tend to be sour.”<br />
A second way is to avoid “inflated phrases.” For instance:<br />
• Change “the increase in current is due to the fact that the conductor was heated” to<br />
“the increase in current is because the conductor was heated.”<br />
Last Updated 8/22/<strong>2013</strong><br />
Page 4
A Guide to Technical Communication<br />
• Change “salt air has a corrosive effect on untreated metal” to “salt air corrodes<br />
metal.”<br />
The famous British author George Orwell (1903-1950) had two rules <strong>for</strong> writing:<br />
If it is possible to cut a word out, cut it out.<br />
Never use a long word when a short one will do.<br />
Granted, one can take this too far (cutting out so many words that the point you are trying<br />
to get across becomes obscured), but proofreading should catch this. Albert Einstein<br />
summed it up best:<br />
Everything should be made as simple as possible, but not simpler.<br />
Strive <strong>for</strong> clarity, conciseness and accuracy in your writing.<br />
Voice, Tense, and Use of First Person<br />
The difference between writing in the active and passive voice is whether the writer<br />
wishes to emphasize the agent or the object of a given action. In many cases, this means<br />
that the passive voice is preferred – in an experimental report, <strong>for</strong> instance, you want to<br />
emphasize what you did, not the fact that you did it. You should not slavishly adhere to<br />
this rule though. There are times when a passage is more difficult to read in the passive<br />
voice. At those times, write in the active voice. Remember, readability is paramount.<br />
Be sure to use appropriate verb tenses. In general, your text should flow<br />
chronologically. Remember that you are recounting what was done, not what you are<br />
doing or what you will do. There<strong>for</strong>e, past tense will be used quite extensively. Only use<br />
the present and future tenses where absolutely required.<br />
Once you move from the past to the present, stay in the present unless there is a<br />
compelling reason to use the past tense. First person plural, i.e. “we”, is appropriate in<br />
many sentences – again, it’s all about making yourself understood. If writing in the first<br />
person, active voice is the most effective way to get your point across in a particular<br />
sentence, just go with it.<br />
Avoid the “Gotchas”<br />
One point that often gets glossed over is that when you write something, you must be<br />
prepared to back it up. There are two ways one can back up a statement. The first is by<br />
citing your own current work: “As seen in Fig. 3, the relationship between Seebeck<br />
voltage and temperature is linear.” The second is by citing previous work in the field: “In<br />
Reference 4, dimensional analysis was used to prove that friction factor is a function of<br />
Reynolds number and relative roughness.”<br />
Numbers, Calculations, Units, and Equations<br />
Numbers one through ten are expressed as words; other numbers are expressed as<br />
numbers.<br />
Unless your professor tells you otherwise, a good rule of thumb <strong>for</strong> the number of<br />
significant figures is the following: Experimental uncertainties should be rounded to one<br />
significant figure, unless the leading digit in the uncertainty is a 1. In that case the<br />
uncertainty should be rounded to two significant figures. Then, the last significant figure<br />
Last Updated 8/22/<strong>2013</strong><br />
Page 5
A Guide to Technical Communication<br />
in a stated value should be of the same order of magnitude as the uncertainty. Even when<br />
your results have no stated uncertainties, remember that the number of significant figures<br />
you use is indicative of the uncertainty you expect. In other words, if you state a<br />
temperature of 100.002°C, you are suggesting that your error is on the order of 0.001°C,<br />
whether you realize it or not! 3<br />
Create all equations using an equation editor. Using the Equation button on the Insert<br />
tab of Microsoft Word (versions 2007 and later) can sometimes result in equations that<br />
are “compressed” so that symbols which should be the same size are not always done so.<br />
Here’s an example of an equation created using this tool:<br />
<br />
<br />
(3)<br />
Note that the symbols in the fraction are smaller than the other symbols in the equation.<br />
Look at your textbooks – are the equations in these books laid out that way? An easy way<br />
to get better-looking equations is to use the Object button (it’s just to the left of the<br />
Equation button on the Insert ribbon). On the pop-up window, select “Microsoft Equation<br />
3.0” and create your equation using the pull-down menus. Here is the same equation<br />
created using Microsoft Equation. Note the difference.<br />
<br />
x<br />
<br />
y <br />
2<br />
<br />
max<br />
<br />
xy<br />
2<br />
<br />
(3)<br />
<br />
Equations are typically centered on a line. If you are going to refer to back to<br />
equations you have already provided, these equations should be numbered. Number the<br />
equations with a number in parentheses to the right of the equation. Equations should be<br />
numbered in the order in which they appear. Equation numbers should be right-justified<br />
on the line, as was done in the two examples above. To achieve this effect, you can set up<br />
a style in Microsoft Word with a center tab stop at the center of the line, and a rightjustified<br />
tab stop at the right margin. When you refer to equations in the text, they should<br />
be mentioned by number, e.g., “In Equation (1) we see…”, or “Equations (3)-(5) outline<br />
the iterative method to determine temperature.” However, sample calculations and<br />
uncertainty analyses can be done using a mathematical program, such as Mathcad.<br />
Make sure you <strong>for</strong>mat numbers and equations properly, even when they are in the<br />
body of the text. That means never use the <strong>for</strong>mat 46E-4; this should be 46×10 -4 . (Why<br />
not?) Also, never use the <strong>for</strong>mat x^2; this should be x 2 . Formatting of superscripts and<br />
subscripts, adding italics, etc., in text is relatively easy to do, and finding special<br />
characters (including Greek letters) is also straight<strong>for</strong>ward. If you don’t know how to do<br />
it, ask someone. Here are some basic tips <strong>for</strong> proper <strong>for</strong>matting of mathematical<br />
expressions so that your work looks professional:<br />
Scalar variables indicated by upper and lowercase Latin characters (A, B, C, x, y, z)<br />
should be italicized.<br />
Scalar variables indicated by lower case Greek characters (α, β, γ, δ, ε, ω) should be<br />
italicized. Upper case Greek characters (Δ, Θ, Π, Σ, Φ) are not italicized.<br />
2<br />
Last Updated 8/22/<strong>2013</strong><br />
Page 6
A Guide to Technical Communication<br />
<br />
<br />
<br />
Vectors should either be indicated with an arrow ( x ), or should be bold type without<br />
italics (x).<br />
Multiplication of scalar variables should be written as ab, not ab, a·b, or a*b.<br />
Exponential, logarithmic, and trigonometric functions (exp, ln, sin) should not be<br />
italicized.<br />
Make sure there is sufficient space be<strong>for</strong>e and after the equation, so it doesn’t look<br />
crowded.<br />
It is interesting to note that some of these rules have changed over time, and will<br />
probably continue to do so. For instance, common dimensionless groups such as<br />
Reynolds number (Re), Prandtl number (Pr), etc. were never italicized, just like<br />
functions. However, it has become common to italicize these abbreviations as well.<br />
All numbers should have appropriate units (unless the number is dimensionless, e.g.<br />
Reynolds Number – by the way, note the lack of apostrophe on “Reynolds”). Do not mix<br />
units in a report: select either SI or British units, or provide the secondary unit type in<br />
parentheses (e.g. 1 in (25.4 mm)). Write units in short hand (e.g. “ft” not “feet”)<br />
Figures and Tables<br />
If you provide a figure or table, it MUST be cited in the text. All figures and tables<br />
need captions. Captions should include numbers, e.g., Figure 1, Table 1, etc. These<br />
numbers should be in the order in which they are cited in the text. Figure captions are<br />
below the figures, not above. Table captions, however must be placed above the table.<br />
Figure and table captions should be descriptive, e.g.:<br />
Figure 3: Comparison of experimental and theoretical friction factors as a function<br />
of Reynolds Number.<br />
Note that you may use the cross-reference capability that is available in most word<br />
processing software. This feature is useful in case a new figure, table, equation or<br />
reference is added. The numbers will automatically shift and no manual numbering is<br />
needed.<br />
There will be more in<strong>for</strong>mation about developing effective graphs later in this manual.<br />
Proofreading: You Still Need To Do It!<br />
How does a group make sure that all parts are correctly <strong>for</strong>matted, and that proper use<br />
is assured? By proofreading! Some people think that in the age of spellcheckers that<br />
proofreading is no longer necessary. Spellcheckers will identify words that are not in the<br />
dictionary, not misspelled words. A spellchecker will not be able to tell you when to use<br />
“they’re,” “there,” or “their.” A spellchecker probably doesn’t know the difference<br />
between “it’s” and “its” (do you?). Proofreading will not only spot misspelled words, it<br />
can also correct organizational problems, find unnecessary words, and all of the other<br />
pitfalls identified above.<br />
If you are writing a report as part of a group, proofreading will help spot mistakes<br />
more easily. Getting a fresh set of eyes on the portions of the report you didn’t write can<br />
help detect mistakes that you aren’t able to see.<br />
Last Updated 8/22/<strong>2013</strong><br />
Page 7
A Guide to Technical Communication<br />
Proofreading only takes a few minutes, and the payoff is well worth the investment of<br />
time.<br />
Organization and Archival<br />
If you are working on a long-term (one or two semester long) design project, you will<br />
most likely be publishing several documents regarding the same project; <strong>for</strong> example, a<br />
proposal at the outset, periodic progress reports, and culminating with a final report.<br />
Some of the narrative of earlier reports should be useful in subsequent reports. There<strong>for</strong>e,<br />
be sure to save your reports on <strong>for</strong> later use. There are now several different options,<br />
including flash drives, <strong>Manhattan</strong> College’s remote drive (the “<strong>Home</strong> Server”), Google<br />
Docs, Dropbox, and the list goes on. They all have their advantages and disadvantages. If<br />
you have done a good job on your proposal, the task of writing your progress reports will<br />
be easier. Likewise good proposals and progress reports lessen the anguish of writing the<br />
final report, the major written requirement <strong>for</strong> such a project.<br />
There are two other very good reasons <strong>for</strong> organizing and archiving your reports. First,<br />
saving copies of your reports can provide a good source of in<strong>for</strong>mation <strong>for</strong> prospective<br />
employers. As was stated above, employers want engineers who can communicate. What<br />
better way to prove this than showing examples of your work? Second, once you get into<br />
industry, it is very possible that some work you have done will be put on hold <strong>for</strong> an<br />
indeterminate length of time – it can be anywhere from weeks to years. If you properly<br />
document the work you have done via reports, memoranda, etc., and archive those<br />
reports, you will be able to pick up where you left off more easily than if you have to<br />
piece material together from memory and sparse notes.<br />
Last Updated 8/22/<strong>2013</strong><br />
Page 8
A Guide to Technical Communication<br />
Presentation of Graphical and Tabulated Data<br />
A report or presentation will typically have several figures and/or tables. Figures and<br />
tables are invaluable, because they can convey in<strong>for</strong>mation or ideas in a compact, easyto-understand<br />
manner. Figures include all photographs, drawings, and graphs. Tables are<br />
data presented in a row/column <strong>for</strong>mat.<br />
Placement<br />
Figures and tables are best placed at the top or bottom of a page. Floating text boxes or<br />
frames in Microsoft Word work well when you want to fix figures or tables in these<br />
positions while avoiding unnecessary white space on pages. Be sure to keep sufficient<br />
space (the equivalent of a single line) between the end of the text on a page and a figure<br />
or table.<br />
Captions<br />
All figures and tables must be numbered consecutively and referenced in the narrative<br />
by that number, i.e. no figure or table should appear without being discussed in the<br />
narrative. Figures and tables should have their own numerical sequences, i.e., if a report<br />
has five figures and two tables, the figures will be named “Figure 1” through “Figure 5,”<br />
and the tables will be named “Table 1” and “Table 2.” Captions should appear below a<br />
figure, but above a table.<br />
Captions should be descriptive. For example: “Figure 1. Design of conical-flowderived<br />
wave rider.” Remember that sometimes figures will be taken out of context, and<br />
writing a descriptive caption will help to insure that the figure is not misused. Part of a<br />
descriptive caption includes describing the symbols/lines used in a graph; sometimes the<br />
legend is insufficient to give all of the in<strong>for</strong>mation clearly, and the caption can be used to<br />
clarify things. Captions are not necessary <strong>for</strong> figures or tables in presentations, since<br />
you’re talking about the figures or tables and can describe them fully.<br />
The caption should be in the same font as the rest of the text, but bold or italicized (or<br />
both) so it stands out from the rest of the text. Captions can be inserted using the Insert<br />
Caption button found in the References ribbon of Microsoft Word. Using this feature<br />
allows you to reference the figures in your text using the Cross-Reference feature, and<br />
automatically updates all figure and table numbers if you insert new figures and/or tables<br />
in a document.<br />
Photographs<br />
Include photographs whenever possible and appropriate. For instance, if you are<br />
documenting an experimental study, photograph the experimental apparatus. If it is a<br />
design study, provide photographs of the finished product (if the design was fabricated).<br />
For clarity, include objects such as rulers or common objects, or people in the photograph<br />
to provide a sense of scale. Photographs of individuals require their approval. Similarly,<br />
secure permission to use photographs that are the property of someone else, or at the very<br />
least cite the source <strong>for</strong> such images.<br />
Last Updated 8/22/<strong>2013</strong><br />
Page 9
A Guide to Technical Communication<br />
COMBUSTION-FIRED<br />
AIR HEATER<br />
TEST CABIN<br />
6 FT. DIA.<br />
GASL, INC.<br />
BLOWDOWN LABORATORY<br />
Figure 1: Sample photograph using text boxes to identify important items.<br />
Items in the photograph referenced in the text can be identified using text boxes, as<br />
shown in Figure 1. Remember, the objective is clarity, so anything you can do to explain<br />
things more clearly is useful.<br />
Drawings<br />
Drawings should be computer-generated; they should not be hand drawn. Otherwise,<br />
use the same guidelines <strong>for</strong> photographs. An example of a drawing is shown in Figure 2.<br />
Graphs<br />
There are several different types of graphs: the most common used in engineering are<br />
bar, pie, scatter, surface, and contour. Each is used to handle different types of data. To<br />
understand which types of data belong in different types of graphs, we shall review the<br />
different types of data: 4<br />
Types Of Data<br />
Nominal data are differentiated using some naming system. This naming system could<br />
be anything; e.g., color, country of origin, fabrication technique, pay grade, etc. The<br />
naming system could be numerical, but the numbers would not necessarily imply levels<br />
Figure 2: Sample line drawing.<br />
Last Updated 8/22/<strong>2013</strong><br />
Page 10
A Guide to Technical Communication<br />
of importance or any other quantitative property.<br />
Ordinal Data are placed in some order based on a scale. In general, the scale does not<br />
allow <strong>for</strong> any arithmetical operations, but relative relations can be drawn from the scale.<br />
An example of ordinal data would be finishing processes <strong>for</strong> a piece of metal, e.g., sawn,<br />
filed, milled, ground. These processes can be classified, (a sawn surface will be much<br />
rougher than a ground surface), but arithmetic operations could not be per<strong>for</strong>med.<br />
Interval Data are measured along an integer scale, i.e., the classifications on the scale<br />
are equidistant. Certain mathematical operations (addition and subtraction) can be<br />
per<strong>for</strong>med on these data.<br />
Ratio Data or Scalable Data can be compared as ratios of one another. Most physical<br />
measurements fall into this category, e.g. mass, speed and time.<br />
Pie Graphs<br />
Pie graphs are most often used to compare nominal or ordinal data. The emphasis is on<br />
the contribution of each category to a whole; there<strong>for</strong>e, pie graphs are especially good to<br />
describe percentages or fractions. 5 For instance, a pie graph would be well-suited to<br />
display the contributions of different types of energy sources (wind, tidal, coal, oil,<br />
nuclear) utilized over a fixed time. A partially-exploded graph is sometimes used to focus<br />
on one of the categories. An example of a pie graph is shown in Figure 3.<br />
Bar Graphs<br />
Bar graphs, like pie graphs, are most often used to compare nominal or ordinal data,<br />
although they are occasionally used to present interval or ratio data. In the latter cases the<br />
graph is often referred to as a histogram. Bar graphs are often used to plot the frequency<br />
of a certain type of data; <strong>for</strong> instance, the number of students receiving various letter<br />
grades in a course. Bar graphs are more versatile than pie graphs in that several sets of<br />
data can be compared easily side by side, e.g., the differences in the distribution of grades<br />
5, 2%<br />
45, 22%<br />
85, 42%<br />
70, 34%<br />
Gas<br />
Coal<br />
Oil<br />
Trash<br />
Figure 3: Usage of various energy sources.<br />
Last Updated 8/22/<strong>2013</strong><br />
Page 11
A Guide to Technical Communication<br />
<strong>for</strong> same class taught in different semesters, or the distribution of material hardness from<br />
samples treated at different facilities. Bar graphs are there<strong>for</strong>e well suited <strong>for</strong> drawing<br />
comparisons. 5 A sample bar graph showing comparisons of different data is shown in<br />
Figure 4.<br />
Scatter Plots<br />
Scatter plots are created by using the abscissa (horizontal axis) to represent an<br />
independent variable, and the ordinate (vertical axis) as the dependent variable. Each<br />
datum is then assigned a location on the plot based in the values <strong>for</strong> the independent and<br />
dependent variables. This type of plot is probably the most common type found in the<br />
reports you will be writing. There are some rules you should follow to make sure these<br />
graphs present the data well.<br />
First, depending on the range and behavior of the data, you should choose the most<br />
appropriate way to present your graphs, e.g. linear or logarithmic axes. If you are not<br />
sure, try them and see which types of scales show the important features of the data best.<br />
Sometimes, if the range of data covers multiple orders of magnitudes, a logarithmic axis<br />
may be preferable. If more than one manner is acceptable, keep it as simple as possible.<br />
In other words, if you can get your point across using either a linear or a logarithmic axis,<br />
use the linear axis.<br />
Second, if you are plotting experimental data, you should plot your data as individual<br />
points. Do NOT connect your data with lines, a spline, or a curve fit; unless there is a<br />
reason to do so, e.g. a trend is to be drawn between the data. In addition, experimental<br />
data should have error bars, corresponding to experimental uncertainties. These<br />
uncertainties should be generated through accepted techniques. Ask your instructor if<br />
he/she has not shown you how to do so. On the other hand, if theoretical data are to be<br />
included on a graph <strong>for</strong> comparison, no points should be shown. Rather, connect the<br />
points with a smooth curve (NOT a curve fit) and remove the points themselves. An<br />
300<br />
Air Auto Train<br />
250<br />
People-Miles (Million))<br />
200<br />
150<br />
100<br />
50<br />
0<br />
1940's '50's '60's '70's '80's '90's<br />
Figure 4: People-miles traveled by various means of transportation from 1940’s<br />
through 1990’s.<br />
Last Updated 8/22/<strong>2013</strong><br />
Page 12
A Guide to Technical Communication<br />
Dimensionless Temperature<br />
1.0<br />
0.8<br />
0.6<br />
0.4<br />
0.2<br />
Rectangle<br />
Sphere<br />
Cylinder<br />
Theoretical Rectangle<br />
Theoretical Sphere<br />
Theoretical Cylinder<br />
0.0<br />
0 2 4 6 8 10<br />
Fourier Number<br />
Figure 5: Sample scatter plot showing multiple sets of experimental data (points)<br />
with error bars, and theoretical data (curves) utilizing different line styles.<br />
example of this can be seen in Figure 5. In this graph the dimensionless temperatures in<br />
different hot objects are plotted as a function of Fourier Number (a dimensionless <strong>for</strong>m of<br />
time). The symbols represent measured quantities, while the curves are theoretical<br />
predictions based on the equations of heat transfer relevant to the particular problem.<br />
In some cases theoretical data are developed from some experimental inputs. For<br />
example, the drag on a body is based on the projected area, which is a measured quantity.<br />
In that case, the theoretical data should consist of two curves: a lower bound and an upper<br />
bound based upon the uncertainty in the theoretical value.<br />
Third, when several sets of data are presented on the same set of axes, a legend<br />
describing each set should be included. Each set of data points should be distinguished by<br />
dissimilar symbols on the graph (e.g. squares, diamonds, and so on). If two different<br />
dependent variables are to be shown, it may make sense to show them on different<br />
vertical axes (left and right side), like Figure 6.<br />
Note that the precision of the axes is important <strong>for</strong> readability. All labels on a given<br />
axis should have the same precision (same number of decimal places), and this should be<br />
the minimum necessary to accurately represent all of the labels on that axis.<br />
Surface and Contour Plots<br />
Surface and contour plots are useful to show when a dependent variable is a function<br />
of more than one independent variable. Both plots show a single dependent variable in<br />
terms of two independent variables. The contour plot shows an X-Y plane, with the<br />
dependent variable represented by different colors on that plane. A surface plot, on the<br />
other hand, is a three-dimensional rendering, with the dependent variable represented as a<br />
Last Updated 8/22/<strong>2013</strong><br />
Page 13
A Guide to Technical Communication<br />
700<br />
600<br />
500<br />
Power<br />
Efficiency<br />
80<br />
70<br />
60<br />
Power (kW)<br />
400<br />
300<br />
50<br />
40<br />
30<br />
Efficiency (%)<br />
200<br />
20<br />
100<br />
10<br />
0<br />
0<br />
0 2 4 6 8 10<br />
Engine Speed (1000 rpm)<br />
Figure 6: Scatter plots showing two sets of experimental data on different axes.<br />
projecting in the third (Z) dimension. Examples of these plots are shown in Figure 7 and<br />
Figure 8.<br />
It should be mentioned that while a program like Excel is capable of generating these<br />
5<br />
4<br />
3<br />
y<br />
2<br />
1<br />
0 1 2 3 4 5 0<br />
x<br />
z<br />
0.8-1<br />
0.6-0.8<br />
0.4-0.6<br />
0.2-0.4<br />
0-0.2<br />
-0.2-0<br />
-0.4--0.2<br />
-0.6--0.4<br />
-0.8--0.6<br />
-1--0.8<br />
Figure 7: Sample contour plot of the function f(x, y) = sin (xy/2).<br />
Last Updated 8/22/<strong>2013</strong><br />
Page 14
A Guide to Technical Communication<br />
1.0<br />
0.8<br />
z<br />
0.6<br />
0.4<br />
0.2<br />
0.0<br />
-0.2<br />
-0.4<br />
-0.6<br />
-0.8<br />
3<br />
5<br />
4<br />
0.8-1<br />
0.6-0.8<br />
0.4-0.6<br />
0.2-0.4<br />
0-0.2<br />
-0.2-0<br />
-0.4--0.2<br />
-0.6--0.4<br />
-0.8--0.6<br />
-1--0.8<br />
-1.0<br />
0.0 0.5 1.0 1.5 1<br />
2.0 2.5 3.0 3.5 4.0 4.5 5.0 0<br />
2<br />
y<br />
Figure 8: Sample surface plot of the function from Figure 7.<br />
x<br />
types of plots, it is not ideal. Dedicated graphing packages, such as SigmaPlot and<br />
Tecplot, are much better equipped to produce quality contour and surface plots.<br />
Tables<br />
Tables should be <strong>for</strong>matted and planned as carefully as plots – using a table as a “data<br />
dump” is not advisable, unless the purpose is to document raw data in an appendix of a<br />
report. The first column of a table is most typically an independent variable, or a list of<br />
categories. The first row is typically “headings,” or a list of variables. Headings and<br />
categories are often centered (horizontally and vertically) in their respective cells.<br />
The <strong>for</strong>mat <strong>for</strong> the data in the table can be a matter of personal taste. Some prefer the<br />
data to be centered, while others prefer numbers to be right justified, and others may want<br />
Table 1: Temperature versus time data collected at the center of a brass<br />
rectangular prism submerged in a water bath.<br />
Time (s) Temperature (°C)<br />
0.00.2 301<br />
10.00.2 351<br />
20.00.2 411<br />
30.00.2 451<br />
40.00.2 471<br />
50.00.2 501<br />
60.00.2 521<br />
70.00.2 521<br />
80.00.2 521<br />
90.00.2 521<br />
Last Updated 8/22/<strong>2013</strong><br />
Page 15
A Guide to Technical Communication<br />
the data in a single column to have decimal points aligned. Check with the person who is<br />
evaluating your reports <strong>for</strong> their thoughts, but above all, clarity is key. A relatively simple<br />
table with caption is shown in Table 1.<br />
Avoid using heavy shading in tables whenever possible. While using multiple colors<br />
may look good on the screen, they might not look as nice (or be as easy to read) when<br />
printed in black and white. Reproducibility may also be an issue; if you print out a colorshaded<br />
table, and make a black and white photocopy, you might be left with a completely<br />
unreadable graph or table.<br />
Last Updated 8/22/<strong>2013</strong><br />
Page 16
A Guide to Technical Communication<br />
Guidelines <strong>for</strong> References<br />
When writing a report, article, or other technical document, often you will call upon<br />
work done by other groups, or work you have already published in another document.<br />
Whenever you are presenting work that is neither new nor original to the authors of the<br />
document, it MUST be referenced. Note the bold, italic, underlined word in all capital<br />
letters. What is the reason <strong>for</strong> the embellishment? If you present work as your own which<br />
is not yours, you have plagiarized. A new set of rules <strong>for</strong> dealing with plagiarism has just<br />
been established across the College, but regardless of the penalty imposed here,<br />
plagiarism is not tolerated in either industrial or scholarly circles. It is theft, pure and<br />
simple. Please consult the Student Handbook <strong>for</strong> the details on the policy.<br />
The rules are simple: if something you write or present is not your own idea, or your<br />
own data, or your own analysis, it must be referenced, unless it is “common knowledge.”<br />
Since the definition of what is common knowledge can be nebulous at times, it is best to<br />
play it safe and provide a reference.<br />
Whenever possible, go to the original reference. For example, if you are researching<br />
something out of a book, but the passage of interest to you was cited from a journal<br />
article, it is better to acquire the article and reference it in your work.<br />
Many different <strong>for</strong>mats exist <strong>for</strong> referencing, and no particular <strong>for</strong>mat is superior, but<br />
certain types of reference <strong>for</strong>mats are more likely to be used in technical literature. In this<br />
department we will use a particular <strong>for</strong>mat <strong>for</strong> references. There is no excuse <strong>for</strong> using an<br />
improper <strong>for</strong>mat <strong>for</strong> references; in fact, publishers will send manuscripts back to authors<br />
<strong>for</strong> improper referencing practices – it has happened. The <strong>for</strong>mat adopted is that of the<br />
American Institute <strong>for</strong> Aeronautics and Astronautics (AIAA), with some minor<br />
modifications. Their guidelines can be found online at the AIAA ScholarOne<br />
Manuscripts Portal. 6<br />
Referencing of Works in a Document<br />
When you want to reference an outside work, it will be done using a superscripted<br />
number, thusly. 1 The superscript is placed after punctuation, e.g., a period, comma,<br />
semicolon, etc. References are numbered in the order in which they are cited, i.e., the first<br />
reference cited is 1, the second is 2, and so on. If two works are referenced <strong>for</strong> the same<br />
sentence, they should be separated with a comma. 3,4 If three or more sequential works are<br />
referenced, it should be done in this manner. 5-7 An easy way to insert references in a<br />
document is to use the Insert Endnote feature in the References ribbon of Microsoft<br />
Word. You will need to make sure the references are numbers, rather than letters or<br />
symbols, and you will need to make sure the references appear in the right location of the<br />
report. A little practice will teach you how to accomplish this.<br />
If a figure or table contains outside work, the reference is placed in the figure or table<br />
caption.<br />
Formats <strong>for</strong> References<br />
Here are the <strong>for</strong>mats <strong>for</strong> the references, with examples of each:<br />
Last Updated 8/22/<strong>2013</strong><br />
Page 17
A Guide to Technical Communication<br />
Periodicals<br />
1<br />
Vatistas, G. H., Lin, S., and Kwok, C. K., “Reverse Flow Radius in Vortex<br />
Chambers,” AIAA Journal, Vol. 24, No. 11, 1986, pp. 1872, 1873.<br />
doi: 10.2514/3.13046<br />
2<br />
Dornheim, M. A., “Planetary Flight Surge Faces Budget Realities,” Aviation Week and<br />
Space Technology, Vol. 145, No. 24, 9 Dec. 1996, pp. 44–46.<br />
3<br />
Terster, W., “NASA Considers Switch to Delta 2,” Space News, Vol. 8, No. 2, 13–19<br />
Jan. 1997, pp. 1, 18.<br />
All of the preceding in<strong>for</strong>mation is required. The journal issue number (“No. 11” in<br />
Ref. 1) is preferred, but the month (Nov.) can be substituted if the issue number is not<br />
available. Use the complete date <strong>for</strong> daily and weekly publications. Transactions follow<br />
the same style as other journals. The DOI (Digital Object Identifier) should be<br />
incorporated in every reference <strong>for</strong> which it is available (see Ref. 1 sample); <strong>for</strong> more<br />
in<strong>for</strong>mation on DOIs, visit www.doi.org or www.crossref.org.<br />
<strong>Book</strong>s<br />
4<br />
Peyret, R., and Taylor, T. D., Computational Methods in Fluid Flow, 2 nd ed., Springer-<br />
Verlag, New York, 1983, Chaps. 7, 14.<br />
5<br />
Oates, G. C. (ed.), Aerothermodynamics of Gas Turbine and Rocket Propulsion,<br />
AIAA Education Series, AIAA, New York, 1984, pp. 19, 136.<br />
6<br />
Volpe, R., “Techniques <strong>for</strong> Collision Prevention, Impact Stability, and Force Control<br />
by Space Manipulators,” Teleoperation and Robotics in Space, edited by S. B. Skaar<br />
and C. F. Ruoff, Progress in Astronautics and Aeronautics, AIAA, Washington, DC,<br />
1994, pp. 175–212.<br />
Publisher, place, and date of publication are required <strong>for</strong> all books. No state or country<br />
is required <strong>for</strong> major cities: New York, London, Moscow, etc. A differentiation must<br />
always be made between Cambridge, MA, and Cambridge, England, UK. Note that series<br />
titles are in Roman type (not italicized).<br />
Proceedings<br />
7<br />
Thompson, C. M., “Spacecraft Thermal Control, Design, and Operation,” AIAA<br />
Guidance, Navigation, and Control Conference, CP849, Vol. 1, AIAA, Washington,<br />
DC, 1989, pp. 103–115<br />
8<br />
Chi, Y. (ed.), Fluid Mechanics Proceedings, NASA SP-255, 1993.<br />
9<br />
Morris, J. D., “Convective Heat Transfer in Radially Rotating Ducts,” Proceedings of<br />
the Annual Heat Transfer Conference, edited by B. Corbell, Vol. 1, Inst. of<br />
Mechanical Engineering, New York, 1992, pp. 227–234.<br />
Reports, Theses, and Individual Papers<br />
10 Chapman, G. T., and Tobak, M., “Nonlinear Problems in Flight Dynamics,” NASA<br />
TM-85940, 1984.<br />
11 Steger, J. L., Jr., Nietubicz, C. J., and Heavey, J. E., “A General Curvilinear Grid<br />
Generation Program <strong>for</strong> Projectile Configurations,” U.S. Army Ballistic Research<br />
Lab., Rept. ARBRL-MR03142, Aberdeen Proving Ground, MD, Oct. 1981.<br />
12 Tseng, K., “Nonlinear <strong>Green</strong>’s Function Method <strong>for</strong> Transonic Potential Flow,” Ph.D.<br />
Dissertation, Aeronautics and Astronautics Dept., Boston Univ., Cambridge, MA,<br />
1983.<br />
Last Updated 8/22/<strong>2013</strong><br />
Page 18
A Guide to Technical Communication<br />
Government agency reports do not require locations. For reports such as NASA TM-<br />
85940, neither insert nor delete dashes; leave them as provided. Place of publication<br />
should be given, although it is not mandatory, <strong>for</strong> military and company reports. Always<br />
include a city and state <strong>for</strong> universities. Papers need only the name of the sponsor; neither<br />
the sponsor’s location nor the conference name and location is required. Do not confuse<br />
proceedings references with conference papers.<br />
Electronic Publications and <strong>Web</strong> Pages<br />
CD-ROM publications and regularly issued, dated electronic journals are permitted as<br />
references. Archived data sets also may be referenced as long as the material is openly<br />
accessible and the repository is committed to archiving the data indefinitely. References<br />
to electronic data available only from personal <strong>Web</strong> sites or commercial, academic, or<br />
government ones where there is no commitment to archiving the data are not permitted in<br />
the reference list.<br />
13<br />
Richard, J. C., and Fralick, G. C., “Use of Drag Probe in Supersonic Flow,” AIAA<br />
Meeting Papers on Disc [CD-ROM], Vol. 1, No. 2, AIAA, Reston, VA, 1996.<br />
14<br />
Atkins, C. P., and Scantelbury, J. D., “The Activity Coefficient of Sodium Chloride<br />
in a Simulated Pore Solution Environment,” Journal of Corrosion Science and<br />
Engineering [online journal], Vol. 1, No. 1, Paper 2, URL:<br />
http://www.cp/umist.ac.uk/JCSE/vol1/vol1.html [cited 13 April 1998].<br />
15<br />
Vickers, A., “10-110 mm/hr Hypodermic Gravity Design A,” Rainfall Simulation<br />
Database [online database], URL: http://www.geog.le.ac.uk/bgrg/lab.htm [cited 15<br />
March 1998].<br />
Always include the citation date <strong>for</strong> online references. Break <strong>Web</strong> site addresses after<br />
punctuation, and do not hyphenate at line breaks.<br />
NEVER CITE WIKIPEDIA FOR ANYTHING. EVER. FOR ANYTHING AT ALL.<br />
Wikipedia, like old book-<strong>for</strong>m encyclopedias, are a starting point <strong>for</strong> research. Look into<br />
the references cited in the articles in Wikipedia, then cite them yourself.<br />
Computer Software<br />
16<br />
TAPP, Thermochemical and Physical Properties, Software Package, Ver. 1.0, E. S.<br />
Microware, Hamilton, OH, 1992.<br />
Include a version number and the company name and location of software packages.<br />
Patents<br />
Patents appear infrequently. Be sure to include the patent number and date.<br />
17<br />
Scherrer, R., Overholster, D., and Watson, K., Lockheed Corp., Burbank, CA, U.S.<br />
Patent Application <strong>for</strong> a “Vehicle,” Docket No. P-01-1532, filed 11 Feb. 1979.<br />
18<br />
Girlea, F. and Leylegian, J. C., “Apparatus, Systems, Methods <strong>for</strong> the Production of<br />
Hydrogen,” U. S. Patent 8,263,027, filed 12 Aug. 2009, granted 11 Sep. 2012.<br />
Private Communications<br />
If you receive in<strong>for</strong>mation directly from a person, which cannot be referenced in an<br />
article, book, or paper, it is a private communication, whether it is in-person, over the<br />
telephone, or via email.<br />
19<br />
Pritchard, P. J., Private communication, 12 November 2012.<br />
Last Updated 8/22/<strong>2013</strong><br />
Page 19
A Guide to Technical Communication<br />
Provide the name of the source and the date(s) over which the communication<br />
occurred.<br />
Unpublished Papers and <strong>Book</strong>s<br />
Unpublished works can be used as references as long as they are being considered <strong>for</strong><br />
publication or can be located by the reader (such as papers that are part of an archival<br />
collection). If a journal paper or a book is being considered <strong>for</strong> publication, choose the<br />
<strong>for</strong>mat that reflects the status of the work (depending upon whether it has been accepted<br />
<strong>for</strong> publication):<br />
20<br />
Doe, J., “Title of Paper,” Name of Journal (to be published).<br />
21<br />
Doe, J., “Title of Chapter,” Name of <strong>Book</strong>, edited by…, Publisher’s name and<br />
location (to be published).<br />
22<br />
Doe, J., “Title of Work,” Name of Archive, Univ. (or organization), City, State, Year<br />
(unpublished).<br />
Unpublished works in an archive must include the name of the archive and the name<br />
and location of the university or other organization where the archive is held. Also<br />
include any cataloging in<strong>for</strong>mation that may be provided.<br />
Last Updated 8/22/<strong>2013</strong><br />
Page 20
A Guide to Technical Communication<br />
Laboratory and Technical Reports<br />
Now that we have described how a report should flow, and have discussed effective<br />
means of communication through graphics, we will get into the actual organization of<br />
technical documents. There are two main types of technical documents covered in this<br />
manual. The first are laboratory reports and technical reports. These reports document<br />
experimental or analytical studies. The sections of these reports are outlined here, with<br />
the similarities, as well as the differences pointed out.<br />
Remember, as stated in the Introduction, if an instructor provides alternate guidelines<br />
on the <strong>for</strong>mat of a report, those alternate guidelines supersede the <strong>for</strong>mat here.<br />
Cover Page<br />
All reports must have a cover page that contains:<br />
Course and section number.<br />
Group number (if the work is being per<strong>for</strong>med by a group).<br />
Name(s) of the student(s) in the group.<br />
Title.<br />
Instructor’s name.<br />
Date experiment per<strong>for</strong>med (if this is a laboratory report).<br />
Date report handed in.<br />
A sample cover page is shown in Appendix A: Format <strong>for</strong> Cover Sheets, and an<br />
electronic version in Word <strong>for</strong>mat is available <strong>for</strong> your use.<br />
A few words about titles: when someone is reviewing a list of reports or articles <strong>for</strong><br />
documents which need to be read, he or she will start with a list of titles. Make your title<br />
as descriptive as possible, in order to make sure that the widest audience possible reads<br />
your report. For instance, “Aerodynamic Characteristics of Two Waverider-Derived<br />
Hypersonic Cruise Configurations” is a far superior title to “Aerodynamics of High<br />
Speed Aircraft.”<br />
Abstract<br />
Give a brief (only about one paragraph), clear indication of what is in the report along<br />
with the primary results or final design characteristics. It should state, in simple<br />
declarative sentences what was attempted and accomplished, how it was accomplished<br />
only if special techniques were utilized, and what was achieved. That is, it should contain<br />
the main results and the main conclusions based on the results. Since the abstract is a<br />
summary of the entire report, you should write your abstract after you have completed all<br />
other parts of the report.<br />
The abstract should be written with the expectation that it will be printed separately<br />
from the report. In fact, technical journals often publish lists of abstracts so that readers<br />
can quickly determine what articles are of interest to them. There<strong>for</strong>e, there should be no<br />
references to figures or tables in the report, works cited, etc. The abstract should be able<br />
to stand alone as a clear succinct summary of the work per<strong>for</strong>med, and should allow a<br />
reader to decide if the work is of sufficient interest to warrant reading the full report.<br />
Here is an example of a well-written abstract, from the NASA Technical Paper<br />
Last Updated 8/22/<strong>2013</strong><br />
Page 21
A Guide to Technical Communication<br />
“Aerodynamic Characteristics of Two Waverider-Derived Hypersonic Cruise<br />
Configurations:” 7<br />
An evaluation was made of the effects of integrating the required aircraft<br />
components with hypersonic high-lift configurations known as waveriders to<br />
create hypersonic cruise vehicles. Previous studies suggest that waveriders offer<br />
advantages in aerodynamic per<strong>for</strong>mance and propulsion airframe integration<br />
(PAI) characteristics over conventional non-waverider hypersonic shapes. A<br />
wind-tunnel model was developed that integrates vehicle components, including<br />
canopies, engine components, and control surfaces, with two pure waverider<br />
shapes, both conical-flow-derived waveriders <strong>for</strong> a design Mach number of 4.0.<br />
Experimental data and limited computational fluid dynamics (CFD) solutions<br />
were obtained over a Mach number range of 1.6 to 4.63. The experimental data<br />
show the component build-up effects and the aerodynamic characteristics of the<br />
fully integrated configurations, including control surface effectiveness. The<br />
aerodynamic per<strong>for</strong>mance of the fully integrated configurations is not comparable<br />
to that of the pure waverider shapes, but is comparable to previously tested<br />
hypersonic vehicle models. Both configurations exhibit good lateral directional<br />
stability characteristics.<br />
Note the fact that not only does the abstract provide a description of what was done, it<br />
also give the reader some specifics on the range of parameters investigated and the results<br />
obtained.<br />
Table of Contents<br />
This is a list containing the section titles and the page numbers on which the sections<br />
begin. Microsoft Word has a built-in Table of Contents function, which will automatically<br />
generate and update your Table of Contents as you assemble your report. Ask your<br />
instructor about this if you do not know how to use this feature.<br />
Introduction and Analysis<br />
These two sections are sometimes written as one; if the in<strong>for</strong>mation is in a single<br />
section, it is referred to simply as the “Introduction.” The Introduction is used to provide<br />
an overview of the problem, and the context within which the problem exists. It also<br />
gives the reader a background to the problem constraints, and required outcomes. It<br />
should familiarize and orient your readers. 5<br />
Introduction<br />
It is important to realize that the title of this section is totally descriptive of its role. It<br />
is to introduce the reader to the report in the same way that you would “introduce a friend<br />
to a third party.” The first element of in<strong>for</strong>mation is the context of the work, which<br />
should be done in a way that is important to the reader. What are the origins of your<br />
interest in the work, and what is the motivation (purpose) <strong>for</strong> the investigation that has<br />
been executed? Be fair – don’t overstate or understate the importance of the work being<br />
done. 5 Given the motivation, the background in<strong>for</strong>mation can next be developed <strong>for</strong> the<br />
reader. It is in this portion of the report that you will introduce material from texts,<br />
handbooks, journal articles, the laboratory handouts, and other available references. You<br />
Last Updated 8/22/<strong>2013</strong><br />
Page 22
A Guide to Technical Communication<br />
should not copy substantial sections of previously printed material (e.g. equations); these<br />
should be summarized with a reference.<br />
Following the motivation and background, the material to be found in the subsequent<br />
sections should be summarized. This will complete the introduction; the reader’s mind<br />
will be prepared <strong>for</strong> what is to follow. The Introduction can (and often should) have<br />
equations in it if they <strong>for</strong>m part of the “background.” However, be careful not to include<br />
unnecessary background material, or to be repetitive.<br />
Note that if this is well done, then all subsequent statements can be fit into a rational<br />
understanding by the reader; if it is not well done, then the reader will expend creative<br />
energies trying to infer what is going on. Reading a report with a poor introduction is a<br />
frustrating experience.<br />
Analysis<br />
The Analysis will introduce the remaining basic equations (i.e., those not yet presented<br />
in the Introduction) and (more importantly) manipulate these into the <strong>for</strong>m required to<br />
interpret and process the experimental data. In some cases, the Analysis Section will<br />
present the equivalent of a “result of the investigation” in that the analytical results will<br />
be separately significant in-and-of themselves. The questions of: “what to include and<br />
what to refer to from previously written materials,” sometimes lead to confusion. In<br />
general, one can answer this question by observing that the analysis must be conceptually<br />
complete…the major steps must be shown…but that lengthy and detailed considerations<br />
are best covered by a reference to their original source. Note that at the conclusion of the<br />
Analysis Section, the reader will be aware of what basic data are required, and what will<br />
be calculated from these data.<br />
Note that “data” is a plural noun; one measurement is a “datum.” Note also that the<br />
symbols must be clearly defined - it is usually appropriate to make use of defining figures<br />
– line drawings are usually the most appropriate in this instance (think of your<br />
textbooks!). All of the symbols to be used should appear in a Nomenclature list (see<br />
below), or described in the text if no Nomenclature list is included.<br />
As a general observation, the Introduction and the Analysis sections should be written<br />
from the perspective that they could have been written be<strong>for</strong>e the experiment was<br />
executed. That is, they will include everything that could have been thought of be<strong>for</strong>e the<br />
work was per<strong>for</strong>med, even if some of it was not realized until the experiment was<br />
finished.<br />
The reader now has the in<strong>for</strong>mation of why the experiment was per<strong>for</strong>med and what<br />
data were desired. The reader is now ready to appreciate how the experiment was<br />
configured to provide the data and what procedures were followed to assure the<br />
correctness of the data.<br />
Experimental Apparatus and Procedure<br />
Sometimes this section is not necessary, particularly when the report is not<br />
documenting an experimental study. In that case, a separate Analysis section (see above)<br />
describes how you did what you did.<br />
Last Updated 8/22/<strong>2013</strong><br />
Page 23
A Guide to Technical Communication<br />
If you per<strong>for</strong>med an experiment, this section should provide a schematic<br />
representation of the experimental equipment, including detailed views of unusual or<br />
important components. This in<strong>for</strong>mation is usually a valuable aid in in<strong>for</strong>ming the reader<br />
about the experiment. The sketch can be used to document pertinent dimensions of the<br />
apparatus and it can be used to specify the experimental equipment used <strong>for</strong> the study. If<br />
the procedure used in the experiment is not an established one, it is necessary to include<br />
details of the techniques used. However, it should not be a simple protocol (a set of<br />
instructions). A method section should contain context (“In order to… we…”), and does<br />
not necessarily be in chronological order, but rather should be in the most logical order<br />
<strong>for</strong> the reader to follow. 5 The criterion here is that someone familiar with the general area<br />
of investigation should be able to reproduce your experiments from the in<strong>for</strong>mation given<br />
in this section.<br />
A common question is whether or not to include equations in the Experimental<br />
sections, rather than the Intro/Analysis sections. A good rule of thumb is if the equations<br />
are theoretical in nature, they belong in the Introduction. If they relate to reduction of the<br />
experimental data based on something specific to your experimental setup, they are more<br />
appropriate in the Experimental section.<br />
Results and Discussion<br />
The next section can be a “Results” or a “Results and Discussion” section; if the<br />
<strong>for</strong>mer, a separate “Discussion” section would follow. The basis of selection between two<br />
options is the volume of the results to be presented-and/or-the complexity of trans<strong>for</strong>ming<br />
the primitive results into the final <strong>for</strong>m. Experience is useful in making this decision and<br />
the stylistic tastes of the writer are important in the selection as well. If one-versus-two<br />
sections are used, then the comments below should be interpreted as applying to the<br />
combined section.<br />
Results<br />
This section is the location of all results of the experiment. The results should be<br />
introduced with appropriate prose; do not simply list a set of results such as P 1 = 3.5 in.<br />
of water, T 2 = 50° F, etc. For example: “Figure 3 presents the transient temperature<br />
distributions at different locations along the aluminum rod” or “Table 2 provides …” It is<br />
important to differentiate between primitive and processed results; that is, the reader<br />
should be aware of what was directly observed and what is inferred by calculations based<br />
upon equations in the Analysis section. It is essential that ALL presented figures or tables<br />
be referred to in the text, and have numbered, descriptive captions. The numbers must<br />
follow the sequence in which they are introduced to the reader.<br />
The results section should focus on presenting the data which answer the questions<br />
asked in the Introduction of the report. Irrelevant results (e.g. raw data) should not be<br />
presented here; rather, show them in an Appendix (see below). 5<br />
It is always appropriate to provide the reader with uncertainties. Their inclusion<br />
expands the in<strong>for</strong>mation content beyond that provided by the base numbers themselves.<br />
At this point in the report, the reader has access to all of the essential and objective<br />
in<strong>for</strong>mation that was available to the writer. Beyond this point, the writer has the<br />
opportunity to in<strong>for</strong>m the reader of the fruits of her/his creative ef<strong>for</strong>ts.<br />
Last Updated 8/22/<strong>2013</strong><br />
Page 24
A Guide to Technical Communication<br />
Discussion<br />
The major task of this section is to interpret the results, to note what is “as expected”,<br />
what is unexpected, and what is of technical interest. The interpretation of the results in<br />
terms of the motivation <strong>for</strong> the experiment should obviously be focused upon. The<br />
discussion could contain a comparison with other similar investigations as established in<br />
the background or an explanation of discrepancies between theoretical and experimental<br />
values. The strong points of the work should be brought out here along with any<br />
limitations. If the writer does not point out the limitations of his/her work, someone else<br />
surely will later. It may also be appropriate to comment on possible future investigations<br />
or improving the experiment. When discussing the experimental results, do not use vague<br />
references to the accuracy of the measurements; note the estimated uncertainties and their<br />
effects on the calculated values. As mentioned above, all graphs and tables should be<br />
discussed and referred to by their corresponding figure and table numbers.<br />
An immensely frustrating aspect of critiquing student reports is to read a passage like:<br />
“It is not possible to <strong>for</strong>m any conclusions from the study since the results are<br />
inaccurate.” On the contrary, it would be pleasant to read a quantitative interpretation of<br />
how the estimated uncertainly influences the extraction of the desired in<strong>for</strong>mation from<br />
the available measurements.<br />
Conclusions<br />
In this section, present the appropriate conclusions which can be drawn from your<br />
work; relate your findings to the original objectives; point out special features of your<br />
work; mention limitations and discrepancies; and demonstrate how closely you have<br />
achieved the objectives. A useful style is to start with a reiteration of the objective of the<br />
study. Following this introductory sentence, the major conclusions can be presented in<br />
the <strong>for</strong>m of simple declarative sentences. The conclusions will follow from the items<br />
developed in (an implied by) the material in the previous sections.<br />
No new in<strong>for</strong>mation (results or interpretation thereof) should appear in this section,<br />
with the exception with recommendations <strong>for</strong> related future projects. It should serve<br />
primarily as a summary of the major points of the work.<br />
References<br />
In general a list of references used should be included in any report. Great care should<br />
be taken to follow the specified <strong>for</strong>mat of the organization <strong>for</strong> which the report is being<br />
written (<strong>for</strong> example a research center may have different guidelines than a <strong>for</strong>-profit<br />
business). In this project, all references used during the preparation of the report, or<br />
during the design process, should be listed in the <strong>for</strong>mat given in the section Guidelines<br />
<strong>for</strong> References.<br />
Microsoft Word has a built-in Endnote function, which will automatically number and<br />
re-number references. Ask your instructor about this if you do not know how to use this<br />
feature.<br />
Appendices<br />
Sample or lengthy calculations, or side issues that are peripheral to the main theme of<br />
the report should be placed in an appendix. This could include computer calculations,<br />
Last Updated 8/22/<strong>2013</strong><br />
Page 25
A Guide to Technical Communication<br />
sample calculations, extra graphs, extra tables, or extra figures. Appendices should be<br />
referred to in the text and should there<strong>for</strong>e be labeled and have a title (e.g. Appendix A:<br />
Motor Per<strong>for</strong>mance).<br />
A criterion <strong>for</strong> deciding whether or not to put something in an appendix is to ask the<br />
question “Does its inclusion in the main body of the report detract from the smooth flow<br />
of the presentation?” If the answer is affirmative, and if the material contributes to the<br />
in<strong>for</strong>mation content of the report, then it should be presented as a separate unit. Each<br />
appendix should be lettered; Appendix A, Appendix B, etc. Each appendix should be<br />
cited in the body of the report (if you don’t mention it, how does the reader know it’s<br />
there?), and the appendices should be ordered based on the order of their citation<br />
(Appendix A must be the first appendix cited in the report).<br />
Some of the most common items to be found in an Appendix are:<br />
Data Sheets<br />
The original data sheet must be submitted. This may be copied or reproduced <strong>for</strong><br />
clarity, in which case the original should still be submitted.<br />
Sample Calculations<br />
This section should include examples of each type of calculation per<strong>for</strong>med in the<br />
experiment. Typically, the first and last set of data in a run should be used <strong>for</strong> sample<br />
calculations. Each calculation should be identified by describing the part of the<br />
experiment that it is from (or the appropriate run number), what is being calculated, and<br />
the specific data that is being analyzed. If a number of calculations are to be per<strong>for</strong>med<br />
on the same data the run analyzed should remain the same. All units must be included,<br />
and numerical values should have an appropriate number of significant figures. The<br />
calculations should also be presented in an understandable manner so that the logical<br />
connection between adjacent calculations can be seen.<br />
Uncertainty Analysis<br />
It is always appropriate to provide the reader with uncertainty estimates of the results.<br />
The experimentalist is, of course, in the best position to per<strong>for</strong>m such estimates. Per<strong>for</strong>m<br />
this procedure on the sample calculations.<br />
Optional Sections<br />
Some types of reports may need additional sections. Examples of these sections are<br />
given here.<br />
Nomenclature Listing<br />
The Nomenclature listing, if included, is normally right be<strong>for</strong>e the Introduction. As the<br />
name suggests, it lists and define all symbols used in the report. Note that the symbols in<br />
the nomenclature should be arranged in alphabetical order and that Greek symbols (also<br />
in alphabetical order) should follow after the Latin symbols. Common subscripts and<br />
superscripts should be listed separately. Where possible, refer to an equation which<br />
defines the symbol. Also proofread your report to ensure that all symbols are defined.<br />
Last Updated 8/22/<strong>2013</strong><br />
Page 26
A Guide to Technical Communication<br />
Acknowledgments<br />
Be sure to thank the people who helped you in a meaningful way, <strong>for</strong> example the<br />
members of the technical services staff of <strong>Manhattan</strong> College, fellow students,<br />
instructors, outside experts, and any benefactors (sources of material or funding). When<br />
mentioning the name of someone you are thanking, also give his or her affiliation.<br />
Acknowledgments are usually placed after the Conclusions. An example of an<br />
Acknowledgments section is provided below:<br />
This work was supported by the National Science Foundation and the Air<br />
Force Office of Scientific Research. We would like to thank Professor Hai Wang<br />
of the University of Southern Cali<strong>for</strong>nia and Professor J. W. Bozzelli of the New<br />
Jersey Institute of Technology <strong>for</strong> their helpful discussions.<br />
Last Updated 8/22/<strong>2013</strong><br />
Page 27
A Guide to Technical Communication<br />
Format <strong>for</strong> Short Laboratory Reports<br />
Occasionally, a professor will ask <strong>for</strong> a “short <strong>for</strong>mat” laboratory report. The idea <strong>for</strong><br />
such a report is a documentation of the study, with primary focus on the collection and<br />
interpretation of the data, without significant underlying theory.<br />
As the name suggests, this type of report is to be short, but prepared according to good<br />
engineering practices. A short <strong>for</strong>m report would contain the following sections:<br />
Abstract<br />
Data Sheets<br />
Sample Calculations<br />
Uncertainty Analysis<br />
Results<br />
Discussion of Results<br />
Conclusions<br />
References<br />
Appendices<br />
Last Updated 8/22/<strong>2013</strong><br />
Page 28
A Guide to Technical Communication<br />
Design Project Reports - General Instructions<br />
Now we will discuss the second major type of technical documents, related to design<br />
projects. There are three types of design project reports – Proposals, Progress Reports and<br />
Final Reports. The next three sections of this manual will discuss the <strong>for</strong>mat of each in<br />
turn.<br />
Remember, as stated in the Introduction, if an instructor provides alternate guidelines<br />
on the <strong>for</strong>mat of a report, those alternate guidelines supersede the <strong>for</strong>mat here.<br />
Last Updated 8/22/<strong>2013</strong><br />
Page 29
A Guide to Technical Communication<br />
Format <strong>for</strong> Design Project Proposals<br />
The first document to be written <strong>for</strong> a design project is the proposal, which outlines<br />
what you set out to do in your project, and how long it will take. All proposals shall<br />
contain the following sections with proper headings as indicated:<br />
Cover Page<br />
A sample cover page is given in Appendix A: Format <strong>for</strong> Cover Sheets, and an<br />
electronic version in Word <strong>for</strong>mat is available <strong>for</strong> your use.<br />
Table of Contents<br />
This is a list containing the section titles and the page numbers on which the sections<br />
begin.<br />
Introduction<br />
The Introduction is a brief discussion that introduces the reader to the project and<br />
prepares the reader to understand the project as described more fully in the MAIN<br />
BODY. It could have background in<strong>for</strong>mation that describes why the project is<br />
undertaken and other in<strong>for</strong>mation that establishes the importance of the project in the<br />
context of the course. It should have no equations and refer to no figures.<br />
Proposal<br />
The Proposal is the principal narrative section. It should contain the project goals, the<br />
accomplishments and remaining tasks. Figures presented are discussed in this section.<br />
Expenses, if any, are reported in this section.<br />
Schedule<br />
The Schedule refers to a Gantt chart presented as a figure that plans the project from<br />
proposal to completion with specific dates. Discuss the principal features of the Gantt<br />
chart in this section.<br />
Last Updated 8/22/<strong>2013</strong><br />
Page 30
A Guide to Technical Communication<br />
Format <strong>for</strong> Design Project Progress Reports<br />
Prepare this report <strong>for</strong> the reader who has not seen your proposal and is otherwise not<br />
familiar with your project. All progress reports shall contain the following sections with<br />
proper headings as indicated:<br />
Cover Page<br />
A sample cover page is given in Appendix A: Format <strong>for</strong> Cover Sheets, and an<br />
electronic version in Word <strong>for</strong>mat is available <strong>for</strong> your use.<br />
Table of Contents<br />
The Table of Contents lists the sections with page numbers on which the section<br />
begins.<br />
Introduction<br />
The Introduction repeats and corrects, if necessary, the in<strong>for</strong>mation in your proposal<br />
introduction and otherwise summarizes developments through the proposal stage. The<br />
final sentence(s) of this section introduces the reader to the discussion of the PROGRESS<br />
TO DATE, i.e., the next section. No figures are to be presented in this section.<br />
Progress to Date<br />
The Progress to Date discusses in detail the progress you have made since submitting<br />
the proposal. Explain the present state of your design with drawings and photographs as<br />
appropriate. Discuss your calculations if included. Remember to refer to all figures in this<br />
narrative and number the figures in the order in which you refer to them. Report expenses<br />
to date and indicate any updates to your budget.<br />
Schedule<br />
The Schedule reviews your schedule of work presented in your proposal. Indicate<br />
whether you are progressing rapidly enough at this stage. Indicate any changes in your<br />
schedule as a reflection of your experience to date. Update your Gantt chart if necessary<br />
and discuss the updates in this section.<br />
Calculations (If necessary)<br />
The Calculations section presents all calculations in an orderly fashion. Identify the<br />
nature of each calculation and discuss the calculation in your PROGRESS TO DATE<br />
section. All units must be included, and numerical values should have an appropriate<br />
number of significant figures.<br />
Last Updated 8/22/<strong>2013</strong><br />
Page 31
A Guide to Technical Communication<br />
Format <strong>for</strong> Design Project Final Reports<br />
Prepare this report <strong>for</strong> the reader who has not seen your proposal and progress report<br />
and is otherwise not familiar with your project. All final reports shall contain the<br />
following sections with proper headings as indicated:<br />
Cover Page<br />
A sample cover page is given in Appendix A: Format <strong>for</strong> Cover Sheets, and an<br />
electronic version in Word <strong>for</strong>mat is available <strong>for</strong> your use.<br />
Table of Contents<br />
Present as in previous reports.<br />
Executive Summary<br />
In two pages or less, state what you accomplished in narrative <strong>for</strong>m, i.e. no equations<br />
and no figures. State the name and address of any cooperating facility. Briefly state the<br />
accomplishments of both your project. This section serves one type of important reader,<br />
perhaps the chief executive of a company, who only wants to know what you<br />
accomplished and its significance. He or she may read only this section of your report<br />
and scan the section with figures. You want to be sure that person receives the message.<br />
[Your Project Title]<br />
This is the main body of the report. Briefly discuss the background to supplement the<br />
executive summary, any design constraints and success metrics <strong>for</strong> this particular<br />
problem, and then present your final design in detail with drawings and photographs<br />
presented as figures. Be sure to refer to all figures in the order you place them. Present a<br />
Bill of Materials which includes sources of supplies. Give a selling price <strong>for</strong> the product.<br />
For guidelines, double the cost of materials if it is a production item, more if it is custommade.<br />
In addition, the item in most cases should be better, cost less, or be both, than<br />
competitive products.<br />
Reflections<br />
Discuss whether you accomplished your goals, where you fell short, and how you<br />
might modify the design if you were to start again knowing what you now know.<br />
Describe problems you encountered. Describe obstacles you overcame.<br />
Calculations<br />
This section presents all calculations in an orderly fashion. Identify the nature of each<br />
calculation and discuss the calculation in your main body of the report. All units must be<br />
included, and numerical values should have an appropriate number of significant figures<br />
Acknowledgments<br />
Be sure to thank the people who helped you in a meaningful way, <strong>for</strong> example the<br />
members of the technical services staff of <strong>Manhattan</strong> College, fellow students,<br />
instructors, outside experts, and any benefactors (sources of material or funding). When<br />
mentioning the name of someone you are thanking, also give his or her affiliation.<br />
Last Updated 8/22/<strong>2013</strong><br />
Page 32
A Guide to Technical Communication<br />
References<br />
In general a list of references used should be included in any report. Great care should<br />
be taken to follow the specified <strong>for</strong>mat of the organization <strong>for</strong> which the report is being<br />
written (<strong>for</strong> example a research center may have different guidelines than a <strong>for</strong>-profit<br />
business). In this project, all references used during the preparation of the report, or<br />
during the design process, should be listed in the <strong>for</strong>mat given in the section Guidelines<br />
<strong>for</strong> References.<br />
Microsoft Word has a built-in Endnote function, which will automatically number and<br />
re-number references. Ask your instructor about this if you do not know how to use this<br />
feature.<br />
Appendices<br />
Sample or lengthy calculations, or side issues that are peripheral to the main theme of<br />
the report should be placed in an appendix. This could include computer calculations,<br />
sample calculations, extra graphs, extra tables, or extra figures. Appendices should be<br />
referred to in the text and should there<strong>for</strong>e be labeled and have a title (e.g. Appendix A:<br />
Motor Per<strong>for</strong>mance).<br />
Sample or lengthy calculations, error analyses, lengthy derivations, or side issues that<br />
are not really in the main theme of the report should be placed in an Appendix. A<br />
criterion <strong>for</strong> deciding whether or not to put something in an appendix is to ask the<br />
question “Does its inclusion in the main body of the report detract from the smooth flow<br />
of the presentation?” If the answer is affirmative, and if the material contributes to the<br />
in<strong>for</strong>mation content of the report, then it should be presented as a separate unit. Each<br />
appendix should be lettered; Appendix A, Appendix B, etc. Each appendix should be<br />
cited in the body of the report (if you don’t mention it, how does the reader know it’s<br />
there?), and the appendices should be ordered based on the order of their citation<br />
(Appendix A must be the first appendix cited in the report).<br />
Last Updated 8/22/<strong>2013</strong><br />
Page 33
A Guide to Technical Communication<br />
General Guidelines <strong>for</strong> Oral Presentations<br />
Communication is key to being a successful engineer – unless you can write reports<br />
and give presentations to share your findings with colleagues, managers, and others, your<br />
findings may end up being ignored. However, you must know your audience and be able<br />
to keep their attention. One key to keeping a group’s attention is to tell a coherent story.<br />
A second key is brevity. Keep your talk short, simple, and to the point. Nothing makes<br />
<strong>for</strong> an uncom<strong>for</strong>table presentation like a long-winded, meandering story. Certain things<br />
can be done to maintain brevity and a coherent story.<br />
Initial Considerations<br />
When planning an oral presentation the presenter must have a clear idea of what has to<br />
be presented. To achieve this, a summary of key topics should be identified. Also, the<br />
presentation should be designed to suit the background and expectations of the audience.<br />
Finally, the presentation should be designed to fit into the allotted time <strong>for</strong> the<br />
presentation. At technical conferences presentations typically last 20 – 30 minutes,<br />
however, a status report presentation might some can be as short as 10 minutes while a<br />
thesis presentation or an invited talk may be as long as 45 minutes. All of these aspects<br />
associated with the creation of the presentation are time consuming there<strong>for</strong>e the<br />
presenter should not underestimate the time that it takes to put together a good<br />
presentation. A general rule of thumb is that you should spend, in average, about oneand-a-half<br />
minutes per slide. Rushing through slides is not a good practice. You should<br />
give enough time <strong>for</strong> audience to absorb the material that you want to convey.<br />
Preparation Guidelines<br />
As mentioned above, you should use no more than two slides per three minutes of<br />
presentation time. That would mean that <strong>for</strong> a 20-minute presentation, you should have<br />
no more than 14 slides, and <strong>for</strong> a half hour presentation, you should have a maximum of<br />
20 slides. This slide count includes the title slide. Don’t look at any of the slides and<br />
think “I can get through this slide in only a few seconds.” If you can do that, there must<br />
not be much in<strong>for</strong>mation on the slide and you can merge it with the slide be<strong>for</strong>e or the<br />
slide after. Remember that the first thing the audience is going to do when a new slide is<br />
put up is look at the slide – they will not be listening to you. If you only keep the slide up<br />
“<strong>for</strong> a few seconds,” they will barely get a chance to look at the slide, and they will not<br />
have heard anything you have said.<br />
Prior to the actual talk the presentation should be practiced to gauge its length, and to<br />
ensure smooth transitions between speakers if multiple speakers are involved. In fact, it<br />
may do you well to script your presentation. This does not mean that you should know<br />
your presentation word <strong>for</strong> word; it does mean that you know exactly what points need to<br />
be conveyed, and (more importantly) in what order. Know what you are going to say is<br />
the best way to avoid (or at least minimize) the “aahs” and “umms” that are peppered in<br />
many presentations. 8 Also, prepare <strong>for</strong> anticipated questions, and in a group environment<br />
ensure that team members do not interrupt or contradict each other when responding to<br />
questions.<br />
Last Updated 8/22/<strong>2013</strong><br />
Page 34
A Guide to Technical Communication<br />
Slide Design and Creation<br />
When creating the slides <strong>for</strong> the presentation, choose a slide design that is bright,<br />
simple, and easy to print out. This prevents the audience from being distracted by the<br />
graphics, and allows anyone to obtain copies of the slides. Also, ensure that the slides are<br />
not too crowded, and use large visual elements to allow the slide in<strong>for</strong>mation to be read<br />
by audience members distant from the screen. There should be minimal text content and<br />
what exists should be in the <strong>for</strong>m of bulleted items (use the oral part of the presentation to<br />
convey most of the word content). In general, if large amounts of in<strong>for</strong>mation, such as<br />
graphs, tables, etc., have to be conveyed use multiple slides. Keep in mind if you make a<br />
slide too crowded with lots of text the audience will start reading the slides, and not pay<br />
attention to your talk. Finally, if presentation software is being used, make sure that<br />
backup overhead projector slides exist in case there is a problem with the projection<br />
system.<br />
Examples of slides <strong>for</strong> different types of presentations can be seen in Appendix B:<br />
Sample Presentations.<br />
To Outline or Not to Outline? That is the Question<br />
The outline slide is a source of contention among people who regularly give<br />
presentations, because people either love them or hate them. You professor will most<br />
likely have an opinion, and it is not the purpose of this manual to offer an opinion.<br />
However, the arguments <strong>for</strong> and against will be provided <strong>for</strong> the benefit of the student.<br />
Be<strong>for</strong>e we get into the pros and cons, just remember that the outline of the<br />
presentation should mimic the outline of a written report. For instance, if you are<br />
presenting the material which would go into a laboratory report, your presentation should<br />
have the following order:<br />
• Introduction<br />
• Analysis<br />
• Experimental Apparatus and Methodology<br />
• Results<br />
• Discussion<br />
• Conclusions<br />
Do not prepare a slide with references. References should go at the bottom of the slides<br />
where the in<strong>for</strong>mation is presented. There’s a good reason <strong>for</strong> this. When you read a<br />
paper, having all of the references at the end of the paper gives you an efficient,<br />
organized way of accessing sources cited in the work. You can flip back and <strong>for</strong>th as you<br />
read the paper and check the references as you go. You do not have this luxury in a<br />
presentation, and so to understand which material is from various outside sources, the<br />
references must be on the individual slides.<br />
The reasons why the sections of the presentation should follow the sections of the<br />
report is simple. The sections of a report are set up to provide a compelling story that is<br />
easy to follow. Why should a presentation be any different? A good presentation should<br />
Last Updated 8/22/<strong>2013</strong><br />
Page 35
A Guide to Technical Communication<br />
have both an easy-to-follow story, and a focus. Without these points, you’ll lose your<br />
audience. 8<br />
Okay, on to the outline versus no outline debate…<br />
Outlines are good to generate, because they are indispensable <strong>for</strong> organization<br />
purposes. The Outline Slide presents the audience with the path that your presentation<br />
will follow. The slide provides the first step in a three pronged approach of giving a<br />
presentation, “say what you are going to say, say it and say what you’ve said.” This<br />
approach rein<strong>for</strong>ces the main points of the presentation to your audience.<br />
However, since you are aiming <strong>for</strong> brevity, an outline slide can disrupt the flow of the<br />
story. By all means, you should have an outline worked out when you develop your<br />
presentation, but do you want to waste a slide telling the audience about the story you’re<br />
about to tell? Just get to the story. Instead of an outline slide, your first slide after the title<br />
slide can outline the problem, i.e., this slide can in<strong>for</strong>m the audience of the objective of<br />
the study. If you explain what you’ve set out to do, there will be no question why you’ve<br />
done anything that you show on subsequent slides.<br />
So what should you do? For now, you should include one if your professor says so, or<br />
not if he/she is against them. However, you should decide what works better <strong>for</strong> you once<br />
you start presenting in the “real world.”<br />
Use of Graphics<br />
Use pictures (schematics, graphs, etc.) as the “anchors” of your slides. Keep the words<br />
on the slides to a minimum; it will prevent you from reading directly from the slides, and<br />
keeps the slides from being cluttered. Equations can be good, but do not go through<br />
derivations in a presentation. Show the basic equations, followed by the final equations<br />
used in the reduction of the data. Skip the intermediate steps, but you can mention in a<br />
general sense how you get from the start to the finish.<br />
Make sure that any text on the slides is large enough to be seen (this includes<br />
equations). Here’s a good rule of thumb: Print the slides out, place them on the floor, and<br />
stand over them. If you can read the printouts from that height (5-6 feet), the audience<br />
should have no problem reading the slides when projected on a screen.<br />
Presentation Issues<br />
There are also several issues that have to be considered at the time when a presentation<br />
is given. The first involves the presentation equipment itself. Be<strong>for</strong>e giving a<br />
presentation, the equipment should be inspected <strong>for</strong> its physical arrangement and<br />
condition to ensure that any necessary adjustments or accommodations can be made.<br />
Remember that YOU ARE THE FOCUS DURING A PRESENTATION. The slides<br />
are there as visual aids to help explain what you have done. There was a professor at<br />
Princeton named Irv Glassman who, at conferences, would routinely turn off the<br />
overhead projector (this was be<strong>for</strong>e laptops and Power Point presentations) after being<br />
introduced. He would talk <strong>for</strong> a minute or two about the motivation <strong>for</strong> the research he<br />
was presenting, and then turn on the projector again and continue. Moreover, he would<br />
have all of his students do the same thing when they were presenting at conferences or<br />
dissertation defenses. While the projector was off there was nothing to focus on but the<br />
Last Updated 8/22/<strong>2013</strong><br />
Page 36
A Guide to Technical Communication<br />
speaker. This practice would establish the speaker, rather than the slides, as the central<br />
concern of the audience. This is a rather radical practice, and few people would be brave<br />
enough to try something like this without significant coaching, but the logic behind the<br />
practice is undeniable.<br />
Be<strong>for</strong>e starting your presentation, remember that you are the expert on the material<br />
you are presenting. It may be difficult to remember this at first, especially when you are a<br />
student being evaluated on the quality of your presentation. However, when you leave<br />
and start presenting you work in your career, this expertise will become more evident,<br />
and there<strong>for</strong>e it will be easier <strong>for</strong> you to remember. It will probably be most evident in the<br />
way questions are asked. In school, questions are asked by the professor to test your<br />
knowledge. After school, colleagues will ask questions because they are interested in<br />
what you have to say, and they want to know more. It’s an empowering feeling, and you<br />
need to cultivate it.<br />
When giving the actual presentation a rapport with the audience should be maintained.<br />
This can be accomplished by working through the slide material rather than from notes; it<br />
creates a more cohesive presentation and shows the audience that the presenter is very<br />
familiar with the material. In fact, don’t even bring notes up to the podium with you.<br />
They’ll serve you no purpose. The speaker should also maintain eye contact with the<br />
audience by facing them at all times, while making sure that the projected image is not<br />
obscured. The presenter should also talk slowly, clearly and loudly enough to allow the<br />
audience to hear what is being said, and use a pointing device (either a telescoping<br />
pointer or a laser pointer) to call attention to salient features on the slides. Also, slides<br />
should not be removed too quickly, since the audience needs time to absorb the<br />
in<strong>for</strong>mation being presented.<br />
Care should also be taken to ensure that the presenter creates a good impression. This<br />
can be achieved by being presentable, neat, and well dressed. In addition, the presenter<br />
should never chew gum, wear a hat, put his or her hands in pockets, or use fills such as<br />
“um,” “ah,” etc. Introduce yourselves to the audience, if you haven’t already been<br />
introduced.<br />
Keep looking at the audience – pick individual people to focus on, but occasionally<br />
shift to different people. Do not let your eyes stay fixed on the screen, since then you’ll<br />
be talking away from the audience!<br />
Do not get rattled by interruptions. They happen. In class, if you’re interrupted, it’s<br />
done in order to improve your presentation style (to make sure you know what you’re<br />
talking about). In other situations, if you’re interrupted, it’s probably because the person<br />
is very interested in what you’re talking about and wants to know more.<br />
Last Updated 8/22/<strong>2013</strong><br />
Page 37
A Guide to Technical Communication<br />
General Guidelines <strong>for</strong> Electronic Mail<br />
Electronic mail (email) has become a common way to communicate with peers,<br />
colleagues, superiors, employees, etc. This mode of communication has, in the past ten to<br />
fifteen years, largely replaced the memorandum as a <strong>for</strong>m of communication within an<br />
organization, just as it has replaced the paper letter as the <strong>for</strong>m of communication with<br />
entities outside an organization. Why are emails so useful?<br />
Complex messages can be transmitted efficiently. Simple messages can be<br />
transmitted via telephone or face-to-face meetings. For something a more<br />
involved, an email is better. 1<br />
They provide a written history. Electronic communications allow <strong>for</strong> traceability<br />
of in<strong>for</strong>mation transfer between entities, and thanks to modern technology, are<br />
automatically archived “in the cloud.” 1<br />
They potentially eliminate meetings. If you can provide updates on in<strong>for</strong>mation<br />
that only needs to be transmitted one way, sending a memo-type email allows<br />
users to read in<strong>for</strong>mation at their leisure, keeping schedules free <strong>for</strong> other items. 9<br />
You will probably be writing more emails than any other type of document, and so it<br />
pays to know how to write them in a way that gets your point across in a clear, succinct<br />
manner.<br />
Just Because It’s Fast Doesn’t Mean It Should Be In<strong>for</strong>mal<br />
Many people treat emails in the same way they treat text messages; it’s a quick and<br />
easy way to send a message to someone. This treatment of email is certainly fine in a<br />
more familiar environment (with friends and family), but such an approach really is not<br />
the most appropriate <strong>for</strong> business communication. Here are two emails recently sent to<br />
me, which serve as examples of what not to do (the names have been removed to protect<br />
the not-so-innocent):<br />
from: Cxxxxx <br />
to: "john.leylegian@manhattan.edu" <br />
date: Fri, Feb 8, <strong>2013</strong> at 8:20 AM<br />
subject: Class Absence<br />
mailed-by: manhattan.edu<br />
Hello professor<br />
I will be unable to make it to class today due to inclement weather. Can u email<br />
me the topics to be covered in class today? Thank you and stay safe.<br />
From,<br />
Cxxxxx<br />
Sent from my iPhone<br />
Last Updated 8/22/<strong>2013</strong><br />
Page 38
A Guide to Technical Communication<br />
from: Mxxxxx <br />
to: "john.leylegian@manhattan.edu" <br />
date: Fri, Apr 26, <strong>2013</strong> at 8:00 AM<br />
subject: Hey professor<br />
mailed-by: me.com<br />
Hey Professor,<br />
I will not be coming into class this morning , I have an early appointment with<br />
the passport bureau to get my passport <strong>for</strong> my upcoming France trip.<br />
Thank You<br />
Mxxxxx<br />
Both of these email messages exhibit a level of familiarity not appropriate <strong>for</strong> business<br />
email messages. In the first, the student wrote the email as if it were a text message,<br />
complete with a “u” where a “you” belonged. The second message has a subject line not<br />
indicative of the subject of the message, and an overly familiar greeting.<br />
TAKE YOUR TIME… and it doesn’t have to be a lot of time. When you write an<br />
email that is in a professional capacity, write it as if it were going to be read by a<br />
potential employer, since it very well might, but more on that in the next section.<br />
Who Will Be Reading Your Email?<br />
Who are you writing to? The short answer is: More people than you think. You might<br />
have an initial distribution <strong>for</strong> your email (people who you are sending to, then others<br />
who are carbon copy (cc:) or blind carbon copy (bcc:) recipients), but <strong>for</strong>warding an<br />
email only takes a single click. Recipients of your email may think it should have a wider<br />
distribution; so <strong>for</strong> better or worse, your email may end up in the inbox of almost anyone.<br />
This fact makes it imperative that you put your best face <strong>for</strong>ward.<br />
When replying to an email the question of distribution is just as important. You should<br />
know the difference between “Reply” and “Reply All.” There are two reasons <strong>for</strong> taking<br />
care with distribution <strong>for</strong> replies. First, you do not want to be the person who needlessly<br />
clutters other people’s Inboxes with in<strong>for</strong>mation that does not apply to them. Second, if a<br />
message is sensitive in nature, it is important to make sure only the people who need<br />
in<strong>for</strong>mation are getting it.<br />
If only the sender needs to see your response, make sure you “Reply” rather than<br />
“Reply All.” Remember: you can always re-send an email to a larger audience, you can’t<br />
“unsend” though.<br />
Subject Line<br />
The subject line is the first thing your recipients will see. There<strong>for</strong>e, it should be a<br />
clear, very concise description of what is to follow. Remember that if you do not your<br />
email may not be given the attention it deserves.<br />
Last Updated 8/22/<strong>2013</strong><br />
Page 39
A Guide to Technical Communication<br />
Another important thing to remember about subject lines: some anti-spam filters may<br />
block a legitimate email you’re trying to send because a subject line is vague, misspelled,<br />
or some other “red flag” is raised. Normally the best way to keep people’s emails out of<br />
your spam folder is to make sure they are in your Address <strong>Book</strong>. You should also check<br />
your Spam folder regularly to make sure important messages are not being inadvertently<br />
ignored.<br />
Keep the Length Appropriate<br />
An email should not be more than one or two pages in length. If you find that it needs<br />
to be longer, perhaps you should consider writing a report to convey your ideas.<br />
Format<br />
There are many different <strong>for</strong>mats <strong>for</strong> memos which could apply to email<br />
communications. They can be in<strong>for</strong>mational or instructional in nature, and more<br />
in<strong>for</strong>mation on these <strong>for</strong>mats may be found in References 1 and 9. The important thing to<br />
remember is, like in reports, to tell a clear, coherent story.<br />
Write an Initial Draft, Then Revise!<br />
When you start to write an email, you may write in a “stream of consciousness”<br />
manner; that is, you will just start to write as ideas pop into your head. This type of<br />
writing is okay to articulate your thoughts, but they typically do not come out in a<br />
reasonable order. There<strong>for</strong>e, once you have your ideas out, they need to be organized into<br />
a more logical manner to the reader. 10<br />
Use the first draft to get your ideas down in writing. The next one or two drafts should<br />
be used to fit your thoughts into a coherent <strong>for</strong>mat. Finally, polish up what you want to<br />
say in the final draft.<br />
Attachments<br />
There are three main issues when dealing with attachments.<br />
First, don’t <strong>for</strong>get them! If you have attachments <strong>for</strong> your email, they should be<br />
included as soon as you think they are necessary. If you don’t include them right away,<br />
you might <strong>for</strong>get them altogether. At this point, you’ll need to write the sheepish mea<br />
culpa: “Sorry, <strong>for</strong>got to include the attachment(s).” Avoid this mistake at all costs!<br />
Second, try to keep attachments in <strong>for</strong>mats that you know your recipients can read.<br />
Things like text files, pdfs, Word documents, Excel workbooks, etc. are best. Files in<br />
other <strong>for</strong>mats should not be sent unless you know that the recipient has the correct<br />
application.<br />
Third, be aware of limitations on overall attachment size <strong>for</strong> emails. You might not be<br />
able to send very large files, and your recipients may not be able to receive them. In this<br />
case, offer a link to the file accessible on the cloud. Applications like Google Drive,<br />
Dropbox, or internal network drives can be used <strong>for</strong> this purpose.<br />
Proofreading, You Still STILL Need to Do It!<br />
Be<strong>for</strong>e you hit “Send,” take a last look at it. Make sure everything is spelled correctly,<br />
grammar and punctuation are correct, the flow of the story is correct, and any attachments<br />
Last Updated 8/22/<strong>2013</strong><br />
Page 40
A Guide to Technical Communication<br />
are included. If it’s really important, ask a colleague, and be sure to return the favor if<br />
he/she asks you.<br />
One consultor once said at one of our meetings, “If someone sends me an email<br />
riddled with grammatical and/or spelling errors, would I want him or her designing a new<br />
airplane, or a car, or even a coffee maker?” Remember, you only get one chance <strong>for</strong> a<br />
good first impression.<br />
Don’t Hit Send in Anger<br />
An important thing to always remember about emails and SMS messages: subtle clues<br />
about intonation, body language, etc., are non-existent. In addition, we all at one time or<br />
another have gotten heavily invested in the work we have done, and a result is<br />
hypersensitivity. A seemingly innocuous message could easily set someone off if it is<br />
misread. There<strong>for</strong>e, we offer two pieces of advice:<br />
First, when sending emails, refrain from any type of language which could easily be<br />
misconstrued as hostile. Leave tongue-in-cheek comments, sarcasm, and the like <strong>for</strong> inperson<br />
exchanges, where they may go over better. If you’re not sure, ask someone to read<br />
your email be<strong>for</strong>e you send it.<br />
Second, if someone has overblown a comment you made in an email, nip it in the bud.<br />
Calmly apologize, and try not to make the same mistake again. Business emails are not<br />
the correct setting <strong>for</strong> a flame war. No one wins.<br />
Closing and Signatures<br />
An email is a letter, and there<strong>for</strong>e should have a closing. The most common closing in<br />
business emails uses a pre-composed signature, but any closing used in business letters,<br />
e.g., Sincerely, Regards, etc. are appropriate as well. Sometimes both the closing and the<br />
signature are used together.<br />
Signatures, if your company uses them, should be standard. Usually if you are a new<br />
hire, guidelines <strong>for</strong> communications are laid out and expected of all employees. A big<br />
reason <strong>for</strong> uni<strong>for</strong>mity is branding. Try to keep uni<strong>for</strong>m between computer and mobile<br />
devices. For example, here is the standard signature used by <strong>Manhattan</strong> College:<br />
-----------------------<br />
John C. Leylegian, PhD<br />
Assistant Professor of Mechanical Engineering<br />
Riverdale, NY 10471<br />
Phone: 718-862-7279<br />
Fax: 718-862-7163<br />
john.leylegian@manhattan.edu<br />
www.manhattan.edu<br />
Last Updated 8/22/<strong>2013</strong><br />
Page 41
A Guide to Technical Communication<br />
The font, including the color, bold face/italicization, etc., was standardized by the<br />
College. On the other hand, if you frequently send emails from a smart phone you might<br />
not be able to have an elaborate signature set up on your smartphone. In that case, use a<br />
plain text version, such as:<br />
--<br />
John C. Leylegian<br />
Assistant Professor of Mechanical Engineering<br />
<strong>Manhattan</strong> College<br />
Riverdale, NY 10471<br />
Phone: 718-862-7279<br />
Fax: 718-862-7163<br />
john.leylegian@manhattan.edu<br />
www.manhattan.edu<br />
----------------------------<br />
Sent from my DROID<br />
If you can apply the rules <strong>for</strong> good technical writing to your approach to emails, you<br />
will be a great deal ahead of your peers when you find yourself in the business world.<br />
Emails versus SMS (Text) Messages<br />
Text messages were mentioned earlier, as an example of what not to do in an email.<br />
Text messages were originally limited to 160 characters, because this was considered the<br />
maximum length necessary to concisely express a thought. 11 For this reason, SMS is not<br />
really the best way to communicate complex ideas, and you should probably avoid it<br />
whenever possible.<br />
If you need to send business messages via SMS, remember that the rules <strong>for</strong> email<br />
should still apply. Conduct yourself professionally, avoid abbreviations and emoticons,<br />
and be clear and concise in your communication.<br />
Last Updated 8/22/<strong>2013</strong><br />
Page 42
A Guide to Technical Communication<br />
General Guidelines <strong>for</strong> Voicemail<br />
When you work you will often need to leave voice mail messages <strong>for</strong> colleagues, or<br />
people who you would like to be potential colleagues. Voicemail differs slightly from<br />
email since voicemails aren’t necessarily editable (some voicemail systems allow you to<br />
re-record a voicemail, but this feature is far from ubiquitous). There<strong>for</strong>e, here are some<br />
simple guidelines when you want to leave a voicemail message <strong>for</strong> someone: 12<br />
Plan out what you’d like to say be<strong>for</strong>e you call. Write out a few key notes to help<br />
you. This way, you don’t lose your train of thought or fill your message with<br />
awkward pauses.<br />
Begin by clearly stating your name and a contact number.<br />
State your purpose <strong>for</strong> calling. Be specific and eliminate any confusion. Avoid<br />
rambling.<br />
End your message with a plan to call again on a specific day. This lets the<br />
recipient off the hook if they are unable to call back, and ensures you’re not<br />
waiting around <strong>for</strong> a return phone call.<br />
Last Updated 8/22/<strong>2013</strong><br />
Page 43
A Guide to Technical Communication<br />
References<br />
1 Eisenberg, A., Effective Technical Communication, 2 nd ed., McGraw-Hill, New York,<br />
1992, Chaps 2-5, 12.<br />
2 Longuski, J., Advice to Rocket Scientists, American Institute of Aeronautics and<br />
Astronautics, Reston, VA, 2003, Chaps 21-24.<br />
3 Course materials <strong>for</strong> 2.272 Project Laboratory, Spring 2009. MIT OpenCourseWare,<br />
URL: http://ocw.mit.edu, Massachusetts Institute of Technology. [cited 24 June 2011].<br />
4<br />
Straker, D., Types of Data, Changing Minds <strong>Web</strong>site, Syque, URL:<br />
http://changingminds.org/explanations/research/measurement/types_data.htm [cited 6<br />
April 2008].<br />
5 Belcher, A., Endy, D., Kuldell, and Stachowiak, A., Course materials <strong>for</strong> 20.109<br />
Laboratory Fundamentals in Biological Engineering, <strong>Fall</strong> 2007. MIT OpenCourseWare,<br />
Massachusetts Institute of Technology http://ocw.mit.edu [cited 24 June 2011].<br />
6<br />
AIAA ScholarOne Manuscripts Page, American Institute of Aeronautics and<br />
Astronautics URL: http://mc.manuscriptcentral.com/aiaa [cited 19 December 2012].<br />
7 Cockrell, C. E. Jr., Huebner, L. D., and Finley, D. B., “Aerodynamic Characteristics of<br />
TwoWaverider-Derived Hypersonic Cruise Configurations” NASA TP-3559, Jul 1996.<br />
8 Daum, K., “5 Tips <strong>for</strong> Giving Really Amazing Presentations,” Roaring or Boring, 3 July<br />
<strong>2013</strong>, Inc. URL: http://www.inc.com/kevin-daum/5-tips-<strong>for</strong>-giving-really-amazingpresentations.html<br />
[cited 8 July <strong>2013</strong>].<br />
9 Connor, P., Business Memos, Writing@CSU, Colorado State University, URL:<br />
http://writing.colostate.edu/guides/guide.cfm?guideid=73 [cited 19 June <strong>2013</strong>].<br />
10 Mias, C. and Zinn, M., Personal Communication, 4 April <strong>2013</strong>.<br />
11 Milian, M., “Why text messages are limited to 160 characters,” Technology Blog, 3<br />
May 2009, Los Angeles Times URL: http://latimesblogs.latimes.com/technology/<br />
2009/05/invented-text-messaging.html [cited 26 June <strong>2013</strong>].<br />
12 McClain, A., “How to Leave a Good Voicemail Message,” eHow Tech, URL:<br />
http://www.ehow.com/how_7516281_leave-good-voicemail-message.html [cited 26 June<br />
<strong>2013</strong>].<br />
Last Updated 8/22/<strong>2013</strong><br />
Page 44
A Guide to Technical Communication<br />
Appendix A: Format <strong>for</strong> Cover Sheets<br />
The following pages provide some cover sheets <strong>for</strong> different types of reports. These<br />
cover sheets can be found in files on the Mechanical Engineering Department Blackboard<br />
site <strong>for</strong> your use. Just be sure to replace all of the pertinent in<strong>for</strong>mation.<br />
Last Updated 8/22/<strong>2013</strong><br />
Page 45
A Guide to Technical Communication<br />
MECH 405 (02)<br />
Thermal/Fluids Laboratory<br />
Experiment No. 4<br />
Forced Convection<br />
Report Submitted to<br />
Dr. Mohammad Naraghi<br />
Group 3<br />
John Aquino Experiment Per<strong>for</strong>med: 14 April 2003<br />
James Knapp Report Submitted: 28 April 2003<br />
Richard Thomas<br />
Mechanical Engineering Department<br />
<strong>Manhattan</strong> College<br />
Last Updated 8/22/<strong>2013</strong><br />
Page 46
A Guide to Technical Communication<br />
MECH 211-01<br />
Introduction to Design<br />
DESIGN PROJECT<br />
Proposal<br />
Group A<br />
Eric Clegg<br />
Philip Ng<br />
Thomas Langowski<br />
September 22, 2004<br />
Mechanical Engineering Department<br />
<strong>Manhattan</strong> College<br />
Last Updated 8/22/<strong>2013</strong><br />
Page 47
A Guide to Technical Communication<br />
MECH 401 (01)<br />
Mechanical Engineering Design<br />
Progress Report<br />
Project: Easy Rider Cart<br />
Report submitted to<br />
Dr. Daniel Haines<br />
20 October 2002<br />
Group B<br />
Twisted Minds Inc.<br />
Charles Dickens<br />
Mary Murphy<br />
James Patterson<br />
Mechanical Engineering Department<br />
<strong>Manhattan</strong> College<br />
Last Updated 8/22/<strong>2013</strong><br />
Page 48
A Guide to Technical Communication<br />
MECH 401 (01)<br />
Mechanical Engineering Design<br />
Final Report<br />
Project: Easy Rider Cart<br />
Report submitted to<br />
Dr. Daniel Haines<br />
10 December 2002<br />
Group B<br />
Twisted Minds Inc.<br />
Charles Dickens<br />
Mary Murphy<br />
James Patterson<br />
Mechanical Engineering Department<br />
<strong>Manhattan</strong> College<br />
Last Updated 8/22/<strong>2013</strong><br />
Page 49
A Guide to Technical Communication<br />
Appendix B: Sample Presentations<br />
In general, there are only three types of oral presentations that are associated with the<br />
engineering field: design presentations, presentations of experimental or theoretical work,<br />
and presentations describing state-of-the-art material. On the following pages there are<br />
frameworks <strong>for</strong> the first two types. It should be noted that these are only guidelines, and<br />
depending on the situation more than one slide may be needed to cover a specific issue,<br />
some slides may not be necessary, or a specific topic may be missing altogether.<br />
Last Updated 8/22/<strong>2013</strong><br />
Page 50
A Guide to Technical Communication<br />
Experimental Study Slides<br />
Slide 1<br />
Experimental Study Title<br />
Names of Group Members<br />
Course Number<br />
Slide 2<br />
Introduction<br />
Use bullets to outline the objective of the<br />
project in question<br />
Use a slide design that is bright and easy<br />
to print out.<br />
Provide a background to the problem<br />
Discuss the State-of-the-Art<br />
Slide 3<br />
Theory and/or Hypothesis<br />
The basic principles<br />
Last Updated 8/22/<strong>2013</strong><br />
Page 51
A Guide to Technical Communication<br />
Slide 4<br />
Experimental Design<br />
Discuss full or partial factorial design<br />
chosen<br />
Discuss the use of any confounding or<br />
blocking<br />
Slide 5<br />
Test Equipment Setup<br />
Use text, pictures,<br />
and/or diagrams<br />
Clearly annotate the<br />
pictures<br />
Describe the<br />
methodology<br />
Slide 6<br />
Data Measured<br />
? Present a sample of the raw data when<br />
appropriate, i.e., when data processing<br />
involves more than simple algebra<br />
Last Updated 8/22/<strong>2013</strong><br />
Page 52
A Guide to Technical Communication<br />
Slide 7<br />
Statistical Analysis<br />
Present the statistical analyses<br />
ANOVA<br />
Regressions<br />
Confidence intervals<br />
Chi squared test<br />
Slide 8<br />
Tables/Graphs of Data<br />
Slide 9<br />
Discussion of the Results<br />
Discuss salient features of the data and<br />
trends observed<br />
Discuss any anomalies<br />
Last Updated 8/22/<strong>2013</strong><br />
Page 53
A Guide to Technical Communication<br />
Slide 10<br />
Conclusion<br />
Present the conclusions that can be drawn<br />
from the experiment<br />
Last Updated 8/22/<strong>2013</strong><br />
Page 54
A Guide to Technical Communication<br />
Design Study Slides<br />
Slide 1<br />
Design Study Title<br />
Names of Group Members<br />
Course Number<br />
Slide 2<br />
Introduction<br />
Use bullets to outline the objective of the<br />
project in question<br />
Use a slide design that is bright and easy<br />
to print out.<br />
Objective of Project<br />
Slide 3<br />
Specifications<br />
Present requirements and constraints<br />
State the what’s that needed to be done<br />
Present and Quality Function Deployment<br />
(QFD) analysis<br />
Last Updated 8/22/<strong>2013</strong><br />
Page 55
A Guide to Technical Communication<br />
Slide 4<br />
Conceptual Designs<br />
Present the fours conceptual designs that<br />
were examined<br />
Use text, pictures, and/or diagrams<br />
Slide 5<br />
Design Selection Matrix<br />
Slide 6<br />
Detailed Design<br />
Design Analysis (assumptions, sample<br />
calculation, and results)<br />
Use text, pictures, and/or diagrams<br />
Present material selection process<br />
Reliability analysis<br />
Last Updated 8/22/<strong>2013</strong><br />
Page 56
A Guide to Technical Communication<br />
Slide 7<br />
Prototype Per<strong>for</strong>mance<br />
Present per<strong>for</strong>mance data and graphs<br />
Slide 8<br />
Manufacturing Issues<br />
Processes to be used<br />
Slide 9<br />
Economic Analysis<br />
Part costing<br />
Manufacturing costing<br />
Last Updated 8/22/<strong>2013</strong><br />
Page 57
A Guide to Technical Communication<br />
Slide 10<br />
Conclusion<br />
Present the salient features of the design<br />
Last Updated 8/22/<strong>2013</strong><br />
Page 58