Caselaw Access Project

Spearheading a new design system, and improved data visualization, for 6.5 million legal decisions throughout U.S. history.

The goal of the Caselaw Access Project is to make all published U.S. court decisions freely available to the public online. According to Adam Ziegler, one of many individuals who initially spearheaded the project in partnership with Harvard Law School's Library Innovation Lab, all court decisions are public and the public should have access to it.

But the reality is a little more complicated. Writing about the legacy of the Caselaw Access Project, he notes,

We all should have free, easy access to the law, and no one should gain competitive advantage from having privileged access to the law itself. But historically we’ve not treated the law this way. Instead, we’ve acted like our law is created and owned by the companies that publish it. Our courts, with few exceptions, have allowed publishers to control access to the law and to dictate how we read, study, cite and use the law.

The Library Innovation Lab set out to change this landscape by creating a website, case.law, that would provide free access to 40 million pages of case law digitized from Harvard's own law library. In addition to the website, the team also released APIs for researchers to query the entire corpus of data. This work largely happened between 2013 and 2018.

I joined the Library Innovation Lab as a senior software engineer in fall 2023, during a key transformation period for the project.

Scoping the Problem

The Library Innovation Lab is primarily a research organization: a small group of scrappy technologists and tech-savvy researchers who want to promote equitable access to knowledge. They needed capacity to be able to pursue other projects and research — and do that, there was a need for more a sustainable approach to the Caselaw Access Project.

One big concern was the maintainability of the project's APIs. Continuing to support the bulk querying and release of data felt untenable — but it was also too important to shut down. To continue to help researchers find the information they need, the lab partnered with the organization Court Listener to keep tasks like advanced querying of data accessible.

The lab also decided to transform CAP's previous monolithic website into a resilient, more easily maintainable format — one that would not require much, if any, effort to update.

Technical Considerations

Leadership at the lab felt strongly that the next iteration of the CAP archive should be driven exclusively by web components.

Web components are a suite of technologies that make it easier for developers to encapsulate interactive functionality. They can be built with a massive array of different libraries (including Lit, Svelte, and Vue), and their single file architecture will be familiar to anyone who has worked with a framework like React.

So what makes them any different? Any more strategic?

The biggest draw for many organizations is that a web component can peacefully co-exist amongst UI built with numerous other technologies, by embracing the "islands architecture" approach to web development. For the web-native version of Photoshop, for example, this approach enabled Adobe to build a feature-rich application with web components and the Lit library and then intermix "a few islands" of React code as needed (the Chrome team details this further in their article, "Photoshop's Journey to the Web").

This interoperability felt like a good fit for the CAP archive, and supported an additional major stakeholder requirement that the next phase of the website could not rely on any module bundlers or any form of build tool.

But before getting started building new web components, there was more preliminary planning afoot.

Interface Inventory

The original case.law website contained many similar, yet not quite identical design decisions. Nearly twenty different font sizes appeared on the homepage alone. There were also at least six different varied takes on a decorated heading — and numerous other variations, between pages, in spacing, color, and other styles.

As far as the team was aware, there was no visual reference beyond the website itself that documented any of these design decisions. This felt like an ideal opportunity for an interface inventory.

An interface inventory, as Brad Frost describes it, is similar to the process of a content inventory. But instead of involving exhaustive documentation of all content on a website, an interface inventory is focused on generating a bank of screenshots of every key UI element found in the wild. This may include headings, icons, text fields, buttons — as well as other unique design patterns.

The CAP interface inventory helped spotlight how subtly different so many aspects of the previous website were. It also clarified the benefits of a unified design system — one that could reduce unnecessary code repetition, improve design consistency, and provide an easier entry point for any future updates to the website that might need to be made.

Creating a New Design System

I knew I needed to organize the many existing styles for the CAP website before attempting to determine the most appropriate path forward for a new design system. Every design decision on a website communicates a visual language, and it felt important that we didn't suddenly shift that language to something completely foreign or otherwise aggressively different.

Attempting this task could have required painstaking attention to screenshots from the interface inventory — or an incredibly tedious journey through existing CSS. But neither approaches are actually required. There's a much easier way.

Zack Leatherman wrote a helpful function that can run in any browser console and output a sorted array of all the computed values associated with a particular css property on a given page.

For example on the homepage this code:

	
		(function() {
let fontSizes = new Set();

document.querySelectorAll("*").forEach(function( node ) {
fontSizes.add( window.getComputedStyle( node ).getPropertyValue("font-size") );
});

return Array.from( fontSizes ).sort(function(a, b) {
return parseFloat(a) - parseFloat(b);
});
})();
	

Output these sorted styles:

	
		[
    "11.2px",
    "13.3333px",
    "14px",
    "15px",
    "15.3px",
    "15.36px",
    "16px",
    "17.6px",
    "18px",
    "18.6667px",
    "18.9px",
    "19.2px",
    "20px",
    "20.8px",
    "24px",
    "40px",
    "56px",
    "90px"
]
	

I collected values across multiple pages into a cohesive dataset. I then picked key values for inclusion in a new set of design tokens.

These design tokens were rewritten, in code, as CSS variables (also known as CSS custom properties) and included as the first contributions to the new website.

Improving Equitable Access

One of the most interesting facets of the original CAP archive was a data visualization on the homepage that used a map to help individuals understand how caselaw statistics varied by legal jurisdiction. Each map region contained a link to a different section of an interior landing page.

While testing the functionality of the map on the old website, I was able to navigate successfully but not intuitively. It took more than two dozen tab stops to reach Minnesota, my home state, after navigating to the map. In the process, the tab focus jumped — and from a user's point of view, seemingly randomly — between disparate geographic jurisdictions on the page.

For a lab with a strategic goal to promote equitable access to information, not simply the availability of it, this felt like a very meaningful area of the website to improve for future researchers.

I rebuilt the map so that it could be intuitively navigated using arrow keys. Knowing that disabled users were most likely to assume that a map would not be designed inclusively — and that navigating a map with arrow keys is also a fairly novel approach to interaction design on the web — I also included concise instructions to notify users how to use the new map.

The new interaction pattern felt personally magical to me, particularly because so many maps and complex data visualization tools fail to make it easy or even at all fundamentally accessible to navigate.

But the logic isn't complicated — it relies on a static JavaScript object that includes data on the map shape itself and it's neighbors.

	
		export const mapData = {
	ala: {
		name: "Alabama",
		path: /* path value */
		neighbors: {
			up: "tenn",
			down: "fla",
			right: "ga",
			left: "miss",
		},
	}
  /* ... other state entries */ 
}
	

By mapping abbreviations like ala* to the representation of Alabama on the map, I was able to implement a seemingly instant lookup whenever a user hit a key to navigate to another legal jurisdiction. This felt like a major win.

The new website launched ahead of the Transform: Justice event at the Library Innovation Lab on March 8, 2024.

*Note: If you're wondering why this dataset uses abbreviations like "fla" rather than "FL" for states like Florida, it's because much of the caselaw citations that CAP archives predate more modern two-letter postal codes.

Return Home