GR2 - Designs

Scenario

Ben Bitdiddle is an M.Eng. student, and he has been appointed as a 6.006 TA. On Wednesday 3/2, Ben needs to post Problem Set 2, due in one week on 3/9. The assignment has 2 theory problems, and one problem that requires coding. Ben prepared a description in PDF format. For the programming problem, he also prepared some input test cases, and Python script to automatically test the students’ submissions. Ben logs on the site, creates a Problem Set, and uploads all files in the right places. He uploads the TA solution, as well as a broken solution, to make sure that his automated tests work as intended. Once Ben is pleased with the results, he makes the Pset visible to students.Alyssa P. Hacker is a sophomore living in Random Hall. Alyssa checks the site and notices the announcement that PS 2 is out. She reads the PDF description, and finds an error. She e-mails Ben, who acknowledges the error. Ben must upload a revised PDF description, and make an announcement that would be visible to anyone who tries to submit a solution.Alyssa finishes the coding problem that evening. She submits her Python program on the website, and finds out that her solution takes too much time to run on the automated tests. She removes her debugging checks, and re-submits. The site assures her that she has passed the automated tests, so Alyssa starts working on the write-up. Later that night, she submits her PDF write-up.PS 2 is due on Wednesday 3/9 at midnight, and the server chugs through the usual last-minute submission rush. Next afternoon, Ben prints out students’ submissions, and starts grading them. Wednesday late at night, he finishes grading. He logs on the submission site, and goes through the stack of psets in front of him, entering the grades on the site. After he’s done, he makes all the grades public.Alyssa goes online on Sunday, and sees her grade for the problem set posted. She also checks the distribution of grades for the problem set, and her overall grade. Louis Reasoner is a senior who recently settled on Course 18C, and is trying to graduate. Prof. Smith signed an Add Form for Louis, and granted him an extension for the two problem sets. Ben pointed Louis to the submission site. Louis signs up for an account, registers for the class, and prints out the two problem sets. He eventually submits everything, after having gotten an undisclosed amount of help from Alyssa.Monday morning, Ben goes through the late submissions, from students who were granted extensions. He prints them out, grades them quickly, and enters the new grades on the site.

Designs

Design 1

With the exception of the login page, the following images depict the interface the the users would typically see after they've filled out all of the desired information. The pages of the interface all follow the same general UI principle of the three-pane view popularized by Apple's Finder. The user first chooses the assignment, then the user, and can then view or modify that user and assignment combination. TAs can assign grades, and students can see their own grades, for example. The three-pane view traditionally supports keyboard interaction. The user can use the arrow keys to navigate the panes (problem sets and users), and press enter to go into edit mode (indicated by visual feedback).

	The user logs in with his or her MIT certificate. Since all of our users are MIT affiliates and use MIT certificates to access WebSIS, they are all guaranteed to have them installed. After they've logged in, they are encouraged to fill out their profile so that the graders have an easier time classifying problem sets. Course administrators are promoted from ordinary users by existing course administrators.
	Ben, the TA, can access a summary of all problem sets for a particular user (their grades) or for himself (grading statistics). Ben can also add a new assignment, specifying the title, due date, the assignment file, and any test cases that would auto-grade the students' submissions. Ben also has the option to publish this assignment to the students and release grades after they've been completed. In addition, TAs can post updates to problem sets, along with a message.
	Alyssa is a student, and she can view assignments and submit her solutions. She can download the assignment files, upload a submission, and view her own grades as well as the class grade histogram. For coding assignments, each submission is graded automatically using the test script. If the tests fail, then an explanation and a stack trace would be shown.
	The TA can grant an extension to the student simply by changing the due date for the problem set. In this sketch, an extension was granted to Louis by rcm. In addition, the TA can look at each student's score and submission summary.

Learnability: This interface is very learnable -- most of the pages follow the same three-pane layout. Even within a page, the hierarchical options are consistent -- the user can deduce what the other options do based on the current option. Mac users will instinctively grasp the keyboard shortcuts that we plan to include (arrow keys to move around problem sets and users, enter to toggle edit mode -- with corresponding visual feedback). Other users will likely try to use the keyboard, we speculate, as it’s very universal and established (even Norton Commander used something similar back in the days of DOS).
Visibility: The state of the system is always visible to the user, because all of the components of the state are on screen: the three panes present the choices of assignment and student, as well as the information about the item corresponding to that combination. All of the features are always visible within one page. The user is able to explore one assignment and can see that he or she has access to the other assignments. Similarly, when grading, all of the other people in the class are visible to the TA. The currently selected set of options is highlighted with a color, as shown in the sketches. Visual feedback will be available for the keyboard shortcuts to indicate, for example, entering edit mode. The menu items on the left side offer information scent about when they should be clicked -- for example, the “Assignments and Grades” link receives a (1) when there’s one new problem set available.
Efficiency: TAs can quickly transition between students when grading. Students can in turn quickly explore all of their assignment submissions and grades. In addition, students and TAs can see the submission status via intuitive colors -- the student's name is highlighted with green for submitted, white for not submitted, yellow for late, and red for not submitted. All of the options are aligned, so that the user can explore. This interface lends itself naturally to keyboard shortcuts like in the Mac's Finder. These shortcuts can greatly increase efficiency for grading, for example.
Errors: Errors can be easily undone in this interface. If a grade was mistyped, then the user can simply retype the correct one. If the wrong file was submitted for an assignment, the student can simply overwrite the old file with a new one. In addition, we will enforce constraints such as forcing grades to be less than or equal to the maximum grade, with an alert being displayed if they're not.

Design 2

The top level of the interface is divided into three tabs - calendar, profile, and classes. The calendar view shows the class schedule and problem set deadlines. The profile page displays users' basic information and class registration information. At registration time, each user indicates whether they’re a student or part of the class’ teaching staff. The class view is divided into two tabs: problem sets and grades. The information under the class tab is further divided into lower-level tabs. The views on problem sets, grades, and students present their information using tables.

6.813/6.831 User Interface Design & Implementation > CourseWeb Seven GR2 -- redo > ben1.png

Learnablity: tags on the same level are very distinguished, so that users can know where to click easily. Psets and students’ grades are organized in tables. Users can click the column title to sort information in order. For psets, there are also short-cut control buttons in each row. To view detailed information, e.g. grades, there are always direct links to the detailed page.
Visibility: there are detailed statuses and update date for pests and students' submissions. When users make a change, the status will change as well. Also I tried to put short-cut buttons on the top-level views, so users can easily find them.
Efficiency: the problem with this design is that there are four levels of tags. To make the interface more efficient, I tried to make more direct links and short-cut buttons for frequent tasks.
Error: status will help users to discover errors more easily (e.g. when users forget to upload a file, the status of the pset won't change.)

Design 3

The drawings below illustrate the various screens that would be encountered during the scenario above.

	The registration form shows all the information that is needed. Having everything on one page eliminates complex cases of half-registered accounts, and reduces burden for TAs. Students are either registered, or not registered. This version recognizes that mobile devices don't support MIT certificates, and provides multiple login options. This comes at the cost of learnability, as some users might think they need MIT certificates, and a Facebook account, and an e-mail / password pair to register. The form's efficiency heavily relies on AJAX requests. For example, once the user's e-mail is known, the backend will do a MIT directory lookup, and pre-fill the personal information section.
	Logged in users see a navigation bar at the top of the screen. The bar points to everything that the user can do on the site, with the downside that some destinations require multiple clicks, so we slightly favor visibility over efficiency. The bar's efficiency can be improved by adding direct links to the current problem set and log out. Sadly, my handwriting is equivalent to using 40pt font at this prototype's scale, so further tweaking will have to wait until we build the computer prototype.
	TAs see one extra menu, Admin. This has the advantage that former students who might have used the site will quickly realize where the new options are. It is slightly inefficient, because all the TA operations will go under one big menu. Fortunately, TA operations are usually complex (e.g. creating a problem set description) and one long menu isn't as critical to speed as it would be for students.
	Problem set creation takes a similar approach to registration: all the required information is in one big form. All the problem sets are available on the page, because it is handy to copy-paste information, such as a file's description, across problem sets. To keep the page manageable, problem sets are presented in an accordion, and each section in a problem set can be expanded or collapsed, following the progressive disclosure pattern.
	Each problem set gets its own page, similar to Facebook profile pages, where relevant information is grouped into a few tabs. Pages display announcements by default, so that students can acknowledge the bug fix announcements before they waste time due to fixed bugs. When the announcements tag is not focused, announcements show up as desktop notifications.
	The grading UI is optimized towards the operation of entering grades for many students on the same problem set, after a grading session. The UI is very spartan, to allow for many students' entries to fit on one screen. Entering anything in a name field will activate the auto-completion, and will add another student row at the end of the form. When a student is selected, the grade fields are displayed on the right side of the student's row. Most importantly, the main data entry task above can be completed without using a mouse. This clearly trades off visibility in return for efficiency. This design relies heavily on transitions for learnability.