- Product (either a webapp or a local application) that gets a student to enter information about classes they want to sign up for and then displays to the student their class schedule before they sign up for classes.
- Product will warn students about schedule conflicts and give alternative sugesstions to remedy schedule conflicts.
- A webapp that allows students to select classes they want to potentially sign up for and then displays them on a two week calendar view for the student to easily see any time conflicts and make changes in their schedule before they sign up for classes.
- All available information on classes will be easily accessible from the schedule, such as instructor, location, prerequisites, and course description.
- Product will allow for any number of classes to be added to the schedule even courses with time conflicts which will be shown as overlayed classes in the calendar and allow the user to see the information of multiple classes with time conflicts and choose one to actually sign up for.
- Product will warn students about schedule conflicts and potentially give alternative suggestions to remedy schedule conflicts.
- Product has integration with PAWS online services. So all students need to do is enter minimal information (class name, CERN, etc...) and the product will search for classes that the student can add to their schedule in the product.
- Product will have a final ‘output crns’ button that will output a tab delimited list of the crns for the classes that you have scheduled. Using these you can (hopefully) copy the list of crns and paste them into the regular paws signup page (one at a time if needed) and hit submit once.
### Needs and Values:
- Allows students to easily preview their schedule and see potential time conflicts before signing up for classes.
- There is currently no available product which provides this functionality, as the only way to see a detailed schedule for classes is after a student has signed up for them.
- This product is to be used by students in the time frame before class sign up is opened, but can be used by students during class signing up is opened.
- Allows students to easily preview their schedule while building it and see potential time conflicts before signing up for classes. This can drastically reduce the time spent trying to resolve time conflicts.
- Consolidates all the information regarding classes to one page (such as prerequisites and course description) alongside the visualized schedule.
- Allows students to view any number of chosen classes on one page while deciding between different classes that take up the same time slot, rather than needing to use multiple tabs.
- There is currently no available product which provides the functionality of visualising a schedule prior to signing up for classes.
- This product is to be used by students in the time frame prior to class registration is opened, but can be used by students during class signing up is opened.
### Stakeholders:
- University of Saskatchewan undergraduate student body as it will vastly improve time spent determining class schedule.
- Undergraduate students with busy schedules and jobs outside their university work will benefit as they can more easily plan their schedules ahead of time before signing up for classes.
- Possibly the University itself if we can market to them as a quality product to be integrated into the PAWS website.
- Concrete feedback can be delivered from friends and fellow classmates
### Quality Assurance:
- Coding practices and guidelines. If creating a locally run application, will use either Qt style guidelines (https://wiki.qt.io/Qt_Coding_Style) and/or Suckless style guidelines (https://suckless.org/coding_style/). If creating a webapp, will use Google style standard of HTML, CSS and Javascript (https://google.github.io/styleguide/htmlcssguide.html, https://google.github.io/styleguide/jsguide.html).
- Coding practices and guidelines. If creating a locally run application, will use Google style standard of HTML, CSS and Javascript (https://google.github.io/styleguide/htmlcssguide.html, https://google.github.io/styleguide/jsguide.html).
- Internal testing done by Evan, but other members of SSLabs can help with testing as well.
- Internally, we have a diverse set of OS's (Windows, MacOS, Linux) and web browsers (Chrome, Firefox, Opera, w3m) to test for functionallity and correctness.
- Externally we can ask other students to test our product so they can review functionallity and correctness, as well as other considerations such as design and workflow of the product.
- Internally, we have a diverse set of OS's (Windows, MacOS, Linux) and web browsers (Chrome, Firefox, Opera, w3m) to test for functionality and correctness.
- Externally we can ask other students to test our product so they can review functionality and correctness, as well as other considerations such as design and workflow of the product.
### Technology Requirements:
- Any x86 device for local application.
- Any device that can run a web browser that supports HTML, CSS and Javascript for web app.
- This product should be very lightweight and require very little system resources. Most intensive tasks will be drawing 2d graphics either through Qt API or through a web browser and looking up database values.
- If local application, Qt graphical front end and C/C++ for operations.
- This product should be very lightweight and require very little system resources. Most intensive tasks will be drawing 2d graphics through a web browser and looking up database values.
- If webapp, HTML and CSS for graphical front end and Javascript for backend operations.
- Will be integrated with the PAWS database, so will need some kind of database parsing langauge like SQL.
- Will be integrated with the PAWS database, so will need some kind of database parsing language like SQL.
### Actions Plan:
- Will have group meetings every friday after the 370 lecture.
- Possible meetings over the weekend and on tuesdays depending if needed.
- Nikhil will manage the GitLab page, update the wiki, manage push/pull requests.
- Braeden will develop the frontend and UI.
- Ben will develop the backend and PAWS integration.
- Evan will manage the quality assurance, review the code and do testing.
- If we decide to code in Qt, Ben will give a tutorial on how to develop with Qt.
### Action Plan:
- Will have group meetings every friday after the 370 lecture to see our progress and have a group work session afterwards if some part is behind schedule.
- Once development starts, at the meeting we will preview the existing program and brainstorm and give feedback on potential problems or improvements on parts of the program that we are not in charge of.
- Short meeting Monday after the 370 lecture regarding what we need and hope to accomplish before the Friday meeting and any additional concerns we have.
- Discord will be used as a communication hub for any questions or concerns that can be addressed at any time to the group.
- Possible meetings over the weekend and on Tuesdays depending if needed.
- Nikhil will be in charge of the GitLab page, updating the wiki, and managing push/pull requests and unexpected merge conflicts.
- Braeden will be in charge of frontend and UI development.
- Ben will be in charge of backend and PAWS integration.
- Evan will be in charge of quality assurance, reviewing the code and testing.
### Functionality:
- Security: Ensuring a secure connection when pulling from the PAWS database. Asides from making sure the connection between PAWS server and the product is sercure, not much else is needed as the browser/OS can handle any local security. Might not even have to have any focus on security at all if PAWS has its own security system.
- Capability: Product should diplay to the student a schedule for the classes they want to sign up for before they actually sign up for them.
- Security: Ensuring a secure connection when pulling from the PAWS database. Aside from making sure the connection between PAWS server and the product is secure, not much else is needed as the browser/OS can handle any local security. Might not even have to have any focus on security at all if PAWS has its own security system.
- Capability: Product should display to the student a schedule for the classes they want to sign up for before they actually sign up for them.
- Reusability: By keeping the program lightweight and versatile we can apply it to any university class sign up system if the university does not have a system already in place.
- Usability: This is a very lightweight program. Speed will be dependant almost solely on the internet speed of the individual.
- Reliability: Any web browser on any platform or x86 compatible computer should work.
- Usability: Interactive GUI that displays detailed information to the user. Interactive schedule. Avoid multi-page navigation, keep on single page. Provides time reduction and page navigation reduction compared to current PAWS system. Ease of use and good workflow. Testing done by users.
- Reliability: As long as PAWS database doesn’t change, then this program should remain reliable.
- Accuracy: Product should be accurate unless if there is an error in the PAWS system.
- Predictability: Product should display the same information as long as there are no changes in the PAWS system.
- Availability: If we make this into a web app it would be easily available online. If we go with a native app we would have a download link to students.
- Performance: Product is very lightweight and will have minimal resource consumption, looking at internet usage in the couple hundred kilobytes. Low ram consumption, and ideally requires one cpu core at low clock to operate
- Availability: Because is web app, should be accessible by anyone.
- Performance: Product is very lightweight and will have minimal resource consumption, looking at internet usage in the couple hundred kilobytes. System requirements is dependent on the web browser being used.
- Supportability: Any modern web browser on any platform should work.
