Building and designing projects for long term preservation
May 17th, 2010 | karindalziel
Although I have attended THATCamp the two years previous to this, this is the first in which I am fully immersed in the day to day building and maintaining of websites. Because of that, my view of what to talk about has become a bit more… pragmatic. Some days I manage to try to ask bigger questions about what we’re doing and why-but most days I am fixing broken things (hard) and trying to not break my own things (harder). Migrating old sites to new technologies also takes up a good deal of our time.
So, the session I proposed was on the life cycle of digital humanities projects- specifically how to design and develop for the eventual long term preservation of a project. Bethany Nowviskie is addressing this in part with her work on Graceful Degradation, but I am also interested in what we can do at the beginning of projects to make them easier to maintain indefinitely. I’m not sure exactly what this might mean. Some ideas: limiting the kinds of technologies used so that projects are easier to support; pre-building a planned HTML only version, to be deployed in case of a loss of technology. (Also of interest is Hugh Cayless’s session proposal). Some sites don’t have such easy answers, like older GIS sites that depend on a specific commercial server. Other aspects include documentation and commenting code (something we have lacked due to heavy workloads around here). I am curious how others in similar situations deal with this- are there standards in place, or do you decide on documentation and technologies on a project by project basis?
May 17th, 2010 at 12:11 pm
Hey, Karin — there might be some commonalities between what you’re proposing and what Ronda Grizzle of the Scholars’ Lab would like to discuss. (I think she’ll be posting about her session later today or tomorrow.) Ronda is our communications goddess, and she spends a lot of time thinking about good documentation and how to encourage it — especially in the digital humanities context, where you’re working with heterogeneous groups.
And thanks for mentioning Graceful Degradation. Dot Porter and I will be presenting on that this summer at DH 2010. For what it’s worth — we’re hopeful our analysis of projects that experienced periods of transition and decline can lead to exactly what you’re talking about: better work up front to prepare, and better understanding of the factors that prevent projects from weathering those periods well — whether that means surviving as living projects or concluding gracefully and “preservably.”
May 17th, 2010 at 12:20 pm
Bethany – thanks for mentioning Rhonda Grizzle’s proposal, I’ll watch out for it.
I think the CDRH really needs to get a communications goddess on staff. 🙂
May 17th, 2010 at 9:20 pm
[…] related to: karindalziel’s session proposal […]
May 18th, 2010 at 12:23 am
[…] Megan Brett and I’m particularly curious for any suggestions from Chad Black, Priya Chhaya, Karin Dalziel, and Matt […]
May 17th, 2010 at 9:26 pm
I just posted Karin. I’m excited that other folks want to talk about documentation as it relates to sustainability and project life cycle.
Oh, and you can borrow my communications goddess tiara anytime you need it. 😀
May 19th, 2010 at 9:09 pm
I think this is very important stuff. A few more ideas: plan for projects to expose their data in detachable, downloadable chunks (e.g. each record serialized as XML or HTML); choose well-documented formats; make dynamic functions modular and make as much of the project static as possible; document intention and editorial practices/conventions, even if not code (your code may well be tossed in the bin anyway, but your successors will want to know what you were aiming for).