Progress Report

Following the fall break, you will give a short progress report describing your research project, the progress that you have made so far, and what remains to be done.

Content

There are four key things that you must communicate lucidly in a very short amount of time:
  • The Problem - What problem are you attacking? Why is this an important problem and why is it tricky to solve?
  • The Solution - What is your approach to solving this problem? What makes your solution novel, difficult, or non-obvious? If you are building a system, show a diagram or schematic of what you are building.
  • Initial Results - What have you accomplished so far? Demonstrate that your basic idea works, albeit in some incomplete way. If your project involves performance measurement, show a measurement that verifies your basic hypothesis. If your project involves collecting data, show some real data and explain some interesting anomaly in the data.
  • The Road Ahead - What remains to be accomplished? Are there any unexpected technical issues that change the directory of your project? What results will you demonstrate at the end of the semester?

    • Grading

    Your grade will be based upon your correct and clear explanation of the four points given above, reasonable progress in your work, and completing the talk in a timely manner.

    Technical Requirements

  • Medium: Your talk should be accompanied by video slides, about five total. You may use any tool that you like to create slides. Powerpoint on Windows is the standard tool, but you can also use OpenOffice on Linux or Sun machines, or Keynote on a Mac. However, your final slides will be downloaded and shown on a single Windows machine, so you must submit them in either Portable Document Format (PDF) or Powerpoint (PPT). (There won't be time for everyone to muck around by plugging in laptops, rebooting machines, or running other software.)
  • Handin: You must email your completed slides to me (dthain@cse.nd.edu) by 9AM Tuesday October 24. I will randomly distribute the talks across the Tuesday and Thursday session. Everyone must be ready to deliver their talk first thing Tuesday morning.
  • Time: Each talk will occupy EIGHT minutes plus TWO minute for questions and discussion. Groups with more than one person should arrange to have everyone speak for a portion of the time. I will give you a silent warning when you have 1 minute remaining. The next talk should load slides and get ready during the question period.
  • Meeting: After the midterm talk, you must schedule a second meeting with me. In the meeting, we will discuss your progress, consider any changes in method or scope, and set goals for the final paper.

    • General Advice from Me

    Eight minutes is a very short talk, so there won't be time for you to hem and haw. A short talk can be more difficult than a long talk in this respect -- you must stick carefully to your message. Practice your talk several times, preferably with someone else paying attention. (It's short, so it's easy to practice several times.) Make sure that you use all of the time available!

    Remember that you have been thinking about this problem for a while, but your audience has not. Start from a high level and explain some of the reasoning that brought you to this point where you are now. Of course, you also want to demonstrate that you are now an expert about this idea, so throw in one tricky detail that shows that the problem is non-trivial and that you are clever. (Your final talk can place more emphasis on the technical details.)

    Use your slides to back up what you say to the audience. A bunch of slides spelling out exactly what you intend to say is pretty darn boring for everyone involved. Instead, display a picture of your system, and describe it in words. Or, display a single sentence that drives home a key idea, and then discuss the idea for minute. Or, display a code snippet on the screen, and then describe what is interesting about the code. Don't just display words and read them out loud.

    In a long talk, speakers often give outline slides describing the whole structure of the talk: Introduction, Overview, Methods, Results, Related Work, Conclusion. Don't do this in a short talk: it is painfully obvious and wastes valuable time.

    A demo is a risky matter. A really good demo can make a complex idea clear. However, demos frequently crash and burn for technical reasons. A good middle ground is to give a "staged" demo (be honest about this) that is a video or screenshot or PowerPoint approximation of what your software does.

    Be prepared for technical malfunction. If a projector breaks, a computer crashes, or the demo fails miserably, don't waste your valuable talk time puttering with the equipment. This makes you look foolish. (Which you aren't.) Just tell a joke and then move on without that element of your presentation. Listeners will remember you for being smart and adaptive. (Which you are!)

    Advice from Others