Berkeley Student Cooperative — a project overview
The Berkeley Student Cooperative is a nonprofit housing cooperative dedicated to providing quality, affordable housing and board to students at UC Berkeley and other Bay Area colleges and universities. Therefore, students are granted an educational opportunity, who otherwise may not be able to afford a post-secondary education. Currently, the BSC has over 1300 student members living in or eating at their 17 houses and 3 apartment cooperatives around the UC Berkeley campus. Each house is democratically run, and everyone contributes through workshifts to keep the housing prices lower and increase member involvement.
Workshifts are house chores/tasks assigned to each house member. Tasks include washing dishes, weeding the garden, cooking meals, or even working with food distribution and administration to offer members experiences more relevant to the professional world. The BSC project team at Blueprint is working with co-op houses, where residents are required to contribute 5 hours per week of workshifts during both the academic semester and the summer.
There is also a resident per house elected as the Workshift Manager, who collects information from other residents regarding their availability, chore preferences, or disability-related workshift accommodations.
The Problem 🤨
The size of each BSC house varies from 20 to 150 members, and because the housing contracts follow UC Berkeley’s academic semester timeline, there are members moving in and out every few months. At each of these houses, there is one (sometimes two) workshift manager tasked with creating workshift, scheduling their house members’ workshift schedules, and tracking their members’ completion of workshift. In addition to the workshift managers’ experience of overseeing the workshift, house members also need to hand in their availabilities and preferences for what they can and would like to do for their workshift. House members also need somewhere they can check their schedule, submit verification of their workshift completion, and track the hours they have completed and or have missed.
The Solution 🤩
Blueprint is creating a web application to support BSC’s work shift processes named the Workshift Web App.
The primary goal of this web app is to help the Workshift Supervisor and Managers manage and oversee workshift, and to improve the house members’ experience by providing them a tool to complete their house responsibilities with ease.
Through the web app, members will have profiles that store their availability, task preferences, and workshift schedule, and they will be able to submit verification for completed tasks and track the hours they have contributed to workshift. The way that we are handling verification of a workshift’s completion is through PIN codes. Once a member completes a task, they are able to ask another member to enter a unique PIN code that acts as a signature of approval. This verification method encourages the house members to keep each other accountable for their workshift. Additionally, a manager will be able to add their own verification of workshift in case members could not find another member to do so, and remove any invalid verifications. Work shift managers will also be able to create house tasks, assign tasks to members using the provided member information, and view completed task verifications. Supervisors will also have the same abilities as the managers, with the added ability of switching between houses whereas the managers are limited to their own house. Overall, the web app will help keep track of workshift schedule and member-hours.
Audience & Features 🙆🏻♀️
The features of the project can be broken down by the user groups.
- Workshift Managers are the users responsible for the specified BSC house that they are assigned to. Their web app functionalities include the ability to create shifts, input house lists, view member users’ availabilities and workshift preferences, assign member users to shifts, and track member users workshift hours.
- Workshift Supervisors are the users responsible for all the BSC houses. Their abilities are similar to workshift managers. They have the added ability to assign users as the workshift managers and to view and edit any house.
- House Members are the users who live at the house. Their abilities are only for the specified house they are assigned to, and include the ability to submit their availabilities and workshift preferences, view the workshift assigned to them, track their own workshift hours, and submit verification of completed tasks with a witness PIN.
A key consideration when building the BSC web application is that users are students. Therefore, the priority of each feature is to improve efficiency through ease of access and an easy user flow, while still managing various kinds of logistical information.
Technical Overview 👀
The BSC team is working with React, MaterialUI, Next.js, Typescript, Redux, RTK Queries and Firebase.
React is a popular JavaScript library for building user interfaces, which provides an efficient way to render dynamic content, and allows for the creation of reusable components.
We also chose to use MaterialUI (MUI), which is a library of pre-built React components that follow MUI design guidelines, providing us a consistent and attractive look-and-feel for the application.
Typescript is a superset of JavaScript that adds static typing, allowing for better type checking and catching errors at compile-time rather than runtime.
Redux is a predictable state management library for JavaScript applications, which provided us a centralized store to manage the state of our application, and allowed for a clear separation of concerns between UI components and backend logic.
RTK Queries is a library that provides a simplified and standardized way to handle data fetching and caching in Redux applications. With RTK Queries, we were able to define “API endpoints” that describe how to make a request to our database and what to do with the response.
Firebase is a platform developed by Google that provides a range of backend services that helps to streamline the development process and reduce the need for managing infrastructure. We used Firebase Authentication for our users and Firebase Cloud Storage to store our data. Additionally, past Blueprint projects have used React, Typescript, and Firebase, so we had the added benefit of familiarity with the technologies and access to resources provided by previous Blueprint projects.
Technical Challenges 🧎🏻
With every technical project, there are technical challenges, and BSC is no exception. Here are the two most notable ones we encountered.
State Management
In the development of our large-scale web application, we faced a significant technical challenge related to organizing and managing the different variables involved with the application’s logic, known as state management. Initially, we opted for React Context, a popular library for managing application state among Blueprint projects. However, halfway through the project, we discovered that React Context was not well-suited for our application, as it struggled to efficiently manage the numerous interconnected parts of our app.
To overcome this challenge, we decided to switch to a different library called Redux. Redux allowed us to create a central hub for managing all the variables in our application, making it easier to keep track of changes and ensure all parts of the app stayed in sync. This approach not only simplified the way we handled various tasks, but it also improved the overall performance of the application by minimizing the amount of unnecessary updates to the visuals on the screen. Additionally, Redux follows a strict set of rules and best practices, which made our application more reliable and easier to troubleshoot when issues arose.
The transition to Redux proved to be a critical step for our project, as it effectively addressed the complex needs of our application while ensuring faster response times and better coordination among different parts of the app. This experience taught us the importance of carefully evaluating the tools and techniques we use, particularly when working with large-scale applications that require robust and scalable solutions. In the end, embracing Redux allowed us to successfully overcome the technical challenge and deliver a high-quality application that met our project goals.
Designing a Good Schema
(Note: Schema is how we save information, acting as a collection of files).
The challenge with designing a good schema was there there was a lot of information that relied on other information. For instance, when a manager assigns a shift, they need to know user availability, preference, previous hours, and how many more hours the user needs to be assigned. However, in order for users to create preferences, they have to wait for managers to first create the shifts themselves. All in all, there is a lot of logistical information that the web app has to account for. Additionally, we had to make sure that information would not be updated destructively. For instance, if a house member washes dishes, and earns 2 hours, but then the next week, the manager realizes that there are not many dishes and decides that washing dishes would only earn 1 hour, if the manager makes this update, it should not take away from the user’s hours who washed dishes the previous week.
Accordingly, we created user flow charts and used a lot of visual aids to fully understand how each action would affect the database. To continue with the previous example of washing dishes, we would make copies of the information, save it into the user profile, and then break the reference pointer only once the shift is completed. With 3 user groups, it is more likely that one group will make a mistake, and since the features are all interconnected, there are also a lot of edge cases. This is the consequence of a complicated app. Nonetheless, by having a bigger team (the biggest one this semester) and making sure everyone was involved with designing the database and schema, everyone understood how the foundation of the app would work to mitigate any risks that come with complexity.
Design 🌟
Managers are the main priority out of the user groups, so the goal was to make their job easier. The current complaints about the website is that it is difficult to navigate. Therefore, our designer last semester, Evan Quan, did a lot of user testing with the designs to make sure that it was intuitive to BSC. Kelly Hu, the designer this semester, is continuing this process by focusing on ease of view with every design decision, displaying most of the information with tables. Below is the planner tab that for workshifts that a Workshift Manager would see.
Next Steps 😌
At the moment, we are finishing the last few bits of the app. The overall app is deployed, but we’re still working on deploying individual features. For managers and supervisors, we deployed ‘creating shifts,’ and soon, we will deploy ‘shift assignment’ and ‘shift verification’ (we are almost done!). For members, ‘availability’ and ‘preferences’ are deployed, and ‘viewing and verifying shifts’ will be deployed next.
Then, we plan to pivot towards user testing with the actual BSC managers. The website is already live and deployed, so BSC managers and supervisors play around with the feature as each new one comes in. However, soon, we plan on having an actual house use it. More specifically, the Euclid Coop, since it is a relatively small house only 23 people), and then we will move on to a bigger house.
Key Takeaways 😻
There are many takeaways from this project that our amazing PL, Greg, would like to share, and we hope that they provide a bit of insight relevant towards working on any project with any team.
- Understand how to Break down Big Projects: The scope of our project was initially quite daunting and overwhelming. Therefore, we learned to break down the project into smaller tasks, so each step would became more achievable and realistic. The skills we practiced of critical thinking and problem solving while considering both the big picture and specific details proved to be an important and valuable skill. CS assignments often provide project specifications for you, but real-world software engineering, unfortunately, does not work like that. And so, we had to learn how different technologies connect to each other in order to properly apply what was relevant to various areas of the project. Another way to break down the project was to separate back end and front end, so we could test various function separately. In the beginning, we weren’t using APIs, so back end functions were used in our front end components. Consequently, there was high traffic, a high number of reads/writes to Firebase, and subsequently Firebase became more expensive to use. Therefore, keeping code clean and documented became extremely important. One more thing to add is that we initially wrote big functions that had a lot of abilities, but these became hard to debug. However, once we separated the functions by individual abilities, it became easier to test, so that we were able to work faster this semester!
- Keep the Team Close: With such a big team, keeping the team close became extremely important. Good relationships with the people around you motivate you to work harder and do better/cleaner work (because you care more). Therefore, as the PL, the moment I got my team, I organized a lot of team dinners to help everyone get to know each other better (now we have a semesterly KBBQ tradition!). I also reserved 30 minutes before each work session for cherries/pits and questions of the day, to give everyone an opportunity to check in with each other before we begin the actual work. Everyone always gave their full attention to the people speaking, and it ended up being something the new members looked forward to every time. Work sessions were interactive and welcoming, creating shared playlists to judge each others’ music or hosting them at people’s places, so we could eat and work at the same time. In the end, I would say we are very lucky to consider each other good friends ❤.
- Define the Boundary between Friend and PL: One more takeaway I had as the PL was learning how to be strict with deadlines/code quality, without jeopardizing a friendship. I found friendly sarcasm and joking around with my developers helpful to keep the environment light and friendly when I needed to confront people to resolve any problems. In the beginning, I was not super strict, but then I started receiving a lot of PRs that were not very clean, and testing became an extremely long and tedious process. Therefore, I shared my experience with my team by being open and honest, and they ended up writing cleaner code because of the close relationships we formed. I also would ask my team when they could get a task done instead of giving them deadlines, so they could prioritize their own mental health or any school assignments. A lot of delegation was required as well as writing/explaining tasks down to the specifics of the names and inputs. This way, as the only one who oversees the entire project, I could ensure that everything was done according to the overarching goal. Through maintaining open and clear communication, I am proud to share that I never let the role of PL compromise a friendship.
My favorite thing about being PL was being involved in every step of the app (scoping, design, front end, back end) and I learned a lot of things that I wouldn’t have learned as just a developer. As a member of BSC myself, it has also been super rewarding to lead a project that helps a community I am apart of and is really close to me. Even though the scope of the project was huge, I chose to PL for the entire year, because I have a lot of insights on user pain points and use that I believed were crucial to finishing this app. My advice to future PLs wanting to take on a big project, choose a something that you are really passionate about, because you’re the one that needs to inspire others to complete that big project. — Greg (Project Lead, Fall ’22 — Spring ‘23)
The Team
alphabetical by first name
Project Leads: Gregoria Millensifer (Fall ’22 — Spring ‘23)
Designer: Kelly Hu (Spring ‘23), Evan Quan (Fall ‘22)
Developers: Andrei Tan, Danashi Messele, Folosade Oloye, Marcos Hernandez, Samantha Oh, Steven Huang
Github
web app 💻
This article was written by Blueprint external member Sarah Peng. If you have any questions or clarifications, email sarah.peng (at) berkeley.edu.
