Give a talk - Revision history

Connor Gramazio at 16:49, 13 January 2015

2015-01-13T16:49:32Z

← Older revision		Revision as of 16:49, 13 January 2015
Line 59:		Line 59:
	** Generally speaking, keep in mind: '''the audience is always right'''.		** Generally speaking, keep in mind: '''the audience is always right'''.

			== Post-talk ==

			After giving a talk, add your presentation to /pro/graphics/talks/[name].

	[[Category:HOWTO]][[Category:Dissemination]]		[[Category:HOWTO]][[Category:Dissemination]]

Jadrian Miles: /* Presentation Style and Audience Interaction */ more on pointers

2012-09-23T22:44:46Z

Presentation Style and Audience Interaction: more on pointers

← Older revision		Revision as of 22:44, 23 September 2012
Line 43:		Line 43:
	* '''Ask Skyped-in audience members to mute themselves'''. People listening on their laptops often make a lot of noise without realizing it, and this can be incredibly distracting amplified over the speakers during your talk. I've seen this fuck up several defenses. The person can un-mute themselves if they need to ask a question.		* '''Ask Skyped-in audience members to mute themselves'''. People listening on their laptops often make a lot of noise without realizing it, and this can be incredibly distracting amplified over the speakers during your talk. I've seen this fuck up several defenses. The person can un-mute themselves if they need to ask a question.
	* '''Pace yourself'''. Pause at the end of each section or after each significant point to implicitly or explicitly wait for questions. Count off to yourself to make sure you don't rush through this pause; subjective "presenter time" and objective "audience time" go at different rates!		* '''Pace yourself'''. Pause at the end of each section or after each significant point to implicitly or explicitly wait for questions. Count off to yourself to make sure you don't rush through this pause; subjective "presenter time" and objective "audience time" go at different rates!
	* '''Use a pointer (with discretion)'''. Make sure you have a laser pointer or something equivalent (stick, telescoping pointer, finger that can reach the projection screen). When there are multiple things on a slide and you refer to them separately, indicate them both verbally and visually as you refer to them. Some people follow verbal cues better, while some are better with visual ones, so doing both covers your bases. ''Don't'' use your pointer when there's only one thing on a slide, or when you refer to multiple things as a single group; few things are more distracting than a laser pointer whizzing around needlessly. Note that '''a mouse pointer on the screen is not sufficient'''; it doesn't stand out enough against your slides and is hard to see.		* '''Use a pointer (with discretion)'''. Make sure you have a laser pointer or something equivalent (stick, telescoping pointer, finger that can reach the projection screen). When there are multiple things on a slide and you refer to them separately, indicate them both verbally and visually as you refer to them. Some people follow verbal cues better, while some are better with visual ones, so doing both covers your bases. ''Don't'' use your pointer when there's only one thing on a slide, or when you refer to multiple things as a single group; few things are more distracting than a laser pointer whizzing around needlessly. Note that '''a mouse pointer on the screen is not sufficient'''; it doesn't stand out enough against your slides and is hard to see. If using your finger, don't just point at the screen, actually tap the place you want to indicate.
	* '''Check that your audience is following your talk'''. This is especially important when you have a mixed audience and a technically-difficult talk. You should have built some checkpoints into your talk; when you reach each one, ask the audience if they have any questions. If there's a specific point you need them to understand, ask them about it specifically. If they don't seem to understand, review the point and plan to go more quickly through some later section of the talk to make up the extra time.		* '''Check that your audience is following your talk'''. This is especially important when you have a mixed audience and a technically-difficult talk. You should have built some checkpoints into your talk; when you reach each one, ask the audience if they have any questions. If there's a specific point you need them to understand, ask them about it specifically. If they don't seem to understand, review the point and plan to go more quickly through some later section of the talk to make up the extra time.
	* '''Finish on time'''. Most people find it disrespectful if a talk runs over its scheduled time limit; they have other stuff to do and don't want to choose between that and seeing your full talk (which includes Q&A afterward). It is entirely the presenter's responsibility to manage the talk in such a way that it will end on time (which is ten or fifteen minutes before the end of the meeting time, to allow for Q&A). If questions in the middle of your talk run long, that means that you have to adapt by speeding up or cutting out later sections of your talk. Talks usually start late and get interrupted a lot. It is your responsibility to plan for this. A thesis proposal, for example, is supposed to last an hour: plan for 35--40 minutes of uninterrupted talking time, knowing that you will start late, get interrupted, and have questions at the end.		* '''Finish on time'''. Most people find it disrespectful if a talk runs over its scheduled time limit; they have other stuff to do and don't want to choose between that and seeing your full talk (which includes Q&A afterward). It is entirely the presenter's responsibility to manage the talk in such a way that it will end on time (which is ten or fifteen minutes before the end of the meeting time, to allow for Q&A). If questions in the middle of your talk run long, that means that you have to adapt by speeding up or cutting out later sections of your talk. Talks usually start late and get interrupted a lot. It is your responsibility to plan for this. A thesis proposal, for example, is supposed to last an hour: plan for 35--40 minutes of uninterrupted talking time, knowing that you will start late, get interrupted, and have questions at the end.

Jadrian Miles: /* Presentation Style and Audience Interaction */ use a pointer

2012-09-23T22:42:00Z

Presentation Style and Audience Interaction: use a pointer

← Older revision		Revision as of 22:42, 23 September 2012
Line 43:		Line 43:
	* '''Ask Skyped-in audience members to mute themselves'''. People listening on their laptops often make a lot of noise without realizing it, and this can be incredibly distracting amplified over the speakers during your talk. I've seen this fuck up several defenses. The person can un-mute themselves if they need to ask a question.		* '''Ask Skyped-in audience members to mute themselves'''. People listening on their laptops often make a lot of noise without realizing it, and this can be incredibly distracting amplified over the speakers during your talk. I've seen this fuck up several defenses. The person can un-mute themselves if they need to ask a question.
	* '''Pace yourself'''. Pause at the end of each section or after each significant point to implicitly or explicitly wait for questions. Count off to yourself to make sure you don't rush through this pause; subjective "presenter time" and objective "audience time" go at different rates!		* '''Pace yourself'''. Pause at the end of each section or after each significant point to implicitly or explicitly wait for questions. Count off to yourself to make sure you don't rush through this pause; subjective "presenter time" and objective "audience time" go at different rates!
			* '''Use a pointer (with discretion)'''. Make sure you have a laser pointer or something equivalent (stick, telescoping pointer, finger that can reach the projection screen). When there are multiple things on a slide and you refer to them separately, indicate them both verbally and visually as you refer to them. Some people follow verbal cues better, while some are better with visual ones, so doing both covers your bases. ''Don't'' use your pointer when there's only one thing on a slide, or when you refer to multiple things as a single group; few things are more distracting than a laser pointer whizzing around needlessly. Note that '''a mouse pointer on the screen is not sufficient'''; it doesn't stand out enough against your slides and is hard to see.
	* '''Check that your audience is following your talk'''. This is especially important when you have a mixed audience and a technically-difficult talk. You should have built some checkpoints into your talk; when you reach each one, ask the audience if they have any questions. If there's a specific point you need them to understand, ask them about it specifically. If they don't seem to understand, review the point and plan to go more quickly through some later section of the talk to make up the extra time.		* '''Check that your audience is following your talk'''. This is especially important when you have a mixed audience and a technically-difficult talk. You should have built some checkpoints into your talk; when you reach each one, ask the audience if they have any questions. If there's a specific point you need them to understand, ask them about it specifically. If they don't seem to understand, review the point and plan to go more quickly through some later section of the talk to make up the extra time.
	* '''Finish on time'''. Most people find it disrespectful if a talk runs over its scheduled time limit; they have other stuff to do and don't want to choose between that and seeing your full talk (which includes Q&A afterward). It is entirely the presenter's responsibility to manage the talk in such a way that it will end on time (which is ten or fifteen minutes before the end of the meeting time, to allow for Q&A). If questions in the middle of your talk run long, that means that you have to adapt by speeding up or cutting out later sections of your talk. Talks usually start late and get interrupted a lot. It is your responsibility to plan for this. A thesis proposal, for example, is supposed to last an hour: plan for 35--40 minutes of uninterrupted talking time, knowing that you will start late, get interrupted, and have questions at the end.		* '''Finish on time'''. Most people find it disrespectful if a talk runs over its scheduled time limit; they have other stuff to do and don't want to choose between that and seeing your full talk (which includes Q&A afterward). It is entirely the presenter's responsibility to manage the talk in such a way that it will end on time (which is ten or fifteen minutes before the end of the meeting time, to allow for Q&A). If questions in the middle of your talk run long, that means that you have to adapt by speeding up or cutting out later sections of your talk. Talks usually start late and get interrupted a lot. It is your responsibility to plan for this. A thesis proposal, for example, is supposed to last an hour: plan for 35--40 minutes of uninterrupted talking time, knowing that you will start late, get interrupted, and have questions at the end.

Jadrian Miles: Added stuff about checkpoints; rearranged sections.

2012-06-27T21:17:25Z

Added stuff about checkpoints; rearranged sections.

Show changes

Jadrian Miles: /* Talk Structure and Content */ be explicit about goals

2012-04-13T20:46:41Z

Talk Structure and Content: be explicit about goals

← Older revision		Revision as of 20:46, 13 April 2012
Line 8:		Line 8:
	* '''Know what your audience is''' and tailor your talk to this audience. Different audiences expect different talk structures, expect emphasis on different points, make different assumptions, know different background, etc. When building or editing your talk, critically ask yourself: "does my audience ''understand'' this point?" "Does my audience ''care'' about this point?" Leave out details that your audience doesn't care about (as they might serve only to confuse, distract, or take time away in your talk). Make sure to include details that your audience does care about.		* '''Know what your audience is''' and tailor your talk to this audience. Different audiences expect different talk structures, expect emphasis on different points, make different assumptions, know different background, etc. When building or editing your talk, critically ask yourself: "does my audience ''understand'' this point?" "Does my audience ''care'' about this point?" Leave out details that your audience doesn't care about (as they might serve only to confuse, distract, or take time away in your talk). Make sure to include details that your audience does care about.
	** ''Pro tip'': your audience for a proposal or defense is the ''faculty''. Each audience member therefore: has deep knowledge about a particular computer science subfield not necessarily related to yours, has a general knowledge of computer science, thinks about problems from a technical/algorithmic/data-oriented perspective, and is probably pretty geeky and detail-oriented. They will ask deep, probing, and potentially picky questions. Organize your talk to minimize confusion for this audience, and avoid irrelevant details that members of the audience might latch onto.		** ''Pro tip'': your audience for a proposal or defense is the ''faculty''. Each audience member therefore: has deep knowledge about a particular computer science subfield not necessarily related to yours, has a general knowledge of computer science, thinks about problems from a technical/algorithmic/data-oriented perspective, and is probably pretty geeky and detail-oriented. They will ask deep, probing, and potentially picky questions. Organize your talk to minimize confusion for this audience, and avoid irrelevant details that members of the audience might latch onto.
			** ''Bonus pro tip'': think very explicitly about '''your goals for the talk'''. What do you want to convey to the audience? In most high-stakes talks, it's not just some fact that you worked out through your research. Other goals might include: "I want the audience to believe that I know what I'm doing." "I want my committee to let me graduate." Write these goals down and ask yourself whether the things you do and talk about in your talk serve them.
	* '''Don't give the same talk to two different audiences'''. The point of a talk is to convey an idea to an audience. Each different audience has a different way of receiving ideas. This means that if you give a talk to two different audiences, it should not be the same talk, even if (to your mind) it's on the same subject.		* '''Don't give the same talk to two different audiences'''. The point of a talk is to convey an idea to an audience. Each different audience has a different way of receiving ideas. This means that if you give a talk to two different audiences, it should not be the same talk, even if (to your mind) it's on the same subject.
	* '''Understand the heterogeneity of your audience'''. No matter how uniform an audience might seem to be, it still contains different sub-groups. For example, for a thesis proposal presentation, your audience is composed of computer scientists, but it includes people from disciplines as diverse as natural language processing, computation theory, computational biology, and computer vision. For a presentation at an interdisciplinary conference (Vis or ISMRM, for example), your audience includes people from computer science as well as one or more application areas, and each of these communities has sub-communities (researchers vs. clinicians vs. engineers, for example).		* '''Understand the heterogeneity of your audience'''. No matter how uniform an audience might seem to be, it still contains different sub-groups. For example, for a thesis proposal presentation, your audience is composed of computer scientists, but it includes people from disciplines as diverse as natural language processing, computation theory, computational biology, and computer vision. For a presentation at an interdisciplinary conference (Vis or ISMRM, for example), your audience includes people from computer science as well as one or more application areas, and each of these communities has sub-communities (researchers vs. clinicians vs. engineers, for example).
Line 21:		Line 22:
	* '''Emphasize contributions, not design process'''. When working on a research agenda that includes multiple contributions, you may conceive of it as a sequence of experiments that you learn things from, where each experiment develops into or informs the development of the next. It's intuitive to explain your research in this way, to show it as a sequence of intellectual developments, but presenting it in this way to an audience is a mistake. If you show in a figure how one experiment leads to another intellectually, your audience will likely interpret this to mean that there is a data flow from the first process to the second, which may not be the case. Instead, present each research item as a separate entity and discuss intellectual connections between them as a secondary point.		* '''Emphasize contributions, not design process'''. When working on a research agenda that includes multiple contributions, you may conceive of it as a sequence of experiments that you learn things from, where each experiment develops into or informs the development of the next. It's intuitive to explain your research in this way, to show it as a sequence of intellectual developments, but presenting it in this way to an audience is a mistake. If you show in a figure how one experiment leads to another intellectually, your audience will likely interpret this to mean that there is a data flow from the first process to the second, which may not be the case. Instead, present each research item as a separate entity and discuss intellectual connections between them as a secondary point.
	* '''Number your slides'''. This way, audience members who want to ask questions about specific slides can note the slide number, to make the Q&A go more smoothly.		* '''Number your slides'''. This way, audience members who want to ask questions about specific slides can note the slide number, to make the Q&A go more smoothly.


	=== Preparation for Your Talk ===		=== Preparation for Your Talk ===

Jadrian Miles: /* Presentation Style and Audience Interaction */

2012-04-13T20:43:11Z

Presentation Style and Audience Interaction

← Older revision		Revision as of 20:43, 13 April 2012
Line 35:		Line 35:
	* '''Pace yourself'''. Pause at the end of each section or after each significant point to implicitly or explicitly wait for questions. Count off to yourself to make sure you don't rush through this pause; subjective "presenter time" and objective "audience time" go at different rates!		* '''Pace yourself'''. Pause at the end of each section or after each significant point to implicitly or explicitly wait for questions. Count off to yourself to make sure you don't rush through this pause; subjective "presenter time" and objective "audience time" go at different rates!
	* '''Finish on time'''. Most people find it disrespectful if a talk runs over its scheduled time limit; they have other stuff to do and don't want to choose between that and seeing your full talk (which includes Q&A afterward). It is entirely the presenter's responsibility to manage the talk in such a way that it will end on time (which is ten or fifteen minutes before the end of the meeting time, to allow for Q&A). If questions in the middle of your talk run long, that means that you have to adapt by speeding up or cutting out later sections of your talk. Talks usually start late and get interrupted a lot. It is your responsibility to plan for this. A thesis proposal, for example, is supposed to last an hour: plan for 35--40 minutes of uninterrupted talking time, knowing that you will start late, get interrupted, and have questions at the end.		* '''Finish on time'''. Most people find it disrespectful if a talk runs over its scheduled time limit; they have other stuff to do and don't want to choose between that and seeing your full talk (which includes Q&A afterward). It is entirely the presenter's responsibility to manage the talk in such a way that it will end on time (which is ten or fifteen minutes before the end of the meeting time, to allow for Q&A). If questions in the middle of your talk run long, that means that you have to adapt by speeding up or cutting out later sections of your talk. Talks usually start late and get interrupted a lot. It is your responsibility to plan for this. A thesis proposal, for example, is supposed to last an hour: plan for 35--40 minutes of uninterrupted talking time, knowing that you will start late, get interrupted, and have questions at the end.
			* '''Avoid excessive marketing'''. Brooks: "Present to inform, not to impress; if you inform, you will impress." While it is important to avoid the question "who cares about this topic/problem?", it is also important to have your audience understand enough of the technical parts that they can draw on their collective wisdom to give advice.
	* '''Show respect for audience comments'''. Note that this is different from ''having'' respect; you may have respect but still not convey it to your audience, which will alienate them from you. Here are some specific recommendations for how to convey respect:		* '''Show respect for audience comments'''. Note that this is different from ''having'' respect; you may have respect but still not convey it to your audience, which will alienate them from you. Here are some specific recommendations for how to convey respect:
	** '''Pause after every question''' so it's clear you're thinking.		** '''Pause after every question''' so it's clear you're thinking.
Line 46:		Line 47:
	** '''Respect ownership of ideas'''. When an audience member makes a suggestion during your talk, they may feel protective of their idea; it's a gift they're giving you, but it's important that you acknowledge that it comes from them. Some presenters try to engage with audience suggestions by connecting them to the work they've done, but this may be counterproductive. In the eyes of the person making the suggestion, this may seem like you're trying to take their idea away from them and claim it as your own, or that you don't understand the significance of what they're saying. Your first priority should be to '''acknowledge the wisdom of your audience'''.		** '''Respect ownership of ideas'''. When an audience member makes a suggestion during your talk, they may feel protective of their idea; it's a gift they're giving you, but it's important that you acknowledge that it comes from them. Some presenters try to engage with audience suggestions by connecting them to the work they've done, but this may be counterproductive. In the eyes of the person making the suggestion, this may seem like you're trying to take their idea away from them and claim it as your own, or that you don't understand the significance of what they're saying. Your first priority should be to '''acknowledge the wisdom of your audience'''.
	** Generally speaking, keep in mind: '''the audience is always right'''.		** Generally speaking, keep in mind: '''the audience is always right'''.
	* '''Avoid excessive marketing'''. Brooks: "Present to inform, not to impress; if you inform, you will impress." While it is important to avoid the question "who cares about this topic/problem?", it is also important to have your audience understand enough of the technical parts that they can draw on their collective wisdom to give advice.


	[[Category:HOWTO]][[Category:Dissemination]]		[[Category:HOWTO]][[Category:Dissemination]]

Jadrian Miles at 20:42, 13 April 2012

2012-04-13T20:42:24Z

← Older revision		Revision as of 20:42, 13 April 2012
Line 21:		Line 21:
	* '''Emphasize contributions, not design process'''. When working on a research agenda that includes multiple contributions, you may conceive of it as a sequence of experiments that you learn things from, where each experiment develops into or informs the development of the next. It's intuitive to explain your research in this way, to show it as a sequence of intellectual developments, but presenting it in this way to an audience is a mistake. If you show in a figure how one experiment leads to another intellectually, your audience will likely interpret this to mean that there is a data flow from the first process to the second, which may not be the case. Instead, present each research item as a separate entity and discuss intellectual connections between them as a secondary point.		* '''Emphasize contributions, not design process'''. When working on a research agenda that includes multiple contributions, you may conceive of it as a sequence of experiments that you learn things from, where each experiment develops into or informs the development of the next. It's intuitive to explain your research in this way, to show it as a sequence of intellectual developments, but presenting it in this way to an audience is a mistake. If you show in a figure how one experiment leads to another intellectually, your audience will likely interpret this to mean that there is a data flow from the first process to the second, which may not be the case. Instead, present each research item as a separate entity and discuss intellectual connections between them as a secondary point.
	* '''Number your slides'''. This way, audience members who want to ask questions about specific slides can note the slide number, to make the Q&A go more smoothly.		* '''Number your slides'''. This way, audience members who want to ask questions about specific slides can note the slide number, to make the Q&A go more smoothly.


	=== Preparation for Your Talk ===		=== Preparation for Your Talk ===

Jadrian Miles: Tips about Skype

2012-04-13T20:41:53Z

Tips about Skype

Jadrian Miles: /* Talk Structure and Content */ figures vs. illustrations

2011-11-29T22:40:34Z

Talk Structure and Content: figures vs. illustrations

← Older revision		Revision as of 22:40, 29 November 2011
Line 11:		Line 11:
	* '''Understand the heterogeneity of your audience'''. No matter how uniform an audience might seem to be, it still contains different sub-groups. For example, for a thesis proposal presentation, your audience is composed of computer scientists, but it includes people from disciplines as diverse as natural language processing, computation theory, computational biology, and computer vision. For a presentation at an interdisciplinary conference (Vis or ISMRM, for example), your audience includes people from computer science as well as one or more application areas, and each of these communities has sub-communities (researchers vs. clinicians vs. engineers, for example).		* '''Understand the heterogeneity of your audience'''. No matter how uniform an audience might seem to be, it still contains different sub-groups. For example, for a thesis proposal presentation, your audience is composed of computer scientists, but it includes people from disciplines as diverse as natural language processing, computation theory, computational biology, and computer vision. For a presentation at an interdisciplinary conference (Vis or ISMRM, for example), your audience includes people from computer science as well as one or more application areas, and each of these communities has sub-communities (researchers vs. clinicians vs. engineers, for example).
	* '''Be careful about terminology''' that means different things to different communities. Either be very explicit about the definitions of your terms, use unambiguous plain-language terms, or just drop them entirely and figure out a different way to present your point. An example list of problematic terms includes "greedy", "Monte Carlo", "solve", "optimal", "energy", "experiment", "model", "fit". If you're certain of the composition of your audience, some jargon of this sort may be acceptable, but remember that audiences are often more heterogeneous than you might think.		* '''Be careful about terminology''' that means different things to different communities. Either be very explicit about the definitions of your terms, use unambiguous plain-language terms, or just drop them entirely and figure out a different way to present your point. An example list of problematic terms includes "greedy", "Monte Carlo", "solve", "optimal", "energy", "experiment", "model", "fit". If you're certain of the composition of your audience, some jargon of this sort may be acceptable, but remember that audiences are often more heterogeneous than you might think.
			* '''Clearly distinguish "figures" from "illustrations"'''. A figure is a picture that relates in a concrete and preferably quantifiable way to the work or point that you're presenting. An illustration is a generic picture that is evocative of the concept you're discussing. Trouble arises when you use a picture that could be mistaken for a figure (for example, a bar chart) as an illustration. You may mean to present it as merely an example of a result that one ''might'' get, or a way that one ''might'' care to present a certain class of data, but if your audience identifies it as a figure instead, they will immediately start digging for details that will aid in its interpretation in terms of your work. This can almost fatally derail a talk. Try hard to reduce ambiguity by either removing irrelevant details from such illustrations (leave off axis labels on your bar chart, for example, and make it look as generic as possible) or by explicitly marking ambiguous illustrations for what they are.
	* '''Use consistent symbols''' between slides. If a particular glyph, color, or figure means something specific in one slide, make sure it means the same thing in others. If you're talking about the same subject in two different slides, re-use symbols to clarify the connection between them.		* '''Use consistent symbols''' between slides. If a particular glyph, color, or figure means something specific in one slide, make sure it means the same thing in others. If you're talking about the same subject in two different slides, re-use symbols to clarify the connection between them.
	* '''Don't overstate your case'''. Explicitly establish the assumptions built into your work and the scope of your hypotheses and conclusions. Think like a scientist or mathematician and be very conservative: unless you specify the scope of your statements, it may be assumed that they apply universally, which is almost always not the case.		* '''Don't overstate your case'''. Explicitly establish the assumptions built into your work and the scope of your hypotheses and conclusions. Think like a scientist or mathematician and be very conservative: unless you specify the scope of your statements, it may be assumed that they apply universally, which is almost always not the case.
Line 19:		Line 20:
	* '''Show concrete examples'''. Your audience will understand what you're doing better if they have a clear picture in their minds of the format of your data. Unless your audience is composed of people who have the same background as you, there will be some basic point that you have to explain before getting into the specifics of your work. If you work with medical images and you're talking to a non-medical audience, show an example image. If you work with visualizations and you're talking to a non-viz audience, show some canonical examples.		* '''Show concrete examples'''. Your audience will understand what you're doing better if they have a clear picture in their minds of the format of your data. Unless your audience is composed of people who have the same background as you, there will be some basic point that you have to explain before getting into the specifics of your work. If you work with medical images and you're talking to a non-medical audience, show an example image. If you work with visualizations and you're talking to a non-viz audience, show some canonical examples.
	* '''Emphasize contributions, not design process'''. When working on a research agenda that includes multiple contributions, you may conceive of it as a sequence of experiments that you learn things from, where each experiment develops into or informs the development of the next. It's intuitive to explain your research in this way, to show it as a sequence of intellectual developments, but presenting it in this way to an audience is a mistake. If you show in a figure how one experiment leads to another intellectually, your audience will likely interpret this to mean that there is a data flow from the first process to the second, which may not be the case. Instead, present each research item as a separate entity and discuss intellectual connections between them as a secondary point.		* '''Emphasize contributions, not design process'''. When working on a research agenda that includes multiple contributions, you may conceive of it as a sequence of experiments that you learn things from, where each experiment develops into or informs the development of the next. It's intuitive to explain your research in this way, to show it as a sequence of intellectual developments, but presenting it in this way to an audience is a mistake. If you show in a figure how one experiment leads to another intellectually, your audience will likely interpret this to mean that there is a data flow from the first process to the second, which may not be the case. Instead, present each research item as a separate entity and discuss intellectual connections between them as a secondary point.


	=== Preparation for Your Talk ===		=== Preparation for Your Talk ===

Jadrian Miles: Added specific advice about who the audience is for a defense

2011-03-01T20:47:09Z

Added specific advice about who the audience is for a defense

← Older revision		Revision as of 20:47, 1 March 2011
Line 7:		Line 7:

	* '''Know what your audience is''' and tailor your talk to this audience. Different audiences expect different talk structures, expect emphasis on different points, make different assumptions, know different background, etc. When building or editing your talk, critically ask yourself: "does my audience ''understand'' this point?" "Does my audience ''care'' about this point?" Leave out details that your audience doesn't care about (as they might serve only to confuse, distract, or take time away in your talk). Make sure to include details that your audience does care about.		* '''Know what your audience is''' and tailor your talk to this audience. Different audiences expect different talk structures, expect emphasis on different points, make different assumptions, know different background, etc. When building or editing your talk, critically ask yourself: "does my audience ''understand'' this point?" "Does my audience ''care'' about this point?" Leave out details that your audience doesn't care about (as they might serve only to confuse, distract, or take time away in your talk). Make sure to include details that your audience does care about.
			** ''Pro tip'': your audience for a proposal or defense is the ''faculty''. Each audience member therefore: has deep knowledge about a particular computer science subfield not necessarily related to yours, has a general knowledge of computer science, thinks about problems from a technical/algorithmic/data-oriented perspective, and is probably pretty geeky and detail-oriented. They will ask deep, probing, and potentially picky questions. Organize your talk to minimize confusion for this audience, and avoid irrelevant details that members of the audience might latch onto.
	* '''Don't give the same talk to two different audiences'''. The point of a talk is to convey an idea to an audience. Each different audience has a different way of receiving ideas. This means that if you give a talk to two different audiences, it should not be the same talk, even if (to your mind) it's on the same subject.		* '''Don't give the same talk to two different audiences'''. The point of a talk is to convey an idea to an audience. Each different audience has a different way of receiving ideas. This means that if you give a talk to two different audiences, it should not be the same talk, even if (to your mind) it's on the same subject.
	* '''Understand the heterogeneity of your audience'''. No matter how uniform an audience might seem to be, it still contains different sub-groups. For example, for a thesis proposal presentation, your audience is composed of computer scientists, but it includes people from disciplines as diverse as natural language processing, computation theory, computational biology, and computer vision. For a presentation at an interdisciplinary conference (Vis or ISMRM, for example), your audience includes people from computer science as well as one or more application areas, and each of these communities has sub-communities (researchers vs. clinicians vs. engineers, for example).		* '''Understand the heterogeneity of your audience'''. No matter how uniform an audience might seem to be, it still contains different sub-groups. For example, for a thesis proposal presentation, your audience is composed of computer scientists, but it includes people from disciplines as diverse as natural language processing, computation theory, computational biology, and computer vision. For a presentation at an interdisciplinary conference (Vis or ISMRM, for example), your audience includes people from computer science as well as one or more application areas, and each of these communities has sub-communities (researchers vs. clinicians vs. engineers, for example).
Line 25:		Line 26:
	* '''Practice in the same room''' where you will give your talk. Do it a couple times, and do it earlier in the day of your talk if possible.		* '''Practice in the same room''' where you will give your talk. Do it a couple times, and do it earlier in the day of your talk if possible.
	* '''Arrive early to set up''', an hour in advance if possible. Make sure your presentation is working right, that you've got all your materials on hand, that the projector works, etc.		* '''Arrive early to set up''', an hour in advance if possible. Make sure your presentation is working right, that you've got all your materials on hand, that the projector works, etc.


	=== Presentation Style and Audience Interaction ===		=== Presentation Style and Audience Interaction ===

← Older revision		Revision as of 20:41, 13 April 2012
Line 20:		Line 20:
	* '''Show concrete examples'''. Your audience will understand what you're doing better if they have a clear picture in their minds of the format of your data. Unless your audience is composed of people who have the same background as you, there will be some basic point that you have to explain before getting into the specifics of your work. If you work with medical images and you're talking to a non-medical audience, show an example image. If you work with visualizations and you're talking to a non-viz audience, show some canonical examples.		* '''Show concrete examples'''. Your audience will understand what you're doing better if they have a clear picture in their minds of the format of your data. Unless your audience is composed of people who have the same background as you, there will be some basic point that you have to explain before getting into the specifics of your work. If you work with medical images and you're talking to a non-medical audience, show an example image. If you work with visualizations and you're talking to a non-viz audience, show some canonical examples.
	* '''Emphasize contributions, not design process'''. When working on a research agenda that includes multiple contributions, you may conceive of it as a sequence of experiments that you learn things from, where each experiment develops into or informs the development of the next. It's intuitive to explain your research in this way, to show it as a sequence of intellectual developments, but presenting it in this way to an audience is a mistake. If you show in a figure how one experiment leads to another intellectually, your audience will likely interpret this to mean that there is a data flow from the first process to the second, which may not be the case. Instead, present each research item as a separate entity and discuss intellectual connections between them as a secondary point.		* '''Emphasize contributions, not design process'''. When working on a research agenda that includes multiple contributions, you may conceive of it as a sequence of experiments that you learn things from, where each experiment develops into or informs the development of the next. It's intuitive to explain your research in this way, to show it as a sequence of intellectual developments, but presenting it in this way to an audience is a mistake. If you show in a figure how one experiment leads to another intellectually, your audience will likely interpret this to mean that there is a data flow from the first process to the second, which may not be the case. Instead, present each research item as a separate entity and discuss intellectual connections between them as a secondary point.
			* '''Number your slides'''. This way, audience members who want to ask questions about specific slides can note the slide number, to make the Q&A go more smoothly.

	=== Preparation for Your Talk ===		=== Preparation for Your Talk ===
Line 25:		Line 26:
	* '''Practice tricky sections'''. Memorize, if necessary, complicated terminology, slides with a lot of text, and complicated sequences of graphical transitions. Looking at your slides rather than your audience or stumbling over your words makes you look unprofessional.		* '''Practice tricky sections'''. Memorize, if necessary, complicated terminology, slides with a lot of text, and complicated sequences of graphical transitions. Looking at your slides rather than your audience or stumbling over your words makes you look unprofessional.
	* '''Practice in the same room''' where you will give your talk. Do it a couple times, and do it earlier in the day of your talk if possible.		* '''Practice in the same room''' where you will give your talk. Do it a couple times, and do it earlier in the day of your talk if possible.
			* If you're using Skype, '''get a lapel mic'''. The mic on your laptop may not pick up your voice well enough from across the room.
	* '''Arrive early to set up''', an hour in advance if possible. Make sure your presentation is working right, that you've got all your materials on hand, that the projector works, etc.		* '''Arrive early to set up''', an hour in advance if possible. Make sure your presentation is working right, that you've got all your materials on hand, that the projector works, etc.


	=== Presentation Style and Audience Interaction ===		=== Presentation Style and Audience Interaction ===
	* '''~~Number your slides~~'''. ~~This way~~, ~~audience members who want to ask questions about specific slides~~ can ~~note~~ the ~~slide number,~~ to ~~make the Q&A go more smoothly~~.		* '''Ask Skyped-in audience members to mute themselves'''. People listening on their laptops often make a lot of noise without realizing it, and this can be incredibly distracting amplified over the speakers during your talk. I've seen this fuck up several defenses. The person can un-mute themselves if they need to ask a question.
	* '''Pace yourself'''. Pause at the end of each section or after each significant point to implicitly or explicitly wait for questions. Count off to yourself to make sure you don't rush through this pause; subjective "presenter time" and objective "audience time" go at different rates!		* '''Pace yourself'''. Pause at the end of each section or after each significant point to implicitly or explicitly wait for questions. Count off to yourself to make sure you don't rush through this pause; subjective "presenter time" and objective "audience time" go at different rates!
	* '''Finish on time'''. Most people find it disrespectful if a talk runs over its scheduled time limit; they have other stuff to do and don't want to choose between that and seeing your full talk (which includes Q&A afterward). It is entirely the presenter's responsibility to manage the talk in such a way that it will end on time (which is ten or fifteen minutes before the end of the meeting time, to allow for Q&A). If questions in the middle of your talk run long, that means that you have to adapt by speeding up or cutting out later sections of your talk. Talks usually start late and get interrupted a lot. It is your responsibility to plan for this. A thesis proposal, for example, is supposed to last an hour: plan for 35--40 minutes of uninterrupted talking time, knowing that you will start late, get interrupted, and have questions at the end.		* '''Finish on time'''. Most people find it disrespectful if a talk runs over its scheduled time limit; they have other stuff to do and don't want to choose between that and seeing your full talk (which includes Q&A afterward). It is entirely the presenter's responsibility to manage the talk in such a way that it will end on time (which is ten or fifteen minutes before the end of the meeting time, to allow for Q&A). If questions in the middle of your talk run long, that means that you have to adapt by speeding up or cutting out later sections of your talk. Talks usually start late and get interrupted a lot. It is your responsibility to plan for this. A thesis proposal, for example, is supposed to last an hour: plan for 35--40 minutes of uninterrupted talking time, knowing that you will start late, get interrupted, and have questions at the end.