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...)