Project 1 Hand-Ins

by Mike Gleicher on April 1, 2011 · 2 comments

in Project 1

The components of turning in Project 1:

  1. Interactive Demo (given to the instructor)
  2. Project Write-Up
  3. Project Video
  4. Project Artifact
  5. Self Evaluation (per-person)
  6. Peer Evaluation (per person)

Note: each person does 5 and 6 individually. Each group turns in 1 thing for 1-4 (unless you want to do more than 1).

All parts are due on Friday, April 8th. However, you get a free “late pass” until Monday, April 11th if everyone in your group turns in a project 2 pre-proposal on April 8th, and provides feedback to their other group members (see the project 2 pre-proposal web page for details – that page is coming soon).

I’d like all parts of your team to be part of 1-4. I have no way to know if one person does all the writing, but I’d really like teams to try to work together so that everyone has the experience of producing videos and writing.

Note: in terms of grading, a large portion of the project is in the quality of the presentation (how well you give the demo, the writing and video, the evaluation writeups). Not only will these be graded explicitly, but they influence what I think of your project. If you have bad presentation of your results, it will be harder for me to see that your project is good (I will try, through asking questions and looking hard at what you give me).

Interactive Demo

You will show off your system and explain it. I’ll ask questions. If you want to have canned movies or other pre-prepared results (in case things break), that’s good. You should think through how you are going to show off your system – it doesn’t need to be a formal presentation, but prepare by choosing examples, knowing what you want to say, etc.

These demos will be scheduled for Monday afternoon (4/11). I’ll give each group 30 minute slots, but I expect it will more like 15-20 minutes.

Project Write-Up

You should send a PDF file to the professor by email. I will post it to the web page (so yes, it will be a public document).

The report should explain your project: what you were trying to do, what you did, how you did it, how well it worked. Include all the technical details (describe all the implementation details). Evaluation (how do you know it worked) and limitations (of your implementation, and the technique) are important to discuss.

Be sure to evaluate the ideas that you were trying to implement. Now that you know a lot about something from a paper, you should have a much better idea as to the strengths and weaknesses of the approach than most people that only read (or review) the paper. Note: evaluating the ideas is somewhat independent of evaluating your implementation of them. You should do both. Be sure to consider the strengths, weaknesses and limitations. Are limitations fundamental (to the approach)? To your implementation?

When discussing the techniques you implemented, discuss the things that you learned from implementing the techniques (as opposed to just reading the paper).

Project Video

You’ve already learned about research videos. Now I want you to try to make one – mainly to learn to appreciate the work it takes to create one by trying to do it.

In terms of “technical details” you should do 3-5 minutes (while 5 minutes isn’t a hard limit, if its longer than that, you should think about how to make it shorter). Create it 720p. Upload it to YouTube (you can do it “private to only people who know the link” or even “specific people”) and send me a link. I’ll also want the video file as part of the “artifact.”

To create the video, I recommend getting a copy of CamtasiaStudio. There’s a 30 day trial, and you can use it for the class. It has excellent screen capture capabilities, and enough editing capabilities to make the kind of video you need for this. Using other screen capture software (like FRAPPS) is OK. Use any editor you can find / know how to use.

Your video should stand alone – it should explain things to someone who has not read your writeup or seen your system. Assume the viewer has not read any of the papers you are implementing. Try to make a video we could show at the beginning of the semester in class. I may ask a “guest grader” unfamiliar with your project to assess how well it “works” for someone unfamiliar with your project (since I will know about your project from the writeup and demo).

To produce a video I recommend:

  1. Decide what points you want to get across. Remember, you can’t say everything in 5 minutes, and some things are too hard to explain in a video.
  2. Write a script.
  3. Record a video while talking over it (to get the timing right). Alternatively, record rough narration and make the video go along with it.
  4. Revise the script to fit the video.
  5. Add titles, captions, …
  6. Re-record the audio to align with the video (including over the titles)

Project Artifact

I will ask you to hand in all files from your project. The source code, the documentation, the video, output examples, input data (if you got them from online databases, just a list might be OK), …

Put it all in one big ZIP file with a README explaining all the contents. Then tell me how big it is so I can figure out how to transfer it/store it. For the deadline, you just need to send me the size information. I’ll actually get the file from you a day or two later.

Self-Evaluation and Peer Evaluation

Note 1: my evaluation of your evaluations is not related to their content. You can write a self-evaluation saying “this project was a total flop,” but explain it in a well-written, thorough, and detailed way. Creating an excellent, but negative, evaluation. My opinion of the content probably won’t be changed much (I find that I usually think projects are better than the self-evaluators do. There are really rare occasions when students think their projects are awesome, but they are deluded. In these cases, they usually have terrible evaluations (positive, but lacking detail and substance)).

Note 2: A lot of the education literature (as well as my personal experience) says that the act of reflecting on doing something really adds to how much you learn from the experience. So the purpose here is really about forcing you to reflect, so you learn more. The self-evaluations are not for you to tell me what grade you should get.

The evaluations will be kept private. I will not post them, or tell your teammates.

Send your self-evaluation and peer evaluations to me via email. You may include them in one email.

Below is a list of questions to addresss in your evaluations. You can add other things, as you see fit.


  • How well did you think the project turned out? Are you happy with it?
  • What did you think of your choice of topic? Did you choose a reasonable goal?
  • What went right? What went wrong?
  • What would you do the same if you had to do it again? What would you do differently?
  • If you had to define a project (with similar content to your project) for next year’s class, what would you suggest. What would a reasonable goal be for a 4 week project? What guidance/preparation should the new students get?
  • What advice would you give to students taking this class who will have to do a similar project (e.g. picking a topic, …)
  • What did I (as the Professor) do right/wrong in terms of running these projects? What should I keep or change if I do this again?
  • What did you learn from this project?

Peer Evaluation (team)

  • Overall, how well did your group work together? What processes/methods did you use to work as a team?
  • What advice would you give to other teams doing a project like this?
  • What did you learn about working on a team?

Peer Evaluation  (For each member of your group)

  • What was their contribution to the project? (and how did this relate to what it was supposed to be)
  • How well did they work as a team member (in terms of coordinating, communicating, working together)? (this is more about process, while the previous question was about content)

Previous post:

Next post: