Building Asylum Analysis
I recently had the opportunity to work on a product for the nonprofit Human Rights First temporarily titled “Asylum Analysis” during the month of April 2021. Being a full-stack developer along with other developers and data scientists was a great experience to refine my communication skills, along with sharpening my coding abilities. Every month, a team of students from Lambda School are trusted with adding on to the application’s components and functionality. Human Rights First is a nonprofit that “challenges America to live up to its ideals”; when US Government and private companies fail to respect human rights, they take it upon themselves to step in and demand reform. Asylum Analysis seeks to be a central location for data about asylum seekers’ cases in order to give representatives a better understanding on how to build a winning case.
Understanding the Problem
The purpose of this application was to create a central space where asylum representatives can upload PDFs of cases to create a dataset that can help these lawyers and representatives build a winning case for their asylum seeking clients. We wanted the user to be able to come to this application and see the data represented in a visually appealing way that is also simple to understand what kinds of things would make a judge more likely to rule in favor of the client. Currently, representatives of those that seek asylum do not have a place where they can review data from similar cases and use that dat to build a solid case for their client. Not having a central dataset is an issue because without this information, refugee representatives are not aware of what types of data hurt their client’s chances of getting their case approved.
The solution to not having a central dataset was to build one out, and have 3 different types of users. The stakeholders knew they wanted to have a standard user of the application, but also wanted to have a way to implement a moderator that could approve/reject case information. They also wanted to have an administrator role that would not only be able to review cases but would also be able to manage users. Through these 3 types of users, the application could be fully functional and solve the problem at hand.
Thinking through our building process
The problem we had when we inherited this application was that there was not a visually appealing way to view individual case information. In addition to that, the functionality of uploading a PDF was not working yet. We also knew that we had to create this new administrator role, which would require conditional rendering of specific components within the product. We identified these problems by speaking with our product manager (PM), technical project leads (TPLs), and stakeholders, then figuring out what exactly it was that they felt that this application was still missing.
As a team, we created a Trello board, which is a shared virtual bulletin board where we can delegate tasks needing to be completed for a given project. We knew that our timeline for the creation of the new Administrator role was the first 2 weeks of labs, and the second 2 weeks were to be spent refining the code we had written the first round. We broke down the tasks into front end, back end, and data science; from there, members of the team were allowed to pick which tasks they felt best fit their skillset or were something they had been wanting to learn. The timelines were estimated by approximating how difficult certain tasks would be and anticipating how many hours of work would be completed per day per team member.
My contributions
I was tasked with styling the headers on a table, implementing the “initial cases” and “appellate cases” tabs for the main cases table, implementing a styled individual case card, as well as pair programming to create a “Manage Cases” component for the Administrator level user. The styled case card was important to implement because we wanted our users to be able to see all the case information in one place that didn’t cause strain on their eyes. I utilized Ant Design (a styling library that can be used with React) for this portion, because our design manager wanted the styling for this application to start to be shifted over to Ant Design. I implemented a loading state for this case card so that users would know if their data was being fetched or if the fetch was complete. When the card was fully loaded, the user had the ability to edit case information.
- Bolded headers and tabs on the main table:
- Loading state of individual case card component:
- Loaded individual case card component:
When creating the “Manage Cases” component, we used the Axios library (a promise based HTTP client) to create a call to request data for the cases that we needed to show, then filtered that data to show only the cases that would be flagged as “pending” once the backend portion is set up. Each row of case data can be expanded to reveal more case information. The backend for this component is not currently set up, and will be something for a future cohort to implement in order to create the functionality of the “Accept” and “Reject” buttons. My teammate, Niki, and I left plenty of notes in our component code for future team members to better orient themselves.
- The manage cases page:
- Opening an individual row to get more case data:
Dealing with challenges and coming up with solutions
Some challenges I faced while coding on this product were merge conflicts, which is when you are working on something and someone else pushes their code to the main repository of the project — leading to conflicts on your side. It is a bit tricky to figure out how to resolve these issues so I elicited help from a couple of teammates. Another problem I ran into while working on this project was accidentally uploading my package.JSON file, which is the file that contains all the dependencies and libraries needed for the application to work on your computer. This file is not necessary to be uploaded to the main repository of your project, and I needed help from a teammate to fix this issue, as well. Uploading this file was also part of the feedback I received during this project. Adding all files to my pull requests was a habit from previous months of work, and was something that took getting used to. I was able to change that habit by consciously adding only the files I worked on to my pull requests.
One technical challenge I had was when I was trying to bold the headers on the tables, it wasn’t enough to just change the CSS for the file, you have to render the headers as bold in the component itself. I discovered the problem while trying to simply change the CSS attached to the a tag inline styles in the cell component of the table. I had to use the following code for every header in each table in order for it to be bold:
Technical Decisions
When completing the tabs in the main cases table, I chose to utilize Material UI styling (MUI) library instead of the proposed Ant Design library. This was unfortunate since we were trying to use a singular styling library on the entire application; however, Ant Design’s tab components did not allow me the freedom to customize them as I needed them for this particular use case (inside of the data table). Material UI had a tabs component that could have accessibility tags added inside them that would be better for screen reader use, and would allow me to customize the colors while the tabs were selected. Choosing MUI over Ant Design allowed me to create a better user experience for those who utilize screen readers, as well as those who utilize the standard approach of clicking with a mouse.
- Part of the code used to implement tabs on the cases table that shows the accessibility tags (aria-labels):
The future of this application
Now that there are tabs implemented into the table, we envision the data being rendered based on the kind of case it is, which will make it easier for users to get to the data they need. It still needs to be figured out whether or not certain features should stay, such as the ability to edit cases in two different places such as on the case upload and upon clicking “edit” in the individual case card.
Some technical challenges that I foresee are when they continue to switch components to ant d; the styles of the application seem to be a combination of a few things and it makes it difficult to be cohesive. It has been difficult figuring out the bugs switching from MUI to Ant D.
Improving as a developer
This project is helpful for future career goals because it allowed me to work in a standard work environment with others, and be able to contribute to a project, review others’ code, and approve changes that would be posted to the main codebase. I loved the communication between our team, it allowed for us to implement a lot of changes to the application and fix bugs that came up while coding. I especially loved pair programming, because it allowed me to build a relationship with my teammate, and gave me the personal aspect of coding that I have been missing. A skill that I have sharpened throughout my time in Labs would be the ability to have confidence in myself and my code. When I first started this project, I was nervous to contribute to a product in production because I felt like all my previous experience was in simple school projects that could not translate to the “real world”. However, I am happy to say that this experience gave the the boost of confidence I need to continue into the job search and know that I know how to take a concept and turn it into a product by breaking the problem down and simply thinking about the solution. For that, I am grateful!
