CSE 118 Research Project

A principal component of this class is a team research project. The purpose of the project is several-fold:

You can pursue any project you wish, subject to approval (based on relevance, feasibility, research focus, etc.). You can come up with an original idea of your own, you can draw on the suggestions below, or you can replicate a published project (or a specific part of one) from the literature. To come up with ideas, you may want to riff on the papers in the readings, get ideas from people doing research that's interesting to you, and discuss ideas with your peers.

The project will culminate in a presentation that will highlight the parts of your project that are hard to present in writing (e.g., a demo). If you build something, your presentation should include a demo of what you built. This presentation will be held during the scheduled time for the final.

Milestones

Week 1 (suggested)
Wednesday, 9/28
Form groups
Week 3
Wednesday, 10/12
Motivation and claim (draft)Turn in written draft
Week 4
Wednesday, 10/19
Related work and bibliography (draft)Turn in written draft
Week 5
Wednesday, 10/26
Research questions(s) and solution approach (draft)Turn in written draft
Week 6
Wednesday, 11/2
Proposal Short presentation [template]; turn in written proposal
Finals week
Tuesday, 12/6
11:30am-2:30pm
EBU3b 1202
Final presentation Extended presentation[template, rubric, schedule]; turn in peer assessments and any supporting materials

Proposal

Required compontents

Your project proposal needs to have the following components:

  1. Motivation: a description of a problem that is of importance to people.
  2. Claim: a statement of how you believe this problem could be addressed.
  3. Related work: a description of prior approaches to addressing this problem (or similar problems) and how your approach is different, novel, and/or better.
  4. Research question(s): a focused question (or small number of questions) describing the goal(s) of your research. What are you trying to find out?
  5. Solution approach: a plan for how to realize your proposed solution and test your hypothesis — design, implementation, evaluation, etc. Use your research question(s) to focus your approach.
  6. Timeline: a concrete set of steps, with scheduled milestones, for testing your solution.
  7. Materials: a list of resources required to complete your project.
  8. Risks: a list of potential causes of project failure. Not failure of your hypothesis, but failure to test your hypothesis. In our setting, most risks involve events that cause delays. In other words, most risks mutate into schedule risks.
  9. Bibliography: a list of references to background material, related work
More details and suggestions

Projects are by their nature positivist. To summon the energy to undertake a project, you must believe--at least for a while--that it can make a difference in people's lives. Even if this project itself doesn't succeed, you need to believe a little that it could be an important stepping stone to success.

The cornerstone of your project will be a research statement, typically provided in the form of a hypothesis or claim. For example, ''We hypothesize that ubiquitous instant messaging can ameliorate modern alienation.'' That's pretty ambitious, but given such a claim, you could undertake a smaller project that addresses a subclaim.

Your project does not need to be an implementation, but it does need to be empirical. That is, your project has to directly engage the phenomena of ubiquitous computing or its current antecedents as a way of testing your hypothesis. For example, you could investigate current uses of instant messaging on a university campus as a way of gaining insight into the potential for ubiquitous instant messaging.

Your project should be informed by the insights of your predecessors. In particular, you should do background research to construct your motivation, drawing on previous successes and failures to justify your motivation and lend credibility to your claim. An excellent starting point is the papers we've read (or will read) in class, but you'll want to dig further into the literature than the few papers we've read. Good literature searching and reading skills will be critical to success. We don't want to reinvent the wheel...especially a square one! A good way to extend your literature search is to check the citations in the papers we've read, as well as papers that cite the papers we've read. To find these, perhaps use google scholar, for example.

Your motivation and design should also be justified by experience, where possible. Thus, empirical techniques such as observation of use of predecessor technologies, low-fidelity prototyping, and deployment of working prototypes is highly recommended. From these, relevantly contextualized critiques of prior technologies and your own solutions should be possible.

Successful projects are obsessed with avoiding and resolving risks. Here are some things that can go wrong:

A key to success is being able to quickly detect when one of these is happening. Thus, regular (weekly) milestones with measurable objectives are a valuable mechanism for bringing problems to light early.

A related key to success is to divide your project into incremental deliverables, with each deliverable increment being a useful end-result as well as a suitable basis for further progress. A simple method is to start with your original idea and then ask, what can we take out? Bit by bit, you can remove system (project) requirements or features, until all that's left is the essential core. The deliverable of the essental core should be well before the final presentation deadline, giving you plenty of room for error.

Finally, modesty is a good quality. No matter what project you choose, it will be harder than you anticipated. If it turns out to be easier, you'll have time to add valuable incremental deliverables, perhaps in the form of insightful user tests.

Project Resources

Hardware.

Some of you are probably hatching projects that require some kind of sensor. You can use your phones or the PDA's to sense a number of things, or a laptop, perhaps with an add-in card:

You may have to search Google in order to find the hardware and driver patches that you need to get everything to work.

Software. There is lots of software out there for your use. In general it is hard to use, either because it it is low-level, complex, or immature. This is the nature of research. The list below will grow over time, and you may find your own resources. Please let me know if you find something interesting:

Project Ideas

Here are some project ideas and contacts. You can either get involved in an existing research project or start a new one. You can work on an idea that you come up with or get suggestions from others.