Hello everyone, this is my second blog post on CHI. For this one, we need to address one of two topics: the importance and relevance of version control in cultural heritage projects, and the experience of creating a digital component for a cultural heritage institution. In my time here as a CHI Graduate Fellow, I found both these topics to be inextricably linked as we went through the assigned challenges in teams, namely the Project Pitch Website and the Mapping Memory Challenges. However, even though the first Project Vision Challenge was an entirely text-based one and devoid of code, version control was still paramount, as I worked with my team members on a collaborative Google Doc, wherein we could make our additions and review each other’s sections. Although the specific form of version control within our CHI Challenges has obvious technological connotations, version control itself has always been an integral feature of any substantial project, regardless of medium. The shift to cloud platforms, for instance, has facilitated collaboration among multiple people on the same documents, with Google and Microsoft’s product suites being two prominent end-user-specific examples.
In essence, to talk about one would necessitate talking about the other, seeing as how version control fundamentally informed how we went about actually implementing our project for a cultural heritage institution, and later, our own project vision, in website form. To that end, the introduction of version control certainly helped smoothen collaboration across the two discrete groups I was part of, helped me be cognizant of interdisciplinary differences, and allowed me and my team members to foster strong communication and task management practices. Git, and more GitHub formally reinforced the significance of version control as we worked across the website and desktop app, in conjunction with Visual Studio Code (VS Code).
Version control fundamentally informed how we went about actually implementing our project for a cultural heritage institution, and later, our own project vision, in website form.
In our Project Pitch Website Challenge, my team and I worked on an AR-enabled perspective into Robben Island’s cultural heritage and emotional memory. Titled ARobben, our team’s goals were to tie into Robben Island Museum’s already extant digital resources to offer a more direct lens into the diverse experiences of people on the island, including the testimonies of those imprisoned, those in the employ of the South African government, and those involved in wartime activities. Right off the bat, version control came into the way we divided specific sections of our project vision, and we transferred the same practice into GitHub during the coding phase. Creating a digital component for our proposed project meant we each had specific responsibilities as we looked into the methodologies and devices we could use in tandem with the Museum’s resources and in accordance with local and governmental regulations, possible funding partners, design choices in accordance with the existing Museum website, ethical choices vis-à-vis those directly involved with Robben Island as well as technological choices with regards to surveillance and recording, and also projects with a similar scope and intent as part of our environmental scanning process. Version control allowed us to conjoin these disparate aspects of digital component formation into a relatively seamless project vision step-by-step.
Right off the bat, version control came into the way we divided specific sections of our project vision, and we transferred the same practice into GitHub during the coding phase.
Because code repositories on VS Code do not take too well to real-time changes from multiple collaborators, version control became invaluable as each of us gradually incorporated our ideas into the website sections we assigned amongst ourselves. Teething issues predictably came into the fray as we engaged with these platforms for the first time, with our many changes conflicting and not resulting in the outcomes we hoped for. But the way in which version control is intrinsic within the platforms we were working with, we could always revert back to a “safe state” for the project; a checkpoint of sorts from where we could retry adding a new section or a new feature to our pitch website.
This effect of version control was similar in the Mapping Memories Challenge as well where I, now part of a new team, implemented a project with a more personal touch. The project was entitled Mapping East Lansing Memories, and enclosed fifteen specific sites across our college town that each of us visited when we first arrived here. Going about the process of mapping the coordinates of these locations, deciding on a map design by virtue of Bootstrap options, and finalizing our individual marker appearance, all involved a kind of version control even beyond GitHub itself. A seemingly simple aspect of communication among multiple parties suddenly called for a surprisingly robust version control practice, which seeped into every aspect of not just the project, but more crucially, of how we went about building it.
For me, the Challenges have certainly created a tangible appreciation for version control in the process of digital component creation in the service of cultural heritage. As we head into the next phase of introducing our Projects, I hope for these lessons to act as safeguards against suboptimal practices of project management and data maintenance.
Recent Comments