6.813/6.831 — User Interface Design & Implementation
Spring 2018

GR4: Computer Prototyping

Prototype & report due 11:59pm on Sunday, April 22, 2018.
Presentation due in studio on Friday, April 20, 2018. Submit your individual self-assessment (one per group member) along with your report.

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

You may want to use a prototyping tool for this assignment, such as an HTML editor. 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.

Building your prototype

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.

  • High fidelity in feel.

    This prototype should run on the web, in a recent version of one of the following desktop browsers: Chrome, Safari, Firefox. Make sure you indicate what browser/OS/version combination you have used.

  • Low fidelity in breadth.

    Your prototype should include every feature needed by your scenario from GR2, but doesn't need any features beyond that.

  • Low fidelity in depth.

    You can 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 created in a drawing program) in places where the final implementation would have to draw on the fly (stroke-model or component-model). Use realistic data in your canned displays, however -- in particular, data of a realistic scale. If you were building (say) an MP3 player and your prototype displays only three songs in the user's library, that's pretty unrealistic, and won't adequately test your UI design choices.

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 though 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 PS5 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. The prototype you give to your evaluators must be in HTML/JS, but you can require evaluators to use a particular web browser and OS to ensure the correct appearance and operation of your prototype.

You can assume that your evaluators can find the appropriate platform if necessary. Most people have access to a Windows box somewhere; Athena clusters have Linux and Windows throughout campus; the MIT New Media Center in 26-139 has public Macs.


Google Doc Project Report. Under the section "GR4 Computer Prototype" add the following sections:

  • Platform details.

    Specify the platform and software requirements for your prototype.

  • Instructions.

    Give brief, step-by-step instructions for starting up your prototype. A URL will most likely be sufficient. All Athena users have a public directory which is accessible by the URL http://web.mit.edu/username/Public/.

  • Shallow parts.

    Describe which parts of the prototype are shallow (incompletely implemented or canned), so that your evaluators know what should work and what shouldn't.

  • Studio Reflection. Describe the feedback you got in your studio sessions, and how you will incorporate it into your project.

Note that your prototype must remain frozen (ie, with no changes) and accessible at the URL you provide for two weeks after the due date.

Studio presentation. You must prepare a Google Slides slideshow to present this work in studio. Send the link to your mentor by 12pm (noon) on Friday. You can find example slides here. Each member of the team should participate in the presentation. Take notes during the discussion of your presentation and put the important ones in your report.

Self-assessment form. Complete your individual self-assessment forms by the deadline.