6.813/6.831 introduces the 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 only).
We will learn how to conduct empirical research involving novel user interfaces.
Prerequisites
6.005 or equivalent software engineering experience, specifically:
-
substantial programming experience in Java, C#, C++, or a similar language (i.e. not just Python and Javascript);
-
experience building at least one graphical user interface
-
experience working in a small software development team using version control
Course Format
Class preparation. Readings will be available on the course website before each class. You will be expected to read this material in advance and be prepared for in-class discussions and quizzes on the material during the class meeting, described below.
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 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.831G 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.
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.
Paper prototype testing. About 6 weeks into the semester (see the course calendar) is an evening session for groups to test their paper prototypes on each other. Your group is required to participate in this session.
Grading
For students in 6.813U:
-
Course project (GR1-6): 7% each, 42% total
-
Assignments (HW1-2, PS1-3): 6% each, 30% total
-
Nanoquizzes: roughly 1% each, 24% total
-
Participation (reading exercises and class activities): 2% each, 4% total
For students in 6.831G:
-
Course project (GR1-6): 7% each, 42% total
-
Assignments (HW1-2, PS1-3, RS1-3): 4% each, except 2% for RS2; 30% total
-
Nanoquizzes: roughly 1% each, 24% total
-
Participation (reading exercises and class activities): 2% each, 4% total
How to ask grading questions. Giving and getting grades is rarely fun, for anybody involved, and can impede the learning process by putting focus on numbers rather than on ideas, and by distorting the relationship between teacher and learner. Although we seek to grade this class rigorously, as you expect from an MIT class, we don't want to spend class time talking about grades, and we don't want grading issues to interfere with your relationship with your TA. As a result, questions about grades may only be asked in person, at a instructor's office hours. TAs are not empowered to discuss or resolve grading questions. Grading questions asked on Piazza or by email will be summarily referred to a instructor's office hours.
How to Get Help
Before you ask...try to find the answer yourself, using the course website, or the course Piazza forum, or just by searching the Web.
...ask your group's TA mentor, listed on your group's wiki page.
...ask on Piazza. The course staff share the load on answering Piazza questions, so you are more likely to get an answer if you use Piazza. Your question may even be answered by another student, sooner. Note that Piazza is NOT suitable for debugging; for that kind of help, go to office hours.
...or go to office hours. The office hour times and locations are listed on the course's Stellar page. You can go to any TA's office hours, not just your group mentor.
...ask a lecturer during office hours. These questions are not suitable for Piazza or email, and cannot be handled by TAs.
...ask a question in Piazza.
...or ask one of the lecturers.
...write a comment in Piazza.
Nanoquiz Grading
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).
Nanoquiz Alternatives
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 alternatives 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.
Studio
On most Fridays, we will be meeting in studio. The purpose of 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.
See the course staff directory below for studio times and locations.
Before coming to studio, you and your group should:
-
Draft your writeup for the project checkpoint on the wiki.
-
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.
Here is what happens in 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 in your wiki. 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 wiki writeup
-
Complete the self-assessment form (one per group member)
Collaboration
You may discuss assignments with other people, but you are expected to be intellectually honest and give credit where credit is due. In particular, for all individual assignments (HW, PS, RS):
-
you should write your solutions entirely on your own;
-
you should not share written materials or code with anyone else;
-
you should not view any written materials or code created by anyone else for the assignment; and
-
you should list all your collaborators (everyone you discussed the assignment with) on your handin.
You may also use third-party libraries and example code, so long as: (1) the material is available to all students in the class; (2) you give proper attribution; and (3) the assignment itself allows it. In particular, if the assignment says "implement X," then you must create your own X, not reuse someone else's.
Failure to adhere to these policies may result in serious penalties, up to and including automatic failure in the course and reference to the Committee on Discipline.
Lateness and Extensions
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, 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 wiki at handin time.
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 a 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.
Differences between 6.813 and 6.831
Students must choose between the undergraduate course 6.813 and the graduate course 6.831. Each version satisfies different requirements in the various EECS degree programs; see your degree program for more details. This section summarizes the main differences between the two courses.
In general, the graduate version is a strict superset of the undergraduate version.
Course content. Students in the graduate course are responsible for all the material in the undergraduate course (classes on design, implementation, and evaluation), plus additional material (classes on research methods). Some nanoquizzes will include extra questions only for the graduate course.
Assignments. Students in the undergraduate course must submit the programming problem sets (PS1-3) and the written homeworks (HW1-2). Students in the graduate course must submit all of these assignments plus the research methods assignments (RS1-3).
Group project. Both courses have the same group project, and students from either course may freely work together in the same group.
Since the two 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 the other course any time before Add Date (by dropping one number and adding the other), but not thereafter. In any case, you are responsible for all the requirements of the course you finally register for.
Textbooks
There is no required textbook.
Recommended books:
-
Norman, The Design of Everyday Things , 1990.
-
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.
-
Dix 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.
Course Staff
Instructors | |
---|---|
Elena L Glassman
Office: 32-G718 |
elg |
Clayton Sims
Office: 32G-718 |
ctsims |
TAs | Studio Location | Studio Time(s) | |
---|---|---|---|
Ryan C Alexander | ryanalex |
4-257 | 12, 1 PM |
Noor Eddin Amer | namer |
26-168 | 1 PM |
Xiaoxue (Sarah) Liu | sarahliu |
66-144 | 1 PM |
Danielle H Man | daniman |
13-3101 | 1 PM |
Kesiena Owho-Ovuakporie | kesiena |
24-122 | 1 PM |
Tricia A Shi | tricias |
34-101 | 1 PM |
Ami Suzuki | asuzuki |
38-166 | 12, 1 PM |
Jessica Z Wang | jzwang |
56-154 | 12, 1 PM |
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.