PlateAgain

PlateAgain

PlateA­gain was a group project com­plet­ed in the final 2 weeks of a web devel­op­ment immer­sive course at Bit­mak­er (GA Toron­to), com­plet­ed in March 2017. It is a ful­ly respon­sive Ruby on Rails app address­ing com­mer­cial food waste in the city of Toron­to.

Screenshots of PlateAgain on multiple devices
Screen­shots of PlateA­gain on var­i­ous devices.

The Story

Com­mer­cial food waste is a huge prob­lem in large cities, and is a mul­ti-bil­lion- dol­lar prob­lem nation­wide. With grow­ing atten­tion in the last few years, new apps and ser­vices are start­ing to appear to address this issue and reduce waste. With two of our group mem­bers hav­ing wit­nessed huge food waste while work­ing in the food ser­vice indus­try, we felt that this was both a mean­ing­ful and scal­able project that we could build as our final project.

Aimed at restau­rants, cater­ers, event plan­ners, etc. in the city of Toron­to, PlateA­gain would allow these “providers” of sur­plus food to cre­ate accounts and list avail­able food items. Shel­ters, meal pro­grams, etc. can cre­ate accounts as “accepters” to view and claim food items. Via PlateA­gain, these two par­ties can view each other’s loca­tions, get direc­tions, and com­mu­ni­cate via in-app mes­sag­ing to arrange trans­fer of the food items, and per­haps to devel­op ongo­ing rela­tion­ships.

The Process

I took on the gen­er­al role of project man­ag­er, though we used a shared Trel­lo board to joint­ly for­mu­late our user sto­ries and the fea­tures we were imple­ment­ing at each iter­a­tion, and to aid the team keep track of each other’s tasks and progress. Though we tack­led some chal­lenges in pairs, as a five­some we always had a floater work­ing solo or in sup­port of the oth­ers.

Our ini­tial focus was to ensure func­tion­al­i­ty of the app and inclu­sion of the fea­tures we real­ly want­ed, so we all worked on build­ing the back end and start­ed with a very min­i­mal UI through sev­er­al ear­ly iter­a­tions. As the project advanced, I moved from build­ing core back-end fea­tures to a more front-end heavy role, while still check­ing in with my team­mates to assist with the back end code and to build in UI ele­ments or improve over­all struc­ture and UX.

Some­how we got away with skip­ping the design and wire­fram­ing we were sup­posed to do for instruc­tor approval at the onset of the project (!), though we did have a brief chat with a knowl­edge­able UX design stu­dent for some guid­ance. This approach was per­haps against con­ven­tion, but I felt that it allowed us to focus on usable, seman­tic struc­ture and build the UI incre­men­tal­ly through pro­gres­sive enhance­ment, lay­er­ing on the CSS and Javascript, rather than think­ing of fall­back design for when those resources fail or are dis­abled.

Presenting PlateAgain app at Bitmaker's Meet Your Makers night.
All set up to present PlateA­gain app at Bitmaker’s Meet Your Mak­ers night, a show­case and demo of all stu­dent final projects. Mar 2017.

I chose to try Zurb’s Foun­da­tion frame­work to struc­ture and build the app, since I was famil­iar with Twitter’s Boot­strap already (from Barn Genius!), and felt that it was some­times too opin­ion­at­ed in its design; any­one who uses Boot­strap knows that although it’s quick and easy to use, that’s only the case if you want your work to scream “Boot­strap”.

In the end it was real­ly fun to work on a sim­ple idea that we were all excit­ed about, and we got a lot of inter­est when we pre­sent­ed it dur­ing our show­case. The prob­lem of food waste is one that is get­ting an increas­ing amount of atten­tion in recent years and is not going to go away on its own, and it was very reward­ing to con­ceive and build a tool (even just a demo) as a pos­si­ble part of the solu­tion.

Tools & Tech

  • Ruby on Rails
  • Car­ri­er­wave
  • Mail­box­er
  • Post­greSQL
  • Zurb Foun­da­tion 6
  • jQuery
  • AJAX
  • animate.css
  • FontAwe­some
  • Google Fonts
  • Google Maps API
  • AWS S3
  • AddThis
  • GitKrak­en
  • Trel­lo
  • Heroku

Lessons Learned

  • It can be tricky to devel­op demo apps with APIs that require real data. We had to use real Toron­to busi­ness in this app in order to imple­ment Google maps, so we had to replace all of our orig­i­nal seed data. We also had in mind to use an API that ver­i­fied busi­ness reg­is­tra­tion num­ber to ensure that the app was used only by legit­i­mate estab­lish­ments. While this would have been a sell­ing fea­ture in a pro­duc­tion app, it was impos­si­ble (or at least not worth­while) to build into a demo.
  • I like GUIs. It was very help­ful to myself and my team­mates to be able to visu­al­ize the work that we’d all done, the branch­es we’d cre­at­ed and the com­mits we’d made by using GitKrak­en.
  • Any front end frame­work is going to be opin­ion­at­ed to some degree. Although Foun­da­tion seemed less intru­sive than Boot­strap, I found that in the end I still cus­tomized a lot of what I put in, and didn’t use as much as was avail­able. Though it was less of a fight than with Boot­strap, it still defeats the pur­pose of using a frame­work if you’re going to keep alter­ing it, and it’s unnec­es­sary to load all of that code into your project if you’re not mak­ing the most of it.
  • Lots of team­work stuff. You always learn more of it every time.

See it

Live site  Source