Project|
CSE510
Project |
An essential part of the course will be a class project. The project should be done in groups of 2 to 4, because many of the techniques are easier to employ with two or more experimenters, and to allow more ambitious projects to be done and to bring several perspectives to the project.
Feel free to use the class e-mail list to send out match-making messages looking for project partners or ideas.
Important!! It's essential to get going on your projects very early in the quarter -- doing iterative design, rapid prototyping, and user studies are things that can't be completed all at the last minute.
There are several possible kinds of course projects:
Below are some more details on the different kinds of possible projects. If you are interested in something else, ask!
Usability evaluations will employ one or more of the techniques discussed in the readings and in classs. The study could be done in an outside organization, or it could be done at UW. This is probably the most straightforward option, since it doesn't involve implementation. Select a system or application, and evaluate the software from a usability perspective. Use a combination of contextual inquiry, ethnographic studies, informal experiments, and usability inspection (such as heuristic evaluation).
Design and prototype an interface for a software system, or modify an existing system, with particular emphasis on the user interface and its usability. As with the first possibility, use a combination of the techniques discussed in the readings and in class to evaluate the system, and combine this with iterative design. The system might be a part of an ongoing research project you are involved in, or might be new.
We expect that such projects will be done on a variety of platforms. Some will involve constructing working interfaces to an existing or new system, while others may involve constructing paper prototypes only, or prototypes in Macromedia Director or another system.
We do not want to over-constrain the implementation projects. A wide range of systems are acceptable as long as they show a reasonable application of techniques and skills learned during the quarter. The project should include and show evidence of extensive brainstorming, storyboarding, domain analysis, experimentation, paper mockup development before beginning any coding. After an initial prototype has been developed, we expect to see user testing and analysis of these tests. The purpose of this project is not to develop a working product, but rather to experience and practice the HCI design cycle. In a sense, we would prefer that you not to invest too much of yourselves into the finished product, because we want you to be able to be critical and realistic about what you have accomplished and how it could be improved. A prototype with limited functionality that shows evidence of solid design and evaluation practices is far preferrable to a snazzy but poorly designed project. An excellent strategy would be to prototype several alternatives, and compare them.
For projects of this kind, investigate a novel technology that is believed to be useful for HCI applications. Some diverse examples are wearable computers, constraint-based layout systems, intelligent agents for information retrieval and filtering, or phycons (physical icons). The initial impetus for this type of project will come from looking for useful applications of a technology. However, after picking the technology, as with the other project types, these projects should have a user-centered focus -- investigate how the technology would be useful to real users in their work. Your investigation should include a combination of iterative design and prototyping -- although given time constraints you might use mockups of the design for evaluation, and separately experiment with the implementation.
If your project is purely an educational exercise rather than a research project, it does not fall under the requirements of the UW Human Subjects Division (see Human Subjects Review Information for CSE). So in this case you don't need to get signed consent forms from your participants or Human Subjects approval. However, in other respects please treat this as you would a research project involving human subjects. In particular, obtain their informed consent to participate, and tell your participants that it is the system being tested rather than them and that they can stop at any time. Also, respect the confidentiality of the participants by handling the data carefully, and by not including any identifying information in your project description and presentation.
However, if your course project might result in publishable research or otherwise feed into a research project, then other Human Subjects issues do arise. There are two ways to proceed. By far the more practical approach is to proceed with the course project as just an exercise. Then, at the end of the class, if it looks promising as a research project, the course project would be regarded as a preliminary investigation - not publishable on its own. One would get the necessary HS approvals, and redo the user studies to get publishable data. The other approach would be to get Human Subjects approval for the project before doing any studies involving humans. This would mean that you could use the data from the studies in research -- but it is unlikely that such approval could be obtained in time for this class. If it looks like a situation of this sort might arise, please talk first with Alan about how to proceed.
By April 18 please post a short description of your project to the online project discussion area describing your project, including the group members, type of project and topic, and methodology to be used. Just post one description per project (rather that one from each participant.) One of the staff will respond to each of these posts with comments, and of course other class members can as well. If you prefer, you can send your description as a message just to the staff and we'll respond by e-mail. However, in this case you won't get the same feedback from other students in the class -- so we recommend using the EPost discussion area instead.
We will have short presentations and discussion of project proposals in class on April 20. Batya Friedman from the Information School will be attending as well.
Each group should turn in a written report on the project. (The report length is flexible; use what you need. We're expecting 5-15 pages.) The complete report is due June 6. If you would like some early feedback, you can also optionally turn in just introduction and method sections earlier, and I'll read this and give you comments.
Project presentations will be June 1, and if needed June 8 (during finals week, in the final exam slot for the class).