We’ve talked a bit already about our work with a vendor to make sure ArchivesSpace supports efficient workflows. After reading Mark’s blog post, I’m re-energized to think of the good this work will do — archivists in repositories will be able to do collection control projects in a far more robust and efficient way!
Right now, we are deeeeeeeeep into this work. During our planning call last night, one of the software developers asked for use cases for some of our requirements for selecting and changing information about containers — I was going to just make a screencast and notes to put in our project management software, but it occurred to me that this could be useful information to document more publicly, especially since folks are asking about how ArchivesSpace can help them do their work more efficiently.
So, here we go.
Here are some use cases.
Managing information about containers in bulk
An entire collection has been described, and I know for sure which containers I’ll be using. I’m now ready to slap barcodes on these boxes, tell the system what these barcodes are, tell the system what kinds of boxes I’m using (we call this a container profile), associate these boxes with a location, and associate an ILS holdings record identifier.
In Archivists’ Toolkit, if you want to do this work, you can only scope it to a single resource record. We know that it might be desirable to do bulk actions across several collections, so we want the option to scope this work to a single resource, but we don’t want to be stuck with it.
And then, in the current Archivists’ Toolkit plug-in, you would pick the containers you want and update various fields. We’ve been thinking slightly differently about which fields we would want to update and how, but suffice it to say that we would want to pick boxes that share an attribute (like location, ILS holdings ID, container type, whatever), and then be able to enter data about that attribute and expect the changes to propagate across containers. 
This is really exciting because currently in ArchivesSpace, every time that you associate a container with a component (like “Correspondence from Anne Shirley to Diana Barry 1877”), you would have to enter the barcode anew. This obviously isn’t very efficient, and it can result in a whole lot of errors. In the workflow we’re proposing, you would be able to know that the box one for each of those components is the SAME box one, and you’d only have to enter the barcode once.
Managing the relationship between containers and locations in bulk
Here’s another use case: Maybe I’m doing a shelf-read. I come to a location in my repository that’s described in a location record. But maybe the location associated with those containers in the database isn’t correct! I want a quick and easy way of selecting the containers in my repository that I see in that location and associating those with the appropriate location record. This is currently impossible to do in ArchivesSpace — in fact, it does a really screwy thing where if you look up a location (like “Library Building, A Vault, Row 1, Bay 1, Shelf 1” ) it gives you a list of all the archival objects there (in other words, intellectual description), not the containers! You don’t want to go into every intellectual description and update the repeating box information. This work would make it possible to say “Boxes 3, 4, 5, 7, and 10 from MSS.111, series 4 all belong in this location” and for the system to know that.
Or maybe that location is a palette or a set of shelves that are designated as needing to go off-site. In order to document the fact that they are, indeed, going off-site, I want a quick and easy way to pick those containers and update the ILS holdings ID. If the palette or location is itself barcoded, that makes it even easier to disambiguate what I’m trying to do! 
I hope you’ve enjoyed this journey through how we want ArchivesSpace to work. Obviously, software development is an ever-changing endeavour, ruled by compromise and the art of the possible. So don’t take these use cases as promises. But it should give you a good sense of what our priorities and values are as we approach this project.
 Our user story for this is: “BULK SELECTION: As an archivist, I want an easy and fast way to choose all or some (contiguous and non-contiguous) records in a result set to further act upon.”
 Our user story for this is: “BULK SELECTION: As an archivist, I would like to define a set of container records that are associated with descendant archival_objects of an archival_object with a set Component Unique Identifier in order to perform bulk operations on that set.” which is obviously a perfect storm of software jargon and archives jargon, but basically we’re saying that we need to know which series this belongs to. Since series information is stored in the component unique identifier, that’s what we want to see.
 Our user story for this is: “BULK SELECTION: As an archivist, I would like to define a set of container records associated with a location in order to perform bulk operations on that set. When defining a set of container records by location, I would like the option to choose a location by its barcode.”