Giving Asylum Lawyers the Tools to Build a Strong Case (1/2)

Rees Harper
7 min readApr 1, 2021

Human Rights First Asylum is a website made for asylum lawyers to compile data from cases across the United States to support asylum-seekers in their legal cases. These lawyers can then filter this data to build a compelling case for their clients. I joined this project on March 8th, 2021, and worked with the Human Rights First team until April 1st, 2021. Human Rights First is a nonprofit organization with the mission of providing legal representation for those in need. This project is just one of the ways they strive to improve the ability to represent those in court who need it. I was able to be a part of the front-end development team working alongside Matt Bokovitz and Dionne Stratton. The front-end team and I worked closely with NodeJS back-end, data science, Lambda project management, and the Human Rights First teams.

The issue the application is designed to solve is there is currently no centralized database for asylum cases. Asylum lawyers have no convenient way to research cases that were not handled by their firm or in their records, giving them a very limited supply of data to research when building a case. This causes some asylum lawyers to be unprepared for a specific judge or argument due to a lack of data showing trends in decisions by certain judges or arguments. Human Rights First asked, “so what if this doesn’t exist?” They decided that they could tackle this issue. HRF worked in tandem with Lambda to create a fully specced application: a website and database that compiles cases from firms and lawyers across the US and display that data in a flexible, customizable way.

As our team stepped into this project the biggest problem that we faced was connecting the three separate codebases: frontend, backend, and data science. This was a priority because, for a user to upload a case, it must be uploaded from the website as a PDF, sent to the data science team to scrape the file for relevant fields to only display the most important information. We had decided that to keep the website secure, we would send the file to the backend team which then uploaded the file to an Amazon Web Services’ S3 Bucket. The data science team would then be able to pull & scrape the file and send the response back to the backend to put it in the database.

The problem of connecting the three codebases became our top priority because as we were discussing the current state of the app the frontend team and I discovered there was currently no way to upload a case file. Which led the data science team to discover that although they had very functional scraping capability; it wasn’t able to receive any PDF’s from the website. As the frontend, backend, and data science teams communicated these findings we decided since uploading a case PDF is the core functionality of the app. We would prioritize this over anything else. The three teams spent the entire following day discussing the tasks that needed to be completed to bring this feature together and solve the issue. We created a Trello board that laid out each foreseeable task that needed to be completed as well as making multiple forms of documentation to align features and naming conventions. One of the major tasks we discussed was having unified naming conventions. This is good understandability; however, more critically, as all three teams pass JSON to one another, these names need to align. We had labeled this feature as a Release 1 priority which meant we had 1 week to have it fully implemented. We decided this because of the number of team members we had. If we each spearheaded one task, we could focus on that for the week and get the application to a more functional starting point.

As we began the process of actually implementing the solution we had come up with, we quickly discovered many steps we must take for it to come to fruition. Firstly, we discovered that our inherited codebase was a mess. Additionally, the deployed version of the website was completely broken. Thus, before making major changes, I decided it was necessary to clean the codebase from any compilation warning or unused code. Afterward, I began troubleshooting the deployment issue. After digging through a majority of the code, it was brought to my attention that a merge conflict was never resolved and had been pushed to the deployed website. This conflict was found in the package-lock file so I had to delete it and regenerate it as a standard for the entire team to use to avoid this issue from happening again.

After cleaning the code the frontend team and I shifted our focus toward matching naming conventions in our code to the ones all three teams agreed on. In this process, we also decided to add any additional fields the stakeholder or previous team mentioned. We were faced with a choice, have all the columns in the table render dynamically, or hard code each column. I heavily pushed to hard code the columns for this release schedule because I believe it would have taken much longer to build out dynamic columns that would work effectively with Material-UI. The risk of this is if there was a desire for expansion of the app later down the line, it would take much more work to add any additional fields. Although having it render dynamically would have forced us to rework a majority of the functionality of the application to make this happen so we just didn’t have the time. Once these decisions were made, however, we worked like a well-oiled machine. Anyone in need of help would just ask and we would work through it together.

Example for the structure of the column data

Once the deadline for release one came, all the teams had updated naming conventions and prepared to finalize connecting all 3 codebases. Yet the data science team ran into an issue that was not allowing them to deploy their code. This remained an issue until the final week of the month when the data science lead for lambda finally cracked the solution and was able to get it up and running. In that time I worked heavily on design and getting Material-UI to work as intended by integrating our search and bookmarking functionality into the data grid. I continued to work on various tasks all around the application to inch it closer to production while we waited to officially connect with data science’s code. Once data science is officially deployed we sprung into action connecting it to our upload file functionality and we can now receive the JSON of the scraped fields.

Filtering multiple columns at the same time
Custom toolbar for Material-UI

If I had more time with this project I would connect the JSON response to the form and have it auto-populate and implement the second endpoint to add that form's submission to a queue for the administrator to review. The process of implementing administration roles may become tricky with the way the app is structured at the moment, due to the upload file and form being on the same page rather than rerouting to the form. If it were structured this way we could reuse the same depending upon if an administrator or user is logged in. Yet reusing that component for the administrator would be clunky and a poor user flow for them. Finding a balance between these two choices will be difficult moving forward.

Throughout my time working on this project and in Lambda Labs I have learned so much about team management and communication. I have grown in the ability to discuss my code with others and explain why I made certain decisions. I have learned how to utilize many different team flow tools such as Trello, Github, and Slack. I have also received much feedback throughout my time on this project that has given me insight on ways to improve as a worker and teammate. One specific piece of feedback I received was to be confident in my work. This has allowed me to grow in my ability to confidently convey my opinions and also just be happy with my work. This experience has led me to decide to begin my job search specifically in frontend web development. I have loved every task I have taken on and want to learn much more. I have learned so much about user experience and user interfaces and am very glad despite not expecting to learn that in my time at Lambda I can take that skill to any job I may find.

This Labs experience has been an incredible journey and learning experience that will benefit me greatly as I transition into looking for a job very soon. I can not be more thankful for the opportunity to work with Human Rights First and the entire Lambda team to make this project what it has become over the last month.

--

--