Coders Unite for Human Rights
Creating a Web App to Empower Asylum Lawyers
Catching the Vision
Learning our Codebase and Understanding the Mission
This past month I have had the privilege of working with Human Rights First, a non-profit, nonpartisan international human rights organization. Human Rights First is an independent advocacy and action organization that presses the U.S. government and private companies to respect human rights and the rule of law.
This project I worked on was focused on creating a web resource for lawyers who represent people seeking asylum in the US due to hostile circumstances for them personally in their own country. These lawyers have limited access to data concerning prior cases. The product I worked on will gather case data from users of the site, then compile and distill it into a format that asylum lawyers can use to see trends in order to better help their clients gain asylum. The app is meant to allow lawyers (and possibly others in the future) to view trends in asylum case decisions, to view data on cases and judges, and to be able to contribute data of their own. The intent is that this data will help them better prepare their cases.
I worked on the frontend for this project and my team inherited a partly finished app using a React.js framework with Redux for state management and two styling libraries I had never worked with — AntDesign and MaterialUI. Our team needed to first learn what was in place so that we would know what needed fixing or finishing, and how the code worked. Being able to understand the code already in place was important so that we could add to it in a way that functions and is cohesive to the overall project.
This was my first time working with such a large codebase and with so much in place that I had never seen before. My biggest concern going into the project was being able to understand and work with code that others had written. Until now, nearly all coding I had done was building out an app from scratch or adding in large features and functionality. Because there can be multiple ways of doing something in code, I knew that being able to go in and change or add to an already large codebase, that was likely written differently from how I would have done it, was going to be a challenge for me.
One Lone Wolf Breaks Everything
Communication is Key
As the various parts of our team looked over the codebases we’d been given and got them running locally, we soon realized that the frontend, backend, and data science pieces were not actually working together. They were not passing data from one to the other, nor could they do so because the various data points were being called different things from one codebase to the other. The result of this lack of communication is ultimately an empty user interface.
Seeing the issue, every part of the team came together in order to put forth a comprehensive list of all data points, new and old, so that each codebase would line up with all the others and could therefore properly communicate. This decision was something that the entire team discussed at some length and agreed upon as being our first priority. The primary task that I took on as a frontend developer, was to change the names of multiple data points to our mutually agreed upon list.
This particular task affects every part of the web app, as none of them can perform properly without the various data sets communicating and was part of an overall effort by our team to unite our databases. Prior to this change, the entire app was nothing but an empty show piece. There can be no true functionality without communication across all three databases. It affects the users ability to use the app in any meaningful way. Without it, the user could not view any of the data currently stored, nor could they upload or download any. Therefore, I volunteered to go through the frontend code and rename variables to line up with our united list.
When I volunteered for the task I had expected it to be fairly straight forward. I knew that the bulk of the items to be renamed were the columns on the two featured tables. However, I immediately realized that the changes could not stop there but actually needed to be made across all of the components and multiple files. The variable names that I was changing were being used in other parts of the code and rendering on every part of the app. Thus, just like the table, they needed to conform to the standard decided on in order to communicate with the other databases.
The biggest challenge I faced was changing “id” to “case_id”. The problem was that “id” is used across most of the code and only some of that had to be changed, while the rest needed to be left alone for the app to properly function. The main challenge then, was to sort through all the instances of “id” and determine if it should be changed or not. This was challenging for a few reasons.
First, there are so many instances of “id” being used across a great number of files that sorting through them all was quite time consuming. Second, not only was the code unfamiliar to me, but “id” was being used for things that I hadn’t seen before. This made it difficult to determine if the particular instance of “id” that I was looking at actually pertained to “case_id” and should therefore be changed or not. Third, for most of the components rendering to the screen, there were multiple instances “id” that would have to all be changed at once. This means that I couldn’t just change one and be able to easily tell if that change was correct or not.
Ultimately, I had to walk through stacks of error messages for each page of the app to identify an entire set to change for it to render to the screen properly.
One clear example of an error that I had to work through was a Material UI error which was preventing the cases table from rendering at all. It turned out to have been caused by changing the ID variable that MaterialUI was using to render the table. With the help of my team, I discovered that the table needed to have a variable named ID for it to work as intended. However, the ID it was being passed was now called case_id. Our team worked together to come up with a solution and settled on mapping over the data being pulled in right inside of the Axios call.
Initially, we set this to case_id. However, later the team decided that each case should have it’s own unique identifier, aside from the case id, to forestall any future problems that might arise from possible changes to case. Thus, the case_id inside the Axios call mapping was changed to primary_key, allowing the table to be rendered using the unique identifier.
Many Voices, One Song
Every Piece of Code Working Together to Render the App
With all of the necessary name changes finally made, and all the other functionality added to the app by the team, we finally had a (mostly) functioning app!
- All pages will route to either a case overview page by clicking case ID or a judge page by clicking a judge’s name.
- Cases and Judges can be saved to a user profile by checking their row’s select box and clicking the save button, this will add them to the saved cases or saved judges page.
- Clicking “search” on either the case or judge table will open a panel with advanced searchability, letting the user filter out unwanted case information.
- Table columns can be sorted by clicking on column headers as well as added or removed by clicking the “columns” button.
- A user can upload a pdf file which is sent through the backend to the DS codebase where it is scraped, analyzed, and returned as data points.
Looking to the Future
Features and Functionality to be Added
At the time of this writing, there are some visualizations — graphs, pie charts, etc. — but not all of them are rendering based on information pulled from the database. Therefore, it needs to be further fleshed out and fully implemented by the next team to work on this project. Getting this functioning properly should be fairly straight forward, but if it proves to be uncooperative, then other ways of rendering the visualizations should be researched.
A few pages need a design overhaul to make them a better user experience. A challenge here would be that there are different ways of doing styling currently being used across the application so there might be trouble getting everything to look good and unified and may require an overhaul of the styling methods used.
Another feature that should be considered, is allowing a user to download a pdf of selected cases from the table. The potential difficulty lies in only having the selected cases added to the pdf created rather than all data available.
Team work makes the Dream Work
My biggest take away from working on this project
Seeing that the web app finally fully populated with data pulled from the backend was very gratifying and only impressed upon me more deeply just how important teamwork and clear communication really is. It’s not only necessary in order to get a final product that actually meets the stakeholder’s expectations, but working together and communicating early and often will head off any number of potential difficulties that come from having to make changes down the line.
Early on in the project my peers noticed that I tend to take on work and then tackle it entirely on my own, waiting longer than I should when I needed to ask for help. I tend to do this because I feel that it’s my responsibility to take care of any work that I said I would do. While this feeling is certainly true, I have had to realize that the app as a whole is a team effort and that if I struggle, then the entire project struggles. I have been working to change this tendency by reaching out to my closest (in terms of the project) teammates soon after I realize I’ve truly gotten stuck. If they are unable to help, I reach out to the rest of the team and we’re able to get me back on track. I’ve also been working on admitting up front when I’m uncertain that I know how to do the work being asked of me. I’m still willing to take it on and use it as a learning experience, but by expressing my uncertainty at the start, I let the team know that I may take longer doing the work than they would and that they can expect me to come asking for help.
Teamwork and communication is important in any work you do, so having this fact truly driven home based on my time on this project, will keep these things at the forefront of my mind moving forward in my career. Working so closely with my team further reinforced to me how wonderful diversity can be. Every individual has a unique perspective, skills, and experience which can lead to creative solutions and a more optimal final product. Having unique perspectives and experiences on a team can help broaden everyone’s horizons and understand things that they had never even considered before.
Furthermore, working with an established and large codebase was eye opening. I can see just how much I have to learn about the various libraries and resources out there. There are so many ways of doing the same thing, each with it’s own benefits and challenges. I want to learn them all!