6.893 User Interface Design & Implementation
Fall 2003

GR0: Project Proposal

Due Wednesday, September 10, 2003, in class

The heart of this course is a semester-long project, in which you will design, implement, and evaluate a user interface. User interface design is an iterative process, so you will build your UI not just once, but three times, as successively higher-fidelity and more complete prototypes. In order to have time for these iterations, we need to get started on the project as early as possible.

Project groups may consist of 1, 2, or 3 people. Two is the ideal number, not only because you can share the workload, but also because user testing is easier with two experimenters --- one to run the experiment, and the other to observe and take notes. You can submit a project proposal as an individual, if you like, but we may encourage individuals with similar project ideas to join forces.

You have a lot of freedom in choosing your topic. Here are some guidelines to help you pick a good one.

Your project must have a substantial user interface. A program that merely plays an MP3 file is not enough; a player that allows the user to browse and organize an MP3 collection would be better.
The user interface must be interactive. A web site that is merely a static collection of web pages would not be acceptable; an e-commerce web site with product search and a shopping basket would be better.
Creative, original projects are preferred. There are countless MP3 players and e-commerce shopping baskets out there. If your project falls in a crowded field like that, you should look for a problem in the area that isn't well handled by existing solutions.

Your project might be connected to research that you're doing outside the class. If you or someone in your research group has a system that needs a better user interface, that may be a possible project.

Most projects will probably be desktop applications, but you can propose other kinds of UI if they are appropriate to the problem you're trying to solve: e.g., web sites, speech, handhelds, or ubiquitous computing. It must at least be possible to simulate your project on the desktop, since one of your prototypes will be such a simulation. Don't overextend yourself; if none of your team members have any handheld programming experience, for example, you may want to think twice before proposing a project that requires it. The teaching staff can help a little with alternative UIs, but we don't know everything.

To spark your imagination, here are some examples of possible projects:

Customizable remote controls. An interface that lets a user create and use customized remote control panels for embedded devices, e.g. lights, A/V equipment, home electronics.
Collaborative whiteboard. An interface that allows multiple users to draw pictures or diagrams together across the network. (e.g., a group of students collaborating over Zephyr might use this to work on a project; a family chatting on IM might use it to share pictures of grandkids)
Route planner. An interface that gives driving directions between two points on a map, allowing the user to adjust the route and compare alternate routes easily. Related ideas: walking directions around a campus, directions by subway or bus, directions by wheelchair.
Photo organizer. An interface for organizing, annotating, and sharing digital photos.
Kitchen assistant. An interface that manages recipes and helps the user plan, shop for, and cook a meal.
Block diagram editor. An interface that makes it easy to draw the kinds of block diagrams typically used in computer science (e.g., finite state machines, module dependency diagrams, system architecture diagrams).
Meeting room scheduler. An interface for locating a meeting room with appropriate requirements (size, equipment) and reserving it.
Field guide. An interface that helps birdwatchers identify birds in the field by sight or sound and record their sightings.
Circuit simulator. An interface that lets a student construct, simulate, and debug circuits of logic gates.

What to Hand In

Your proposal should be about a page long, and include the following parts:

Problem. Describe the problem(s) that your project will seek to solve. Take the user's point of view. Consider what the user's goals are, and what obstacles lie in the way. Note the project ideas above are not problems --- they're solutions. For example, "build a customizable remote control" would be an unacceptable answer to this part.
Target users. Characterize the user population that faces the problem you're trying to solve.
Solution. Describe a possible solution to the problem --- i.e., the interface that you envision, and how it will address the problem. You aren't absolutely committed to your solution, since you may find after building and evaluating some prototypes that a wholly different solution will work better.
Group members. List the members of your group.

Only one proposal is needed from each group. It should have all the group members' names on it. Hand it in as hardcopy, in class, next Wednesday.