Play is a central part of human experience -- not just in a "game" form, but in our everyday interactions. When you make a joke, or play a prank on your friends... these are different forms of play. We are interested in play as a concept in this class because many kinds of play are affected by technology -- if technology is not designed right, then play devolves into something less interesting, or it does not allow for the right kinds of play.

Your project can involve some kind of play, or multiple types of play. There are two fundamental types of projects for this course: study project and design project. A study project involves examining one context of play, and understanding it -- this means conducting user research to understand the nature of play in that context. This type of project would generally involve exploring a particular type of game and how it is played. A design project involves actually designing or building a simple game.

Deliverables for this project include: (a) a project mini-proposal; (b) a project proposal; (b) a literature review; (c) a final presentation/demo, and (d) a final paper. Raw materials (code, data, etc.), should be handed in with the project paper.


By the third class, you will see an example of both a design project and a study project. Both of these began as 599.81 projects, and grew into real, academic, research papers!

For the mini-proposal, I expect you to develop (at least) three different ideas, and submit each description with (about) a paragraph level of granularity. For each, identify (a) whether it is a design vs. study project, (b) the central research question you are addressing with the project, and (c) what you think you can do to complete the project.


Mirror Video Conferencing (design project). Most video conferencing systems use a "through with window" metaphor, where the person you are talking to is on the other side of an audio/video-connected window. In this project, I would like to explore the design of a system that re-imagines video conferencing such that it looks and feels like both participants are looking in a mirror. The central research question is whether this has an impact on the style of video interaction. For the course project, I would like to build this system using the Kinect, capturing video, and sending it to a remote site, and reconstructing it with the local camera feed.


Develop a chosen project idea into a full proposal. The written proposal should be no more than two pages in SIGCHI extended abstract format (excluding the front page, which barely has any room). It should have the following sections:

  • Abstract (brief description of the entire proposed project)
  • Introduction (three paragraphs: 1. outline the basic motivation -- why is the general research question you are exploring interesting/worth doing, and if relevant, what others have done in relation to the question you are proposing; 2. outline the basic idea of the project -- what will you do; 3. outline what you expect to have at the end, who should care, and more broadly, why this is interesting)
  • Proposed Work (outline exactly what you will do by separating it into at least three or four phases or deliverables)
  • Timeline (provide in a tabular form, exactly when you will complete each minor phase of the project -- as a suggestion, have a goal/milestone for each week)

Mini-workshop Notes Rubric

Literature review

In two pages (in SIGCHI extended abstracts template), provide a review of four-to-six pieces of related work. For each project, describe: (1) what was the research problem/question being tackled; (2) what was their approach/solution; (3) how did they evaluate that solution, and (4) how does this relate to your project?


Develop a 10 minute presentation based on your work.

Your presentation ought to have about five major sections (timings should be used as guidelines):

  1. Problem/Motivation (1min). Remind us again succinctly why you did the project that you did. What is the real life problem or question that you are trying to tackle with your research project.
  2. Demo/Video (5min). Almost right off the top, show us what you did. If it is a demo, make sure that everything is primed and ready to go. Do not be futzing around setting it up when it comes time to demo. Make sure that each demo "moment" is important, shows us something interesting, and is well-scripted. Note: this is different than a "feature walkthrough." If your system makes use of a database, make sure the database is populated -- don't just tell us that it "would be populated." A few ways to demo well: (a) give us a scenario of how the system would be used (say to address the motivation/problem you outlined earlier); (b) play a sample "game" for us with your system; (c) describe a scenario, and illustrate a small handful of really neat, interesting features. Remember to do these (particularly videos) as sandwiches: (a) tell us what we will see; (b) show us; (c) tell us what we saw.
  3. Justify your Design (2min). Along the way, you would have had to make design choices -- describe a handful of these (two or three), and describe the choice that you made, and why you chose to make your system the way that you did. This could be a low-level design detail (e.g. we used peer-to-peer networking vs. client-server networking) all the way to a UI design.
  4. Describe Future Work (1min). If you had more time to work on things, what else would you do? What are logical next steps, and what are some "pie in the sky" ideas that you'd thought about but never had the chance to try.
  5. Reflection (1min). Reflect on the project as a whole. Knowing what you know now, what would you have done differently? What would you, for example, tell the next student joining this class to do with his/her project, particularly if s/he wanted to do something similar?

Expect to have to answer a handful of questions from your classmates and me. I will be grading you on the smoothness of your presentation/delivery, and particularly your demo. Think carefully about all the feedback you have given (and received) about presentations. Try to incorporate those lessons into your presentation. The demos you have done before -- now think about how to amp that up and shine.

If you did a study project, you ought to replace the Demo/Video and Justify your Design sections with two other sections:

  1. Describe the Study setup. What was the hypothesis? What were the conditions? What did you expect to see? Justify your choice of setting the study up this way. What data did you collect? How did you analyze it?
  2. Highlights from Findings. Choose 3-4 major findings from your study (maybe even fewer, depending on time). Explain what these were, and then support your findings with some data from your study (e.g. summary numbers, transcripts, video clips, etc.).

Final Paper

Develop a 6-8 page paper (in SIGCHI extended abstracts template) based on your work. Ensure that you also send me a .zyp file (or a Dropbox link) containing any source code that you have written.

The page limit is a soft-limit, though try to avoid going over 10 pages. To help, note that you can use the margins for images and figures. You should include an appendix with all of your raw data (this does not count against your page limit).

Your paper should probably have the following sections:

  1. Abstract
  2. Introduction (motivation, research question, etc.)
  3. Related Work
  4. System / Study
  5. Findings / Major Design Decisions
  6. Discussion (knowing what you know now...)
  7. Conclusions
  8. References

You'll notice that many of these sections are things that you have either written before (proposal or related work), or appear above in the presentation. There's a reason for this! You can re-use material. Go for it.