The general strategy: 1. Decide what it is that you want to say. Order it by importance, logical dependence. 2. Decide who your audience is. Decide what they already know, what you need to tell them. There could be some background reading that you did which took you to the main problem in your report. The main ideas from the background reading must appear in your report, possibly in an appendix, or even in-line in the text. 3. Write the report (or, prepare the transparencies). 4. Read it, have somebody else read it (or, practice the talk). 5. Revise. 6. Repeat all steps as necessary. ------------------- CONTENT OF THE REPORT/TALK Statement of the problem. What you have accomplished, what you have read, what you plan to do. What is exciting. What is unknown. What background material you need to include. Different parts will apply for seminars, first stage of project, final stage of project. For seminars, it is good if you can write more lucidly, or give more examples, details, than the papers you read. AUDIENCE: The general rule that seems to be gaining currency is that 80% of your talk/report should be accessible to other collegues of yours. The rest of it may be intended for a more expert audience (but without any specific expertise in your topic) Follow this rule. For every sentence, you should be able to state who your audience is. ORGANIZATION: Important topics first: Simply by placing something first, you accord it importance. Very important ideas should get their own chapter. Less important ones a section, still less important ones a subsection and so on. Any idea worth its salt must at least get a paragraph. Usually do not put two ideas in a single paragraph. Give good names to chapters, sections, subsections. Overview first: The first chapter must be an overview of the report. The first section of a chapter should be an overview of the chapter. And so on. Good authors can often even make the first sentence contain the gist of the entire paragraph. Converse of the above: In the first chapter/section/... the reader expects an introduction. So you should do that. Furthermore, you should not say "We begin by giving an introduction" -- the position itself conveys this, and so dont say it again. INTRODUCTION There must be a serious introductory chapter to your report (likewise you should spend enough time on the introduction in a talk). The introduction must contain a good description of the problem, what constitutes the input and what are desirable outputs. While discussing this avoid discussing HOW to compute the outputs, but just focus on WHAT outputs are desirable/acceptable. Give examples. The problem statement should be clear to every reader, even those who arent paying 100% attention. Give the motivation for solving the problem. The motivation could be a real life situation, a subgoal in a larger problem -- any of these helps the reader. The introduction should also give some idea as to why the problem is hard. Is the problem NP-complete, for example? Why do simple algorithms not work? Finally give an overview of the rest of the report. Even in a talk, it is better to give the overview after the introduction. PREVIOUS WORK: This may be included in the introduction, but also may be a separate chapter. You may choose to discuss it after you discuss your own work -- if convenient -- though this is somewhat unorthodox. Previous work should include journal and conference papers. Articles from websites may be included, but these must be viewed somewhat skeptically, since they are typically not reviewed, and hence may be less reliable. ALGORITHMS: Discuss what quantities you will compute at an abstract level, e.g. say "In step 2 we compute the sets S_i which have the property ...". It is better to describe algorithms by stating properly what gets computed at each stage -- and then you can even omit how it gets computed. In most cases it is better to describe the precise data structures at the very end ("Note that if we represent S_i using a priority queue then T_i can be found in nlogn time"). THEOREMS AND PROOFS: I prefer a top down style. The main theorem of the chapter/section must be stated first. You may even give a proof immediately: "Follows from Lemmas 5.3 and 5.7 which we prove shortly". Or you may defer the proof till the end of the chapter/section. But please dont expect the reader to go through lemmas and theorems without knowing what grand result all this is leading upto. DEFINITIONS AND NOTATION: If some quantity is important in your work, it probably deserves to be defined explicitly (say using latex \definition). It probably also deserves to get a good symbol. The converse is also true -- if you are giving names and defining symbols for unimportant quantities, you are probably doing something wrong! Placement of definitions: close to the point of use. DO NOT PUT ALL DEFINITIONS AT THE TOP. This is similar to variable declarations in programs. Truly important definitions (global scope) should be at the top -- and the less important, local ones close to the point of use. HOWEVER: it should somehow be clear where I should look up a definition if I need it somewhere in the middle of your report -- please dont assume that I will always read your report from the beginning and will remember everything. DIFFERENCES BETWEEN TALKS AND REPORTS Talks can be less formal. Talks may cover only a subset of the material from the report. In talks you may consider not giving formal proofs (which should be present in the report) but instead just explain the important cases only. You may even say, "let us see what happens on this example" -- if that gives out the main idea of the proof/algorithm. Talks should also be broken into parts. You could do this by putting in transparencies which just show the title of the next part. Leave this transparency on the screen for 2-3 seconds, perhaps even without saying anything. That will signal the beginning of a new part.