The origins of mbira lie in an earlier project, msu.seum (msu.seum.matrix.msu.edu). Developed as a collaboration between the Cultural Heritage Informatics Initiative (chi.anthropology.msu.edu), a Program in the Department of Anthropology which I direct, the MSU Campus Archaeology Program (http://campusarch.msu.edu), and MATRIX: The Center for Digital Humanities and Social Sciences (matrix.msu.edu), msu.seum is a mobile experience that allows people to interact with the rich cultural heritage of MSU’s campus, and understand how the MSU Campus Archaeology Program helped uncover it. Built on the idea of ‘campus as museum,’ the app connects heritage directly to place, encouraging people to explore what is known about the heritage of the MSU campus, as well as the rich and exciting story of the archaeological and historical research.
The initial version of msu.seum was the result of a collaboration between students in my 2011 MSU Department of Anthropology’s Digital Heritage Fieldschool (http://chi.anthropology.msu.edu/ fieldschool/) and MSU Campus Archaeology Program Fieldschool (http://campusarch.msu.edu/? page_id=273). Offered every other summer at MSU, the Digital Heritage Fieldschool is a unique experience that employs the model of an archaeological field school to teach digital heritage methods. While students participate in lectures, hands-on workshops, and rapid development sessions on a variety of digital heritage methods, tools, platforms, and technologies, the primary focus of the field school is the collaborative development of a significant digital heritage project. Each year, the Digital Heritage Fieldschool has a specific theme in order to guide both instruction and projects. Each year’s theme is chosen in order to reflect current trends in digital heritage.
In 2011, the field school theme was ‘Mobile, Locative, and Geospatial.’ Instead of receiving specific projects on which to work at the beginning of the field school, students are challenged to work collaboratively in order to brainstorm the final field school project. This model is important for several reasons. First, it gives students an opportunity to step through the entire development process – from concept to launch. Second, the model gives the students ownership of their projects – they come up with the idea, develop it, and then build it. Finally, this model allows students to integrate the ‘theoretical’ portions of the field school (design research, user centred design, best practices, etc.) with the applied (development) portions of the field school – thereby building applications that truly meet the needs of heritage questions, challenges, and content. As the field school director, I guide, give feedback, and help students think through the approaches they are taking as they develop the project. I never specifically dictate the design choices they make or outright control the development process. During the 2011 Digital Heritage Fieldschool, students were fortunate to work collaboratively with the students from the MSU Campus Archaeology Program field school, directed by Professor Lynne Goldstein. The result of that collaboration was a prototype version of msu.seum.
After releasing this prototype version of msu.seum at the end of the 2011 field school, MATRIX: The Center for Digital Humanities and Social Sciences, in collaboration with the MSU Campus Archaeology Program, began work on a new, greatly enhanced version of msu.seum. The current version of msu.seum is the result of this collaboration.
In addition to the application itself (which can be downloaded for free on the iTunes App Store), msu.seum’s underlying programming (or source code) was released on GitHub under an open source license. (https://github.com/matrix-msu/msu.seum). This decision was motivated by the desire to enable other heritage spaces or archaeological projects to develop msu.seum-like applications for their particular setting without having to build from the ground up.
After its release, msu.seum enjoyed moderate exposure and popularity both within and beyond the MSU community. In
addition to being downloaded more than 1000 times from the iTunes store, the application was the focus of several official university news stories. Despite this moderate popularity, however, msu.seum has several significant challenges. First, it is only available for Apple iOS devices. The reasons for this were purely logistical, as building an iOS version was easier given the skill-sets of the programmers that MATRIX employed at the time. However, msu.seum’s unavailability for mobile web or Android reduces the number of potential users. Second, all of msu.seum’s content is hard coded into the application itself. This means that if content needs editing, updating, or adding, this must take place directly in the app’s source code. Any changes made to the source code, however minor, means that the applications are effectively brand new and must be resubmitted to the iTunes App Store for approval. Only when the new version was approved by Apple (a process that can take anywhere from weeks to months), would it be available for public download. This workflow makes updating the application with new content incredibly difficult, time-consuming, and frustrating. In addition, even though we released msu.seum’s source-code on GitHub under a liberal open source license, a significant amount of technical expertise is required to adapt it and launch a fully functioning application for another setting. Finally, although msu.seum successfully explored the archaeological process alongside the product (the scholarly narrative about heritage research on the MSU campus), it did not support or encourage multivocality, co-creation, or citizen scholarship. This was both a factor of design and technical implementation. The resources available at the time of development and the timeframe in which we wanted to launch the application meant that we eschewed the inclusion of features that would support community voices from the outset of the project.
After its release, we considered developing an upgrade (msu.seum 2.0) to remedy the issues we identified with the previous version. We decided instead to develop a tool that would allow anyone to build, publish, and sustain msu.seum-like mobile heritage experiences. This shift in focus (to create an authoring tool instead of msu.seum 2.0) led to the development of mbira, where we applied the lessons and solutions discovered while developing the original version of msu.seum.