6.831 User Interface Design & Implementation
Fall 2004

GR0: Project Proposal

Due Wednesday, September 22, 2004, 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 2 or 3 people. 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 good user interface, that may be a possible project. Good projects have also been inspired by other groups or activities around campus that have specific software needs: dorms or living groups, sports teams, activity groups, classes.

Most projects will probably be desktop or web applications, but you can propose other kinds of UI if they are appropriate to the problem you're trying to solve: e.g., speech, gesture, 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 share pictures across the network. For example, 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.
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.
Database merging. An interface that allows a database administrator to map out a transformation between database schemas so that the databases can be merged. Related idea: visualizing file differences and merging them.
Disk space utilization and cleaning. An interface that helps make free space on a filesystem by deciding which files to delete or offload to another filesystem, and which applications to uninstall. Related idea: cleaning up email.
Access permission visualization and control. An interface that helps a user understand at a glance who has access to which of their files and change those permissions easily.
Grade recording and organization. An interface for course teaching staff to record and process grades.

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, two weeks from today.