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 Figure 1. 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.