GR4: Computer Prototyping
Due at 5:00pm on Wednesday, April 9, 2008, on the wiki.
Overview
In this group assignment, you will do the first computer-based
implementation of your term project.
You may want to use a prototyping tool for this assignment --
such as a GUI builder if you're writing a desktop application, or an
HTML editor if you're building a web application. You don't necessarily
have to throw this prototype away, so you can choose a tool that will
produce code you can use in your final implementation. But you shouldn't
get too attached to this prototype either, and be prepared to make
radical changes or throw it away if evaluation reveals serious usability
problems.
Your computer prototype should consist of a horizontal prototype
of all features needed by your scenarios (broad but shallow), plus a
vertical prototype of one particular part of your interface (narrow and
deep). Choose the riskiest part of your design for vertical prototyping.
A feature might be risky because of its user interface; GR3 gave some examples of user interface risks. Or
it may be risky because of its backend implementation: maybe it's a
complex algorithm to implement, a big library or system component that
you haven't used before, or maybe you don't know if the backend you're
thinking about using will be fast enough. Think about both frontend and
backend risks when judging which feature is worth prototyping deeply.
You've already thought about the frontend risks in GR3, and we've given
you some ideas about what we thought were the risky parts in our group
meeting.
Your 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.
- Medium fidelity in feel. This
prototype must 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. But you don't have to implement
all your input interaction techniques, such as drag & drop or
direct manipulation (unless this is the risky feature that you're
implementing deeply).
- Medium fidelity in breadth.
Your prototype should include every feature needed by your 3 scenarios
from GR2. In addition, your prototype should include every major screen
you expect to have in your final implementation.
- Mixed fidelity in depth:
shallow for most features, but deep in one risky area. Leave out most
of your backend. Where system responses are needed, make them canned
(i.e., always the same) or random. Consider using static images
(pixel-model output that you drew in a drawing program) in places where
the final implementation would have to draw on the fly (stroke-model or
component-model). But implement your chosen risky feature deeply and
thoroughly.
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 layout for that size (using either automatic layout or even
absolute positioning). Your final implementation probably should support window resizing,
depending on your application, but you should decide how to make your
interface's default look as good as possible, before worrying about
variation.
- Platform independence. Even if
your final implementation will run on multiple platforms -- different
browsers, different operating systems -- your prototype doesn't need to
look good or work well everywhere. Focus on one platform for now.
After you hand in your prototype, it will be distributed to at
least four of your classmates, who will do heuristic evaluations of it
for assignment HW2 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 (Firefox, Opera,
Safari, Internet Explorer). 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.
- Windows, Linux, Solaris, or
MacOS X executable. You can assume that your evaluators can find the
appropriate platform if necessary. Most people have Windows boxes at
home; Athena clusters have Linux, Solaris, and Windows 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 the course staff first.
What to Hand In
Add the following section to your project's wiki page:
- GR4 Computer Prototype. This
section provides instructions for accessing and starting up your
computer prototype, both for your classmates who will be evaluating
your prototype and for grading purposes.
- Specify the platform and software requirements for your
prototype.
- Give brief, step-by-step instructions for starting up your
prototype. For web sites, a hyperlink to the site is sufficient. For
JAR files or executables, say how to start the program.
- Describe which parts of the prototype are shallow
(incompletely implemented), and which are implemented deeply, so that
your evaluators know what should work and what shouldn't.
- If your prototype must be downloaded, like a JAR file, put it
in a place where it can be downloaded over the Web, and include a link
to it in your wiki. All Athena users have a Public directory which is
accessible by the URL http://web.mit.edu/username/Public/.
- Your prototype must remain frozen (no changes) and accessible
at this location for two weeks after the due date.
- Your prototype should be downloadable as a single file.
Package multiple files into a ZIP archive for easy downloading.
[an error occurred while processing this directive]