Vaccine Adjuvant Compendium (VAC)
The Vaccine Adjuvant Compendium (VAC) was established in 2020 by the NIAID Division of Allergy, Immunology, and Transplantation to foster collaborations between NIAID-supported adjuvant researchers and the broader scientific community. The VAC displays adjuvant characteristics or metadata defined through NIAID-supported adjuvant studies to help vaccine developers identify suitable adjuvants for various vaccine indications, including immune-mediated and infectious diseases. In addition, the VAC welcomes the inclusion of adjuvant metadata generated by other research programs.
I worked with a team of both Net eSolutions developers and internal NIAID developers to build a React.js based website that will go live in Spring 2021. My role was creating static templates, assisting in the translation of those templates to dynamic React code, 508 accessibility standards and cross-browser compatibility.
Net eSolutions Project team: Jalia Evans, Henry Lavoo
An adjuvant is an ingredient used in some vaccines that helps create a stronger immune response in people receiving the vaccine.
The ultimate goal of NIAID’s adjuvant research programs is to develop a “toolbox” of adjuvants that can be matched with antigens to optimize vaccine efficacy. NIAID also aims to strengthen immunology research to further increase understanding of immune mechanisms and fuel the adjuvant pipeline.
The Vaccine Adjuvant Compendium is a website that allows researchers and (eventually) the public to search NIAID's large database. Researchers are able to submit forms and add their own projects. Our goal was to quickly build and roll out this application for COVID-19 researchers, among other scientists, and allow the public to learn more about the research process.
For this project, I broke down the designers’ mockups, built the static templates, then worked with the NIAID back-end developer to connect the front-end to the database. I corrected issues with React.js page rendering, connected graphs and entry forms to the database, and built custom Material-UI components.
I was in charge of the site’s responsiveness and accessibility standards. This website will become public in Spring 2021, so attention to detail in 508 accessibility was paramount.
We needed to export forms as PDFs, but there was a huge issue with translating the form to the printable version. Best practice styling is built on percentages and media queries. It works in a browser window, but as a PDF has no browser window, percentage-based styles have nothing to work with. This was a constant issue at my company, as we have to use this feature on most of our sites.
I realized that because the PDF was a fixed width, I could use fixed widths for the columns of content. This simple solution allowed us to delete multiple styling libraries that our base template was using and freed up space in our files. We hadn't thought to use fixed width styling because it was left behind as browsers of different sizes became common, but this fix saved a lot of time and browser weight.
This was a constant nuisance for our team, and now my solution is part of the base template we apply to all of our projects. We got rid of the bulky plugins that took up a large amount of storage and use a very simple, CSS-only fix.
As a project for public release, the website needed to be fully functional across all of the major browsers. While building the styles, I learned to check my code every night across six browsers: Google Chrome, Mozilla Firefox, Safari, Internet Explorer, Microsoft Edge and Opera.
This was my first project working directly with the developers at NIH, and I learned quickly that NIH requires developers to work with Azure DevOps Server (TFS).
In my four years learning code, I had only used Git for version control. There is a very steep learning curve for using TFS. It does not allow for branching so developers cannot work on their own code and combine their work later. The lack of branching meant that I was working on the same files as 16 other developers (a logistical nightmare) and quickly needed to learn how to use Visual Studio for launching servers.
I still prefer Git by a large margin, but I'm glad that I learned how to use Visual Studio with NIAID's team. I got to know my counterparts during our frantic calls over the broken development servers and I went from being a junior developer communicating through her supervisor to an intermediate developer working directly with NIAID's team. Now, I have daily calls with NIAID developers to solve issues and bugs that they get stuck on and I am a fully independent member of my company's team.