We are all part of several large group chats, and it is not uncommon for a student to ask for a favor. We wanted to consolidate this behavior into a campus-wide system that is inclusive of all students who might not have the same large social networks that other students may have. We also felt that many of the errands that college students run result in redundancy relative to time and transportation emissions. By allowing students to easily request favors and communicate when they are going on these errands, we can drastically cut down on the amount of unnecessary trips that students must take. Finally, everyone likes an opportunity to get paid. Not only did we want to give students back their time by consolidating trips, the students making these trips can earn a little bit of extra cash by assisting their peers in need.

What it does

Our web-app, favor, enables student to connect with each other and assist each other with various tasks. There are two main aspects of our application: the ISO page and the opportunity page. The ISO page allows users to make post for tasks that they are seeking out help with in exchange for money. Other users can then fulfill these requests. This then sends the request to each user's landing page where they can monitor its progress. Then there is the opportunity page which allows students who are already intending on completing tasks to reach out to other students who could benefit from their actions. A student posts the action they intend on performing at a designated time, and other users can add comments onto their post, indicating that they are interested in a favor. By enabling students to help each other accomplish even the smallest tasks through our application, we are cutting down on emissions through redundant transportation as well as building new social bonds.

How we built it

We started building our project by propping up a firebase database with built in Google Authentication as a placeholder for a user API. Then we started structuring our page layout and building shared components that we could then populate with firebase data retrieved through our service class. The rest of the project time was spent polishing and implementing minor details of the web-app.

Challenges we ran into

We frequently struggled with date/time conversions between their representations in our frontend and how they are stored in firebase. Additionally, we had some challenges in maintaining data integrity across all our pages and service calls.

Accomplishments that we are proud of

This was most of our first times using firebase as the backend for our web-app. Since it is a smaller project, we didn't feel the need to build out an entire API using SpringBoot or .NET, so our entire backend is based in javascript. This was also the first project that we relied on external APIs for, so it was rewarding to integrate them into our own system.

What we learned

We learned a lot of using frontend frameworks and component libraries in conjunction with custom styling as well as the importance of prioritizing mobile-first development practices.

What's next for favor

If we have more time, we intend on building out a notification center so users are not reliant on each other’s real contact information, a payment system, a rating system for favor requesters and granters, and the ability to link the opportunities with the landing page lists in addition to the already existing ISO information.

Share this project: