Date
14 March 2025	Assigned
3 April 2025	Slides due (all groups)
4 April 2024	Presentation Group 1
18 April 2025	Presentation Group 2
25 April 2025	Presentation Group 2

Presentation Schedule

• Presentation Schedule

Final Presentation

Your final presentation is a 10 minute presentation composed of:

• an introduction to your project
• background of the problem or issue you've resolved
• a detailed discussion of your method and/or artifact architecture
• a live demo of your project (limited to 2 minutes) viewable on the room projector
  • recorded demos are only acceptable in cases where live demos are impractical
• figures and other visual display of your experimental results
• a conclusion which assesses the relative success of your project

All presentations will be followed by approximately 5 minutes of Q&A.

Turning in your presentation

You'll notice that everyone has the same due date for slides: 3 April 2025 (the day before presentations start). At that time, Faculty will expect that you've turned your slides in using PDF form. To turn them in, you will upload the final PDF to the docs folder of your research journal (the folder will exist before the due date, even if it doesn't as of issuing this assignment).

As a reminder, due to the form (PDF), there isn't really any way to effectively do animation. Keep that in mind.

Structure

Introduction

Likely the most difficult part to get right, the Introduction features some formal constraint-based conventions which make it a bit tough:

• the name of the project
• simple, succinct description of the project which is direct and not abstract
• the well-defined value/problem that the project provides or solves

While departures from this format obviously work, focusing on building your presentation from these elements will help you to define your project in a clearer, more focused way.

Background

While your introduction convinces an audience to pay attention it's your job to convert listeners from interested and attentive to receptive and (hopefully) supportive of your intervention or solution. In nearly every case, you should expect that your audience knows nothing about the backround or history of the area you're addressing. To remedy this, your presentation needs to briefly:

• summarize what has been attempted in relation the problem area(s) you're addressing
• areas where these "prior art (i.e. previous established) projects succeeded, failed, ended, or gestured toward (but did not, themselves, complete)
• a pitch that qualifies how your intervention/artifact is different or addresses a gap in the literature
• cite multiple sources in either figures, paraphrases, or quotations to establish "prior art"

Method / Architecture

The previous section of the presentation prepares the audience for your take on the subject. To adequately define this area of your project you should:

• include at least one diagram that presents and overview of the technical solution implemented or described
• discussion of the technologies used to develop the solution
• trade-offs experienced in systems design or technology selection
• clearly describe how your artifact achieves something novel or new

Demo

Yes, we require you to present a live demo. There are many reasons for this: namely that videos of technology are, by and large, not interesting to watch. So, instead, we will live on the bleeding edge for 2 minutes.

Your demo should:

• demonstrate most major aspects of the artifact in at least one use case
• be an interactive demo in which the presenter uses the software, while they
• provide narration that explains the significance of the steps taken and outputs generated, and can
• relate what the audience is seeing to the method, architecture, and "prior art" referenced in the Background section
  • i.e., describes why your solution is novel

Note: if software fails or crashes during a live demo, it's not the end of the world and is not automatically going to fail a presentation. Just ask Bill Gates, who experienced a Blue Screen of Death (BSOD) during a key demonstration of Windows 98.

Experimental Results

Having conducted your experiment(s) to understand the efficacy and effectiveness of your artifact(s), present those to the audience to persuasively describe the relative success or general failure of the project. Here, there are three main categories of success: success, _qualified_ success, failure.

Here:

• describe, at a high level, the structure of your experiment(s) and what they sought to demonstrate or find out
• display at least one figure, chart, graph, or other visual containing key, compelling results
• highlight nuances of surprising data and the effect(s) it has or will have on your artifact (e.g. if you make revisions based on discoveries)

Conclusion

It's easy at this point to believe that your presentation, as full of content as it is, says and shows enough. However, consider your Conclusion your opportunity to further shape and refine the impact that your 10-minute data dump will have.

You want to leave your audience with a sense of concreteness and cohesiveness, arriving at the end of a highly-structured and practiced 10 minutes whose conclusion feels clear and inevitable. Second only to the Introduction in difficulty, the Conclusion is possibly the most important section in the presentation: it serves as the last thing anyone will see or hear.

Use this section as a chance to recap the highlights of your presentation, namely:

• what you did (i.e. revisit your artifact's name and its novel features)
• describe how your method and experimental results define your rubric for how they dictate relative success or failure of the project
  • i.e., how do you define success and how did your work display or evidence it?
• directions indicated for future work on this artifact or areas that other artifacts should explore

Note: a project can achieve high academic marks and still be called a failure. If your experimental results clearly display that your artifact's method has little or no efficacy, focus your presentation of this section on why that was the case. A well-explained failure still holds great value as inquiry.

Slides

These reminders come from the Demo Day presentations given last semester. While the final presentation is twice as long, the general rules of good presentationeering still apply.

The following guidelines and suggestions will appear arbitary and restrictive, but focus on a couple of key assumptions derived from situations where slide decks go wrong:

1. Slides are not for the presenter (i.e., you)
2. Slides merely support a presentation and are not, themselves, a substitute for one

Similar to the description of the presentation Conclusion, we'll assume that folks have a limited memory.

Let's follow the former Y Combinator Partner Kevin Hale on a general rubric for all slides:

• Make it legible
• Make it simple
• Make it obvious

Design

On legibility

Many slides aren't readable because color choices do not provide enough contrast (i.e. ability to differentiate between any two colors on a slide). In addition, slides often cram a lot of type on a single slide (even slides for this course are guilty of this). Here are there rules to heavily consider:

1. use a sufficiently large typeface for everyone in the room to read
2. pair colors which feature high difference (i.e. contrast)
3. use fewer than 10 words on a given slide

On density

Slides which feature multiple, competing ideas are confusing. Each slide's content should represent one idea and only one idea.

On content

Looking at the amount of information expected to come from the presentation, we encounter a problem: how do we present this information with restrictions that make it seem like there should only be 7 (or fewer) slides? We do it in 7 or fewer slides.

Keep in mind that this presentation is not for the presenter relaying the content. Slides shape the experience of the physical presentation. The ways in which a given slide reinforces (but does not duplicate!) what the content you're delivering helps the audience with our two retention problems:

• the audience will only pay attention to 1 idea at a time
• folks will really only remember the 3-4 facts you use as your presentation Conclusion

On practice

In one verb: practice.

In fact, you will be required to practice with your machine in the room where you will be giving the presentation.

Presentations are capped at 10 minutes. It'll be over before you know it and, if you don't have the chance to make it to the ultimate concluding slide(s), you've lost your chance to make the presentation feel (as written above) clear and inevitable.

Short assignments in this course will force you to practice, though you should practice even more on your own. You should practice with friends that know your project. You should practice with friends that don't know your project. You should practice with your readers. You should organize practice sessions with other folks practing and order pizza.

Ideally, practice with anyone who you can convince to pay attention.

As presentation day approaches, you should be able to present your 10 minutes as if a set of memorized facts. The only way you get there is through practice.

Evaluation

Presentation attendees have the opportunity to submit scorecards for each project. These scorecards are organized around the criteria defined at the start of this document and are Yes/No and "Likert scale" responses to a series of questions with additional space to rate a given presentation as Exceptional in a particular category.

The evaluation form will be released on the first day of presentations. Attendees will be given a short amount of time between presentations to complete the form.