Progress Report

Following the fall break, you will give a short progress report describing your research project and the progress that you have made.

This talk has several purposes. First, the talk is meant to develop your voice regarding your project, allowing you to flesh out the bigger picture and consider your work in the larger context of computer science. Second, it is also a technical defense that will allow others to constructively criticize your approach and thus strengthen and/or improve your approach and techniques. Finally, it is a progress report that allows you (and me) to evaluate your current progress and possibly reconsider how much you will be able to accomplish in the remaining time.

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.
  • The Reality - What have you accomplished so far? Can you demonstrate that your idea works, albeit in some incomplete way? (Answer should be yes.) Do you have some preliminary results supporting your original hypothesis? (Answer should be yes.)
  • The Road Ahead - What remains to be accomplished? Were any tasks easier or more difficult than you expected? What results wilsl you demonstrate at the end of the project?

    • Requirements

  • Medium: Your talk should be accompanied by video slides, perhaps 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. 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 Phil (psnowber@cse.nd.edu) by 5PM Monday. He will choose a random order for the talks: half will go on Tuesday, and the rest on Thursday. Everyone should be prepared to speak on Tuesday.
  • Time: Each talk will occupy EIGHT minutes plus TWO minutes 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 two minute period.
  • Questions: You must ask at least one insightful question of another speaker during the two-day 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, preferably with someone else paying attention. (It's short, so it's easy to practice several times.)

    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