DEV Community


Roadmap to Blue Witness - Human Rights First

・4 min read

First Stop: Introduction

Blue Witness Logo

Human Rights is a non-profit entity that engages with the American public to make sure the integrity of human rights is held above all else. During the last month, I’ve had the privilege of working alongside a team of developers to deliver a platform known as Blue Witness that is tasked with recording and displaying instances of police force, while classifying by level of brutality. The team was comprised of roughly 15 members which were distributed amongst a Front End, Back End and Data Science team. My assigned team was the Front End team.

national incidents map showing number of incidents per state

graph legend showing police brutality by rank as well as total number of incidents

This project has been in progress for roughly nine months and many teams have had the opportunity to contribute to its development. While this would be an opportunity to work on something great, the challenge was inheriting the codebase itself. Many of the features lacked documentation and while the structure of the project was intact, some of the files contained unused code or commented blocks of code with little to no explanation. The timeline was set for one month of development, polishing the application all throughout in order to ensure a timely delivery to the stakeholder.

Second Stop: The Development Process

In order to maximize productivity, the team decided to use Trello to keep track of tasks. The board was organized by the project leads and organized by roles. To populate the board, we leaned on user stories and framed our tasks accordingly.

trello board outlining tasks and user stories

The user stories I was responsible for were all pertaining to the Front End given that was my primary role. These tasks involved refining the user experience and making sure there were no inconsistencies with any of the visual elements on the application. This proved to be a challenge given the inconsistencies in the styling patterns used. Some files used styled components to style their components, while others used css files. Some used both!

folder structure of the project

This was intimidating at first but given that there seemed to be some method to the madness, I was able to fine tune the CSS properties that enabled the app to have a consistent appearance all throughout the user experience. Given more time, the appropriate course of action would be to refactor everything to follow a uniform pattern for styling such as by strictly using styled-components.

Another problem I was given the opportunity to work on was the debugging of the administrator dashboard. The dashboard was supposed to be open only to admin users and the latest feed of incidents would then populate the page, ready for review. Administrators are responsible for reviewing incidents and approving or denying them based on their relevance for the page. This is content that is then shared with the end users. The dashboard is where these incidents are loaded as well as where users can approve, deny, or request additional information from the social media users who uploaded the incident, specifically from Twitter. The problem was that when the user loaded the page, there was no incidents loaded and the console would display an error message with a status code of 403. So what this means is that the user that was logged in was trying to access a resource and did not have the adequate permissions. This was a problem because any one can currently access the dashboard page but would not see any data loaded. I consulted with three developers from the Back End team and we troubleshooted the application together.

Turned out there was a problem with the Authorization headers that were passed with the request after a user was logged in. The third party service from Okta was unable to parse the JWT token that was passed in the header and so the user was never fully authorized. In fact, there was no concept of authorization working! I took a look at the request coming from the client and noticed that the string was passed in with "Bearer" in front and then we realized the Back End was not accounting for this in the token, which was ultimately causing the problem. After updating this, the bug was resolved therefore correctly authorizing admin users before directing them to the dashboard page.

Last Stop: Looking Back

The experience I had working on HRF Blue Witness and with the team at Lambda during this final month was an experience I'll never forget. It gave me insight on how developers are onboarded to an existing project and allowed for me to get to know my team well. My skillset has grown and improved, as I familiarized myself with how developers are onboarded to a project and learned how to reach out for help, rather than trying to figure things out on my own. Understanding the crucial role of documentation for other coworkers who may be tackling the project for the first time has also helped me become a better developer.

Discussion (0)