Building the face of our new catalogue

As part of our ongoing work to build a better catalogue experience, we’re bringing you a series of behind-the-scenes posts. Our team is sharing insights into the catalogue’s development, the user experience (UX) and design process, ongoing user testing and feedback, and some of the challenges we’ve faced along the way. Some posts may venture into slightly technical territory, but we hope you’ll find these peeks under the hood interesting even if you’re not a techie! We’re kicking off with a post from our front-end development team.

___

Our team wanted to build a new catalogue both to improve the public interface that our web visitors see, and to refine the data model (how content and files are structured) underneath. Here we discuss our new public or ‘front-end’ interface — why we built it the way we did, the basic tools we used, and some of the challenges we faced. 

In 8 steps to building a better digital library experience we touched on our approach of ‘going headless’ — separating what the user sees from the underlying technical systems that drive the experience. Above all, we needed to have greater control over user experience than what an 'off-the-shelf' product could give us. 

Even though we’d been working with platforms that provided carefully considered and tested interfaces, we would often find ourselves locked into the vendors’ way of doing things. This approach can work well for some libraries but didn’t always suit our needs as a cultural institution. 

We often ran into difficulties when trying to implement custom features. Even simple tasks like adding a message banner could be a challenge or might not be possible at all. Usually we could find workarounds for small issues, but more complex challenges — such as how our catalogue search functioned or the way results were displayed — were difficult to overcome. 

We wanted to avoid over-customising our existing platforms, as this isn’t sustainable when you need to perform system upgrades and provide long-term support. Going headless with our front-end interface would allow us to integrate as many systems as we wanted, while giving us greater control and the ability to customise the systems we connect to.

Part of this process has been to decouple our newly developed API (Application Programming Interface) — which we’ll describe in more detail in a future post — from the front-end interface. This gives our back-end development team more freedom and flexibility to manage the Library’s data for multiple use cases into the future. This approach was based on research by the Library’s DX Lab. 

We’ve used the React JavaScript library to construct the front-end. It was developed by Facebook’s open source development team and is used extensively across the industry. Now in version 16, it's well tested, portable across desktop and mobile, and works across a range of web browsers.

The transition to headless development and using React hasn’t been entirely smooth. Challenges have included: developing a better understanding of the component model and lifecycle that React applications use, asynchronous event-driven programming, and integrating React with other libraries we depend on. We’ve also worked to maintain a high level of code quality, implement ongoing testing, and manage data and mocking up data (for testing or presentation). Our main challenge in using React has been to ensure that the new interface is as accessible to as many people as possible. 

We’re looking forward to revealing more about how we’ve built the front-end framework for our new catalogue experience and sharing our ideas for the future. This continues to be an exciting and interesting project to work on, and we hope that what we’ve made will be useful and useable to everyone. 

Geoffrey, Priyanka, Kaho and Nithya 
Front-end development team