Orbital Proposal: Study Plan Builder [1332]

[naixian]

Problem Statement

Having completed our first year of study in NUS, we felt that it would be important for everyone to plan ahead his or her four years of study so that he will be making full use of the period of study in school fulfilling graduation requirement and as much as possible, plan for exchange period or NOC if desired.

However, this process is currently troublesome without the help of widely recognised tools. Many of us end up searching repeatedly for prerequisite relationships in NUSMods and referring back to course requirement pages over and over again. The hassle might cause inefficiency and mistakes in the planning process and this has implication on the subsequent semesters of study in NUS.

Although we understand that NUS Oracle attempts to solve this problem, it still relies on manually looking for pre-requisite relationships from NUSMods and it does not prevent you from setting up illegal study plans (e.g. taking CS2020 before CS1010). Hence, we aim to facilitate the planning process by designing a four-year study plan builder that takes into consideration prerequisite-postrequisite relations and graduation requirement of courses in NUS.

User Story

We aim to make our project an extension of NUSMods. The interface would be quite similar to the normal timetable in NUSMods except that columns are replaced by the 8 semesters, as illustrated in the figure below: (we have done some photoshopping to demonstrate what we aim to achieve)

Figure 1

1. The user starts off by indicating his or her major, and then the graduation requirements of the major will be automatically loaded in the backend.
2. The user can add any major modules without pre-requisite to the main table by clicking on the “+” button under Y1S1. (Figure 1 shows this moment.)
3. Clicking on the “+” button, or clicking on an existing module in the table, would lead to an additional section to the right of the main table. This is shown in Figure 2 below. This section would contain modules having this module as their prerequisite (which we refer to as “postrequisites” in this project) within the course requirement. The user can then add these postrequisite modules into the table (but only the earliest semester in which the module is offered and he is eligible to take it).
4. The user can also move a module to other eligible semesters once it has been added. Alternatively, he can delete a chosen module from the table (and all its postrequisites will also be removed as well). The process repeats until all modules within the course requirements are added to the table.

Figure 2

Explanation of Figure 2: The user has indicated a major in Computer Science (matriculated in AY2016/17). He has already added 5 modules across 3 different semesters. Each of the 8 semesters has one unique colour code. Figure 2 shows what happens just after he clicks on the existing module, CS1231: a total of 3 fictitious post-requisite modules appear, namely CS1232, CS1233 and CS1234. Among them, CS1233 cannot be added because its pre-requisite CS1020 has not been added to the table. On the other hand, CS1232 and CS1234 can (only) be added to different semesters because CS1232 has no pre-prequisite other than CS1231, while CS1234 has an additional pre-requisite, MA1101R, other than CS1231. For simplicity, the system does not explicitly notify the user that CS1234 has another pre-requisite and it is hoped that the user will check out the module information page for CS1234 so as to understand why CS1234 cannot be added in Y1S2.

5. Elective modules within a major will be marked with an “E” label. Other elective modules will not be shown in the post-requisites section if the elective requirement for the current category/level is complete.
6. As such, users do not need to repeatedly check the prerequisite relations between modules and referring back to course requirements. By doing this we hope to provide a hassle-free experience for the users to build, update and maintain their study plan.

Notes:

1. We shall plan to work with a single-major study plan first, that means there is no double degree, double major, minor, general education requirements (GEM), faculty requirements and unrestricted elective modules (UEM). Considering the flexibility and lack of prerequisite relationships in GEM and UEM modules, we will allow customising the user’s own module code or name (names such as “GEM” or “GEM”).
2. Retrieving the year-specific course requirements for each major is difficult in view of the different formats in which different faculties and departments publish their course requirements. We will first enter some the majors’ requirements manually and then see if there is a way to automate later.
3. As with one of the ideas behind NUSMods v3, our solution is intended to be mobile-friendly and it only involves clicking, but not dragging.

Weekly Timeline

May(W0-W3)

Finalise project specification details; Understand implementation of Nusmods v3; Learn relevant languages and tools; Finalise implementation plan;

June(W4-W7)

Making a prototype with basic features (i.e. MVP) for a few majors. The design and the algorithms must allow the logic of module addition in the way described in Figure 2, which include loading all pre-requisite and post-requisite data given a selected major, keeping track of current modules and their semesters, properly handling preclusion modules, keeping track of remaining required major modules, and so on.

July(W8-W11)

Incorporating other considerations that are mentioned or not mentioned above. such as non-major modules, non-manual retrieval of course requirement, adding more semesters and special term options, and so on. Making the product aesthetically presentable and reasonably usable; Asking people to try out the platform and modifying it based on their feedback

Implementation Plan

We will be at least working with Github, HTML/CSS, JavaScript, Redux and React; a lot of ideas and features will come from NUSMods v3 as well and it is very important that we understand how it works. It will be good to use topological sorting to load the module plan based on given prerequisite relations.

This proposal is prepared by Yiwen and Naixian from Team 1332. Thank you for reading and we look forward to your valuable inputs!

[li-kai]

This plan seems to be quite well planned out, good job!

NUSMods Prerequisite Tree API

Understanding the API is quite simple and essential here. What you need to understand is the genReqTree folder. This is where we parse the pre-requisites and post-requisites (which is called LockedModules in the API).

I'm guesstimating that we manage to parse 90% of the prereqs accurately. 10% may be incomplete or wrong. This will put certain limitations on your design if you want module planning to be restrictive.

You have two choices, either

1. Make choices more flexible
2. Make the parser better

UI design

I think the plan is well thought out, and it is pretty intuitive. Do design and consider for mobile, then move your way up the screen sizes. Industry term is: "mobile first design".

Plans

I think the plan is not bad. You should make a small todolist out of the standard React-Redux framework, as implementing it would make you learn much more and deeper than just reading what others have implemented. Don't be afraid to ask questions if you hit roadblocks on this.

Otherwise the rest of the plan looks reasonable enough to be followed through.

Also: see Zhi An's comment for the other team. They're quite relevant.