CSE 118 Project

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

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 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. Solution approach: an idea of how to realize or test your hypothesis.
  4. Plan: a concrete set of steps, preferably with scheduled milestones, for testing your solution.
  5. Materials: resources required to complete your project.
  6. 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.
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 citeseer, 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. This is an essential element of feature-oriented software development, but the method can be extended beyond software. 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.

The project will culminate in a 5 page paper (ACM format, 10 point font), and a short project 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, unless we all agree on a better time in advance.

Required Milestones

Proposal: Short proposal presentation; turn in supporting research material
Due: Tuesday 10/26
  
Web page: Public site for your project
Due: One week after proposal
  
Final presentation: Extended presentation; turn in supporting research material
Due: Wednesday Dec. 8, 11:30am - 2:30pm

For more thoughts on approaching a project, see my CSE210 project page.

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 (more coming)

You can pursue any project you wish, subject to approval (based on relevance, feasibility, research focus, etc.). Here are some ideas, if you don't have your own. You may want to riff on these ideas, riff on the papers in the readings, or get ideas from someone who might have an interest in what you build. We're just scratching the surface here: