Student Emotions and Relational Databases
For our final project, we worked on a web application for the Boys and Girls Club of Conejo Valley, California. The Boys and Girls Club is a non-profit organization that has impacted the lives of children and families across the US. The Conejo Valley Boys and Girls Club(B&G Club) is a string of 9 clubs throughout Conejo Valley whose membership includes 4,000 children(members), 500 volunteers, and over 100 full-time employees. The problem we were tasked to solve is adding an “Emotion Tracker” feature in their existing application. This feature’s primary goal was to give the student’s agency, allowing them to express their sentiment as they enter, leave and finish a program at the Boys and Girls Club. This emotional data would also allow administrators to make better informed decisions about student well being and the efficacy of the programs at each club. To solve this problem, and give the B&G Club the emotional data capture and management tools to better serve their members, my team began planning how to implement this important feature.
This product feature is composed of two parts. The front end user experience that would allow staff members to choose the current program where the students can line up in a queue, scan their QR codes to sign in and choose an emoji that best represents their sentiment at the time. On the click of the “submit” button, this emotion data along with a student, program, and club id would be sent to our backend system to organize the data. The organizers of the data must keep in mind the analytics the B&G Club will be performing on this data to better serve their students.
When we started this project, I was a bit concerned about the best way to keep track of this emotional data. I chose to work on the backend team. At the beginning of this project, I didn’t have a clear vision of the best way to model the data. This issue would soon become far more complicated after conversations with my team and our stakeholders, but we would rise to the occasion.
Do we need a Join Table here?
My main contribution to this project has to do with the design of the database. The backend team and I were asked to record member reactions as a response to all club activities including arriving and departing the club. The fun started when our team had differences of opinions on how best to implement the database, which made for a lively technical discussion. One group on my team believed that the member emotions for checking in and out of the club should be properties of each member and program reactions should be properties of each program. I thought this was quite an easy, straightforward solution and our team began to plan around this database design. As time went on, and through conversations on data modeling with our stakeholder, we understood that we need to keep track of which member reacted to which club program. To accomplish this with our current database design, the member reactions for each club program(ex. soccer) would have to be a list of key-value pairs with the key being the member id and the value being their emotion after soccer. After our stakeholder meeting, the team and I discussed this issue and while talking it through a colleague and I came up with a different database design structure.
This new database design would treat every piece of member emotion as a response to a club program. This means that we have to expand the idea of a club program to include checking in and checking out, which indeed are events that happen at the B&G Club. Following this logic, checking in and out would be a program that members express their emotion to just like soccer, art or music. In this formulation, we don’t have to segment data that is interconnected, and our data modeling becomes easier and more straightforward for our stakeholders to understand.
After this revelation, I was brought down to Earth by the fact that just because I think this is a brilliant solution does not mean my team is on board. Especially because we have made some progress with the first database design idea, but I foresaw some major issues down the road not just for my team but the inheritors of our code, so I had to state my case. Luckily in software engineering you don’t have to convince people with just human language. With my team’s blessing, I created a new branch in Github and me and my colleague got to work on this pivot of our database design. Once we got to the point where the code was readable, understandable, and we could demonstrate it functions as intended. We brought it back to the team.
This beautiful member reaction save function lives in our member reaction controller but calls upon services and repositories from throughout our application. First, this function restricts authorization only to administrators(ADMIN), club directors(CD) and staff(YDP). The parameters that are necessary to complete this API call are the member id(mid), the program id(pid), the club id(cid), and the reaction id(rx).We then go through each piece of our parameter data that was passed from the front end to ensure quality in our data. At the next line beginning with “Member member”, we began to make sure the member, program, club and reaction are in our database. We are doing this because every member reaction must belong first to a member(1), that member must be responding to a program(2), that program must exist in a B&G Club(3), where that club has a list of emotions(emojis) that members can express themselves with(4). To ensure robustness in our data we check to make sure all those components(1,2,3,4) exist in our database, if all of those identifiers are found in our database, then we can successfully save a member reaction. We also use this save function to take attendance so the “clubMembersRepository” save function saves the member at the club id that was given.
The save function above relies on a cascade of other functions our team built to function properly. This is what made this problem tricky, to save a member reaction, we have to be able to save and verify members, clubs, programs and reactions for everything to work. Luckily, our team had most of that functionality fleshed out before we put it all together to be able to deliver our key objective. So after the demonstration of how this code works and what its purpose is to the other members of my team, we decided to merge it to the production branch and that is our new database design going forward. Through this harrowing experience, I fully internalized the power and fragility that comes with relational database systems. I also learned that asking good questions early, can save you a world of hurt later on.
Through an incredible amount of teamwork and coordination we were able to ship some great features for B&G Club:
Scan QR code and authenticate student:
To capture emotion sentiment of B&G Club members:
On the backend, storing emotion data in a reliable and useful way:
Our stakeholder told us the Boys and Girls Club is moving to implement this emotion tracker across the US. It is amazing to think how code I worked on, thought and dreamed about, panicked over, could one day be used by so many people. To me, the future of this application is data analytics and user experience. My backend team was able to model and organize the data in a useful and clear way. From now on, data scientists will help our stakeholders visualize and use this data to fulfill their wonderful mission. How exactly they decide to make sense of all of this data will be a fun challenge. On the front end, tailoring the user experience of the application to fit the needs of the students and staff who use it multiple times a day will be crucial to ensure quality of data. The biggest challenge as a whole will be ensuring the quality of the data with everything from the user experience to the database structure. Ensuring the quality of data means making sure the data reflects the member’s emotional sentiment as accurately as possible.
Throughout this project, I have reached out to many colleagues for guidance, discussions and code reviews. One of the biggest things I’ve learned from those experiences is the attention to detail necessary to pull off a big project. My mind has always been quicker to grasp the big picture ideas and it takes me a bit longer to understand all of the details. Through the process of formulating the idea for the database design change, to implementing it showed me the importance of all of those details and how they create the big picture. The save function I showed above relies on many smaller functions throughout the codebase. If any of the smaller functions don’t work properly, then neither does the bigger function that encapsulates them. The interconnectedness of this database design and relational databases in general showed me very clearly: every detail matters.
As a former teacher, I was thrilled to work with the Boys and Girls Club on this interesting project. Moving forward I will pursue opportunities in E-learning where I can partner my technical skills with my education experience.
Thanks for reading!