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?
Be sure to include a carefully prepared diagram that shows the components
of your software, system, or algorithm, and how they interact.
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,
perhaps five to ten total. You may use any tool that you like to
create slides: Powerpoint, OpenOffice, and Keynote are common choices.
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 by 9AM Tuesday October 26. I will put the talks in random order; everyone must be
prepared to start the first talk on time.
Time: Each talk will occupy TEN 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 progress report, 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
Ten 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 multiple 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!
Keep in mind 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