I thought of doing a more specific breakdown of the web applications I had contributed to. Hopefully this can also give people (like my juniors) who want to take this module an idea of what to expect, but really the type of ideas are limited by your creativity. There are also some groups who did native for final project, but it’s because they are (really) good at it. I’ll not be covering Assignment 2 as it was an application critique and no building was done. If you’re rreallyy ‘kiasu’ (scared to lose) also check out the CS3216 website.

Assignment 1: Facebook application - Exchange Buddy

Description:

Web application for exchangebuddy.com started by Eugene to connect people going for exchange programs. Parts of Facebook API used: facebook login, facebook events API. We received the highest ‘coolness’ factor points but we got about average overall mainly due to our report being rushed, and thus not answering some of the questions properly.

Features:

  • Grouping exchange students by their exchange batch
  • Real-time chat for exchange group
  • Events lookup (using facebook and meetup.com API)
  • Collaborative editing of tips

Stack:

  • Front-end: React, MeteorJS (for real-time pub-sub)
  • Back-end: MySQL
  • Hosting: Digital Ocean (frontend), Irvin’s VPS (backend)

Assignment 3: Progressive Web App - Drop Ins

Description:

Realtime chat application where you can drop emoticon pins on a pokémon GO themed map, supporting videos and soundcloud links. Got above average for this but I thought we could have polished it a bit more if we had more time. Uses facebook login.

Features:

  • Real time updates of ‘drops’, votes, comments using socket.io
  • 3D Vector Map view using Mapbox GL
  • Offline caching with sw-* packages

Stack:

  • Front-end: React (using Create-React-App boilerplate)
  • Back-end: MySQL
  • Hosting: Heroku (frontend), AWS RDS (SQL server)

Final Project - 1our

Description:

1our is a platform for NUS students maximize their time in school, and get paid for it. We do this by bringing them fun and interesting projects, studies as well as experiments that they can be part of. 1our also wants to help NUS student researchers and professors succeed in whatever they are doing, be it a study on decision-making behavior or an experiment pushing the frontiers of science.

Features:

  • NUS OPENID login
  • Time slots for each ad-hoc jobs
  • Tracking of money earned through platform
  • Listing of adhoc jobs by category with sorting and filtering

Stack:

  • Front-end: React, Webpack
  • Back-end: PostgreSQL
  • Hosting: AWS EC2 (frontend), AWS RDS (backend)

Now that STePS is over and all my backdated blog posts are done, I just want to write a general post-mortem on the whole process, which hopefully would be useful for anyone considering to take this mod.

Firstly, if you’re considering whether to apply, I would say just work hard to level up before applying and just give it your best shot. I too was concerned about whether I was good enough, I had applied at the end of year 1 sem 2, having done Orbital and GSoC in the summer. I could build web apps and do designs with PS and Sketch. That was my skillset, and although I know I wasn’t the best I knew I could hold my own ground and do the work. The people who apply for CS3216 all have serious skills and impressive portfolios - some of them were coming back from internships at Uber, Google, CS3217, etc. but my experience is that (mostly) everyone (technical people) can build what needs to be built. Some will do more work than others but it’s not the kind where 1 person carries the team, my own experience is that my teams for all 3 assignments had our own differentiated skillsets (biz, backend, frontend, design, etc.) After receiving my acceptance email I had actually considered dropping out as I thought I was not good enough, if not for my persistent friends who encouraged me, I would have missed this amazing opportunity to sharpen my skills.

Teamwork

I think picking the right team really helped, being more of the front-end developer I could design and also implement mockups using React/ Angular. Being used to developing with mongoDB and noSQL really was a pain, as the assignments required us to use a SQL database for the schema diagrams and such, but fortunately there was always someone who knew how to settle the backend.

I’m glad to have known all my teammates, it was awesome working with these fun and talented people. (Irvin, Chi Thanh Lam, Eugene, Larry, Thành Nguyễn Hữu, Kai Yi, Xu Jie, Kent)

Fighting Spirit

I used to joke that this mod was like fighting a war, and I’m glad it’s over so I can start studying for my other mods, but still I kind of miss the long nights and overnight coding sessions at utown and SoC. It really almost feels like going outfield. Anyway, Colin did say CS3216 was like ‘Ranger Course’, and I guess if the analogy holds then ‘fighting spirit’ is definitely a core value that all CS3216 people will develop.

From learning and building new shiny things like progressive web apps in a matter of weeks (days), to pivoting our ideas with 3 weeks to STePS, and talking to and getting real users, the whole experience really pushed me out of my comfort zone, and made me more confident in my skills.

I think this quote from alice in wonderland that colin showed in his final lecture really struck a chord in me so I’ll just end with this too.

“Would you tell me, please, which way I ought to go from here?”
“That depends a good deal on where you want to get to,” said the Cat.
“I don’t much care where–” said Alice.
“Then it doesn’t matter which way you go,” said the Cat.
“–so long as I get SOMEWHERE,” Alice added as an explanation.
“Oh, you’re sure to do that,” said the Cat, “if you only walk long enough.”

After we had the idea, next step was to build it and get the users. Most of the shell of the app had already been done, the first thing that occured to us was that we needed to fill up our web app with some content.

From IVLE student events, we manually filtered through the paid surveys and research opportunities. We added them to our site, but at the same time emailed each of the researchers that we had done so, and when there were interviews we emailed them the interested participants.

We had also emailed Anthony unknowingly from the previous CS3216 batch as he was managing the IVLE announcments as part of NUSSU CommIT, and he even advised us to learn from AirBnB’s growth hacking tactics. We didn’t have a craigslist to take users from but IVLE student events was a good starting point.

Some of the emails that Xu Jie sent out did not get any replies, but a few replied enthusiastically, even commending us that they had built something better than IVLE. Well, that was definitely encouraging, we could also use it in our STePS poster.

We also managed to get an event posted in IVLE!

Other things we did were also to go down to the paid studies themselves and advertise to the participants as well as researchers. Research studies were our main user base as they had an urgent need for their FYP research interviews and surveys especially from the Psychology department, and IVLE student events would be unavailable in December.

Within around 3 days we had around a hundred users, I’d say it went ok, and things were (finally) looking better (even great) for our team.

We also talked to OSA, who initially agreed to help us send an email blast, but at the last minute told us that they were not allowed to due to no clearance, which was kind of expected. But at least they helped us share it on their facebook page, which also helped our marketing.

Ok, so this was a rather vague question I asked myself when we were coming back from Mandai.

Instead of coming up with a solution, now we had to find a better problem to solve.
We also had to meet Colin the day after so we decided to shift our target audience to students, whose problems we knew better.

Initially the group were discussing about an idea for attendance taking, but that problem was already solved, when we spoke to Colin about it. Also the problem was that the target audience was too small, also the advantage of the teams doing games was that the target audience is already large if they can do a decent job.

So while we were discussing with Colin about shifting our end-users to be students instead of VWOs he suggested continuing on with the volunteering jobs idea but doing part time jobs instead. I then remembered that IVLE Student events were going to be closed down in DEC 2016, and that a lot of requests for student helpers and participants in paid experiments were listed there.

Seeing that there was (or was going to be) an unmet need we shifted our ideas to tracking ad-hoc and part-time jobs instead. Fortunately for us we had already built the backbone of the app, so we could change it without much trouble/ wasted work, and we could present the staging version of the website for the progress report 2.

So the way we answered the question was to look at what was lacking currently, afterall the need was already validated for us, all we had to do was build a better version of it. To put it more abstractly, Timing.

https://www.ted.com/talks/bill_gross_the_single_biggest_reason_why_startups_succeed

This also reminds me of a TED video on the single reason why startups succeed, which also argues that ‘timing’ is the reason for the success of startups. Personally I thought it was too safe a statement to make, as although generally speaking the ‘timing’ would makes sense on hindsight, every situation is different and the specific conditions that one looks out varies widely. In our case the change was specific to IVLE and ad-hoc jobs on campus. But still, I thought it was apt that one had to be opportunistic to exploit changes in the landscape, either situational or technical that tended to have better results.

So, one thing that future batches of CS3216 students can learn from my team is that talking to your users is key. My previous blog post was listening to feedback. But all these people we talked to were not our end-users. For many apps, the users are it’s currency. And at the time of the previous post we had talked to exactly none.

The problem is that while the feedback may be great to hear, it wasn’t strong enough for us to change direction. On hindsight, we should have went straight to VWOs instead of linking ourselves up with people who knew VWOs and volunteers. That was exactly what we did around 4 weeks before STePS, when we went down to St. Joseph’s Home in Mandai(!), and talked to Geraldine, their volunteer manager.

We found out that the needs of the VWOs were more than we could accomplish in a month. It wasn’t just tracking but a whole host of other interconnected problems, from before volunteering begins, when they recruit volunteers and screen them, to after volunteering when they want to engage them. Verifying volunteers’ attendance at first seemed like a well-defined problem, but after speaking to Geraldine we realised that most volunteers don’t actually have the level of incentive that we had envisioned, and even if we could solve, that there just was not much demand.

There is a saying by Paul Graham that

“A startup founder should be writing code and talking to users. That’s it.”

We got the writing code part down, but again it was talking to users that was the missing link.

In hindsight, maybe it was just easier not to talk to the users, I think the mentality that we as programmers (or at least I) have is that “talk is cheap” and I would rather someone just “show me the code”, which I still think is true. If only I could have convinced my past self that while that is true in programming iteslf, building a product isn’t the same thing. Other people are involved in the creation, the main and maybe only important group being users, and understanding their needs is the core of whether that creation has a reason to exist.

I think personally talking has always been something I was lacking in, and I’m glad at the very least CS3216 reminded me of how much I needed to improve in this aspect.

Getting Feedback

During the past week we’ve talked to a few people, besides Colin, who were involved with our main user group, volunteers, in various ways about the idea of time credits and got some valuable feedback on the idea.

The first was Prof Sun Teck, who pitched his idea about reaching out to ‘at risk’ users on social media. In the end both our groups’ and his idea had different objectives, but he was willing to give us contacts to people who managed volunteers that he knew, and suggested people who were doing CIP as they may want other incentive. His group also questioned whether the time credits would de-value volunteer work, the idea that extrinsic motivation would crowd out the intrinsic motivation of the satisfaction and relationships formed through volunteering work.

We also contacted Mr Moh Hon Meng, founder of hoodchampions.sg, whose blockpooling.sg was similar to our initial idea. Being on the board for the children cancer foundation, his insights were quite useful too, and he also offered to link us up with some of the volunteer managers he knew to help us test the app. From our conversation, his opinion of the nature of volunteering was that for younger volunteers it was more on an ad-hoc basis, and VWOs (Voluntary Welfare Organisations) were trying to adapt to cater to more ‘on demand’ volunteering, in contrast to long term commitments from older volunteers, and that the whole process of verification of hours volunteered was manual, tedious and a problem worth looking into as we could add real value, in terms of saving costs and increasing the volunteer pool for VWOs.

Also, he cautioned against doing material rewards as he felt that for volunteers the rewards were less material, and more psychological - from his experience the interaction with children, appreciation from the VWOs, also of the general trend of employers hiring based on more than grades, but also looking at things like social consciousness. Some ideas for additional rewards for VWOs, in addition to number of volunteers and exposure, from our discussion also were to improve the interaction with volunteers, like leaving messages or positive testimonials for each other.

Lastly, Xu Jie also contacted some of the social oriented clubs and societies in NUS, as they could be our potential users as well. Some feedback we got were that, it would be useful for VWOs although the current idea requires employers to verify the hours on our platform, also that time credits could take away the spirit of volunteerism, and tasks for helping out in your own community would be helpful.

From the above feedback we concluded that rewards may not be desirable, in a way it lightens our load as Colin was afraid that the marketing effort would be too much as we had to go and pitch to merchants also and the rewards that we would get may not be that attractive.

Getting more Feedback

Still, I believe that building the prototype and getting the end-user feedback would be more important, and to see what they do instead of what they say aka the first rule of usability. Starting usability testing asap would be useful to iron out our features, and tailor it to the problems that volunteers and VWOs would face.

Design considerations

Here’s some preliminary designs that Irvin and I came up with for 1our, a platform for volunteers, businesses and causes to show appreciation through time credits:

Some UI decisions were:

  • Not using hamburger menus ( After this article about avoiding hamburger menus )
  • Guidelines for organising layout, for eg: how many buttons on the bottom bar ( we went for three ) Material design has some neat and specific guidelines
  • A question: Would the app not be simple enough for users (businesses/ volunteers) to get onboard? ( How to reduce the number of steps for businesses/ volunteers to redeem time credits - Would QR codes be a good idea? )

Ideas on users:

  • Who the main target audience would be? ( Volunteers who could use a bit of incentive, charities who need volunteers, businesses interested in supporting causes )
  • We were familiar at least with volunteering, but engaging business could be an issue
  • Would there be too many stakeholders? There’s that famous advice about doing things that don’t scale

This week while having my mid-terms I researched on the idea of time credits, which my team is planning to adapt in our final project, 1our.

Time Banking was initially popularized in the US by human rights lawyer Edgar Cahn in 1986, when “money for social programs dried up” and no dominant approach to social service in the US was coming up with creative ways to solve the problem, and the term ‘Time Credits’ were coined by him. The first time bank was started in Japan as early as 1973 by Teruko Mizushima, where she had foreseen problems of an ageing society in the 1940s(!).

Time == Money?

Spice (justaddspice.org) is based in the UK and is one of the more popular developments of the Time Credits concept, where:

“for each hour that an individual gives to their community or service, they earn a Time Credit. These credits can then be spent on an hour’s activity, help from another individual, or gifted to others.”

Given this association with time credits and social work, it may make sense to apply time credits to social work instead of just a general listing of work or odd jobs. MCI seems to have the same idea in the ICT masterplan preliminary ideas, but it seems that it hasn’t materialized. In Singapore, it seems more volunteers are needed in some areas like the elderly

Is / will there be demand?

An issue may be that people just “don’t have the time”, especially in busy Singapore.

With regard to volunteerism, youths may not want to volunteer. Still, first on the list of goals in the survey were maintaining strong relationships, and third was learning new skills and knowledge. Time credits have been shown to exactly meet these needs, and seems to me more meaningful and useful than CIP hours.

With 43 per cent of those aged between 15 and 24 served as volunteers in 2012, and the number rising, our project may add more meaning to the somewhat top down and forced CIP volunteerism. Of note is that the rates of volunteerism drop for working adults who concentrate on building their careers, so we can probably rule them out as our main target audience.

Time < Money?

It has been found that most may just want to give money instead of time. Again this would apply to the general working population, so maybe we should focus on people who are still studying and those who have retired, who have the most ‘free time’.

Is there time for us?

Spice has an extensive list of partners and backing from the local government, but for our 2 month project perhaps we could focus on validating the idea instead of trying to scale it to many organisations. Some suggestions are to start small, with activities the community is familiar with

As assignment 3 comes to an end, just wanna share a few options for deploying the app which was built upon the create-react-app boilerplate.

The no-backend option

These are mainly the options stated in the documentation, which makes use of the build folder generated with npm build script command. There’s heroku buildpacks, modulus, now and surge.sh, and probably more being added soon. These had been useful for deploying the frontend of the app, when our backend was not ready yet.

With backend

Deploying the backend comes with its own set of challenges. Before that, developing one to work with the webpack dev server was also a tough one, here’s a tutorial that came in useful for us. We eventually used Express for out backend, and it worked out quite well for us.

These were steps that worked from the discussion in the issues:

  • Delete Procfile
  • Move "react-scripts": "0.2.3" from devDependencies to dependencies

In the server’s package.json:

To tell npm to run server.js:

  • Replace "start": "nf start -p 3000" with "start": "node server.js"

Heroku runs npm install as default so to also run npm i in our client build’s package.json:

  • Replace "server": "API_PORT=3001 ./node_modules/.bin/babel-node server.js with "install": "cd client && npm install && npm run build && cd .."

In server.js

To tell serve up the static site on the root domain:

  • Add const path = require('path');
  • Replace process.env.API_PORT with process.env.PORT
  • Add app.use(express.static(path.join(__dirname, 'client/build')));

In routes.js (or wherever your routes are)

1
2
3
4
5
6
7
8
9
var router = express.Router();

router.get('/api/feeds', FeedsController.getFeeds); // Get all the feeds

// ... other API routes

router.get('*', function (req, res) {
res.sendFile(path.join(__dirname, '/../client/build/index.html'))
})

This is so that if I type in a direct url for example https://dropins.space/drops, I won’t get a 404.

It sucks that heroku puts dynos to sleep, but a simple workaround I googled was to do:

1
2
3
4
var https = require("https");
setInterval(function() {
https.get("https://dropins.space");
}, 300000); // ping every 5 minutes (300000)

So yea, check out dropins.space, and phew, time to start studying for midterms.

Get offline with sw-precache

Progressive web apps have offline functionality because of service workers caching static assets and data.
Starting with the create-react-app boiler plate, you can easily see this in action by following the steps in https://github.com/jeffposnick/create-react-pwa.

As with any PWA, first make a manifest.json in the root folder and link it in index.html, and also register the service worker that will be created by sw-precache:

1
2
3
4
5
6
7
8
9
10
<link rel="manifest" href="manifest.json">
<!-- ... -->
<!-- At the bottom -->
<script>
if ('serviceWorker' in navigator) {
navigator.serviceWorker.register('service-worker.js').catch(function(ex) {
console.warn(ex);
});
}
</script>

Then in the package.json under “scripts”:

1
2
3
"scripts": {
"build": "react-scripts build && cp manifest.json build/ && sw-precache --root='build/' --static-file-globs='build/**/!(*map*)'",
}

This creates the production build, copies the manifest.json into the build folder, runs sw-precache in the build folder and caches the static content.

To deploy the static build to a https I used surge.sh, assuming you’re in the root folder, I can deploy to a https domain to see it working:

1
surge client/build --domain drop-dev.surge.sh

Open chrome dev tools under application you should see it:
ss