soc-pe-bot
commented
2 years ago Team's Response
While being very easy to implement, the design decision was not to put it into the description due to the following,
-
Certain modules have long names that cannot fit into the description nicely. It would look cluttered for things like "Organizational Behavior Seminar: Work, employee and organizational well-being" or "Everyday Life of Chinese Singaporeans: Past & Present (taught in English)".
-
The user is deemed to be able to recognise the module from its code, as is the case for most NUS undergraduates.
Items for the Tester to Verify
:question: Issue response
Team chose [response.NotInScope]
- [x] I disagree
Reason for disagreement: The issue was not referring to the title of modules, but rather a lack of a way to view module lesson information through the CLI itself. Right now the application is reliant on external software like the NUSMods website to function, since the user does not know what lessons exist for each mod and their timeslots without referring to NUSMods. E.g. I want to add the 10am lab session for CG2271 to my timetable, but in this app itself, I am unable to find out what the name of the slot is. I have to open NUSMods externally in order to figure out that it is 02.
The capability to get lesson information from the NUSMods API and add and print their details is already there, meaning it would be trivial (and thus cannot be classified as NotInScope) to add a command to print the lesson details for a specific module. Furthermore, as a CLI app that is supposed to be efficient, it does not make much sense to be reliant on external applications like NUSMods via Chrome in order to function properly. All in all, this seems like a crucial feature that is missing.
Perhaps a way to view mod/lesson information through the app itself could be added? This would make the module command a lot less cumbersome to use since it would not require tabbing out to check the names of the lessons.