ActiveRoster
Written Summer of 2019 (ActiveRoster)
Written Summer of 2020 (ActiveRoster2)
Pictured: The main UI window of ActiveRoster.
Pictured: The main UI window of ActiveRoster.
When I was elected as Captain of HPRC, one of the things I wanted to do was create a better system for tracking member attendance on the team. While the team had a criteria for who qualifies as an active member, it was hard to tell who met them and subsequently it was hard to tell the exact size of the team along with who qualifies to attend competition. I wasn't interested in managing a massive spreadsheet tracking every event, so I did some research. As is often the case, I didn't find any software that was an exact match for what I was looking for so I decided to take it on as a summer project.
The end result was ActiveRoster, a Python program designed to track members attendance at HPRC events and automatically determine their member status. Once a member in the system, all they had to do was swipe their student ID to be counted at an event. Despite there being a couple bugs when I rolled it out at the beginning of the year, they were soon fixed and it was able to do its job effectively.
I learned a lot in the process. In order to sync between computers, it utilized Google Firebase which was my first time using a cloud database. I also learned about distributing Python programs, which was more difficult than I expected.
In the time since I wrote ActiveRoster, I learned more about databases and software engineering. Looking back, I've realized that the ActiveRoster database implementation broke some best practice rules. There were also a few officers who were reluctant to learn a new program. Because of this, and a couple smaller items issues, I hoped to revisit the project.
As the team prepared for the 2020-21 competition year, we had to transition to a virtual workflow. Because of this, swiping student IDs was no longer an option. I decided to revisit the project to create something that would accommodate this. I also wanted to simplify the program. While packing a program with features has taught me a lot about programing in the past, I've learned that often times users just want something intuitive with well polished core features.
The team was using MS Teams for video meetings, which is able to generate attendance reports. I decided to, instead of managing my own database of members, utilize these reports. This meant that in writing the new program, I could completely eliminate the database. Member credentials and check in were managed by MS Teams and the reports were just stored on the team's file repository which had the side affect of creating a simple workflow for officers.
In the end, ActiveRoster2 is only 124 lines of code, 91% smaller than the original ActiveRoster. Offloading functionality to familiar applications we already used helped to prevent users from being overwhelmed by needing to learn a new program and prevented me from "reinventing the wheel". Sometimes a compact and efficient design is all you really need.