Recent Posts

We’ve been doing a lot of technological systems work at the Archive Center over the past few years; we’ve been standing up and migrating to new systems, tweaking and refining existing systems, and developing entirely new services to help with everyday work. We’ve recently kicked off a systems infrastructure audit project that aims to help us understand our systems better and make improvements on how we develop, deploy, and maintain our archival systems. This blog posts aims to provide some background for why we took a close look at all of our systems, both in production and development, and lays out some findings from our systems audit, and some of the general talking points that we posed to ourselves in trying to figure out a way forward. Hopefully, our experiences will help others in the same situation figure out what questions they should be asking of themselves.

I recently attended Designing for Digital in Austin, a conference that brings together UX professionals and strategists from libraries and library-adjacent institutions. I shared a talk on strategies for operationalizing UX, giving some project-based examples from the work we’ve done at the RAC. I’ll be reporting more on this work in future posts, particularly as it relates to our design and development of a new archival discovery system as part of Project Electron. However, in this post I’d like to share some highlights from other talks at Designing for Digital 2020 that connect to our UX work at the RAC, including topics related to accessibility auditing, measuring UX maturity, and a resource to support usability testing. I want to note that this conference occurred as COVID-19 cases were first being detected in the United States, and while the conference was still held in-person, many folks also participated and presented remotely, and many of the conference slides are available online.

In late 2014, the RAC migrated from Archivist’s Toolkit to ArchivesSpace. Shortly thereafter, we started working with ArchivesSpace’s API by writing scripts, mostly in Python, to export EAD, produce reports, and otherwise help to manage archival description at scale. After use, they were filed away in a GitHub repository, which over time became a sort of junk drawer.

Flash forward to the end of 2019. While we’re still using the ArchivesSpace API, a lot of other things have changed. Our coding chops, both individually and collectively, have improved dramatically thanks to several years of sustained engagement with Project Electron development work. We’ve also helped to seed the development of efforts like ArchivesSnake, which took all of the disparate code archivists had written to interact with the ArchivesSpace API and combined the best of it into a single Python package. It was time, we thought, to open up the junk drawer and see if there was anything worth saving.

Last week I attended the #a11yTO Conf in Toronto. #a11yTO promotes digital inclusion for the design and development communities in the Toronto area, and the conference brings together accessibility experts and disability advocates from around the world to present on topics ranging from legal strategy, standards, and values to more technical talks on design and web development.

Back in August, Hillel shared a post describing the next phase of Project Electron, which focuses on enabling users to find and access our archival records. In my role as an archivist who thinks about UX design and usability, I’ve been looking at how we might improve and reimagine the user experience of archival discovery at the RAC in ways that leverage our data model and data services work and represent what we’ve learned from our user research. In this post I’ll share our first steps in thinking through a user-facing site for archival discovery through creating wireframes, conducting some participatory site mapping activities with our staff, and looking at how other archives are approaching discovery.