One row per slide, to glance at while the deck is on screen. The reasoning behind every answer is in the sections below. Deck: /deck/presenting-mathematics/main.pdf.
| Slide | On screen | What you fill in or say |
|---|---|---|
| 2 | A presentation is a performance | It is not your slides. If they could get it all without you, you wrote a document |
| 3 | Three more claims | They will look at whatever you put up; less is more; teaching and presenting are not the same thing |
| 4 | What to watch for | Fill one column per recording, from the room. Hold the band back until the discussion has run |
| 5 | Communication is 30% of the project mark | Paper and presentation marked together, on five things. One mark covers both |
| 6 | Fifteen minutes. Spend it. | No single right answer. A workable shape: 3, 3, 5, 2, 2. Wrong: eleven minutes of mathematics and three of software |
| 7 | Scenes, not slides | A scene is not a slide. One scene may need three slides, or none. Planning in slides produces a transcript |
| 8 | The demonstration is recorded | A failure left in the recording is worse than a live one, because nobody watched it back. Rehearse once, view once |
| 9 | This week's reading | Principles of presentation, and the documentation chapter |
| 10 | Four sections. Which is which? | In the order on the slide: how-to guide, tutorial, explanation, reference |
| 11 | README, or docstring? | README to decide and to learn; docstrings to read one function. Both. A good name is documentation that cannot go out of date |
| 12 | How do you know it is enough? | Give it to another group. Suggest they swap READMEs in this week's meeting |
| 13 | Before you leave | Everyone speaks, matching contribution.md; rotate the roles; Week 9 minutes to the next session. Fourth of five |
A group-work week. The single hour is not a lecture on presenting: students work through the principles of presentation themselves. This week is the second of the two exceptions to the question-and-signpost format, because the hour is given over to watching student presentations from past years.
Show recorded presentations from previous cohorts, then take the discussion that follows.
Past student work is the right material here, and better than a presentation of your own, for two reasons. It is the actual standard being asked for rather than a demonstration by someone with twenty years of practice, so it is attainable. And it is the same 15 minutes, on the same kind of library, under the same constraints, which makes every observation transferable.
Show two or three, and pick them at different levels rather than three strong ones. A presentation that runs out of material at nine minutes, or that spends eleven minutes on the mathematics and three on the software, teaches more than a polished one, because the failure is visible and nameable. Say which band each sits in once the class has discussed it.
After each one, ask what worked and what did not before giving your own reading. Questions worth putting to the room:
Then signpost the principles of presentation as the thing to work through, and point at the Communication criterion, which covers the presentation and the paper together and is 30% of the project mark.
A practical note: keep a small set of recordings you have permission to reuse, and refresh it as cohorts pass. Check before the session that the group consented to their presentation being shown to later years, and say in class that these are shown with permission. Students are noticeably more willing to be in next year's set when they have seen it done that way.
There is a write-on deck at /deck/presenting-mathematics/main.pdf. Slides 2 and 3 are the frame, two minutes at most, before the first recording goes on.
Slide 4 is the one to keep coming back to. It is a grid: five questions down the side, three columns for the three presentations. Put it up after each one and fill a column in from the room. The last row is the band, which you give once the discussion has run.
Slides 5 to 8 are for after the last recording. They cover what Communication is marked on, a fifteen minute budget each group fills in for its own talk, a storyboard of eight empty scenes, and the point about the recorded demonstration. Slide 6 is the most useful thing in the hour, because the commonest failure becomes visible as soon as the numbers are written down.
Slides 9 to 12 are this week's documentation chapter. Answers to everything are at the end of these notes.
The Python chapter this week is documentation, and the deck puts three questions to the room.
Slide 10, four sections, which is which? The four analogies, in the order they appear, are a how-to guide, a tutorial, an explanation and a reference. Take them in whatever order the room offers. What matters is the reason behind each: a recipe tells you to chop the onion without saying why, a first time in a kitchen is somebody being shown every step, the chemistry of a cooked onion is understanding, and the list of ingredients is somewhere to look things up. The Scope criterion asks for all four by name.
Slide 11, README or docstring? The README is for somebody deciding whether to use the library, and then learning how. The docstrings are for somebody reading one function. They need both, and the common failure is a long README with no docstrings behind it. The question underneath, which of the two a good variable name belongs to, has no clean answer and is worth the thirty seconds it takes: a name is documentation that cannot go out of date, and it sits in the code rather than beside it.
Slide 12, how do you know it is enough? Give it to another group. The criterion is that the README would be usable by somebody outside the group with no extra help, and swapping READMEs with the group at the next table tests exactly that in ten minutes. Suggest they do it in this week's meeting.
"Do we all have to speak?" Yes. The contribution record and the presentation should tell the same story about who did what.
"Is 15 minutes a limit or a target?" A target. Substantially under suggests the work is thin; substantially over usually means the design decisions got squeezed out at the end, which is the most valuable part.
"What do we do about the live demonstration?" It is a recording, so there is no risk of a live failure, but a recorded failure is worse. Rehearse the demonstration once before recording it.
Send the following message before class:
Hi all,
In this week's session I will show you presentations given by
students in previous years for this exact piece of coursework.
You do not need to prepare anything. It is worth coming: these are
the real thing at the real length, so it is much easier to aim at
them than at a description of what is wanted.
Please get in touch if I can assist with anything,
Vince
Send the following message after class:
Hi all,
Today we watched presentations from previous years' groups and
discussed what made them work and where they lost time.
What to work through on your own: the principles of presentation,
https://vknight.org/pop/
A reminder that the presentation and the paper are marked together
under Communication, which is 30% of the project mark.
Please get in touch if I can assist with anything,
Vince
Slide 4, the grid. The five rows are deliberately countable rather than impressionistic. The first, minutes before the library appeared, usually produces a number that surprises the room. The third, what you learned that the README would not tell you, is the one that separates a presentation from a document read aloud: if the honest answer is nothing, the talk had no reason to exist. Hold the band back until the discussion has finished, then say which one it sat in and why.
Slide 6, the fifteen minute budget. There is no single right answer, and it is worth saying so. What is wrong is eleven minutes of mathematics and three of software, or a budget with nothing left for the design decisions and the limitations. A workable shape is around three minutes on the problem, three on the mathematics, five on the library and how it is built, two on the demonstration and two on what it does not do. Let them argue with it.
Slide 7, the storyboard. Eight boxes, and the instruction is to storyboard it as a film. The point to make is that a scene is not a slide: one scene may need three slides, or none. Groups that plan in slides end up with a transcript on the screen, which is exactly what the second principle warns against.
Slide 8, the recorded demonstration. Nothing can fail live, so a failure still sitting in the recording is worse than a live one, because it means nobody watched it back. One rehearsal before recording, and one viewing before submitting.