补充阅读 Giving a talk

Giving a Talk Introduction Giving a talk is much more difficult than it seems. Especially when your talk is about a high-level computing science subject. There are syntactical as well as semantical forms to be observed, and these might differ for each environment. Timing is an issue, as is keeping the attention of your audience.Being a computing scientist, it is probable that you will be asked to give a (large) number of talks during your career. Since these talks have some points in common, we will focus on those points. As your experience increases, giving talks becomes easier, but especially the first few talks need extensive preparation. There is one important point to address first: PRACTICE! If the first time you give the talk is in front of the intended audience you will get into trouble. Your timing might be off (too long, too short due to lack of questions, or too many questions), Your presentation might be flawed (sheets in the wrong order), and so on. There are basically two ways to practice your performance. The best is to do both, in the order given below. Practice In front of the mirror When you have finished your notes, sheets, or slides, practice your talk in front of a mirror (or just in the air). Keep eye on the time, and just pretend you are speaking to an audience. Pretend they are asking questions, and imagine their possible reactions. After practicing check how much time you took. If you feel it did not go smoothly (stuttering, lack of right words) try it again and again until you are satisfied. For a select audience Ask some friends or colleagues to help you, and try the talk on them. Let them ask questions and time your performance again. Ask them for every comment and critical remark they can come up with, and incorporate this in your talk. Syntactical Basically, just speaking is not enough. You cannot expect the audience to grasp all you are saying from hearing alone. This is a well-established fact, and one of the reasons blackboards and overhead projectors were introduced in educational environment. A recent addition that gains in popularity are powerpoint slides. If you use powerpoint slides, do not use animation when it is not absolutely necessary. There are, of course, various means to augment your presentation, but the ones most often used are the overhead projector and the blackboard. Therefore, we will focus on these two media. Blackboard Using a blackboard in a presentation will present you with run time as well as compile time difficulties. As you probably have no blackboard available when you prepare (and practice !) your talk, you will not know what to expect (chalk or markers ? size ?). This will give you problems in your preparation, and might create run time problems. At run time, you basically have to keep two points in mind:n Write large and clear. You cannot scribble as you do on paper. Characters have to be distinguishable from the back rows. n Divide the board into blocks. Dont wipe out part of old remarks to put new ones in. The best way to accomplish this is to draw the lines separating the blocks, and only remove whole blocks. If you give a talk to a school audience, you can expect that everything you put on the board will appear in their notebooks. Be very careful about what you actually write down. If you, for example, present a common mistake, write COMMON MISTAKE in capitals. Do not just wipe it out. The main advantage of the blackboard is that it provides a visual means of showing progress. You can feed information a bit at a time in a natural way. Furthermore, it is very handy for adding runtime remarks and answering questions in your talk. Overhead Projector An overhead projector projects transparencies (or sheets) on a wall or white thing.Preparing sheets Obviously, if you do not prepare sheets beforehand, the overhead projector will be only an inferior version of the blackboard. Thus, if you want to use sheets in your talk, you had better prepare them in advance.Basically, there are two ways to prepare sheets. You can write on them with a felt marker, or you can copy print-outs onto them. If you are confident with your handwriting, the first method is easiest. If you, like me, have bad handwriting, it is better to create sheets with programs like slitex, framemaker or interleaf. A sheet might look like a lot of information can be crammed onto it, and this is actually true. However, it is not appropriate to do so. If you put too much information on one sheet, it will boggle the audience. It is better to restrict yourself, and use more sheets. A big pit-fall in creating sheets is adding details. It is so easy to do, and so dangerous. Small details should be giving in accompanying speech, where broad outlines should be given in sheets. Example: instead of writing We can prove theorem A by structural induction, where we use the fact that F returns a natural number in the second caseit is probably better to writeTheorem A can be proven by structural inductionand allow the how to be a response on a question from the audience. Finally, dont cover part of your sheets to be revealed later. There is hardly anything that is more annoying during a talk. Except perhaps a slide crammed with powerpoint animations. Placement When you are giving your presentation, you should be very careful how you position yourself physically. Do not stand in front of text you want your audience to read. For this reason, do not point at parts of the actual transparency, but point at its projection on the screen.SemanticalIn your talk, you are not expected to cover the area of your research extensively. The audience wants results. Problems you ran into are only interesting if the audience might encounter them as well. Proofs you made or read and details that were important are only interesting if they are important at this higher level. You can compare it (in a way) to abstract programming. We do not care how a compiler translates our code, we care what effect our code will have. So, if you discuss your programming language, the audience is probably not interested in how you use this particular machines architectural features, but more in what your programming constructs actually do. (Of course, if you discuss implementing a programming language this is a different matter). This doesnt mean proofs are not necessary. They should be provided in accompanying papers or literature references. You have to keep in mind that the audience could read about the subject. You can have an accompanying article, or a bibliography that allows the audience to research the subject more extensively. What they want from your talk is an overview. Dont misinterpret the above as be shallow. Youre covering of the area has to be clear, encompassing and correct. Be transparent in your talk. Dont make it a mystery story with a triumphant conclusion. In the beginning you should give an overview of the structure of your talk, and you should strive to maintain this structure during the talk. Basically a talk should have the following structure: n Introduction name n Overview tell the audience whats com