Case study
A bilingual educational content library shared across PBS stations
Editors publish learning resources in English and Spanish; families and other PBS stations search, filter, and download them. Built inside the station’s CMS rather than beside it, on purpose.
The constraint
PBS SoCal produces learning resources for families: printable activities, guides, and media for children, in English and Spanish. Before the library, the only way a family got them was in person. Station staff brought printed materials to free community events, so a resource reached the families who lived near an event and showed up to it, and nobody else.
The ask was a library: editors publish once, families search and download, and other stations in the PBS network draw from the same catalog. The first collection was Family Math, a set of activities parents could do with young children at home.
What made it non-obvious:
- Downloads had to be controlled, not just served. Editors decide, per file, whether it is public or restricted to signed-in members. That rule has to hold on every path to the file: the front end hides what a visitor cannot have, and the back end checks the same rule again before it generates a signed download URL. Nothing on the page points at the file itself.
- Bilingual is a data model, not a translation. A Spanish resource is not the English one with different text. It may have a different file, different metadata, and no counterpart at all. Search had to work in each language on its own and let an editor link the two when a pair existed.
- The editors were the bottleneck, and they were not engineers. Adding a new kind of resource could not require a developer. The CMS had to let editors define and fill content types themselves, and everything downstream, search included, had to follow.
- One developer, two months. There was no team to operate a second system after launch. Whatever shipped had to be something the station’s existing platform and existing staff could carry.
Options considered
- Build it entirely inside the CMS. New content types in Brightspot, search on the Solr index Brightspot already maintains for everything it publishes, and downloads served by the CMS backend after an access check. Fastest path, and the editors already know the tool. The cost is coupling: the library’s search and delivery share the editorial platform’s capacity and release cycle, and station traffic lands on PBS SoCal’s CMS.
- Incorporate an open-source library platform into the CMS. Take an existing open-source digital library or asset-management system and embed it behind the CMS. It would bring faceted search and download management ready-made. The cost is a second admin interface for editors, a second login, a second thing to patch, and an integration that is never as clean as the demo. Editors would have to learn a new tool to do the thing they already did in Brightspot.
- Author in the CMS, serve from a dedicated stack. Editors keep working in Brightspot. Published resources are pushed to a separate Solr index, a separate front end serves families and stations, and downloads go through their own authorization service. The right shape at large scale. The cost is two systems to keep in sync, an index that can drift from the source, and an infrastructure footprint that one developer would spend the whole two months building instead of building the library.
What was chosen and why
Option 1. The editors already worked in Brightspot every day, and the one thing the project could not afford was a second tool for them. Brightspot already indexes what it publishes into Solr, so faceted, bilingual search could be built on the index that was already there rather than on a new one that had to be kept in sync. And the schedule was one developer and two months. Every hour spent on a dedicated stack was an hour not spent on the content model, the search, and the download path, which were the actual product.
The tradeoff was coupling. The library shares the CMS’s fate: when the CMS is slow, the library is slow, and any change to how a resource is structured ships as a CMS release. Search is limited to what Brightspot’s Solr configuration can do, rather than what a purpose-built index could. I accepted all of that on purpose. The alternative was a separate system that nobody at the station could operate once I moved on to the next project.
The download path was the design. The access level lives on the resource as a field the editor sets. The front end only renders a download control the visitor is allowed to use. When they click it, the backend checks the visitor’s session against the resource’s access level again, and only then generates a signed URL to the file. The file itself is never linked from the page, so a URL copied out of the source or shared in a chat does not bypass the rule. The files themselves live in a private S3 bucket that only the signed URL can reach.
Design details:
- Search: Built on Brightspot’s Solr index. Facets come straight from the resource fields, so an editor adding a field gets a facet without a developer. English and Spanish resources are indexed as separate documents, with a link between them when a pair exists, so each language searches on its own.
- Secure download: The access check runs twice, once to decide what to render and once before generating the signed URL. The second check is the one that matters. The first is only there so visitors are not shown a button that will refuse them.
- Operations: The library runs where the CMS runs: Java on EC2 behind an ALB, with Route 53 in front. Nothing new to operate after launch.
What happened
- Launched in March 2023 with the Family Math toolkit collection. Resources that had only ever been handed out at events were available to any family online, in either language, for the first time.
- Used by stations across the PBS network.
- Editors have added new collections since launch without a developer, which was the point of building the content model the way it was built.
If I did it again
I’d still make the same call on building inside the CMS. At this size, I feel a dedicated search stack would have been a liability the station couldn’t staff. What I’d do differently is spend the first week with the editors defining the resource fields before writing any search code. Every facet is a field, and if you add fields later, you have to re-index and re-tag everything that’s already published. I’d also count downloads per resource from day one, because that’s the number an education team needs to show funders. It’s also the number that tells you whether the library is actually working.
Open to technical lead and solutions architect roles, remote. Get in touch or read the other case studies.