Orbital Project Wiki

**Project Reports for nusmods**

This project is done at the Vostok (beginner) level.

First Report (Week 3)

The aim of the project is to develop a platform which will allow NUS students to easily retrieve prerequisites and preclusions of modules offered by NUS. The motivation to do so is because the current system offered by NUS is not as user friendly, especially for bulk retrieval of information for several modules. We have targeted 2 platforms to develop for, namely, a web application as well as an android application. We would be using Google Datastore for storage and other platforms will access the data through a REST interface.

The main features in the website are the table mode, graph mode and REST interface. The table mode allows users to view information of multiple modules in a single table. The graph mode allows them to manually map out a dependency graph of their modules. The REST interface allows other developers to make use of all module information that we have already preloaded into our database.

Second Report (Week 8)

Over the last couple of weeks, we have managed to successfully implement all features that were proposed.The features are as follows:

1.Beautifying the UI of the android app - The UI has been improved to include instructions and boxes for neater display of content, the submit button has also been enlarged so it is easier for users to hit it. Screenshots available at https://play.google.com/store/apps/details?id=com.limbenjamin.nusmods. The screenshots are pretty self explanatory in case you are not using android or do not want to install the app.

2.Tidying up the code (currently most of the code is hacked together) - Most of the excess code for functions not being used has been stripped, query has been parameterised to improve on security.

3.Share on facebook/twitter functionality - Can be observed on main site.

Reponse to feedback

Changing name because there is an existing nusmods.com - We will retain the URL nusmods.appspot.com but our page title and page name will be named "NUS Modules" to avoid confusion.

Putting table at side of graph- We have added a feature so that when you hover your mouse over a module, the prerequisites will show in a popup bubble

Additionally, we have also added in instructions throughout the website to guide users. Pictures in the banner to show users what they can expect. We have also added in additional data on which semester a module is offered as feedbacked.

For the next sprint, we will working on the following three features:

1. Allowing users to export the table/graph as csv/jpg

2. Improving the UI of the graph page

3. Script to automate process of updating module information

User Stories

Feature 1: A year 1 arts student has spent the last 30 minutes graphing out her modules and wants to save it for future reference. She is not familiar with computers and does not know how to use the print screen function.

Feature 2: A year 2 new media student wants a nicer looking graph page than the current drab grey coloured page.

Feature 3: The developers of this app do not want to spend the rest of their time in NUS updating modules and want a script which will automate the process.

Final Report (Week 12)

We have sucessfully implemented all the features that were targeted in the previous sprint. Video can be found [here](http://limbenjamin.com/video3.mp4)

1) Allowing users to export the table/graph as csv/jpg - instead of csv for the table and jpg for the image, we have implemented export to xls for table and png for image due to exising libraries which are already present for the file formats. Unfortunately, there are a few security features triggered which might inconvenience users, excel 2013 would display a warning that the file might be unsafe and chrome will block the image popup.

2) Improving the UI of the graph page - The prerequisite popup bubble has been styled to look nicer, users have the option to toggle between white, red, green or blue background color for the module by double clicking on it. Colors can be used to differentiate between core and electives, or users can come up with their own color scheme, e.g. different colors for different level modules.

3) Script to automate process of updating module information - The script to download and parse module information from IVLE website has been completed and uploaded here. This script will generate a CSV file which is ready for upload to GAE using the bulkloader. We did not automate the uploading because of the amount of information will definitely exceed the daily upload quota.

No additional work was done on the android app for this sprint.

Initial aim : Vostok

Current Estimated level : Gemini

List of features implemented:

Display of module information in table form
Manually graph out module prerequisites
API to allow other other developers to access database
Android app to access module information
Social media integration
Export information as xls and png
Shell script to automate updating process

We intended to automate the graph generation but eventually decided not to implement it because parsing the prerequisites might introduce errors. E.g. instead of module A AND B, our parser might interpret it as module A OR B. This would be disastrous if the user did not double check and relied solely on our graph.

Comments after reading evaluator's feedback(Week 3)

Firstly, we would like to thank everyone for their time spent reviewing our application.Points that were raised include

Changing name because there is an existing nusmods.com - We will consider the suggestion, the main problem faced is that it will take another 8 days to upload all 10,000 module's information due to daily quota limits of app engine.

Using webview, or mobile view of website - Our current website is already optimized for mobile. The reason for having an android app is due to user story 3, because you might need module information in a hurry and might not remember the URL for the website. Secondly, the single module search only is actually a limit that we imposed, reason being it is meant for quick checking use as described in user story 3 and not for mapping your entire 4 years. I also did not want to clutter the screen since screen size for mobile devices is quite small.Need not worry about the time it takes, we need to finds things to fill up 130 hours.

Putting table at side of graph- We have considered it but the main drawback is that you would have less screen real estate available to do your graphing. We may implement a popup bubble with prerequisites when you mouseover the module item.

Better explanations throughout website - We have actually hinted by placing "CS1010,is1103,EC1301" in the search box to show that multiple modules are accepted and input is not case sensitive. Nevertheless, we do acknowledge that the website is very poorly explained because we were focusing on functionality and making sure everything works.

We will be working on improving the user experience through better instructions to make sure that users are not confused when using the website. Xofel has also suggested adding in information on whether a module is offered during which semester. These 2 features will also be completed in the next sprint. As for the automated graph, we will be putting it on hold due to the complexity of the task.

Comments after reading evaluator's feedback(Week 8)

Feedback 1: Students have to first look through the module listing from school website before entering into NUS modules website.

It will be very convenient if we could just select our major/stream and have the list of modules automatically loaded. Unfortunately, we do not know of a website which list all the required modules of all the various majors/streams from all faculties. It would be too troublesome to search each faculty's website and manually add in the modules. Furthermore, certain faculties may not even publish this information on their websites.

Feedback 2: Location where instructions are placed are normally used for website description

That is certainly true, we will look into modifying the layout to accommodate the instructions at a suitable location

Feedback 3: Implement Unit testing

May consider if we have time, but priority is to finish up the features specified.

Feedback 4: Get non-SOC people to test

We would try approaching a few non-SOC friends to get their feedback on the app.

Since there is no feedback on the user stories for the next sprint, we will be retaining it.

Note: The graph feature will continue to be manually drag-and-connect. Plans to automate it has been shelved because we cannot guarantee its accuracy to a reasonable level. Users will therefore have to double-check the generated graph to be safe (or they risk not graduating on time). There is no point automating the process if you have to manually double check the results, therefore we have decided not to implement it.

Comments after reading evaluator's feedback(Week 12)

Feedback 1: Seamless switching between graph and table mode without re-entry of modules.

Why yes! We are unsure how this managed to escape all our minds for so long, but this is definitely a very good and useful feature.

Feedback 2: Additional information e.g. timetable schedule, workload

Unfortunately, we feel that this would deviate from the use case of the app. We intend to provide a way to easily look up and graph prerequisites for modules. We are not interested in creating a timetabling app or modules per semester app. By implementing too many features, it may dilute our core functionality. Others apps out there serve a very specific purpose as well. E.g. nusmods.com for timetabling, corspedia for CORS bidding and so on.

Feedback 3: Input format restriction

This is a concern. We will allow space for graph mode. However in the long run, we are looking are implementing an "autocomplete" type of dropdown menu so users can select instead of typing out the full module code. This would hopefully reduce input problems. However, one of the biggest challenges is that the "autocomplete" list has 10,000+ modules.

Feedback 4: Graph UI improvement

Improving and changing the UI is a continous process that we will be doing.

Feedback 5: Video

We apologise for the video. What happened was that both of us were very busy during submission week so we finished the video and wiki 1 week earlier. We had assumed that the video would be similar to previous iterations. I.E. less than 3 mins, introducing new features. Unfortunately, when prof released the details, it was a 5 minute video about the entire app. By then, we were already too busy and did not have enough time to redo the video.

We would like to thank all our fellow peer evaluators for their time and effort reviewing and giving feedback for our app. We have certainly benefited from the constructive feedback and hope that we have not fallen short on our evaluation of your apps. We will continue to maintain this app for the next 6 months. Beyond that, it depends largely on the amount of traffic. It makes no sense to spend time on a project that is not utilised. We would rather work on something that is of use to someone.

Competitors

Currently, we see no competitors as we do not know of a web app that provides similar functionality. The IVLE site provides minimal competition as the information is scattered and difficult to locate. Nevertheless, we have taken note that a number of teams in orbital are embarking on a similar project and might pose competition.

Stakeholders

NUS students. This app is created for the community and will be provided free of charge. Students who feel that it is beneficial can choose to make use of it.

External Dependencies

We have scrapped information from over 10000+ modules in IVLE and uploaded it into the datastore, so there are currently no external dependencies in the short term, however, next semester when we wish to update the information, we have to scrap IVLE once again, so the only condition is that IVLE has to be updated and there are no major changes to the URL structure.

For the next sprint, we will working on the following three features:

1. Beautifying the UI of the android app

2. Tidying up the code (currently most of the code is hacked together)

3. Share on facebook/twitter functionality

User Stories

1) A year 3 student at NUS, who has only 4 semesters left, must quickly figure out which remaining module is the most "deeply nested" so he can clear all its prerequisites before the final semester and graduate on time.

2) A year 1 student at NUS wants to identify which core modules he is eligible to take next semester.

3) A year 2 student is discussing with her friends over lunch on what module they should take next semester and wants to quickly find out the prerequisite for a certain module.

Tech Stack

GAE/Python for website - Requirement for Vostok Level, greater level of support available

Android for mobile app - Possess hardware required for development, easier to distribute final product

ndb - Querying datastore faster and simpler then external db. ndb provides better caching which would be useful since only a small portion of the 10000+ modules will be accessed frequently.

Rest - Simple. Port 80 is always open since it is used for HTTP. Easy to cache. Module information is available publicly for anyone to access, no security concerns

Libraries/Plugins

Boomi rest server - For rest interface

jsPlumb - For the graph mode

Data Schema

[http://nusmods.appspot.com/rest/metadata/Modules](http://nusmods.appspot.com/rest/metadata/Modules)

Timeline

As of now, all of the major features suggested during ignition have already been completed. We will be working on minor details and touch up. If you have features you would like to see being implemented, please feel free to share with us.