Blue Witness: Creating a Resource to Help Examine Police Use of Force
For my last month at Lambda School, the Labs unit involved teams of students working on actual products being sponsored by various stakeholders, to give us a taste of what working on products in the industry would be like. My team was assigned the Blue Witness project, by an nonprofit called Human Rights First. Based in New York City, they have over forty years of advocating for human rights, including protecting refugees and asylum seekers, fighting against torture, and more.
The Blue Witness project seeks to use a machine learning prediction model that gathers data from Twitter and a dedicated Reddit API, in order to accurately assess and map data from incidents where police and law enforcement are involved, as well as rank the use of force utilized. All of this information is placed on an accessible and easy-to-use website that anyone, including lawyers, activists, and researchers, can browse.
I was concerned that with such a hefty project, it would be an overwhelming experience, but much of the groundwork was already laid out for us by previous Labs teams, as well as the students on my team being very proactive about communicating and putting in work to make the website come to life. In the span of just under a month, we’ve drastically improved the prediction model used, as well as cleaned up numerous aspects of the site’s presentation, and built more functionality into admin users who may wish to review incidents manually.
Sass Makes Me Sad
As design lead in the project, I was responsible for sourcing feedback on the overall design of the website as well as implementation of any changes we wished to do. This included frequent meetings with other design leads in order to gather feedback quickly, as there were other, more pertinent objectives we were trying to achieve with this release as well, and the faster that design changes could be implemented, the smoother it would be for the project timeline.
One of the first things we noticed was that the styling of the elements for the project was done using Sass. This caused quite a few issues, outlined below:
- Changes made locally would have to be compiled down to CSS when viewing through a locally spun-up server. We utilized the Live Sass Compiler for this in VSCode, but it was finicky and more often than not required multiple restarts of the compiler as well as the server to see changes reflected. Sometimes, the changes would not be reflected at all, which was frustrating, to say the least.
- In order to have the changes reflected in the deployed site, one person would have to compile the Sass down to CSS before pushing up to the deployment branch, otherwise changes to styles would not be reflected or implemented at all.
This was probably one of the greater sources of frustration on the project.
MVP and Beyond
By the end of our Labs cycle, we managed to accomplish a number of goals stated in the project roadmap, including:
- A general update to the site’s design, making numerous UI improvements (especially to navigation, the map, and the layout of the graphs).
- Revamping the prediction model used by the backend to gather incident data, and hosted an robust database using AWS.
- Fleshing out the admin dashboard so that users with elevated permissions can manually review incidents, as well as merge duplicates that are not caught by the prediction model.
A quick overview of the site is shown below:
As for the future of this project, as more releases are made, different ways of showcasing and accessing the data should become easier, as the backend that was created and hosted on AWS was designed to be robust over multiple iterations. The biggest obstacles I foresee are more along the frontend integration of the data, as well as making styling changes due to Sass. If someone wants to completely refactor the styling to use standard CSS, Less, or something similar, that would probably make things much easier in that department. For this release, there were simply more pertinent goals we needed to achieve in the roadmap, but perhaps this can be a goal down the road for a different release.
As the impromptu design lead, it was a little difficult in the beginning to balance those duties with the duties of the team, and things were a little confusing and scattered on that front. The team noted this, especially my TPL, and encouraged me to be open and more communicative if I was having some trouble. I was able to express these concerns to both my design lead team and my team members, who helped me manage both my time and tasks better, and allowed our UI/UX tasks to be accomplished and help the project move forward.
Being able to work as a design lead and work with multiple team members across different technical disciplines was a very useful experience. I had to balance my own obligations as a design lead, as well as working with the team on implementing features and code, and over the course of a month I got a lot better about that than I was before starting Labs. Being able to work with a larger team than I have previously was a valuable experience, and something that I will be taking with me once I start a career in tech.
