CollectionSpace is an open-source, web-based collections management system for museums. It is being developed by and for the museum community, recognizing the commonalities in collection management and facilitating museum information processes, workflows, tasks and needs. A partnership among the Museum of the Moving Image, University of California, Berkeley, and the University of Cambridge, the project is dedicated to user-centered design and has taken shape through workshops that identified five essential themes, starting with the idea that the software should be a museum’s core information resource, serving all aspects of collection management. The software developed must be user friendly, support comprehensive data through resource linking, serve the outside community as well as museum professionals and encourage broad use by avoiding information silos. Though funding and participation challenges are normal for such an ambitious project, CollectionSpace is expected to change the way museums manage their collection information while promoting community ownership and development of the software product.
museum collection management systems
Bulletin, February/March 2012
CollectionSpace: A Story of Open-Source Software Development and User-Centered Design
by Megan Forbes
The Museum of the Moving Image (Moving Image), in partnership with the University of California, Berkeley, and the University of Cambridge, has been working for the past four years on the design and development of CollectionSpace – an open-source, web-based collections management system for museums. Over the life of the project, we have changed software platforms, project partners and staff members; however, our focus on user-centered design principles has remained constant.
Museums and related cultural organizations are adept at describing how they are unique and different from one another – the silo approach. With CollectionSpace, we are interested in focusing on the ways in which we are alike in managing our collections and collections information and then using that information to develop common processes, workflows, tasks and needs. When we start with what we share, we are better able to develop solutions for the largest number of community members.
Brief History: Why Museum of the Moving Image?
Moving Image first got involved with the world of open-source software development in 2004 after a fruitless search for a collections management system that was flexible enough to deal with our extremely heterogeneous collection of artifacts relating to the art, history and technology of the moving image and that was also inexpensive enough to allow us to both implement the software and retain a staff member to manage it. We turned to a developer friend for help, and with a grant from the Institute of Museum and Library Services (IMLS) he developed the first versions of an open-source, web-based application for collections cataloging and online public access – key aspects of what we expected a collections management system to support.
Impressed by the work coming out of Moving Image, in the winter of 2008 the Andrew W. Mellon Foundation's program in research in information technology (RIT) provided significant financial support for a major overhaul of the existing software. Devoted to supporting technology innovation in the foundation's core program areas (higher education, scholarly communications, conservation, museums and the performing arts), the program officers at RIT saw in Moving Image’s early work the potential for a new way of working with collections information and a new way for museums to participate in community-based software development.
Our very first act as a new project was to hold a series of community design workshops, designed to find out exactly what the museum community’s needs were around collections information management. The workshop focused on process, roles and documentation – not on software. Because so much of the work we do is framed by the technology we use to accomplish it, it would be easy to spend days critiquing all the ways our current systems fail us. Instead, the workshops focused on talking through each of the processes museum professionals need to work through in a day in managing collections and exhibitions (for example, the acquisition, cataloging and loan of objects and media management) so that the project team could later design software to accommodate them.
Guiding Principles: Why We Do Things the Way We Do
One outcome of the community design workshop phase was the distillation of five themes that have served as guiding principles for the project team. Most of these themes center on the idea that information should be easy to capture, easy to maintain and easy to share. As we work on our design and development plans, we use these themes as a check to ensure that the software we’re producing supports the needs of our community. They are as follows:
- A collections management system should serve as a core resource, used to manage every aspect of a collection – from the location and condition of objects to their display and dispatch.
- A collections management system should be familiar to its core users, reflecting the ways they interact with collections each day.
- The collections management system should be a tool for collecting insight and knowledge in order to build a collective intelligence.
- The collections management system should be a way to bridge gaps between an individual museum and the entire museum community.
- A collections management system should provide a way to de-couple information from process and function, reconciling conflicting information uses within a museum.
Theme 1. A collections management system should serve as a core resource used to manage every aspect of a collection – from the location and condition of objects to their display and dispatch.
One of the most common pain points described to us at the community design workshops was the plethora of applications required to complete one workflow. Attendees described loan scenarios that spanned four different systems (one of the four being a collections management system), acquisitions processes that relied heavily on email and spreadsheets, and activities such as rights and reproductions management that took place entirely outside a collections management system. This fragmented information flow is not just an annoying time sink, it can also lead to lost or duplicated data, and it also invites the risk that one person might inadvertently hoard the data by saving it to a personal folder rather than to a shared directory.
As we developed our information architecture and functional requirements, we tried to head off these pain points by reducing the need to go outside the system to complete the basic steps of one given process and by flattening out interactions so that linking up cataloging records with loan records or acquisition with valuation records, didn’t require learning a new interface or leaving one area of the system to go to another (and hoping that the data would follow).
Theme 2. A collections management system should be familiar to its core users, reflecting the ways they interact with collections each day.
On an average day, I might spend two hours using Moving Image’s collections management system. For our summer cataloging interns, that number is more like four, and our registrar has the system open all day – ready whenever she needs to find an object, create a new loan record or file a conservation report. For a piece of software that plays such an integral role in the day-to-day activities of a museum the project team feels a real obligation to create something that not only will be easy to use, but which will make doing the work itself a little easier.
We worked to achieve this goal by putting ultimate approval over the design and functional requirements in the hands of our end users. In addition to the data we gathered at the community design workshops, we vetted individual interactions such as creating a new record or uploading an image with staff people at early adopting institutions and with interested community members. Our interaction designer posted wireframes and designs often and encouraged our community members to comment, via either structured feedback sessions or the project wiki (http://wiki.collectionspace.org). Similarly, all functional requirement documents were placed on the wiki and opened for comments to the community. The comment threads for the proposed data elements for each procedure (for example, cataloging, acquisition, loans) were the source of a great deal of feedback and debate with our users. These comments and suggestions were more often than not incorporated into the core code of the software.
Theme 3. The collections management system should be a tool for collecting insight and knowledge in order to build a collective intelligence.
A traditional collections management system focuses on the objects in the collection and may be adequate for capturing tombstone (summary, core descriptive) information about objects, such as identification numbers, materials and dimensions, which is typically found on museum wall labels or in online collections catalogs. In the networked world, this type of limited system is no longer sufficient for the requirements of the field. Information about an acquisition, for example, is never just the tombstone-like information contained in the deed of gift – there are research documents, collections committee reports, donor-supplied images, auction catalogs and more to be considered. Limiting the collections management system to the official or summary record means cutting ourselves off from the supporting documentation required to fully describe and interpret our holdings.
To help solve this problem, we turned to the conventions of the web; specifically, the ability to create once and link many times. The information architecture we created does rely heavily on relationships in order to decrease illogical operations, such as uploading one image twice in order to attach it to both an acquisition and a cataloging record. Our flatter architecture puts all record types on the same level, so that a user can relate one cataloging record to both receipt of an object and its loan or one media record can both document an acquisition and depict an object.
Theme 4. The collections management system should be a way to bridge gaps between an individual museum and the entire museum community.
Many collections management solutions were initially designed for a specific museum or collection type, such as art, and to this day carry with them a data model and other assumptions derived from that particular type. These data models are difficult to modify or customize. As a result, individual museums have developed their own, localized technology solutions that rarely benefit the wider museum field.
With the support of a National Leadership Grant from the IMLS, the project team is working to change the way museums and other collecting organizations work together on software development, use and governance. The grant supports the development of communities of practice – institutions that share collection types, geography, are on the same campus or other traits. These communities of practice then work together to take the core CollectionSpace data model and add extensions that would benefit their entire community.
For example, the Walker Art Center in Minneapolis is working on extensions that will make it easier to catalog performing arts commissions. At a community design workshop in November 2011 over a dozen representatives from performing arts organizations came together to talk about what it means to document the performing arts in a museum context and how museum professionals can use CollectionSpace to assist with such documentation efforts. The project team will hold workshops on other topics at the Museum of the Moving Image and the University of California, Berkeley, at the beginning of 2012.
Theme 5. A collections management system should provide a way to de-couple information from process and function, reconciling conflicting information uses within a museum.
Information silos are a constant source of frustration for all of us who would like to share information across domains and institutions. What we discovered at the community design workshops and our follow-up meetings was that museum professionals are just as frustrated by the information silos within their own organizations. Curators have curatorial files, registrars have acquisition files, and exhibition designers have exhibition files. It is too easy for information to be duplicated, fall out of date or become lost when its keeper does not share the information or leaves the organization.
Our community requested a system they could use in all departments in a museum, so that even if the data were to be gathered for different purposes –for example, the exhibitions designer needs to know how large an object is so he can build a pedestal, while the registrar needs to know so she can order a box to store it – the data would be centrally located and accessed. The solutions we developed to help with this issue include roles and permissions support that allow different users to see (or edit) only information relevant to them, an interface that is simple to learn for the infrequent user and a web-based architecture that allows anyone in the museum with appropriate permissions to have access.
Conclusion: It’s Not Easy, but It Is Worth It!
For many of our community members, participation in this project marks the first time they have been actively involved in the software development process rather than being passive recipients of whatever solution the IT department passed along. We were delighted to discover that once we started asking questions about what people really wanted out of a collections management system – and gave them a mechanism through which to contribute – we were nearly overwhelmed by feedback.
As with any project of this size, there are struggles. Our commitment to user-centered design, configurability via institution- and domain-specific extensions and accessibility has led to a somewhat slower software development process, which is frustrating for museums working on implementations with tight timelines and tighter budgets. Many museums, especially those not linked to academic institutions, state or federal agencies, lack the IT resources necessary to make significant code contributions back to the project.
In the end, we work through the positives and negatives toward a two-fold goal: one, that we develop a software application that changes the way in which institutions collect, manage, preserve, publish and leverage collections information; and two, that we help establish a new way for museums and other cultural organizations to take ownership of the software development process by working together as a community.
The author would like to thank Angela Spinazze for her contributions to this article.
CollectionSpace.org: www.collectionspace.org – The project’s public-facing website. Visit for a guided tour of CollectionSpace, a link to the online demo, a project FAQ, discussion forums and more.
CollectionSpace Project Wiki: http://wiki.collectionspace.org – The project wiki is a warts and all look at the inner workings of the project. It’s the main repository for the collective intelligence of the project, including the following:
Community Design Workshop Final Report:
CollectionSpace Deployment Wiki:
http://wiki.collectionspace.org/display/deploy/CollectionSpace+Deployments – The deployment wiki is home to the working documents of the CollectionSpace early adopters. Visit this wiki for examples of data maps, gap analysis, wireframes for new functionality and more.
Spectrum Museum Documentation Standard: www.collectionslink.org.uk/programmes/spectrum – "SPECTRUM represents a common understanding of good practice for museum documentation, established in partnership with the museum community. It contains procedures for documenting objects and the processes they undergo, as well as identifying and describing the information which needs to be recorded to support the procedures." The Spectrum Museum Documentation Standard is the source of the core CollectionSpace data model [McKenna, G, & Patsatzi, E. (Eds). (2009). SPECTRUM: The UK Museum Documentation Standard. Cambridge, England: Collections Trust. Retrieved December 16, 2011, from www.collectionslink.org.uk/ spectrum-standard]
CIDOC Conceptual Reference Model (CIDOC-CRM): www.cidoc-crm.org/ – The CIDOC-CRM was one of the reference documents used during the development of the CollectionSpace information architecture. “The CIDOC-CRM provides definitions and a formal structure for describing the implicit and explicit concepts and relationships used in cultural heritage documentation.” [CIDOC. The CIDOC Conceptual Reference
Model. International Council of Museums. Retrieved December 15, 2011, from www.cidoc-crm.org/]
Megan Forbes is the collection manager at the Museum of the Moving Image and project manager for CollectionSpace. She is currently working on creating extensions for CollectionSpace software that will allow museums and other cultural organizations to more easily manage information around digital objects, from media art to video games. She can be reached at mforbes<at>movingimage.us
Articles in this Issue
CollectionSpace: A Story of Open-Source Software Development and User-Centered Design