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.
As I have mentioned several times in class, the most important thing that you must show at the midterm report is a working system. It need not be complete, fully featured, or have good performance. But, you must show that you are capable of making all the parts work together in a way that will let you finish your project.
Time: Each talk will occupy fifteen minutes plus 4 minutes for discussion and 1 minute for change to the next speaker. Two-person groups should arrange for each member to talk for about half of the time. I will give you a silent warning when you have 5, 2, and 1 minutes left.
Medium: Your talk should be backed up by a video presentation. PowerPoint slides are the standard way to do this. I will provide a video projector and a laptop to show slides. Place your PowerPoint files on the web so that they can be easily downloaded and shown. If you like, you may use other software or equipment, but then you are on your own.
Handin: Print out your slides so that I can write feedback on them for you later. Hand them in at the beginning of class.
Order: Volunteers are welcome to go first. Otherwise, I will pick an order randomly on that day.
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.
The Problem - What problem are you attacking? Why is this an important problem, and why hasn't it been solved before? How do people currently deal with this problem? Is there some ugly workaround or clumsy solution currently in place?
The Solution - What is your approach to solving this problem? What is the structure of your system? What makes your solution novel, difficult, or non-obvious? What are the limitations of your solution?
The Reality - What have you actually accomplished? Can you demonstrate that the system works, albeit in some incomplete way? (Answer should be yes.) Do you have some preliminary results supporting your original hypothesis? (Answer should be yes.) What more do you need to accomplish before the final paper?
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 up 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 at length. Or, display a code snippet on the screen, and then describe what is interesting about the code.
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. I'll expect a real demo when you meet with me later.
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 both incompetent and anti-social. (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!)