Care Don’t Care

Background

Initial Plan

Role: Front-End Developer

Duration: January 2024 - March 2024

Tools Utilized: React, Firebase, External News API

Application Type: Web

"Care or Don’t Care" is an innovative web application that allows college students to engage with trending news. Inspired by the mechanics of modern-day dating apps, the application features a functionality that enables users to express their preferences regarding specific news articles by indicating whether they "care" or "don’t care" about them.

This project was developed for my INFO 442 course, Cooperative Software Development. I was tasked with creating a "Care or Don’t Care" application, with the project requirements being intentionally vague. My team was responsible for devising our own development plan, timeline, and implementation strategy. We opted for the following approach:

  • Utilizing React to build our web application

  • Styling the page with Bootstrap

  • Storing our data in the Firebase Real-Time Database

  • Sourcing information from a News API

Throughout development, I adhered to an agile approach, which facilitated organization and structure, allowing for multiple iterations. We performed pair programming throughout this project, allowing me to learn from my partner and vice versa.

My initial plan was very ambitious. I came up with a product containing a ton of functionality and unique features. I quickly realized that this would not be feasible in the short time we had to develop. I was one of two front-end developers on our team of 6 which meant that we would have to work quickly and effectively. I had to rethink my initial approach, and to come up with a concise set of features for our MVP (Minimum Viable Product). I knew that ensuring full functionality of our product with the essential features was much more important than having all of these extra features which failed to perform properly.

Implementation

After some reconsideration about our features, my partner and I came up with a plan for our web application. We chose to focus on 4 main features:

  • A signup (1) and login/logout screen (2)

  • A modal which displays news articles providing the user with the ‘care’ or ‘don’t care’ option (3)

  • Saving articles to a profile (4)

I split up work into these 4 categories and took on each task one by one. After having implemented one feature, I tested functionality and ensured that it worked properly before moving onto the next feature. Afterwards, I ran through some user testing with 5 participants to analyze the outcome of our efforts. The user testing passed the use cases, and my team developed the web application seen in the demo video.

Challenges

Deciding which features were essential was a big challenge since I had been so inspired about implementing so much functionality into my team’s application. In the end I’m glad that I simplified our product since it is something that I can be proud of for completing.

I had a lack of knowledge with regards to creating a web application with a database, fully reactive frontend, and all of the data pulled from an API, so this project was definitely a learning experience. I ran into a lot of bugs, and researched a lot online to be able to build the finished product that is now seen in the GitHub.

My team and I were planning to host the web app through firebase and to publish it online, but towards the end of the quarter I realized that the API we had implemented required a paid subscription so unfortunately the only way to view the web app is hosted locally.

Major Takeaways

Included is my team’s final presentation for the course, with a listing of all of my team members and their roles. Included in the presentation are MVP and MLP features, the database design and component/system diagram, a short-term and long-term roadmap, and a couple of additional slides with information about the product.

  • This project taught me valuable lessons in adaptability and simplification when faced with time constraints.

  • The process allowed me to identify the key features necessary for our final product and to make decisions about features which were ‘must have’ as opposed to ‘nice to have’.

  • I also learned about breaking down a web application project into key components and making a list of action items. Taking on each feature one by one and flushing out functionality before moving onto another feature was very useful and allowed us to fix problems along the way without having multiple features faultily interacting with each other.

Overall, this project allowed me to utilize my React knowledge, efficiently style with Bootstrap, practice with the Firebase-Realtime Database, and provided me with my first encounter for pulling data from an API. My problem solving skills were put to use, and my team and I were able to finish the project in time for the deadline at the end of the quarter.