Designs

Scenario

Paul Quimby is a second semester freshman who is trying to choose a major. He's decided he wants to be course 6-3 and is excited to plan out his remaining 3 years at MIT. Paul needs a tool to help him do this, so he's decided to try out our program. Paul must first specify that he wants to be Course 6-3 to ensure that he fulfills the requirements. He then must input the classes that he's already taken (and is taking) for the first 2 semesters. From this starting point, he needs to create a map. Paul uses the automated features of the program to generate a schedule. He then makes manual adjustments based on classes he doesn't want to take together and classes that he wants to take with his friends. He also wants to go out for the baseball team in the spring, so he wants to limit his spring semester to 48 units, but he's okay with taking up to 60 units in the fall.

1.5 years later...

Paul is now a junior and 2 of the classes he was planning to take in the fall have a conflict, so he must postpone one. He logs in to the program. He first marks and updates all of the classes he has completed over the past year. He decides which class to keep, and notes that the other  cannot occur in the Junior year fall semester. He then uses the automated tool to help him generate a new schedule.

Designs

Design 1:

Paul begins by launching the FourPlan program. The initial screen prompts him to either create a new map or open an existing map. Whereas this is his first time ever using the software, he presses the ‘NEW’ button.

Before the application can generate a course map, it prompts Paul for some basic information about the degree (degree start year, graduation year, major, and concentration in the major). These fields are filled using combo-boxes, allowing Paul to select the data from lists. After he selects his major, the combo-box for ‘CONCENTRATION’ is generated with valid values pertaining to the major. When all of the fields are filled, Paul presses the ‘CREATE’ button. This solves some initial constraints and builds him a basic course map.

The map takes up the majority of the window providing a physical representation of each of the courses. The courses are arranged in columns, where each column relates to a semester. This UI design follows a Direct Manipulation approach. Though some courses may be fixed in place due to hard constraints in the curriculum (these courses are displayed in a different color to illustrate their fixed status), all other courses can be clicked and dragged around the map. On the map, each course is represented as a bubble that has some basic information about the course.

Clicking on a course will open more data about the course in the left-hand pane. The figure below shows the result of Paul selecting 6.005.

In the course pane, Paul can modify properties of the course entry. This allows him to jump the course to a different semester, note a course’s completion, and provide a grade for the course. For 6.005, he sets the FIX ON MAP field to YES. This guarantees that when changing other courses around, the constraint solver does not move 6.005 to a different semester.

At this point, Paul can edit his map in several ways. First, he can drag courses around to various semesters until he is happy with the results. Second, he can select and drag the ‘NEW COURSE’ from the top left onto any point on the map. This allows Paul to enter additional electives that the map did not populate. When adding the new course, it is added as a dummy course. Paul must select it and edit its data in the Course Pane. You can see below what happens when Paul creates a new course object when trying to add 6.813.

The last way in which Paul can update the map is to use the map comparator. He does this by selecting ‘COMPARE MAPS’ from the menu. This generates a second map containing the same courses but in a different layout. These two maps are different views for the same model and thus Paul can set the ‘FIX ON MAP’ field for each of the courses on the either of the maps. When he is done modifying the maps, he selects ‘MERGE MAPS’ from the menu, which attempts to merge the maps into one, solving any new constraints. The back end will prevent Paul from creating any conflicts (ie. not allowing him to change the fix status on one map, if it is already fixed on the other).

When Paul is done creating his map, he selects ‘SAVE’ from the menu and exits the program.

Later, when Paul is faced with his scheduling conflict, he relaunches FourPlan and is once again faced with the initial screen. This time he selects ‘OPEN’ and is shown his old map. The first thing Paul does is select each of the courses he has taken and edit their ‘COMPLETED’ and ‘GRADE’ fields. He then proceeds to resolve his conflict. He does this by selecting the course which conflicts and changes its ‘FIX ON MAP’ field to ‘CHANGE’. This forces the constraint solver to push the course to a future semester and thus pulls a new course over to the current semester. Another option would have been for Paul to click and drag courses around manually to resolve the conflict. When Paul is happy with his map again, he selects ‘SAVE’ and exits the map.

Design 2:

Paul launches FourPlan and the following window greets him. He selects Course 6-3 as his major, inputs 2008 as his entrance year and 2012 as his expected year of graduation, and presses continue.

Paul then sees the main window of the application. On the right is his current schedule. It initially starts out empty with 4 boxes (representing classes) per semester. On the left is a list of the MIT courses. Paul can scroll through this list or search. Items can be added to the schedule by dragging the line in the list on the left to the space on the right. The figure shows the outcome of dragging “6.01” to a specified box in Semester 2.

The requirements tab on the left lets Paul see all of the requirements that he has not added to his schedule. Paul can also add courses from this list by dragging. Here, we see that Paul has added all of the classes he has already taken to the schedule. He has clicked the lock for each. (Since he has already completed the courses, their positions in the schedule are locked.) Paul can also use the lock to “fix” the positions of courses as he adds them to future locations in the schedule.

The next figure demonstrates how one can expand each requirement to see more information and specify things like which semester they want to take the class.

The wishlist tab lets Paul select classes that he wants to take outside of the requirements list. For example, here he could specify what HASS classes he wants to take (or a broad list he’ll choose from) and the scheduler will work to fit them in among the requirements.

Paul could create his schedule by hand, clicking and dragging all of the courses into slots, but he decided to use the automated tool to help him out. He does this by clicking the Auto-Generate button in the upper right corner. A window like the following appears. The current and proposed schedules are set side-by-side. The changes in the new schedule are highlighted (or in this case, starred). Paul can choose to accept changes or not. He can also accept only selected changes by using the checkboxes. By selecting “Accept” the new schedule will be displayed in the main window.

When Paul has advanced in his academic career and encountered a conflict, he can open the program and will see the same schedule where he left off. Paul will need to click the lock icons next to the classes he actually took to confirm their completion, or update the courses accordingly. To resolve the conflict that has occurred, Paul must first select which class he wants to keep. He can then edit the course preferences (using the button in the top right) as shown in the following figure. This will let the user specify fine level controls, such as “NOT in Fall 2011”.

Paul can continue to iterate on the schedule (using both the manual and automated methods)  until he is satisfied with the result. (At least, until the next conflict...)

Design 3:

Paul launches FourPlan and a wizard begins asking him questions about his preferences for scheduling, citing reasons why these questions are relevant. Questions include previous classes he has taken, what classes he wants to take, and other questions that the constraint solver thinks are useful. If Paul doesn’t want to answer a question or thinks it will be irrelevant later, he skips it. A typical question might look like figure 3-1.

A different template will be needed for different types of question such as “Yes/No”, “Yes/No/Maybe”, “Select X of Y”, “Search for X from BigY”, “Enter X”, but there is a small finite list of these question types that can be used with dynamically generated data from a constraint solver. All elements in these questions that refer to definitions or external links should provide links to definitions (like the term “AUS”) or use a mouseover display to display information about a course.

After a while the system thinks it has enough information to plan out a schedule Paul will like and Paul is shown a proposed schedule in a new interface. For each course, Paul can see a list of reasons why the system thinks each class should go where it suggests, showing other options for where it can go. Paul decides to make some preference changes so he uses a direct manipulation metaphor to drag and drop classes from one semester to another, but the vast majority of his schedule has already been generated to his preferences. Viewing his schedule looks something like figure 3-2.

A year later Paul decides to use FourPlan again and is asked some questions about the events that have happened in the year between his last plan and the current date. FourPlan alters its internal state to reflect the courses that were completed and updates its plan, asking a few questions to resolve new issues that have arisen due to a conflict. Paul makes a change using direct manipulation based on his outside knowledge of courses that work well together.

Design 3 Analysis:">Design 3 Analysis:

This interface’s big concept is “Ask as few questions as possible and do the work for the user.”

This interface is particularly learnable because it has exactly one thing of interest on the screen at any time, and there is a clear call to action. The current question is the only thing the user needs to be concerned about, rather than modes, tabs, panels, or menus. If the user is confused, they can skip a question.

The major theme of this interface is visibility into the software’s constraint solver. Sometimes very logical and practical decisions made by a computer can be reduced to a solution a human can’t explain. Instead of trying to find out why the system suggested an unusual plan, users often get frustrated. Therefore this interface is explicitly designed to show its reasoning behind every step. For example, when asking questions this design always begins with a reason such as “The 6-3 degree track requires you to take 2 AUS subjects.” This explains why the system is asking for which AUS subjects Paul wants to take. Furthermore this system also helps deal with more complicated situations such as when Paul has already specified he wants to take 6.805, which is an AUS. In that case this interface would ask “The 6-3 degree track requires you to take 2 AUS subjects, and you already have already indicated that you want to take 6.805. Please choose 1 additional AUS subject to take:” This sort of dynamic behavior helps give the user positive feedback about the process, since it is clear the interface is listening to the user’s inputs. This theme is further echoed when the user is shown the end result of the wizard. If a user mouses over a course, the constraint solver can show exactly why it picked to put the course in that semester. Instead of being confused, the user can query any decisions that seem odd.

One criticism of this interface is that it requires a leap of faith on the part of the user; the interface doesn’t make it easy for Paul to enter a bunch of things he has already decided. This could frustrate a particularly competent student who just wanted help on part of his schedule. One way around this would be to start with a set of questions about what things the user already know he wants to do. The constraint solver could then take those classes as givens. With this improvement, the interface is efficient because only the minimum number of questions needed by the constraint solver will be asked.

Another criticism is that until the questions are complete, there is very little evidence that Paul is making progress other than watching the number of questions he has answered increase. Constraint solving often involves major changes to the solution near the end of the constraint input process. Therefore this interface doesn’t do a particularly good job at keeping the user engaged through a big slog of questions. One possibility would be to show a schedule-in-progress, but this would take up screen space and potentially be highly annoying if every question radically changes the output. I suspect this aspect of visibility is one that will simply need to be a tradeoff; either the user sees an artificial measure of progress like a progress bar based on the number of questions, or the user simply doesn’t get any notification at all.

There is also a risk that the constraint solver might be slightly incomplete. In a particularly annoying edge case, users might be forced to game the system by guessing at what questions really mean and giving false answers so that their intended results will happen. This will only be fixed by making sure the constraint system is implemented thoroughly.

Minimal error prevention is implemented by checking that the user is giving reasonable responses to each question. It is also the case that no choices made by the user are expensive to undo. Should a user incorrectly answer a question, they can simply back up and change their answer. In this case, excessive error prevention such as confirmation dialogs is not worth implementing, because the cost to fix an error is so small.