Role

Project Co-Lead • Product Designer • Full Stack Developer

Timeline

September 2021-December 2021

Tools

JavaScript • HTML • CSS • Figma

Project

01

CreATE

Web Development • Product Design • Project Management • Class Project

This project was developed in my junior year during my undergraduate program as part of my coursework. We were tasked with creating a web application - a recipe manager that satisfied CRUD (Create, Read, Update, and Delete) requirements. I was assigned as a Co-Lead for my team, consisting of 11 other students who, like me, had little to no experience in web development.

We were given a tight schedule of 10 weeks where we were required to follow Agile practices in brainstorming, planning, designing, developing, testing, and finally deploying. Our team decided to focus on a niche audience of college students and young adults who typically find it hard to eat healthily and inexpensively at home while also balancing school and work.

Given the time constraint and the steep learning curve, we set our goal to build a CRUD Recipe Manager with cloud-based memory storage and an integrated shopping list feature.

Overview

02

Problem

How can students and young adults who struggle with planning meals, particularly during the week, find ways to make recipes that aren’t time consuming, cost effective and healthy that suit their lifestyle?

Background

I love to cook for me and my roommates, but on days I have work or school, I’m usually tired and exhausted by the end of the day. I think most of my friends in similar positions tend to resort to fast food and takeaway.
I don't particularly like fast food because it it's not really good for my body or my wallet. To add to my problem, most internet recipes either take too long or are too complicated and their websites are filled with ads and pop-ups which only make them more confusing to navigate.
Personally, I know a lot of my friends and peers also feel similarly, supported by the findings below, and that’s what CreATE aims to solve!

overiwe-charts

Solution

A place to create, inspire and find recipes for you and your roommates that are easy, quick, affordable and most importantly amazing!

Contribution

This project was part of my coursework, CSE110 a web development course. I was a co-leader for my group as well as the lead UX designer and a developer.
As a Co-Lead I had to schedule weekly standup meetings with different sub-teams in our group. As the teams project manager, I had to organise and maintain our GitHub repo, which stored not only our dev files but also our meeting notes, design docs and internal wikis, by setting up branch protection rules, pull request reviews, a simple but efficient CI/CD pipeline all according to Agile practices.
We brainstormed and ideated everything using Miro where as the lead designer I came up with our style guide, wireframes both fatmarker and higher fidelities. As the product designer I performed user research on potential users and other recipe apps and websites.
With regards to development, I transformed our finalised design to CSS and worked on the front-end for our landing page. In terms of testing, I wrote the unit tests in our pipeline for our recipe creating feature as well as for the shopping list.

GitHub Repo

User Research

03

Research Insights

Mobile vs. Desktop

We observed that this application is most useful when it is used along side the actual cooking process. This means that it's most useful to be optimized for mobile. As we were constraint to developing a web application this made us particularly focus of responsiveness.

Touchpoints

Reducing the number of touchpoints is crucial because as this application is meant to be used while cooking having minimal reasons to touch your phone is crucial. This meant we had to make our display of recipe cards not only easy to navigate but minimal to reduce scrolling.

Recipe Library

Observing other recipe manager and recipe finder websites and apps we saw that using only local storage will make our project too limited. However, scraping the internet for recipes seemed too bloated and defeated the purpose of our application. We landed on having the ability to share recipes among friends and peers and storing them within their own libary which would be stored on the cloud.

user-personas

Design

04

Iterations Brief

Iteration #1

During this iteration we designed the fatmarker as well as some aditional features that we had initially ideated such as a more detailed search and filter option but later removed due to time constraints.

Wireframes

wireframes

Iteration #2

Here, we added a timer within the recipe view which we later removed as well due to development issues. Below is a screenshot of our login page, homepage, recipe libary page as well as our shopping list page.

screenshots

Iteration #3

During our final iteration we simplifed our home page and recipe card view to make all potential user flows as simple as we could to allow a user to easily navigate and access our features. Below is an example of that.

screenshots

Development

05

Outline

This was the most challenging part because we didn't have much collective experience using HTML and JS and had a month to complete development testing and deployement. Before we started this phase of our project we divided ourselves into 3 sub teams, front-end development, back-end development and testing.
The next part of our plan was to program in sprints of 10 days with the intention of having 3 iterations to create the best application we can. This was challenging because to our lack of experience leading to the first sprint taking 2 weeks which made us recalibrate our original plan and we ended up completing only 2 sprints.
Some other obstacles were our unfamiliarity with one another and programming styles as well version control of our assets. Using stratergies such as CI/CD pipelines, multiple sprints and pair programming we were able to overcome our obstacles. I've gone into more detail about some selected development problems and how we dealt with them below.

sprint

Challenges

#1 Storage

We had issues dealing with storage for each users' recipe libary both on the cloud and locally. Storing the library of recipes a user created wasn't the tricky part. Our primary issue here was storing the images. We couldn't figure out the best way to store the image on the device without it consuming excessive space. In terms of cloud storage we had trouble communicating with the end points we had. Here too we had a similar problem with storing the images. On top of this, we had bugs regarding to retreiving a user's stored data from the cloud. This leads me to our second challenge.

#2 User Authentication

As we wanted the ability to share recipes we needed a way to identify a user's our recipes. We decided to use Google's Sign-In API as a ways to use their email-id as their unique identifier. This gave us a lot of trouble as weren't able to uniquely identify a users' created recipes and the recipes that are shared with them.

#3 Shopping List

Our Shopping List features was designed to interact with recipe cards allowing users to select ingredients from the ingredient list and add them to their shopping List if they wanted to. This was tricky as due to our cacheing issues mentioned above the list didn't update correctly when we added the selected ingredients.


API diagram

Solutions

#1 Storage

To reduce the amount of space consumed by images, we compressed the images before storing them using local storage on the device. ANother possible solution we considered was using a content delivery network (CDN) to serve the images to your users, which can help improve load times and reduce storage costs. What we finally decided to do was to encrpyt all the images using base64 conversion. We chose this solution because by doing this we didn't need to set up any compression pipeline or use a CDN as the base64 conversion could be easily stored as a part of the json file with the rest of the recipe's text fields.

#2 User Authentication

This was the easiest fix as we had a bug with how we called the API which was easily fixed. To uniquely identify a user's created recipes and shared recipes, what we did was assign a unique ID to each recipe and store that ID along with the user's email in a database. This allowed us to associate each recipe with its respective user and enable sharing between users.

#3 Shopping List

Websockets. That was our solution. We didn't really know what they were before we encountered this issue. To ensure that the shopping list updated correctly when users select ingredients, we implemented a real-time update system using websockets. This allowed us to push updates to users' shopping lists in real-time, ensuring that they always have an accurate and up-to-date list.

Retrospective

06

Outcome

Our final project was a simple prototype of the web application which performed the 4 main tasks of creating, reading, updating and deleting recipes as well as managing them within a cloud-based database.

If we were to continue to build on this I would try to make the recipe card's expanded view more interactive and intuitive as well as a in-built timer feature as a part of the recipe card.

Reflections

Due to the fast pace of our quarter, we faced a significant challenge in completing the development of our project within a tight timeframe of just 3-4 weeks. The difficulty was amplified by the fact that most team members had limited or no prior experience with HTML, JavaScript, and CSS, the core technologies required for our project. This lack of familiarity with these languages posed a major hurdle in creating the desired features and effectively communicating with the backend system.

One specific setback we encountered was the inability to implement the filter feature in our application. This feature would have allowed users to search for recipes based on specific tags or categories. However, due to time constraints and the complexity of the task, we were unable to add the necessary tags and categories into the metadata of each recipe. This limitation made it challenging to populate our recipe bank with the required information, ultimately leading to the exclusion of the filter functionality from the final product.

Despite the challenges we faced, the overall experience was highly rewarding. We managed to overcome numerous obstacles, including the steep learning curve of working with unfamiliar technologies and the time limitations imposed by the project timeline. Despite not being able to implement all the desired features, we are satisfied with the outcome of our efforts. The project provided us with valuable insights into the development process, honed our problem-solving skills, and fostered collaboration within the team.

That's the end!

If you want to go back to the top click here.
Or,

<- Go back to all projects