Final Milestone Thoughts

As we arrive at the third and final milestone of the Orbital Programme, we’d like to take stock of our lessons learnt and changes since the second milestone. Also, to review the decisions brought up in the previous post.

‘My Polls’ page (app-polls.html)

We have made some changes to improve the layout and usability. We felt that the polls interface is critical to the user’s experience of the application.

Firstly, the status of each poll is now dynamic with regards to the actions that the user can perform on each poll.

While there are no bulk action functions, we feel that the current application does not need housekeeping for the questions that the user creates due to a clear timestamp present in the interface.

Next, we have also included a ‘Help’ button that serves to guide new users. We felt that the application may not be as straightforward and self-explanatory to the user (as much as we have already catered for the usability of the application). The button sizes for the actions have also been enhanced to allow for easier clicking and interaction on mobile devices as well as on the desktop.

Some work has also gone into the inclusion of a column known as the Description – which we primarily conceived as a ‘Tagging’ feature we hoped to put in place for better organisation of different polls together to sort and display. Instead, the description is provided as a plain text attribute for each poll. This serves as an indicator for the user to differentiate between identical polls, but meant for different situations.

Final cleaning up and fixes

Since we have decided to get rid of some redundancies, we had to rebuild the routes on the front end to serve the correct pages for the appropriate links that we have provisioned for. Pages such as app-dashboard.html and about.html have been removed entirely from the app, keeping our focus mainly on the poll interface and the core functionalities of our question-and-answer features.

The results page now contains the option for users to toggle between different data visualisation methods on Google charts (incomplete, not ready for UAT) as well as an export function, which we have created to help presenters take stock of their responses offline to do operations such as a sum, min-max, etc for insightful analysis.

We’ve also provided for a hyperlink to the poll answering page on the ‘Get Link’ page for convenience of the presenter to navigate there should it be necessary.

Features that could not meet the final version

As much as we hoped to provide for a more complete to serve presenters, we were unable to finish up features that we have listed on our README:

  • Open project out to anyone to use

We have stuck to NUS OpenID despite the feedback to open it up to the public to use. We were looking at the option to completely remove the need for a login, where a user can immediately use the application freely and however he/she likes. However, we ran into a dilemma on whether we should go on to cater for anonymity in the polls, with how we should provide the option to bypass the authentication that is necessary to ensure that we have human responses.

  • Choice of Data Visualisation (Pie, Bar, Column)

As of now, we have provisioned for 3 different visualisation methods such as the Bar, Pie, and Column charts – all insightful for the quantitative sum of responses that would make sense on these charts.

(However, the visualisation techniques are not finished and we are unable to complete the implementation in time for this final milestone.)

  • “Youtube Live Comments” concept of open-ended results (comments)

This didn’t make the final cut as well as much as we wanted to. Solving the problem of the answer schema deemed to be too big a task for either one of us to deal with on ourselves without meeting up, and since we are miles apart, it was difficult to implement this portion given our priorities over the course of this project.

Self-assessment and reflections

Looking back on the 3 month journey (well actually 2, considering June was a time-vacuum which we completely left Feedbaker alone in its MVP state), we’ve touched and familiarised ourselves with the technologies we have summed up in this post.

Throughout the course of orbital, we found ourselves dabbling beyond the requirements and needs of Feedbaker as well to further our learning on other technologies.

For Jonathan in Berkeley, he has been actively engaging himself in conferences such as the Google I/O event, ForwardJS conference, as well as participate in the AngelHack and Outside Hacks Hackathon events which I am sure has further honed his skills and knack as a developer and product spokesperson.

For myself who has remained in Singapore, juggling a side project and the internship has been a strong practice in maintaining priority of tasks. I have also went for an AWS conference to learn more about Amazon’s cloud services and how to leverage on AWS to build, test, and develop applications that I may find myself doing in future. Besides that, I have also taken the time to dabble with Ruby on Rails using this guide to prepare for the Red Dot Ruby Conference in June. Feedbaker was my very first web development project and a fresh new endeavour that has taught me much over the many posts we have documented in this blog. I’d like to wrap up based on the important skills/traits I felt was important in seeing the successful state of this project in its current form:


It isn’t about what we knew that was important, but how we go about finding what we needed to know. Most of the time, trial and error was an imperative in figuring out what works and what does not. There were things on StackOverflow that I could not understand at times, and very often find myself in a situation where the documentation was not enough. Knowing the appropriate terminology to the things we want to find out more about helped in getting to the pages and answers that we were looking for.

Building incrementally

Skills that I picked up from CS1010 are truly the basics that we could not have lived without. For every feature that we wanted to develop:

  1. Get the most basic function to work first
  2. Build on the content/data
  3. See if it still works
  4. Repeat from 1

Thanks to the tools such as JSHint, Grunt, and plugins on our text editors, this process was hastened and we got by on existing web scaffolds (Yeoman) to build Feedbaker up very quickly (3 weeks) based on this method.

Getting Feedback

Since we were building an application on getting feedback, we actually had to get feedback to know more about what we can do, what could be done better, and what we should not do. Maintaining a constant feedback loop was important in figuring out what was necessary and what was not. Things that got us to focus can be essentially broken down into 3 main tiers (see also the MoSCoW Method):

  1. MUST-haves: What is essential (CORE features)
  2. NICE-to-haves (Augmentations)
  3. NO-NEED-to-haves

Going through the milestones (although we did not follow it strictly in its entirety) helped us to look at how a software development cycle feels like, and how our roles as a pair of developers are crucial in making sure that we trim the excess from the product to ensure that we meet our deadlines and expectations.

All in all, we feel that the Orbital experience has helped tremendously in accelerating and facilitating our growth as students in SoC, and as computing students that ought to sharpen our programming competencies.

We hope that this project blog has helped those who have accompanied us in this journey and has provided insights into our methodology and thoughts.