Requirements

We are designing a Course Conflict Manager.

The user selects courses from a list of all possible courses to add to their preferred courses list. This preferred courses list is then stored and presented on the following page.

There are no user prerequisites for this feature.

The user sees a list of all possible courses on the page. They are asked to select all of their preferred courses from which they wish to find a compatible schedule. There is some method for the user to select courses. For example, there may be checkboxes or a selection list.

There is a Clear button to deselect all selected courses. There is also a Submit button to store a list of all selected courses and continue to the next page.

The user scrolls through the list of courses, selecting their preferred choices. If they decide to reset the list, they press the Clear button and all courses become deselected. If they decide they have finished selecting their preferred choices, they press the Submit button.

If the user hits Clear, all courses/groups are unselected. If the user hits Submit, any and all selected courses/groups are “saved” in a list that is carried over to the next page. All selecting/deselecting works as normal. No other action is possible by the user.

• The user selects nothing and hits clear. Nothing changes.
• The user selects nothing and hits submit. A warning pops up saying: “Warning: No classes have been selected.”
• The user selects 1+ courses and hits clear. All courses are unselected.
• The user selects 1+ courses and hits submit. The next page loads with all selected courses in the preferred course column.
• The user hits no buttons: the page remains static.

This feature is high priority. It is necessary to have the user create a list of preferred courses that they want to analyze in order to find meaningful information regarding possible schedules for that user.

The user must have generated their list of preferred courses and have at least one course, or group.

They see a box representing the course they select appear on the schedule/disappear from the schedule.

They check a box on one of their preferred courses/groups.

The user clicks on the checkbox located on one of their preferred courses, and that course is designated as selected and displayed on the schedule at the appropriate location for it's times, as a colored box with text indicating the course title. If the course is already selected, it is removed from the schedule.

Updates are sent to the conflict detector accordingly, and a warning will appear beneath the schedule if a conflict is generated, and the conflicting schedule items will appear in a scary red color.

Priority:

This feature is high priority. You can't very well detect conflicts between selected courses if the user cannot select courses to begin with.

Groups allow the user to indicate collections of multiple courses which are to some degree substitutable. Instead of the user manually searching for a set of compatible courses, the scheduler automatically searches through every possible schedule which includes one course from each selected group and each selected individual course. When there are multiple compatible schedules, the scheduler picks one based on the user-specified order of the groups, and then the order of courses within the groups.

The user must have already selected and submitted a list of preferred courses. The second page is loaded with the preferred courses listed in a column.

All courses and groups are listed vertically in a column.

For courses: Both dept/number and course name are immediately visible with a checkbox to the left. Clicking on the name toggles the professor's name and course time in smaller font under the course title.

For groups: Group name is shown: A toggle arrow to the left of the group label may be clicked to show a vertical list of courses/sections in the group indented to the right; each course has a checkbox next to it and may be interacted with in the same manner as listed above. A checkbox lies to the left of the toggle arrow. (Idea: group names could have gray background to differentiate from course names).

To combine two courses into a group: The user clicks on one course, and drags it over the other course's name. When the mouse is released, the dragged course disappears and the other course turns into the new group.

To add a course to a group: The user clicks on the course and drags it over the group's name. Upon release, the course's name is added to the group.

To combine two groups: The user clicks and drags a group's name onto another group. Upon release, the new group is created by moving all courses in the dragged group into the dragged-onto group.

To remove a course from a group: Not yet decided. There may either be an x to the right of the course name which can be clicked, upon which the course is removed from the group and added to the bottom of the list, or the user right-clicks on the course name and selects “Remove from Group.” (Note: If there are only two courses, the last course becomes a separate course as well.)

When a user clicks and drags a course or group onto another course or group, a new group containing all relevant courses is made. If the user removes a course from a group, the course no longer appears on the group list and is instead in the main preferred course list. If the user tries to click and drag a course or group onto an erroneous area (no group or course), nothing happens and the course/group goes back to its original location.

The user may:

• Combine two courses into a group
• Add a course or group to another group
• Remove a course from a group

via the processes described above (in What Does the User Do).

Priority: Medium-Low. Despite potentially interesting uses, it is not necessary for the overall project.

The user may also be able to select departments (ie CSCI, PSYC) and/or distribution requirements (ie LIT) to add a premade group of all courses in that category to the preferred courses list. This is done the same way as adding a course to the list. The group would then act in the same manner as a user-created group.

Having grouped courses implemented.

Preferred courses page.

On the preferred courses page, the user sees two tabs at the top. One (selected by default) says “courses” the other says “groups”. If the “groups” is selected, instead of the default list of courses, they see a list of preselected groups that they can choose from.

Click the checkboxes next to the group, and then submit when they are finished.

I need to fulfill my Humanities FDR. So I click the tab, see the “HU” group, click the checkbox next to it, get very excited, and then click the submit button.

Low

This feature detects a wide variety of conditions in the schedule.

First and foremost it will detect any conflicts between different classes in the schedule, but it will also detect if there are multiple non-conflicting possibilities that the user can choose between.

It will also detect when it is impossible to choose an individual course from each selected group such that each individual course is compatible with all the others.

For this feature to do anything, we will need to have populated the Preferential course list AND selected some of the courses.

The user will see a warnings displayed in a designated box, some like conflicts will be in red and indicate that the schedule is not viable, while some like the multiple possible schedules will display in yellow to indicate the schedule is not strictly defined.

The user can see these warnings and can take necessary actions if he or she wants.

When the user edits his selections, warnings could be added or removed.

Again, a user can respond to the indicated warnings; the feature will help the user see what is wrong with their schedule.

High, this is the premise of our project.

Save and load schedules/preferred course lists/groupings into a file so that a user may come back to it later.

We would need to have designed everything necessary to build said schedule int he first place, so preference lists, scheduling etc.

The user would see a save button and a confirmation that it was saved and a download file. The schedule would be loaded upon the user's return via an upload of the saved file.

The user selects save or load and either downloads or uploads a file. From there the user can exit (if he saved his file) or go on to edit his file.

When a user selects save either it will work and download or there will be an error message for the user. When he selects load he will be prompted to upload a saved file, if everything works it will populate the schedule and preference listing, otherwise there will be an error message.

If the user wants to come back later he can save his work and then load it when he is ready to work on it later!

Medium

Export/Import into external programs. (e.g. iCal, Outlook, etc.)

We would need to have designed everything necessary to build said schedule int he first place, so preference lists, scheduling etc.

The user would see an export button and a confirmation that it was exported and a download file.

The user selects export, selects the format and downloads a file. From there the user can import the schedule to another venue.

When a user selects export either it will work and download or there will be an error message for the user.

When the user has successfully made his schedule and he would like to easily port it to his actual calendar!

low