General Information & FAQ

6.813/6.831 introduces principles of user interface development, focusing on the following areas:

Design. We will look at how to design good user interfaces, covering important design principles (consistency, visibility, simplicity, efficiency, and graphic design) and the human capabilities that motivate them (including perception, motor skills, color vision, attention, and human error).

Implementation. We will see techniques for building user interfaces, including low-fidelity prototyping, input, output, model-view-controller, and layout.

Evaluation. We will learn techniques for evaluating and measuring interface usability, including heuristic evaluation, predictive evaluation, and user testing.

Research (6.831 PhD only). We will learn how to conduct empirical research involving novel user interfaces, and read and discuss current and classic papers from the HCI research literature.

6.005/6.031 or equivalent software engineering experience, specifically:

• programming experience in Java, C#, C++, or a similar language (i.e. not just Python and Javascript);
• building at least one graphical user interface
• working in a small software development team using version control

The class consists of three versions that meet together and share many assignments:

• 6.813U for undergraduates
• 6.831M for masters and MEng students
• 6.831D for doctoral students

In general, the two graduate versions are supersets of the undergraduate version, but different supersets:

Course content. All three courses have the same material on design, implementation, and evaluation. Students in 6.831D have additional material on research methods and HCI literature.

Assignments. Students in 6.813U must submit the programming problem sets (PS1-3) and the written homeworks (HW1-2). Students in 6.831M must submit PS1-3 and HW1-2 plus the analytics assignments (AS1-3). Students in 6.831D must submit PS1-3 and HW1-2 plus the research assignments (RS1-3).

6.831M’s analytics assignments (AS1-3) are a problem set sequence about A/B testing. AS1 will be implementing a B version of a user interface, given an A version. AS2 will be running the A/B test against other users and collecting data. AS3 will be analyzing and writing up the results. Each assignment is designed as a one-week problem set, but AS1 involves implementation which may be challenging.

6.831D’s research assignments (RS1-3) are a problem set sequence about replicating a user study from a published conference paper. RS1 will be implementing the user interface technique and the infrastructure to run the test. RS2 will be running the experiment with users and collecting data. RS3 will be running statistical tests on the data and writing up the results. Each assignment is designed as a one-week problem set, but RS1 involves challenging implementation.

Group project. 6.813U and 6.831M both have the same group project, and students from either version may work together in the same group. 6.831D has a research-focused group project, with groups consisting of 6.831D students.

Studio meetings. 6.813U and 6.831M have group-project studio sections on about half the Fridays of the semester, to present progress and give critique. 6.831D has studio every Friday, to cover the additional material on research methods and research paper reading.

You should generally do the version appropriate to your current degree goal (undergrad, masters, or PhD), but you may upgrade if you wish, i.e. undergrads may choose to do 6.831M or 6.831D, and masters students may choose 6.831D.

Since the courses have substantial overlap, MIT will allow you to get credit for only one of them during your MIT career. Keep this in mind when deciding which course is right for you. You can change your mind and switch to another version any time before Add Date, but not thereafter. Note that if you’re switching between the undergraduate version (numbered 6.813) and one of the graduate versions (numbered 6.831), then you also have to do an Add/Drop with the Registrar. In any case, you are responsible for all the requirements of the version you finally register for.

Readings. Most classes will have a reading that you must read before coming to class, with online exercises that you should do and submit by 10pm the night before the class. The online exercises are designed to be practice for the in-class nanoquizzes, but are not graded for correctness, only for completion.

Nanoquizzes. Each class meeting will include a short “nanoquiz” which covers the content of the current or recent classes. Every full-class meeting will have a nanoquiz, including meetings marked as “work time” on the calendar. Nanoquizzes are closed-book and closed-notes, with a 3-minute time limit. There will be approximately 25 nanoquizzes. Your lowest 5 quiz grades will be automatically dropped, and you can make up missed nanoquizzes or low grades. Makeup instructions can be found in the Nanoquiz section below.

No other quizzes or exams. Aside from the nanoquizzes, there will be no other in-class quizzes, no midterm, and no final exam.

Participation. You are expected to participate actively in class discussions and activities.

Laptops required. In order to participate in quizzes and in-class activities, you will need to bring a laptop to all class meetings. Your web browser should have your MIT certificate loaded in it.

Group project. A major part of the course is a group project, in which you will work in small groups to design, implement, and evaluate a user interface, through an iterative design process with a series of graded milestones (GR1-GR6). Students from 6.813U and 6.831M may work in the same group.

Studio recitations. On about half the Fridays of the semester, the all-class meeting will be replaced by studio recitation sections, consisting of 5-6 project groups and a TA. In studio, the groups will make short presentations to each other and give each other feedback about their projects. Active participation in studio is expected and graded. 6.831D will have studios every Friday.

Programming labs. During the first week or two of the semester (see the course calendar), optional evening labs will be held for students who need an introduction to client-side web programming with HTML, CSS, Javascript, and jQuery. These labs are optional, but they may help you with the programming problem sets and the group project implementation, which are required to be done in HTML/Javascript.

• Course project: 42%, divided equally among GR1-6
• Assignments: 32%, divided equally among the individual assignments for your version:
  • 6.813U: HW1-2, PS1-3
  • 6.831M: HW1-2, PS1-3, AS1-3
  • 6.831D: HW1-2, PS1-3, RS1-3
• Nanoquizzes: 20%
• Participation: 6%, divided among reading exercises (2%), class activities (2%), studio (2%)

Nanoquizzes consist of multiple-choice questions with several options. Each option is worth one point. If you correctly choose the answer when it’s right, then you get one point. If you correctly don’t choose the answer when it’s wrong, then you get one point. This scheme applies uniformly to choose-all-good-answers and choose-one-best-answer questions.

For example, consider a choose-all-good-answers question with choices A,B,C,D, of which only C and D are correct. If you answer C,D then you get 4 points. If you answer A,C then you get 2 points (since you were wrong about A, right about B, right about C, and wrong about D). If you answer A,B then you get 0 points. For example, consider a choose-one-best-answer question with choices A,B,C of which only C is correct. If you answer C, then you get 3 points. If you answer A, then you get 1 point (since you were wrong about A, wrong about C, but right about B).

We automatically drop the lowest 5 nanoquiz grades. If you’re dissatisfied with any of your remaining nanoquiz grades, however, you can earn up to half the lost points for that quiz back, in one of two ways:

• Write a good nanoquiz question for the same lecture. Quiz questions must be multiple-choice (“choose one answer” or “choose all good answers”), and must indicate what you think the right answer(s) should be. Good questions should be relevant to the lecture content, straightforward to answer by someone who read the lecture notes, and hard to get full credit on otherwise. Good questions will generally come from the Knowledge, Comprehension, or Application levels of Bloom’s Taxonomy. Higher levels are better. See Multiple Choice Questions based on Bloom’s Taxonomy for ideas.

• Find a good example for the same lecture. An example consists of an image (often a screenshot of a user interface, but not necessarily) and a paragraph of text, related to a specific topic discussed in the lecture. Don’t riff on the lecture’s hall of fame/shame example, because that’s not considered a specific topic of the lecture.

Make sure you do the right lecture. Nanoquizzes are numbered by the lectures they cover. If you don’t like your grade for Nanoquiz 1, then you should be offering a question or example related to Lecture 1. Note that these makeups are worth only half of the lost points. If you took the nanoquiz and got 8/10, then this makeup can bring your grade up to 9/10. If you missed a nanoquiz entirely and got a 0/10, then this makeup will raise it to 5/10.

The deadline for making up a nanoquiz is one week (7 * 24 hours) after that nanoquiz’s grades are posted. Makeups may not be revised or resubmitted. Only one submission per nanoquiz will be considered. Makeup submissions are reviewed roughly once a week. You will receive an email about whether your submission was accepted.

Submit your questions or examples using the nanoquiz makeup submission form.

Students in 6.813U and 6.831M meet every second friday for studio. The purpose of the studio is for you and your group to get feedback from your peers and your TA on your group project at each checkpoint. To facilitate discussion and feedback, each studio will have only five to six groups.

Students in 6.831D meet more frequently, i.e., every friday. They will also use studio time to get feedback for the group project, but in addition participate in HCI research paper discussions and learn additional material on HCI research methods in the studio.

See the course staff directory below for studio times and locations.

Project presentation and feedback in studio (6.813U, 6.831M, 6.831D)

• Before coming to studio:

  • Draft your writeup for the project checkpoint on the google doc.
  • Prepare a short, 4 minute presentation for studio using Google Presentation (to avoid laptop switching). Share the link with your TA. See examples and suggestions on content and style.

• At the studio:

  • Each group will have 4 minutes to present. You must split this time evenly among the team members.
  • Members of the studio will then have 4 minutes to provide you with feedback on your project.
  • Take notes during the discussion of your presentation and put the important ones on your google doc. Feel free to answer any clarification questions that are being asked, but resist the urge to defend yourself. You don’t have to take every suggestion provided, but you can miss a lot by not listening and reflecting on your peers’ feedback. Resist.
  • When providing feedback, do your best to be helpful and respectful. To facilitate this, we will strive to use “I like,” “I wish,” and “What if” at the start of any feedback we provide. Here are some examples:
  • I like how your user classes are well-defined and clear.”
  • I wish that goals of the users were more varied.”
  • What if you include more information about your user age-groups?”
  • Whenever possible, keep your feedback short and specific. Giving good feedback is HARD. Be mindful, and when in doubt, fall back on being helpful and respectful. We will also practice giving feedback in our first studio session.

• After studio, before the project checkpoint due date on Sunday:

  • Revise and finalize your google doc writeup
  • Complete the self-assessment form (one per group member)

Paper discussion in studio (6.831D)

• At the studio:
  • we will not use any laptops in the paper discussion studio, so please keep them closed and focus on the discussion
  • each week, one of the studio participants will lead the paper discussion
  • the job of the discussion leader is to structure the discussion, raise interesting opposing points, and ideally know something about the topic that goes beyond the two papers everyone has read
• if you are the discussion leader for this studio
  • read the papers and create a google form with questions about the papers
    • use the week 1 example form from us to get an idea of the format: studio reading list
    • we need this google form monday, 8pm, of the week we are reading your paper in studio
  • since you created the form, you will have access to the answers from all participants, use them to guide the discussion in the studio
• if you are a studio participant
  • print out the research papers we will discuss in the next studio
  • read the papers and make your annotations directly on the paper
    • this will help you remember what you read when you come to the studio
    • we will collect them at the end as part of grading participation
  • after reading the paper, answer the questions in the google form linked below the papers on the studio reading list
    • the deadline for filling in the form is thursday evening 8pm, the studio will be friday 1pm.

This topic has its own page: collaboration and public sharing.

To give you some flexibility for periods of heavy workload, minor illness, absence from campus, job interviews, and other occasional (but often predictable) circumstances, you may use limited extensions on problem set deadlines, called slack days. Each slack day is a 24-hour extension on the deadline. You have a budget of 5 slack days for the entire semester, which you may apply to any combination of individual assignments (HW1-2, PS1-3, AS1-3, or RS1-3). You can use at most 2 slack days for a given assignment. Assignments more than two days late will not be accepted. Slack days apply only to individual problem sets, not to group work (GR1-GR6). For group assignments, we will grade whatever you have on your google doc at handin time.

To use a slack day, just submit the assignment late. You DO NOT need to notify the staff. When we grade your assignment, we will see that you submitted late, and dock you the appropriate number of slack days in our records. You are responsible for keeping track of the slack days you’ve used. If you have used up your slack days, or exceeded the 2-day limit for a single assignment, you will need an instructor’s permission and support from an S^3 dean for more extension.

We expect that almost all your needs for extensions will be handled by slack. Only truly exceptional, extreme emergency cases will be considered for extensions after your slack days are exhausted. In particular, to receive said extension you will need to convince the staff that all five of your slack days were used for reasons that would have justified an extension. So use your slack budget wisely. Finally, we want to emphasize that slack days are for emergencies. Plan to submit every assignment on the real due date, and only use a slack day or two if something unexpected comes up last-minute. Do not treat slack days as pre-planned due date extensions. In particular, if you are already using two slack days for an assignment and email us at the end of your second day requesting an extension for a third day, we will probably turn you down.

There is no required textbook. Recommended books:

• Norman, The Design of Everyday Things , 1990.

This little book is a classic work on usability, not just of computer interfaces but also of physical objects like doors, showers, and stoves. Full of great anecdotes, plus theory about how users form models in their heads and how users make errors. Belongs on every engineer’s shelf.

• Nielsen, Usability Engineering , Academic Press, 1993.

Somewhat dated but still useful handbook for discount usability engineering, covering many of the evaluation techniques we’ll be learning in this class.

• Mullet & Sano, Designing Visual Interfaces , Prentice Hall, 1995.

A terrific guide to graphic design, chock full of examples, essential principles, and practical guidelines. Many programmers have a fear of graphic design. This book won’t teach you everything – it still pays to hire a designer! – but it helps get over that fear and do a competent job of it yourself.

Good references:

• Lidwell, Holden, and Butler, Universal Principles of Design, Rockport Publishers, 2010.
• Baecker et al., Readings in Human-Computer Interaction: Toward the Year 2000 , Morgan Kaufmann, 1995.
• Shneiderman, Designing the User Interface: Strategies for Effective Human-Computer Interaction , 4th ed., Addison-Wesley, 2004.
• Diex et al., Human-Computer Interaction , 2nd ed., Prentice-Hall, 1998.
• Olsen, Developing User Interfaces , Morgan Kaufmann, 1998.

Other books we like:

• Tufte, The Visual Display of Quantitative Information , Graphics Press, 1983.
• Raskin, The Humane Interface , ACM Press, 2000.
• Johnson, GUI Bloopers: Don’ts and Do’s for Software Developers and Web Designers , Morgan Kaufman, 2000.
• Card, Moran, & Newell, The Psychology of Human-Computer Interaction , Lawrence Erlbaum, 1983.

Books about statistics and experiment design:

• Gonick, Cartoon Guide to Statistics , Harper, 1994.
• Box, Hunter, & Hunter. Statistics for Experimenters: An Introduction to Design, Data Analysis, and Model Building , Wiley, 1978.
• Miller, Beyond Anova: Basics of Applied Statistics , Wiley, 1986.