NUSMods Wiki

Scenario

Information about NUS modules can come from official NUS sources or through other platforms like blog posts, youtube etc. Currently, NUSMods has a dedicated module page for each module, showing reviews, module information and timetables. However, users need to search for other resources about modules on their own as these information is scattered over the internet.

As a solution to this problem, we would like to create a wiki platform where students are able to collaborate and share resources on a module anonymously.

This initiative would allow users to quickly obtain information about a respective module. The focus of this platform is to include more user-generated content that is editable by non-technical users. Each module would have a wiki page with some static content obtained from the NUSMods API and the rest of the content would be maintained and updated by students/lecturers.

Implementation Plan

Features

Display static content through NUSMods API. Other sections would be user generated
Every module would have its own page, each faculty would display their own coded modules
Share wiki pages through social media
Users can insert/edit relevant information about the module
- Facebook groups
- Videos
- Projects
- Lecturer information
- Past year papers and answers
- Others (e.g. fun facts)

Technology Stack

Front-end development is our focus in creating NUSMods Wiki. It has to be attractive and simple for students to use the platform. We are adopting the following technology stack:

HTML/CSS
React/Redux with Express
Firebase

Sample package.json file

{
  "name": "nusmodswiki",
  "version": "1.0.0",
  "description": “NUSMods collaborative wiki",
  "main": "server.js",
  "scripts": {
    "build:js": "browserify ./src/app.js -t [ babelify --optional es7.classProperties ] --outfile public/all.js",
    "build": "watch 'npm run build:js' ./src"
  },
  "author": "",
  "license": "ISC",
  "devDependencies": {
    "babelify": "^6.2.0",
    "browserify": "^11.0.1",
    "watch": "^0.16.0"
  },
  "dependencies": {
    "body-parser": "^1.13.3",
    "cookie-parser": "^1.3.5",
    "ejs": "^2.3.3",
    "express": "^4.13.3",
    "express-session": "^1.11.3",
    "firebase": "^2.2.9",
    "markdown": "^0.5.0",
    "react": "^0.13.3",
    "react-router": "^0.13.3"
  }
}

Sample server.js file

var express = require('express');
express()
    .set('view engine', 'ejs')
    .use(express.static('./public'))
    .get('*', function (req, res) {
        res.render('index');
    });

Sample database.js file

var Firebase = require('firebase');
var firebase = new Firebase('https://nusmodswiki.firebaseio.com/');
var router = require('express').Router();
router.use(require('body-parser').json());
router.use(require('cookie-parser')());
router.use(require('express-session')({
    resave: false,
    saveUninitialized: true,
    secret: '<random key>'
}));

Sample Mockups

NUSMods Wiki Homepage

nusmods wiki homepage

NUSMods Wiki Module Page

nusmods wiki module page

Policy for Quality Control

Revision History (could explore using this https://github.com/reactjs/react-router-redux)
Captcha before editing (Google reCaptcha https://www.google.com/recaptcha/intro/invisible.html#)

Timeline

Timeframe	Description
8 May - 14 May	Ideation/Initial proposal
15 May - 21 May	Updates on proposal Learning relevant technologies (NUSMods API, React/Redux, Firebase)
22 May - 28 May (Evaluation Milestone 1)	Learning relevant technologies Design and implementation of prototype interface
29 May - 4 June	Changes to design/implementation based on user feedback Implementation of features Main Page Search Bar
5 June - 11 June	Implementation of features Main Page Search Bar Module Page Layout
12 June - 18 June	Implementation of features Faculty page (List of modules for that faculty) Module page features Database update
19 June - 25 June (Evaluation Milestone 2)	Implementation of features Module/Faculty page features Search and tag filters Database update
26 June - 2 July	Changes to design/implementation based on user feedback Implementation of features Revision History Captcha before editing Test Cases
3 July - 9 July	Changes to design/implementation based on user feedback Implementation of features Revision History Captcha before editing Test Cases
10 July - 16 July	Minor fixes to interface Integration and testing of system/Work on possible enhancement
17 July - 23 July	Minor fixes to interface Integration and testing of system/Work on possible enhancement Documentation and write up
24 July - 30 July (Evaluation Milestone 3)	Minor fixes to interface Integration and testing of system/Work on possible enhancement Documentation and write up

Are you doing server-side rendering or an SPA/API approach? I see that your package.json has mixed server side packages and client side packages together. Not sure if it's by intention or by accident.

Revision History (could explore using this https://github.com/reactjs/react-router-redux)

How will react-router-redux be used to implement revision history? Revision history is not a trivial thing to implement. You'll need some diff-ing tool (something like Git). Would recommend that you leave this out of your project at the moment.

The architecture of your application is not clear. What is the role of express in your application?

Is there user authentication required for this? I see that you mentioned that students can update it anonymously. If there is no user login required, you might not even need a server; the front end can interact with Firebase directly.

However, I do think there's a need for user authentication. If not anyone can just deface the content and there's no way of tracing who did that. When dealing with Firebase, beware of authentication issues also. If the Firebase policies are not properly set, anyone can just wipe out your whole database 💥

Module reviews can be done directly on your site. If your wiki goes well, we can shift the NUSMods reviews over to the wiki instead / or integrate the wiki into NUSMods.

Nice mockups btw! Tip: Use text placeholders to show more details in the mockups.

Hey @yangshun! Thanks for the feedback!

How will react-router-redux be used to implement revision history? Revision history is not a trivial thing to implement. You'll need some diff-ing tool (something like Git). Would recommend that you leave this out of your project at the moment.

We thought of implementing revision history but wasn't sure how we are exactly going to do about it. Chancing upon the mentioned resource, we thought we could explore and work with the history instance. However, this can be marked under potential enhancements at the later stage of the project phase once we got the basic building blocks of the project up first. Our primary concern is that users may overwrite useful content with content that is not constructive. We would like to seek some advice on some things we could do to control such behavior.

Are you doing server-side rendering or an SPA/API approach?

However, I do think there's a need for user authentication. If not anyone can just deface the content and there's no way of tracing who did that. When dealing with Firebase, beware of authentication issues also. If the Firebase policies are not properly set, anyone can just wipe out your whole database 💥

We plan to do server-side rendering with express. We are slightly concerned on the issue of logging in to post resources since students might be not in favor of the idea of logging in. However, we agree that security should be of utmost priority and authentication is needed. In this case, we can also use the server to handle different user sessions and interact with firebase.

Revision History

I don't think most people will prank the system by overwriting useful content. A more realistic concern is a race condition in the editing of the content, where User A and User B are editing the same content at the same time and the later person that hit saves will overwrite the previous guy's changes. Few ways around this:

Store every revision in the database and make sure the user is always editing the latest version of the content. If the content has been changed while the user is editing it, prompt him to refresh because there's a new version. Downside is that you'll have to save each version and it can consume a lot of space. It's also not trivial to publish the update event to currently editing clients. Then again, this will be a rare case. It's probably not worth the effort to implement it.
Do not have shared content that can be modifiable by multiple people. Stuff like past lecturers/useful links/projects can be implemented in a list format, and people either add/remove to that list. There won't be race conditions when there are is no editing involved. You don't have to store the revision history either. This would be much easier to do and I recommend this.

Server-side Rendering

If you're going to do server-side rendering, then I would recommend using next.js. It's not easy to build a server-side rendered React app yourself especially if you are new to React.

Closing this since Orbital has ended. Hope you guys enjoyed your summer 😄

nusmodifications / nusmods

NUSMods Wiki [1349] #396