There are several possibilities for course projects:

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 the techniques discussed in the readings and in class: 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 company or UW 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 system, while others may involve constructing prototypes only in Macromedia Director or another system. (Alan has a copy of Director by the way.)

We do not want to over-constrain these projects. Almost anything is acceptable as long as it shows 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.

Richard Anderson and Sumeet Sobti have been investigating algorithmic issues around dynamic compression of web page information, with kibbitzing by Alan. The UI motivation for this is that one often doesn't have room to display all of the relevant information on a single web page, and one would like to dynamically compress or elide information, based on such considerations as what information is more or less important, the space available, particular interests of the viewer, desired font size, priorities as stated by the web information provider, and aesthetics.

Here is a typical problem. Metro bus schedules are available on the web (see http://transit.metrokc.gov/bus/timetables.html). The schedules are usually too large to be completely visible within a browser window, and unfortunately the information one needs – the relevant stops and relevant times – are typically not both visible simultaneously, leading to such behaviors as putting a finger on the screen for the right column for the stop and then scrolling the window so that the time for that stop is now under one's finger. (At least that's what I do.) It would be more useful to make sure the needed information is all visible within the screen by eliding information of less interest. Similarly, the results of a book query to amazon.com may not fit on a screen. Can information be selectively replaced by shorter versions or elided?

A related investigation is of table layout: given an html table, how wide should the rows and columns be for the best layout?

Richard and Sumeet have some promising but preliminary results on the algorithmic side, but we need to look at the HCI side as well. It's clear that the problem is real. But what are the best ways of compressing or eliding information for a given domain? This project would probably involve looking at a number of representative web pages, doing mockups of different compressed pages, and studying their usability. Another usability issue relates to the author's task: how can providers of information easily specify alternate text with varying amounts of compression, information that is needed when other information is displayed, and so forth. (If it's too hard to specify and update this information, authors won't do it.)

This project may involve implementation, but could be just a paper design. (In the longer term it could result in an interesting research topic, however.)