the app

wherework is a web app that shows the nearest places in which you can get stuff done. The app was built within a week using Ruby on Rails and Postgres by a team of four.

Users can filter results by availability of seats, power sockets, wi-fi, coffee, noise level, etc.

You can search for places around a location other than your current one. The app also displays further details on each location, e.g. opening hours.

pros and cons

Some points on which we are satisfied with the app:

  • relatively free of bugs (fingers crossed)
  • some attention paid to UI
  • responsive design
  • interaction with APIs including Google Maps, Google Places, and Twilio, which we were happy to learn how to integrate.

But we could definitely have done better by:

  • implementing more features like user ratings, and filtering results taking opening hours into account
  • reducing bandwidth by filtering location results at the back end
  • researching the potential causes for Google geolocation failures
  • including automated testing
  • seeding the app with location data beyond the Orchard Road area.

challenges and lessons

Coding alone is hard, and while extra hands enable more features to be developed within the limited time, collaboration presents a different set of challenges.

One thing we learnt was how to work on different git feature branches. Each time any of us wanted to merge a feature branch, we would submit a pull request. The proposed merge would then be reviewed by one or more team member(s) whose code may be affected.

Being violently yanked from a feature you are working on to approve someone else’s pull request is definitely disruptive to workflow.

Thankfully, all of us were nevertheless on the same page that code review was necessary to avoid crippling conflicts down the road. It also takes really thick skin to ignore a team member waiting to start on a new feature.

A major premise underlying the app was that users would be willing to update data on the various locations in real time. For example, we bet that a user in a café who saw seats freeing up would provide an update for the attention of other users.

Evidently, the generous goodwill of users is a rather shaky assumption on which to build our app. To validate this, we conducted some user research that turned out to be reasonably encouraging: 84% of respondents had previously contributed to a crowdsourced platform.

We also consulted Kim, a UX designer, for some valuable input on app design. Working with a designer was pretty fun. Some of us did already have some appreciation of the importance of UX/UI, but nothing beats having the input of someone focused purely on design, free from development difficulties lurking at the back of her mind. I believe we all learnt a lot from negotiating tradeoffs between fab features and finite development time.

We also had many a heated discussion on the features we definitely wanted to include, and what could be excluded given the limited time. Our arguments traversed well-trodden areas including whether we should focus on serving a narrow set of users, or different users ranging from the budget-conscious to people who cared particularly much about lighting. This was probably our greatest challenge, and after reaching agreement it was relatively straightforward setting up our entity-relationship models.

One thing we could have done better is to streamline the process of working through sometimes-stark differences in opinion more amicably. In other words, and probably obviously, focusing on the people issues should rank high on your list of priorities if you want to maximise team performance.