Highlight and Report Instructions

1) The highlight should be 200-300 words and should describe who worked on the project, what problem you solved, and how you did it. This should be written for a general audience and should not include any jargon. I sent an example of a good one yesterday.

2) The report should be 5 pages using the below templates with the template size fonts. The report organization depends exactly on your sub-discipline which you should ask your adviser about. For example, in computer architecture, they often put the background at the end. The citation style is also quite different in these sub-disciplines. IEEE uses numbers [1], [2], etc while ACM uses name/year such as [Guthaus2010]. Pick a style guide from IEEE or ACM:

http://www.ieee.org/conferences_events/conferences/publishing/templates.html (use the conference one, not the journal one)
http://www.acm.org/sigs/publications/proceedings-templates

Most of these will be 2 column format and include the references style and an example of what it should be formatted like.

The structure of your report should be something like the following, but the body sections are often quite different depending on the topic presented:

-- Abstract - A 4-5 line summary of what problem, how you solve it, and what result you got.

-- Introduction - what you are solving and why it is important

-- Background - any prior research on the subject or possibly some basic review of items relevant (assume you are talking to general engineers, but they don't know the details of your project). If there are previous people that have addressed this (or similar) problems you should provide a sentence or two description on what they did and why it is different than yours.

-- Body sections - 1-3 sections with titles relevant to your work. This should discuss the details of your contribution. This may be a new algorithm, a new design, or whatever you actually did. It can be 1 large section with subsections or a couple separate sections -- you decide.

-- Methodology - Your results will have some experiments or a demonstration. What tools did you use to create your software, simulator, or parts did you use to create your prototype?


-- Results - The measurements of results including tables, pictures, or other information.

-- Conclusion - Basically, restate how you solved the problem from the introduction and what your result was.
 
-- References - You should not copy ANY text. If you paraphrase text, it is likely that you should reference it. If it is a "general engineering" concept, you might not need to cite it or you may want to cite a textbook. In the background, you will have to cite prior similar works. You may cite these again in the results if you compare against them or in the body sections if you explain the detailed difference of your project.
 
When someone READS your paper, they will generally read the abstract and decide if it is relevant to them. Then, they will read the introduction and the conclusions. If they are really interested in your conclusions they will read the methodology and results. Only someone who is doing similar work will generally read the body sections. Background is often read by new researchers but after working in an area for a while most researchers will skip it altogether since professors/PhDs know all the previous work on a topic.
 
Tables, graphs and images - These go in the results and possibly the body sections. These should have captions that are useful and should be referenced in the text somewhere. The caption should summarize the CONCLUSION of the plot and not just restate what it is a plot of. This is actually a pet peeve of mine as many people will just say "Figure 1. Plot of X vs Y." but you can gather this from looking at the axes. It is better to say "Figure 1. In the W simulator, Y has a quadratic relationship to X under our assumption of uniform Z." This explains how you got the results, what the results mean, and any limitations to the results. This also helps people skimming your paper to see if it is worth reading!