commit 3eb931ae567b0403924c82ec4b4918a2509a0562 Author: Mark Claypool <claypool@cs.wpi.edu> Date: Tue Apr 11 14:29:09 2023 -0400 Updates diff --git a/presentation.md b/presentation.md index b95d29b..50e884a 100644 --- a/presentation.md +++ b/presentation.md @@ -31,9 +31,10 @@ Don't focus on your slides too long, other than to glance at them or point out some part. Instead look at the audience. + **Tip**: If looking at the audience makes you nervous, try looking -just over the tops of their heads. Being nervous is ok and normal. -Remember, the audience is on your side. They *want* you to succeed in -your talk! +just over the tops of their heads. + ++ **Tip**: Being nervous is ok and normal. Remember, the audience is +on your side. They *want* you to succeed in your talk! Don't read your slides. commit 8b86429db9d1bbfa358290fae02af9c11ff8b8f2 Author: Mark Claypool <claypool@cs.wpi.edu> Date: Tue Apr 11 14:26:56 2023 -0400 Updates diff --git a/presentation.md b/presentation.md index aa211de..b95d29b 100644 --- a/presentation.md +++ b/presentation.md @@ -1,6 +1,6 @@ --- pagetitle: Presenting a Project -version: 1.4 +version: 1.5 --- # Presenting a Project @@ -25,13 +25,15 @@ Working on them simultaneously can be synergistic. Make sure to have a conclusion. This revisits the problem and methodology briefly then states what you built/did/found concretely. You don't conclude "there is more to be done" nor conclude "our code -has bugs". You state unapologetically, firmly what you did. +has bugs". You state unapologetically, firmly, what you did. Don't focus on your slides too long, other than to glance at them or point out some part. Instead look at the audience. -+ **Tip**: If looking at the audience makes you nervous, try looking just -over the tops of their heads. Being nervous is ok and normal. ++ **Tip**: If looking at the audience makes you nervous, try looking +just over the tops of their heads. Being nervous is ok and normal. +Remember, the audience is on your side. They *want* you to succeed in +your talk! Don't read your slides. @@ -55,18 +57,18 @@ If you have complicated graphs/figures, make sure you take the time to *explain them*. First, explain axes and trendlines. Then, tell the audience what messages they should see in the figure. ++ **Tip**: It can be helpful to have the message text in small font +someplace on the slide to remind yourself and audience what it is. + Acknowledge those that helped/mentored you - this includes any project sponsors but also fellow students or WPI faculty. Be generous with giving credit - this is good professional advice to apply the rest of your career. -+ **Tip**: It can be helpful to have the message text in small font -someplace on the slide to remind yourself and audience what it is. - If you have a live demo planned, have a backup in case it fails. -+ **Tip**: Good backup plans include: a) pre-recorded video, b) or screen -shots you can walk through. ++ **Tip**: Good backup plans include: a) pre-recorded video, and b) or +screen shots you can walk through. Don't apologize for anything or say other defacing comments (e.g., "I'm not prepared ..."). This will subconsciously make the audience commit 19b0e3beb78e17cc3b58695be99da1d23e2400c2 Author: Mark Claypool <claypool@cs.wpi.edu> Date: Wed Dec 14 10:56:30 2022 -0500 Updates diff --git a/presentation.md b/presentation.md index 371aeda..aa211de 100644 --- a/presentation.md +++ b/presentation.md @@ -19,7 +19,7 @@ Your talk should start broad, like your report introduction, but narrow to a problem statement early. Then, related work, methodology, results and conclusions, possibly a demo in the middle. -+ *Tip*: The structure often parallels your report and vice-versa. ++ **Tip**: The structure often parallels your report and vice-versa. Working on them simultaneously can be synergistic. Make sure to have a conclusion. This revisits the problem and @@ -30,12 +30,12 @@ has bugs". You state unapologetically, firmly what you did. Don't focus on your slides too long, other than to glance at them or point out some part. Instead look at the audience. -+ *Tip*: If looking at the audience makes you nervous, try looking just ++ **Tip**: If looking at the audience makes you nervous, try looking just over the tops of their heads. Being nervous is ok and normal. Don't read your slides. -+ *Tip*: If you want, have notecards that you refer to (but don't ++ **Tip**: If you want, have notecards that you refer to (but don't read). Remember, you've been working on your project for 2+ months, but @@ -60,12 +60,12 @@ sponsors but also fellow students or WPI faculty. Be generous with giving credit - this is good professional advice to apply the rest of your career. -+ *Tip*: It can be helpful to have the message text in small font ++ **Tip**: It can be helpful to have the message text in small font someplace on the slide to remind yourself and audience what it is. If you have a live demo planned, have a backup in case it fails. -+ *Tip*: Good backup plans include: a) pre-recorded video, b) or screen ++ **Tip**: Good backup plans include: a) pre-recorded video, b) or screen shots you can walk through. Don't apologize for anything or say other defacing comments (e.g., commit 5e3450c889472974737bd92a537c8dd076bb286b Author: Mark Claypool <claypool@cs.wpi.edu> Date: Wed Dec 14 09:56:13 2022 -0500 Updates diff --git a/presentation.md b/presentation.md index 9750380..371aeda 100644 --- a/presentation.md +++ b/presentation.md @@ -19,7 +19,7 @@ Your talk should start broad, like your report introduction, but narrow to a problem statement early. Then, related work, methodology, results and conclusions, possibly a demo in the middle. -*Tip*:: The structure often parallels your report and vice-versa. ++ *Tip*: The structure often parallels your report and vice-versa. Working on them simultaneously can be synergistic. Make sure to have a conclusion. This revisits the problem and @@ -30,12 +30,12 @@ has bugs". You state unapologetically, firmly what you did. Don't focus on your slides too long, other than to glance at them or point out some part. Instead look at the audience. -*Tip*: If looking at the audience makes you nervous, try looking just ++ *Tip*: If looking at the audience makes you nervous, try looking just over the tops of their heads. Being nervous is ok and normal. Don't read your slides. -*Tip*: If you want, have notecards that you refer to (but don't ++ *Tip*: If you want, have notecards that you refer to (but don't read). Remember, you've been working on your project for 2+ months, but @@ -60,12 +60,12 @@ sponsors but also fellow students or WPI faculty. Be generous with giving credit - this is good professional advice to apply the rest of your career. -*Tip*: It can be helpful to have the message text in small font ++ *Tip*: It can be helpful to have the message text in small font someplace on the slide to remind yourself and audience what it is. If you have a live demo planned, have a backup in case it fails. -*Tip*: Good backup plans include: a) pre-recorded video, b) or screen ++ *Tip*: Good backup plans include: a) pre-recorded video, b) or screen shots you can walk through. Don't apologize for anything or say other defacing comments (e.g., commit 54d5e48657cd6c828e9303c0ba551998197dd62c Author: Mark Claypool <claypool@cs.wpi.edu> Date: Wed Dec 14 09:52:03 2022 -0500 Updates diff --git a/presentation.md b/presentation.md index 03ec548..9750380 100644 --- a/presentation.md +++ b/presentation.md @@ -1,73 +1,78 @@ --- pagetitle: Presenting a Project -version: 1.3 +version: 1.4 --- # Presenting a Project -+ Assuming you have a 15 minute block, plan on 12 minutes for your - presentation. The remaining time will be for questions/setup. - -+ Think of the visuals you will make (i.e., slides). Roughly, On - average, slides take about 1.5 minutes or so per slide, so you'll - have only about 8 slides! - -+ Everyone in the group talks. Work out the transitions for who says - what. - -+ Your talk should start broad, like your report introduction, but - narrow to a problem statement early. Then, related work, - methodology, results and conclusions, possibly a demo in the middle. - - *Tip*:: The structure often parallels your report and vice-versa. - Working on them simultaneously can be synergistic. - -+ Make sure to have a conclusion. This revisits the problem and - methodology briefly then states what you built/did/found concretely. - You don't conclude "there is more to be done" nor conclude "our code - has bugs". You state unapologetically, firmly what you did. - -+ Don't focus on your slides too long, other than to glance at them or - point out some part. Instead look at the audience. - - *Tip*: If looking at the audience makes you nervous, try looking - just over the tops of their heads. Being nervous is ok and normal. - -+ Don't read your slides. - - *Tip*: If you want, have notecards that you refer to (but don't - read). - -+ Remember, you've been working on your project for 2+ months, but - your audience is just learning about it today. Take the time to - introduce difficult/new content (i.e., don't just jump in). - -+ Make sure slide fonts are not too small. Everyone will be further - away from your slides than you. Make use of white space on the - slides to increase font sizes as much as possible. - -+ Don't have paragraphs of text or even sentences. You don't want the - audience reading your slides. The slides are mostly so they can - follow along with your talk, but listening to you for content and - not reading. - -+ If you have complicated graphs/figures, make sure you take the time - to *explain them*. First, explain axes and trendlines. Then, tell - the audience what messages they should see in the figure. - - *Tip*: It can be helpful to have the message text in small font - someplace on the slide to remind yourself and audience what it is. - -+ If you have a live demo planned, have a backup in case it fails. - - *Tip*: Good backup plans include: a) pre-recorded video, b) or - screen shots you can walk through. - -+ Don't apologize for anything or say other defacing comments (e.g., - "I'm not prepared ..."). This will subconsciously make the audience - immediately downgrade your talk. Prepare as best you can (see next - bullet), then deliver it as if all is going according to plan. - -+ Practice, practice, practice! The way to give a good talk is to - rehearse. Since your talk is 15 minutes, you can do 4 complete runs - in as little as an hour. Do this! +Assuming you have a 15 minute block, plan on 12 minutes for your +presentation. The remaining time will be for questions/setup. + +Think of the visuals you will make (i.e., slides). Roughly, On +average, slides take about 1.5 minutes or so per slide, so you'll have +only about 8 slides! + +Everyone in the group talks. Work out the transitions for who says +what. + +Your talk should start broad, like your report introduction, but +narrow to a problem statement early. Then, related work, methodology, +results and conclusions, possibly a demo in the middle. + +*Tip*:: The structure often parallels your report and vice-versa. +Working on them simultaneously can be synergistic. + +Make sure to have a conclusion. This revisits the problem and +methodology briefly then states what you built/did/found concretely. +You don't conclude "there is more to be done" nor conclude "our code +has bugs". You state unapologetically, firmly what you did. + +Don't focus on your slides too long, other than to glance at them or +point out some part. Instead look at the audience. + +*Tip*: If looking at the audience makes you nervous, try looking just +over the tops of their heads. Being nervous is ok and normal. + +Don't read your slides. + +*Tip*: If you want, have notecards that you refer to (but don't +read). + +Remember, you've been working on your project for 2+ months, but +your audience is just learning about it today. Take the time to +introduce difficult/new content (i.e., don't just jump in). + +Make sure slide fonts are not too small. Everyone will be further +away from your slides than you. Make use of white space on the slides +to increase font sizes as much as possible. + +Don't have paragraphs of text or even sentences. You don't want the +audience reading your slides. The slides are mostly so they can +follow along with your talk, but listening to you for content and not +reading. + +If you have complicated graphs/figures, make sure you take the time to +*explain them*. First, explain axes and trendlines. Then, tell the +audience what messages they should see in the figure. + +Acknowledge those that helped/mentored you - this includes any project +sponsors but also fellow students or WPI faculty. Be generous with +giving credit - this is good professional advice to apply the rest of +your career. + +*Tip*: It can be helpful to have the message text in small font +someplace on the slide to remind yourself and audience what it is. + +If you have a live demo planned, have a backup in case it fails. + +*Tip*: Good backup plans include: a) pre-recorded video, b) or screen +shots you can walk through. + +Don't apologize for anything or say other defacing comments (e.g., +"I'm not prepared ..."). This will subconsciously make the audience +immediately downgrade your talk. Prepare as best you can (see next +bullet), then deliver it as if all is going according to plan. + +Practice, practice, practice! The way to give a good talk is to +rehearse. Since your talk is 15 minutes, you can do 4 complete runs +in as little as an hour. Do this! commit a262d8201a5895c7251c935b937c58e2506228c5 Author: Mark Claypool <claypool@cs.wpi.edu> Date: Tue Aug 9 09:17:35 2022 -0400 Updates diff --git a/presentation.md b/presentation.md index 9739479..03ec548 100644 --- a/presentation.md +++ b/presentation.md @@ -1,5 +1,5 @@ --- -pagetitle: Presentating a Project +pagetitle: Presenting a Project version: 1.3 --- commit 0a3a035cc794a63af63c86c0c68decfdb2d808f2 Author: Mark Claypool <claypool@cs.wpi.edu> Date: Mon Aug 8 13:58:58 2022 -0400 Updates diff --git a/presentation.md b/presentation.md index 74dcad6..9739479 100644 --- a/presentation.md +++ b/presentation.md @@ -1,8 +1,11 @@ -# Project Presentation Guidelines +--- +pagetitle: Presentating a Project +version: 1.3 +--- -v1.2 +# Presenting a Project -+ You have a 15 minute block. Plan on 12 minutes for your ++ Assuming you have a 15 minute block, plan on 12 minutes for your presentation. The remaining time will be for questions/setup. + Think of the visuals you will make (i.e., slides). Roughly, On commit e5cfe6bf704f9f36d0c26fae9e94d6228e50907b Author: Mark Claypool <claypool@cs.wpi.edu> Date: Tue Feb 26 12:53:28 2019 -0500 Updates diff --git a/presentation.md b/presentation.md index dbf15bd..74dcad6 100644 --- a/presentation.md +++ b/presentation.md @@ -1,5 +1,6 @@ -# MQP Presentation Guidelines -v1.0 +# Project Presentation Guidelines + +v1.2 + You have a 15 minute block. Plan on 12 minutes for your presentation. The remaining time will be for questions/setup. @@ -17,6 +18,11 @@ v1.0 *Tip*:: The structure often parallels your report and vice-versa. Working on them simultaneously can be synergistic. + ++ Make sure to have a conclusion. This revisits the problem and + methodology briefly then states what you built/did/found concretely. + You don't conclude "there is more to be done" nor conclude "our code + has bugs". You state unapologetically, firmly what you did. + Don't focus on your slides too long, other than to glance at them or point out some part. Instead look at the audience. @@ -26,15 +32,16 @@ v1.0 + Don't read your slides. - *Tip*: If you want, have notecards that you refer. + *Tip*: If you want, have notecards that you refer to (but don't + read). + Remember, you've been working on your project for 2+ months, but your audience is just learning about it today. Take the time to introduce difficult/new content (i.e., don't just jump in). + Make sure slide fonts are not too small. Everyone will be further - away from your slides than you. Make use of white space on - the slides to increase font sizes as much as possible. + away from your slides than you. Make use of white space on the + slides to increase font sizes as much as possible. + Don't have paragraphs of text or even sentences. You don't want the audience reading your slides. The slides are mostly so they can @@ -42,8 +49,11 @@ v1.0 not reading. + If you have complicated graphs/figures, make sure you take the time - to *explain them*. Explain axes, trendlines. Tell the audience what - messages they should see in the figure. + to *explain them*. First, explain axes and trendlines. Then, tell + the audience what messages they should see in the figure. + + *Tip*: It can be helpful to have the message text in small font + someplace on the slide to remind yourself and audience what it is. + If you have a live demo planned, have a backup in case it fails. commit d6194bca0efc44d33555c06635f6eb77264b6487 Author: Mark Claypool <claypool@cs.wpi.edu> Date: Tue Feb 27 23:32:28 2018 -0500 Updated diff --git a/presentation.md b/presentation.md index e87f156..dbf15bd 100644 --- a/presentation.md +++ b/presentation.md @@ -50,6 +50,11 @@ v1.0 *Tip*: Good backup plans include: a) pre-recorded video, b) or screen shots you can walk through. ++ Don't apologize for anything or say other defacing comments (e.g., + "I'm not prepared ..."). This will subconsciously make the audience + immediately downgrade your talk. Prepare as best you can (see next + bullet), then deliver it as if all is going according to plan. + + Practice, practice, practice! The way to give a good talk is to rehearse. Since your talk is 15 minutes, you can do 4 complete runs in as little as an hour. Do this! commit ca7404caee84b3ca8f6f1f8c8a78765f9be05418 Author: Mark Claypool <claypool@cs.wpi.edu> Date: Sun Feb 25 19:54:24 2018 -0500 Added presentations diff --git a/presentation.md b/presentation.md new file mode 100644 index 0000000..e87f156 --- /dev/null +++ b/presentation.md @@ -0,0 +1,55 @@ +# MQP Presentation Guidelines +v1.0 + ++ You have a 15 minute block. Plan on 12 minutes for your + presentation. The remaining time will be for questions/setup. + ++ Think of the visuals you will make (i.e., slides). Roughly, On + average, slides take about 1.5 minutes or so per slide, so you'll + have only about 8 slides! + ++ Everyone in the group talks. Work out the transitions for who says + what. + ++ Your talk should start broad, like your report introduction, but + narrow to a problem statement early. Then, related work, + methodology, results and conclusions, possibly a demo in the middle. + + *Tip*:: The structure often parallels your report and vice-versa. + Working on them simultaneously can be synergistic. + ++ Don't focus on your slides too long, other than to glance at them or + point out some part. Instead look at the audience. + + *Tip*: If looking at the audience makes you nervous, try looking + just over the tops of their heads. Being nervous is ok and normal. + ++ Don't read your slides. + + *Tip*: If you want, have notecards that you refer. + ++ Remember, you've been working on your project for 2+ months, but + your audience is just learning about it today. Take the time to + introduce difficult/new content (i.e., don't just jump in). + ++ Make sure slide fonts are not too small. Everyone will be further + away from your slides than you. Make use of white space on + the slides to increase font sizes as much as possible. + ++ Don't have paragraphs of text or even sentences. You don't want the + audience reading your slides. The slides are mostly so they can + follow along with your talk, but listening to you for content and + not reading. + ++ If you have complicated graphs/figures, make sure you take the time + to *explain them*. Explain axes, trendlines. Tell the audience what + messages they should see in the figure. + ++ If you have a live demo planned, have a backup in case it fails. + + *Tip*: Good backup plans include: a) pre-recorded video, b) or + screen shots you can walk through. + ++ Practice, practice, practice! The way to give a good talk is to + rehearse. Since your talk is 15 minutes, you can do 4 complete runs + in as little as an hour. Do this!