Adventures in Digital History

Refresh, Restore, Rescue: Reflection

At the start of the semester I was placed with the Refresh, Restore, Rescue group alongside Carson Berrier, Ashley Diminio, and Eugene Hlaing. We were informed by Dr. McClurken that the project we had been assigned was one that had never been done before. We were not going to be completing a traditional digital history project like the other groups. Instead of researching a topic and publishing resources and findings online as part of a comprehensive digital history site, we would instead be examining every digital history project created by current and previous iterations of the Adventures in Digital History class with the intention of fixing any issues those sites may have while creating a database others may consult about the sites in question.

This was a highly ambitious project, one I am honored to have been given the chance to work on. From the beginning my team knew it was going to be challenging. There was only four of us, over twenty different digital history sites with a plethora of issues, and a limited amount of time. We started this project off by separating into two sub-groups. Carson and Ashley would work on creating the digital history archive, which we collectively dubbed “The Hub,” while myself and Eugene would work on identifying issues with specific sites before attempting to fix them.

Fixing sites sounds simple enough, but when taking into consideration the age, amount of detail, and specific types of software used to create each individual site, we soon realized we had a lot of work cut out for us. I was in frequent contact with Shannon Hauser from the Digital Knowledge Center throughout the semester, trying to gain access to sites and ensuring I wouldn’t accidentally crash a site or UMWBlogs as a whole. Shannon was a fantastic help, getting us access to some of the newest sites we identified had pressing issues. Essentially, we ended up working backwards by year. Once we gave Shannon our list of sites with explanations of what needed to be fixed, she would back up sites before giving us admin access. We would then go in and fix those issues before moving on. I personally got into the practice of taking screenshots of each site before making any changes. This proved to be essential for our site as later I was able to integrate those screenshots into blog posts explaining the changes I made to each of the sites. On my own I managed to fix issues on a total of seven different sites, each of which have been archived on our Digital Preservation tab.

The large scope of this project and finicky nature of WordPress and Omeka means we did not manage to fix every site as we envisioned. Older sites could not be accessed the same ways as newer sites, forcing us to forego fixing them due to time restraints. The reality of working with sites that are not carefully curated means things break and disappear. Software becomes obsolete or updates cause critical failures. Some sites even shut down completely, breaking project sections that were otherwise creative and inventive. Some of the most common errors were associated with timelines, maps, and images. Hosting these thing locally or in personal drives is not optimal, as they may later be deleted. It’s best to provide transcripts, sources, links, and other documentation as a failsafe in case something happens. Many of the groups this semester actually took inspiration from us and implemented these ideas into their projects, making PDFs and transcripts available for any parts of their projects that use outside software. I think we scared them a bit, but it proved to be good practice in preserving the information of their sites.

As far as working together goes, I could not have asked for a better team. Carson, Ashley, Eugene, and myself were understanding of one another. We were able to bounce ideas around, working collaboratively on a huge project that no single person would have been able to complete. Our initial outline for this project was just as ambitious as the project itself. We had plans for creative uses of software that we eventually decided to do away with. One of the things we discussed adding to the site was a TimelineJS project for each of the digital history sites. We decided not to do this in favor of a tag system where each page on our site is tagged based on year and content. This was done to keep our site, which is essentially a database for every UMW digital history project, as simple as possible. Likewise, I had the idea of using WordPress’s featured image system to liven up blog posts, but soon discovered it was more feasible to simply not have it. We learned a lot by doing this project. One of the biggest takeaways I got from completing this project is that bigger is not always better. The more complex you make a site can only result is bigger issues down the line. Sometimes simpler is better, to ensure a project is preserved for future use and is accessible by all.

I would not have been able to do this project without the other people in my group. I am eternally grateful I got placed with such wonderful people who helped me create such a useful and creative project. We envision that this project will last for years to come, and hopefully will be updated by future Digital History students. We have already started the process of handing everything over to Dr. McClurken for future use. I can only hope all our preparations will come through and that our site will not meet the same fate as some of the previous projects we explored this semester. For now, I’m just happy to see the result of all our hard work. This site honestly turned out so much better than I could have hoped, and I have even heard people talk about it on campus since we started advertising it through social media! I hope anyone interested in UMW’s digital history projects continue to make use of it, making its history and legacy live on!

Leave a Reply

Your email address will not be published.

css.php