Summary: do research in human-computer interaction. I encourage you to engage the theme of this years class, but you are free to pursue other topics as well.
I expect your final projects to be honest attempts at HCI research. I also expect that most of you will do your projects in teams of 2 or 3. Larger teams are discouraged because coordination becomes very difficult. If you have a good reason to go solo (e.g., you want to use this project as a stepping stone toward your quals or undergraduate thesis), talk to me.
Prepare two ideas for a final project. Your presentation should provide a clear motivation for each project, an outline of your approach, and a clear statement of anticipated contributions (assuming everything works out). All members of the team should speak.
Updated on Oct 18: We have 11 teams so we will have 5 minutes per team to present both ideas! That's fast so it's a very good idea for you to practice your pitch ahead of time. We will provide feedback asynchronously using this online form. Please make sure to bring a laptop to class! Also, please come up with a name for your team.
This is really your formal project proposal. It should already be in the proper format (see below). You will write it in three parts: introduction, related work and work plan.
Your introduction should address the following questions:
In general, an introduction to a paper should answer all of the What? questions related to the paper (what is the problem? what is the approach? what have you found? what are the contributions?), but leave out answers to the How? questions until later sections.
The related work section is not just a list of other research --- it should be a thoughtful synthesis that highlights both the strengths and shortcomings of prior work and that contrasts prior work with what you hope to accomplish. You do not need to be defensive or constantly point out the ways in which your work is going to be superior.
The plan should be included as a separate section. It should capture what project-specific goals you hope to accomplish by each milestone (see below) in addition to the generic requirements listed below. Every project is different so the milestones listed below are vague. In your plan you need to make them concrete.
Additional resources: you can take a look at Scott Hudson's slide deck on how to write a UIST paper.
You are encouraged to plan your project such that most of the building (if your project involves building some software) is done by this date. You should extend your paper by adding an appropriate technology-related section. For a system-based paper, this would be the system description (such section should have a conceptual part that describes high level design choices and what purpose they serve, as well as a technology/implementation section that show off how you made things possible). In a study paper, you should have most of the Experiment section drafted at this point.
There is a chance that your ideas about your project have evolved since you've submitted your initial proposal. That's OK. But make sure to revise the introduction appropriately.
At each milestone submit the entire write up (including the sections submitted previously). Make sure that you have responded to the comments you got on previous sections. Also include the Plan section for now and note any changes to it.
You’d better had some data by now. The data should be rich enough so that you can reflect on which aspects of your project are working and which aren’t. Finalize your system and/or experiment design sections. Also submit a brief summary of the results and what they mean for your continuing progress. This results write up probably won’t make it into the final paper. If your data made you revise your project goals or contributions, please update your intro (and other sections) appropriately.
You should have most of the data by that point. You will give a formal presentation in front of the class. We will set aside 15 minutes per team. Plan on speaking for no more than 12 minutes (ideally 10-ish) and leave the rest for questions and a conversation. Each member of the team should speak.
You are done!
Your final project reports will be written using the ACM SIGCHI paper (not extended abstract) format. Seems like a nitpick? Well, it’s important. Nearly all publication venues in computer science have specific and strict formatting requirements. Incorrectly formatted papers do not get reviewed. So you might as well get some practice now. You can find LaTeX and Word templates at the ACM web site: http://www.sigchi.org/publications/chipubform
Word vs LaTeX? Every time I had to write a paper in Word, I regretted it. With Word, it’s nearly impossible to parallelize the writing process, reference management is a pain, not to mention all the random things that Word’s opaque formatting engine springs up on you. The change tracking is nice, though. Setting up a good collaborative LaTeX environment is a paint, but it's worth it. Consider overleaf -- Harvard now has a site license so make sure to create your account using your Harvard email address.
You may discuss your final project ideas and any technical challenges with others, but you must acknowledge any help you receive in your write ups. You may reuse any code you find on the internet (as long as it is legal to do so; acknowledge all sources). You may also use code shared by another team (if it makes sense). You may also reuse code that you contributed to in prior assignments even if not all members of your prior teams are working on the final project with you.