Learning to Code and Coding to Learn

Lessons Learned from Delivering Product Features in a Team Environment

My team recently partnered with Human Rights First which is an independent advocacy and action organization dedicated to holding those in power to account for injustices or human rights violations.

Our project was a website called Blue Witness, which tracks and collects reports of use of police force across America.

The problem Blue Witness is trying to solve is how to track and display reports of use of police force in an accessible way. That means they need to collect and verify a wide swath of data but also distill it so that interested parties can find the information they are looking for quickly.

Blue Witness helps solve this problem by using a Twitterbot and scraping data from Twitter and Reddit to find reports of police use of force. In terms of the user experience, our team paid a lot of attention to providing tools for filtering information across a range of salient criteria. We also worked on presenting this information in maps and graphs.

I had concerns about my ability to dive into an established code base that uses some unfamiliar libraries and make sense of how it all fit together. At the same time, coming across something unfamiliar allows you to learn something new. I was eager to dive in and start figuring out what I could contribute to the project.

Challenges

My team’s two primary challenges were to collect and verify data and also present that data in an accessible and digestible way. My area was devoted to providing options for users to filter data. This task involved a few different components. I had to hook up filters to a map, a drop-down box with incident reports in card form, and to a component we called Reports that evolved into a panel drop-down with more detailed information about each incident.

One technical problem that arose was that the calendar search for reported incidents did not connect with the map. So, if the user were to put in a start date and end date to filter incidents, nothing happened on the map. All of the points representing reported incidents remained visible, regardless of which search criteria the user selected.

The hunt for the solution began. First, what information was the front-end receiving from the API? How was that information structured? We found that the API was sending just about every piece of relevant information to the front-end right from the start in an object data structure.

An oddity occurred to us. There is a drop-down menu right next to the map on the Home page that contains cards with information regarding reported incidents in it.

That must have meant that the reported incident data must have been structured as an array and filtered somewhere already. We tracked that code down and started brainstorming about ways to get it to interact with the map.

We settled on creating a custom React hook to filter incidents. We creatively called it ‘useIncidentFilter’. We could then call that hook in any other component across the app that needed to filter incidents. Here is the code:

This maneuver worked in giving access to the filter function to the reported incidents connected with the map:

But we ran into another snag. When 1. the filter for the map and the drop-box is the same and 2. the filter is opened up to allow for many reported incidents, the drop-down box experienced performance issues. There was a pretty hefty lag as the container was filled with hundreds of cards of information.

To address this issue, we coded a 15 entry limit into the rendered drop-down box. This solution is sub-optimal, as it is possible for there to be a point on the map that you cannot immediately access in the drop-down box. An optimal solution would make a card accessible for each point on the map for ease of comparison. However, given our constraints, I believe the entry limit was a clever, workable solution, and I do not deserve any credit for it. My teammate John came up with the idea.

Finally, the filter worked but did not return the reported incident entries in any chronological order. We wanted descending by date, so that the most recent came up first and the oldest was at the end of the list. We added a .sort method to sort by date, included in the picture below.

Coding to Learn

In summary, my team shipped a functional map tracking reported incidents of police use of force, a timeline with the most recent incidents, a Reported Incidents page that allows for a deep dive of the data and csv export file, a Graphs page with various data visualizations of trends, and an About page with information about Human Rights First and the Blue Witness project.

The future for Blue Witness is exciting. There is a lot that could be added. The data science folks could have a fun time finding ways to get more sources for reports of police incidents. They can also work on refining their data models and verifying the reliability of these reports. On the web side of things, although my team added a lot of filter functionality, there is still room for improvement. These methods might include cross tabs for dates, types of incidents, and levels of force used (e.g. empty hand versus use of taser or gun).

Working on this project gave me a chance to work with an existing code base, learn new patterns for slicing up and distributing state throughout the app, and adapting to new ways of making an app work. I can now build on this experience and carry this knowledge into new apps. For instance, I became better acquainted with useSelector and useDispatch hooks for passing state around, and I can see advantages of using them rather than using a connect function to manage global state. There is no real substitute for diving into a project and coding until you end up somewhere you want to be. It’s almost impossible not to learn if you are putting the time and effort in, and that is why I think it makes sense to say that you not only learn to code, but that you also need to code to learn.