Following our initial release of Aurora, we’ve continued to improve the application through usability testing with RAC staff members. This process has been essential in identifying usability issues in Aurora and guiding our strategy to implement fixes to address those issues. In this post, I want to share our approach to usability testing, a summary of our findings and fixes, and our next steps.
We are very pleased to announce the initial release of Aurora, an application to receive, virus check, and validate the structure and contents of digital records transfers. It provides a read-only interface for representatives of donor organizations to track transfers, so that they can follow their records as they move through the archival lifecycle. It also includes functionality for RAC staff to add or update organization accounts and users associated with them, appraise incoming transfers, and initiate the accessioning process. Aurora is built on community-driven standards and specifications, and we have released it as open source software. This is a major milestone for Project Electron, and we are excited to share it with the world. Many thanks to our partners at Marist College IT and to the Ford Foundation for their generous support of the project.
We will continue to improve Aurora as we test and integrate it with a chain of other archival management and digital preservation tools.
Read more about Project Electron here.
I recently attended the IA Summit 2018 in Chicago. This was my first time attending the conference, which brings together a mix of information architects and design-related professionals, and I came away with some fresh perspectives on my work here at the RAC. The summit consisted of both practical talks about specific methods and tools, as well as wider reflections on ethical considerations and trends in the field. Continue reading
The underlying architecture that enables the movement of data between systems is a key aspect of Project Electron. In our project values, we talk about components as modular and generalizable, independently deployable and flexible enough to accommodate integrations with changing systems. The project value to “support data in motion” recognizes the strength of duplicate and distributed data, and articulates Project Electron’s approach to systems as points at which humans interact with or manage that data. All of this is to say that our strategic decisions relating to choosing an approach to system architecture, particularly with regards to systems integration, is essential to the project’s success and sustainability. In this post, I’ll share some of our current thinking around the various systems integration models and our considerations in choosing an approach that will enable these integrations of archival applications. Continue reading
In the last Project Electron update, I discussed the benefits of user interfaces as communication tools during development. This month I want to share more about the archival functions that those user interfaces enable in the application, which has been the focus of our recent development work. Specifically, I will share how the application enables appraisal and accessioning functions, as well as managing structured rights statements.
As development of the Project Electron transfer application has continued over the past month, one important aspect of the work has been the creation of user interfaces based on the wireframes we have designed during the design planning process. In this month’s update, I will discuss how both wireframes and the resulting user interfaces (UIs) of the application are important communication tools both internally for the development team, and externally with user groups including Rockefeller Archive Center staff and donors. Continue reading
It has been a busy month for Project Electron as we near the end of the first phase of development, which focused on building an application to enable the secure transfer and validation of digital records and their metadata according to the Rockefeller Archive Center BagIt specification. In addition to the transfer application development, much of our work this month has been about planning for the next phase of the project. In this post I will share a few activities and strategies we undertook to prepare for development and to keep users at the center of the design process. Continue reading
I recently attended the edUI conference in Charlottesville, VA. It’s a conference for web professionals working in educational institutions, and the speakers come from a variety of professional contexts including design, development, management, content strategy, and UX. For me, this conference was a chance to hear from and connect with folks outside of the archives field who are doing related work. It pushed me to think about familiar problems from a fresh perspective, build conceptual connections, strategize to improve communication across disciplines, and learn some practical approaches and skills that are not often emphasized in archives-specific conferences.
This month has been all about developing the Project Electron transfer application. The work is based on our defined specifications and the development decisions we made last month with our Marist College partners at the hackathon. We are really excited about testing transfers in the coming month.
In this post I am going to briefly discuss Gherkin, which in addition to being a delightful little cucumber, is a language that is used to define the requirements of software in order to document and test the software’s behavior as part of Behavior Driven Development (BDD). We have been using Gherkin to write Quality Assurance (QA) tests for the functions of our Project Electron transfer application. The language is human-readable, so it can enable communication between teams working in different domains across a project.
We kicked off this past month with a hackathon, hosted by our Marist College partners, to plan and start developing the part of Project Electron that enables the transfer of digital records from donor/depositor organizations to the RAC over a secure network connection. We worked with the Marist College team, including Marist students, to diagram the transfer structure and dependencies, building from the transfer specifications that we released in June and discussed in our last blog update. These specify the metadata and structural requirements for transfer and provide a bag profile to validate bags from donors. Additionally, we created wireframes and started building out the user interfaces (UIs) to view and track transfer information, view error messages, and manage user and organizational accounts. Continue reading