6.893 User Interface Design & Implementation
Fall 2003

GR3: Computer Prototyping

Due 12:30 pm, Wed October 15, by email

In this group assignment, you will do the first computer-based implementation of your term project.

Your computer prototype should be:

High fidelity in look. Use this prototype to explore the graphic design of your final implementation. Lay out screens as you want them to appear in your final implementation. Make choices about colors, fonts, alignment, icons, and white space. Your prototype need not be pixel-for-pixel identical to your final implementation, however. For example, the prototyping tool you choose may draw standard widgets like buttons and scrollbars differently than your final implementation.
Medium fidelity in feel. This prototype will run on a desktop computer with a mouse and a keyboard. For most projects, the desktop is the target setting, so your prototype will approach high fidelity in feel. For pen-based or handheld projects, the mouse will only approximate the feel of the final implementation. Also, your prototyping tool may not support some interactions with high fidelity, such as drag & drop. That's OK. You can simulate these interactions with a little animation, or at least with a popup that describes in English what would happen.
Medium fidelity in breadth. Your prototype should be able to handle at least the 3 scenarios you described in your task analysis. In addition, your prototype should include every major screen or dialog you expect to have in your final implementation.
Low fidelity in depth. Don't implement any backend. Where system responses are needed, make them canned (i.e., always the same) or random. Write minimal code, ideally none at all.

Here are some issues you should not worry about in this prototype:

Window resizing. When a window is resized, its layout has to adjust to respond. Don't worry about this for now. Determine a good default size for your windows and design a good fixed layout for that size, using absolute position for controls. Your final implementation probably should support window resizing, depending on the task, but you should decide how to make your interface's default look as good as possible, before worrying about variation. Those of you building handheld interfaces may not need to worry about window resizing at all.
Platform independence. Your final implementation may need to run on multiple platforms -- different browsers, different operating systems -- but your prototype doesn't need to look good or work well everywhere. Focus on one platform for now.
Reusing code for your final implementation. Plan on throwing this prototype away. We don't require you to use a prototyping tool that's different from your final implementation toolkit, but doing so would help discipline you to discard it.

After you hand in your prototype, it will be distributed to at least two of your classmates, who will do heuristic evaluations of it for assignment PS3 and give their reports back to you. Since your evaluators must be able to view and interact with your prototype, this puts some constraints on how you implement your prototype. It must run on a conventional desktop computer with a mouse, keyboard, and screen, running at least one of the common platforms at MIT (Windows, Linux, Solaris, Mac OS X). The prototype you give to your evaluators can be any of the following:

Java JAR file. All four platforms can run Java programs.
HTML. All four platforms have web browsers that support modern HTML and JavaScript (Internet Explorer, Mozilla, Opera, Safari). You can require evaluators to use a particular web browser to ensure the correct appearance and operation of your prototype, as long as the browser is commonly installed on at least one of the four platforms.
PowerPoint presentation. Windows and Mac OS evaluators can use PowerPoint or the free PowerPoint viewer to interact with it. Linux and Solaris evaluators could use the free StarOffice or OpenOffice, which are installed on Athena.
Flash animation. All four platforms have free Flash players.
Windows, Linux, Solaris, or MacOS X executable. You can assume that your evaluators can find the appropriate kind of box if necessary. Most people have Windows boxes at home; Athena clusters have Linux and Solaris throughout campus; the MIT New Media Center in 26-139 has public Mac OS X boxes.

If you want to hand in your prototype in a format not listed here, check with Rob & Jaime first.

What to Hand In

By 12:30 pm on Wednesday, October 15, you should hand in a report (electronically) with the following parts:

URL for your prototype. Put your prototype in a place where it can be downloaded, and include its URL in your report. All Athena users have a Public directory which is accessible by the URL http://web.mit.edu/~username/Public/.

Your prototype must remain frozen and accessible at this location for two weeks after the due date.
Your prototype must be downloadable as a single file. Package multiple files into a ZIP archive for easy downloading.

Startup instructions. Specify the platform and software requirements for your prototype. Give brief, step-by-step instructions for starting it up.
Briefing (from GR2). The briefing you gave to users of your paper prototype describing the purpose of your application and background information about the domain.
User analysis, task analysis, and scenarios (from GR1). For scenarios, use the stories you told in GR1, not the abbreviated index-card tasks you used in GR2. You don't need to include the sketches from GR1, since the prototype now stands in for the sketches.

Your report wil be graded by us. Copies of the report will also be sent (without our grading feedback) to your heuristic evaluators. The components from GR1 and GR2 are included for the sake of your heuristic evaluators, to help them understand and evaluate your application in context.

Send your report in PDF or Postscript format by email to both Rob Miller (rcm@mit.edu) and Jaime Teevan (teevan@ai.mit.edu).