Research Project

From CS260Wiki
Jump to: navigation, search

Project Overview

In this course, you will complete a half-semester-long research project. This project will be completed in groups of two.

At a high level, successful projects will raise an important research question, and plan and execute a methodology for answering that question. Often, this methodology will include building and evaluating a prototype system, but hacking is not strictly necessary. All projects require a study — obviously a much more thorough study will be expected of projects that do not involve system building. The goal of the project abstract draft (described below) is to help you scope your work appropriately.

Topics and Scope

Your topic should break new ground - while the homework assignments asked you to reimplement existing projects, we now expect you to go beyond the status quo of published prior work.

Projects are often successful if they integrate into an existing larger research effort such as your dissertation research. If you already have an existing research agenda, think about a project that can help you further that agenda.

If you are looking for a new project idea, we ask you to address one of three themes:

  1. Tools for designers or programmers
  2. Crowdsourcing: leveraging online communities
  3. Rich interactions through sensing & actuation

You have approximately 8 weeks to complete your project -- be mindful of this limitation and propose something you feel you can actually complete in that timeframe.

You are free to propose your own project within these guidelines. We also have a list of suitable Project Ideas (private page, use same login/password as for readings).

Timeline

Due dates:

Fri, Oct 1: Post Project Ideas
Fri, Oct 22: Project Abstract (Draft)
Fri, Oct 29: Related Work Review
Fri, Nov 5: Project Abstract & Introduction (Polished)
Fri, Nov 19: Project Prototypes
Fri, Nov 26: Project Evaluation Plan
Fri, Dec 3: First Draft of Paper
Fri, Dec 10: Final Project Presentations
Mon, Dec 13: Final Project Paper


Forming Groups

This project will be completed in groups of two (other group sizes are possible but strongly discouraged). Project groups will be self-paired. Use this Google Form to submit project groups. (One submission per team is enough. To assist you in finding the right group, use the wiki page on Project Ideas.

Project Abstract (Draft and Final Versions)

A draft of your project abstract is due on October 22nd. Course staff will provide feedback on the draft to assist in the preparation of a polished version, due on November 5. Both are submitted online.

The project abstract should cover the following topics:

Research Question: what are you trying to answer? State this as clearly as possible in one sentence. Hypothesis: what do you think the answer to your question is, and why? Method: how will you explore your hypothesis, and why is that the right approach? (This should include the design of your study.) Grounding this in methodologies that other researchers have used (e.g. by drawing from the class readings) is a good idea. There are three major points you should hit here.

Study design: What are you going to do? Be very detailed and precise.
Evaluation: How will you know you succeeded? What will you measure? How will you measure it?
Ecological Validity: Why does your study answer your research question? Why does your evaluation address your hypothesis? Make sure your study, and the variables you're measuring, properly address the question you are asking.

Study Recruitment Plan: how will you get participants for your study? For pilot studies, we suggest you recruit from within the class -- "trading" participation with other groups is a great way to learn about what others are doing. For larger studies (e.g. for those not building a system), you need a clear recruitment plan.

Related Work: what have others done that is similar? (You need not have related work in the draft version.)

Biggest Risk: what's the riskiest component of your project? (may not be able to get the hardware you need, robustly implementing the ___ algorithm may take too long, the difference between conditions may not be measurable, ...)

For the draft, we expect you to cover all topics in 1-2 paragraphs--be concise but concrete in your descriptions. For the final version, you'll want to go into greater depth (approximately 2 paragraphs for each issue, with the exception of the research question, which should still be be one precise sentence).

We encourage you to iterate multiple times on this abstract. While there is only one formally defined point for receiving feedback from course staff, you should seek out more informal feedback as you work on this. E-mail us at any point if you'd like us to take a look at your current submission, or come to office hours if you'd like to discuss in person. You are free to change directions after submitting your draft, but the sooner you nail down a direction, the better your project is likely to be.

Progress Meeting

On XXX, course staff will meet individually with each project group to provide feedback on your progress. (We'll schedule this a week or so beforehand.) You should be prepared to present your working system, discuss your study plan, and have pilot results. Use the online submission system to submit any materials you'd like to discuss (e.g., prototypes, data, draft writing.) Come to the meeting prepared to show and tell. What will the title of your final paper be? In other words, how will you summarize your research contribution in just a few words? This exercise will helps you focus and sharpen your efforts on what will best address your research question. This focus will be especially important as time gets tight: some things will matter more than others.

Final Presentation

At the end of the quarter, you will present your research results to the class and outside guests. We have invited a couple HCI luminaries. Feel free to invite interested friends and colleagues! Presentations will be on XXX.

Each group has 8 minutes: 5 for the presentation and 3 for questions. This time limit will be strictly enforced – groups should set up during the question session of the group before them. To enable this, unplug the video cable from your laptop before answering questions. Test (and debug) your laptop video projection before presentations begin. Time spent fiddling with display settings will count against your presentation time.

Structure your presentation like a pyramid — begin with a one-sentence statement of your research result. This will get everyone on the same page. Then, offer a short (e.g., 1 slide, 4 sentences) description of what you did and why you did it. Then, explain things in detail.

This presentation is short enough that you can write out everything you want to say long-hand. Do this! This will allow you to convey information efficiently and effectively. Read through it enough times so that you have it basically memorized, but not so memorized that you get flustered if you skip a word or someone asks a question.

Know your audience! You can expect that everyone in the class knows everything you learned in class. So, you don't need to re-introduce the whole field of HCI. A sentence or two to situate your work in the field is good, but spend the rest of the time telling us what you did. When presenting, stand near your slides. And look at the audience.

Final Paper

In addition to the presentation, you will present your findings in a final paper. Final papers should be 2-4 pages long in the UIST format. While this may sound short, it is much harder to write an effective, complete short paper than it is to ramble.A good approach to writing a great short paper is to write a long one first, and then trim it down to the most vital parts. Much of the advice from above for preparing your presentation applies to the paper as well. Here are a few more suggestions for preparing your paper:

Find a paper that you particularly like because of how it's written, and use it as a template. This paper needn't be on the same topic, but a close mapping in terms of type of contribution (e.g. a tool paper vs. a theory paper) will give you more guidance as to how to structure your paper. The title and abstract are the most important parts of a paper, and should clearly convey what you did. Motivate your specific problem (not the field as a whole), and focus on what you did. After reading the abstract, the reader should know what your contribution is – don't speak in generalities. For example, instead of saying "We analyze different methods for preparing cookies with interesting ingredients by running a user study.", say "We present three new recipes for chocolate chip cookies each employing a unique ingredient: jellybeans, tofu, and corn nibblets. Cookies were compared using a blind, within-subjects taste test with 30 individuals. The cookie with tofu was found to have superior mouth feel when compared with the other two, but subjects preferred the taste of the corn cookie by a 2:1 margin."

Review the Project Abstract assignment. Make sure you clearly address each of the important bullets from the abstract in your final paper. Please use the APA heading structure to describe your study & results. Clearly tie your analysis to your hypotheses.

Use pictures to show your interface and graphs to present your data. Graphs should generally aggregate across participants, and show variance. (Only show individual data points if the reader learns something more by doing so.)

Groups who do excellent projects will be encouraged to submit their research to the CHI 2011 Work-In-Progress session These submissions are due January 14 2011.

Tips on Running a User Study

If you have instructions, present them to participants in written form. You'll have a lot on your mind. Likely too much to remember to say everything you want. Written instructions also help insure that everything is consistent across participants.


Credit: This page adapted from Scott Klemmer's CS376 at Stanford.