Multiple schedules for evaluating different possible 4-yr layouts

[pranavavva]

Is your feature request related to a problem? Please describe.
Not related to a problem.

Describe the solution you'd like
Similar to how ReCal allows creating multiple schedules for the same term, I think it would be a good feature to allow a user to create multiple 4-year schedules. This would allow them to experiment with the pre-reqs for different majors, different certificate programs, or even different paths through the same major.

Additional context
This could likely be achieved by having a tab panel just below the "Schedule/AP Credits" selector but above the first row of semesters. Ideally, the user can rename the different schedules as well, as in ReCal.

[bnehoran]

Agreed. This would make a great addition!
We've had a number of users request this feature in their feedback forms, and I also agree that it would be very useful to try out different paths!

For the specifics, I'm actually thinking that we can just get rid of the "Schedule/AP Credits" selector and replace it with the tabs as you mention for the different schedules, and yeah ReCal's tabs could be a good reference.
The "AP and External Credits" page could either be its own special tab (which is permanent and cannot be added/removed), or it could simply be moved into a modal similar to the settings page.
In fact, I think the "AP and External Credits" UI itself should be overhauled, but that's a separate issue.

@pranavavva Is this something you would like to try to implement?
Let me know if you'd like some pointers on how to get this going!

[pranavavva]

I would love to take a shot at this! One question that I have is that the database currently stores one schedule per user profile. Would this feature require a change to the database to allow storing multiple schedules? There are a couple of ideas that I have of implementing this:

• The JSON representation of a user schedule is an array of 9 arrays. The first 8 arrays represent the semesters and the 9th represent external credits. We could simply append another array-of-9-arrays to the user schedule. The benefits of this method are that we do not need to modify the database. However, we would need to modify the parsing mechanism for the user schedule JSON, though this shouldn't be too difficult. The new JSON representation of a user schedule would look like this:

[
  [ # Begin Schedule 1
    [...], # Sem 1
    [...], # Sem 2
    [...], # Sem 3
    [...], # Sem 4
    [...], # Sem 5
    [...], # Sem 6
    [...], # Sem 7
    [...], # Sem 8
    [...], # EC for Schedule 1
  ], # End Schedule 1
  [ # Begin Schedule 2
    ... # see contents of Schedule 1 above
  ], # End Schedule 2
  ... # Schedules as defined above, ad infinitum
]

• The second, and possibly much more difficult, method would be to modify the database to add columns for more user schedules. The benefits of this is that we would not need to modify the JSON schedule parser. However, this would require a complicated overhaul of the database, and users could only have a finite number of schedules.

Personally I prefer the first method because users can have an infinite number of schedules and we wouldn't need to heavily modify the database, if at all. Let me know what you think @bnehoran!

[bnehoran]

Yes! I like the first method.
As you say, it's simpler, cleaner, and allows users to have a virtually unlimited number of schedules.

I would only add to it that we might want to allow for additional metadata about each of the user's schedules.
For example, as you brought up, we might want to allow them to name the schedule tabs, or we might even allow them in the future to assign different potential majors to each schedule.
These might be reach goals, of course, and I wouldn't expect them to be included in the first attempt at this, but just to lay the groundwork for it, you might want to have it structured as a list of dicts, where each dict contains a schedule as well as metadata about that schedule.

I wonder, by the way, if we can make the schedule parser backwards compatible in a way, so that we don't have to actively modify users' database entries and can instead do it lazily.
What I mean by this is that whenever it reads a user's schedule data, it first checks whether it's of the old format or the new format, and then when it writes it back, it always rewrites it in the new format.
If we could do this, it would probably allow for a much smoother transition.