The first presentation of the project progress is due during week 3. This is very early in the program, so you likely will not have a lot of “results” to share and your audience will be other members of the DSSG group. The final presentation will, instead, encapsulate the entirety of your work, represent a final product, and be addressed to your partners as well as some “external” interested individuals.
Interim and final presentations are thus very different. There is no use pretending that your presentation in week 3 is a first pass at your final presentation or that your final presentation will naturally grow out of your interim one. Take each one at a time.
While the interim and final presentations are very different, they are nonetheless both presentations. Doing some oral reporting early will allow you to experiment with different approaches, to hone your skills and to find an effective way of showcasing your work. So, you can think of interim presentations as a learning experience.
At the same time, you should be aware that they are “a thing”: any project you will ever be involved in will require such updates to sponsors/patners/collaborators while you are in the thick of things. So you can think as your interim presentations to DSSG also as “rehersals” for your interim presentations to your partners.
The presentation during week 3 substitutes your weekly report. It will have the same goal of summarizing for yourself and your mentors what you have acheived in your project so far and what are the directions you intend to pursue next.
In a 10-15 minute oral presentation you will not have the time to go into all the details you need to keep an accurate record of – luckily, you can rely on a handout to make all of your statements precise enough for the audience to give you useful feedback.
Indeed, as in any interim presentation, one of the goals of this presentation is for you to successfully get feedback. To do this, you need to stay away from the temptation of showcasing something that looks like a “perfect,” polished final product. Bring your questions to the forefront; solicit input; provide the audience with a couple of directions and see what they have to say; be concrete and make sure the discussion is not happening far up in the air; use the prototyping…
Software tools are instruments in our hands and they can lead to good or bad results depending on how we use them. The quality of a presnetation is not determined by the software tool the authors used to put it together. At the same time, tools are not neutral: just as language, they shape how we think. For example, they influence how much time we spend making different kind of decisions, or make it more or less easy to go down a certain design path… It is important to be aware of their influence not to be overpowered by it. One way to increase our awarness is to try using different tools and see how our presentations change with them.
The .Rmd document you were asked to modify last week for your presentation was constructed using beamer, a LaTeX package to create slides. This is just one possible tool out of many, and by no means a perfect one. Here are some of its advantages:
beamer, relying on LaTeX, allows for excellent rendering of mathematical formulas;.pdf slides, which, open with Acrobat reader, so far outperform any other format in terms of portability across computers and optimization of screen space;.Rmd it allows you to use the same code for running the analysis, creating reports and slides.The last point is particularly important for interim presentations. In the thick of things, you need to be mindful of the time you devote to preparing reports/presentations, as it is often time you take away from the project itself.
What are beamer disadvantages? What are alternatives? Try it out, and share information! Suggest other packages to the group…
We experimented last week with the use of handouts. We noted how they can be a very useful way to provide reference information, without cluttering the slides. We also noted the advantage for the audience to have this reference information in their hands, so that they can decide to consult it at any point during the talk, when they need it, rather than being presented with it only at the beginning of the presentation when it might not be very meaningful to them. For example, maps of Italy, with the names of the different regions, were very appropriately included in the handouts. Similarly, a “screen shot” of R prompting the names of variables (or the output of a summary function) makes very concrete for everyone what are the objects we are talking about.
We also struggled a bit on how to make sure that handouts enhance the presentation rather than becoming a source of distraction: you do not want your audience to go on a journey by themselves while you give a solitary performance in front of them. Two suggestions come to mind. (1) Include in the handout the information that will allow your audience not to wonder: to keep their attention on you, give them the details they need. If they know how many people live in each of the regions in Italy, they will not wonder how much this might influence the numbers you are presenting. (2) Keep your handout tightly linked to your presentation. This should not be a paper that readers could read on their own.
Some of the most engaging data analysis talks I have ever seen are those given by Brad Efron. He uses handouts together with slides. His handouts are typically an expanded version of the slides. Slides have very few words, they are often occupied entirely by figures (or some key formula); the same figures appear on the handouts, accompanied by an expanded reading key. By asking the audience to look at a specific point in the handout, he engages them: “please turn to page 3” is a very active way of keeping your audience with you.