This post is the intro to a series on the process I recommend for creating a digital humanities project from scratch, from initial conception to launch and aftermath. The last few months, I’ve been researching design and development processes in an effort to establish and document them for folks at CHNM, and for my own benefit. In a lot of cases, the process could be generalized for any kind of project, but I hope to address specific goals and concerns that humanities projects have at various stages of development. So, here’s what to expect:
The Series
Part One: Figure Out What You’re Building
Figure out what exactly you’re building. Seems simple enough. Meeting with project managers and content creators about what exactly we’re doing, what kind of site we’re building, is of the utmost importance at the beginning of a project. This post will address some basic questions to answer when first starting a project, establishing responsibilities, and setting a timetable that works for everyone.
Part Two: Information Organization and Architecture
Get organized. Before you touch a line of code or a pixel, figure out what the information architecture of a site is. A lot of people fail to realize that the structure and organization of content greatly affects the design and development of a site. Here we’ll take a look at some useful techniques for working out how the information is organized throughout a site and on specific pages.
Part Three: Design Process
Create meaningful design solutions. Now that we have a stable information architecture, its time to put that information into a useful, meaningful design. The important thing to remember here is that design is about solving problems and addressing specific issues. Its not about your favorite color or font; its how all the design elements (color, typography, space, layout) work in concert to provide users with a meaningful web experience that we defined in previous steps. Here we’ll discuss how to start brainstorming for design ideas, how to bring those ideas into tangible results backed by a concept, and how to present and discuss those results with the project team to get productive feedback.
Part Four: Front-End Development
From pictures to code. OK, so we have a design concept that everyone on the project team has approved. Now we need to take those mockups and translate them into working web pages, and eventually apply them to the entire site. In this post, we’ll take a look at how to go from those image-based mockups to HTML mockups to a full-scale working website.
Part Five: Going Live, Maintenance, Documentation
Launch and post-launch tasks. When you take the site live, your work is still not done. The site will need to be maintained, content may need to be added, and user concerns will certainly need to be addressed. Here I briefly discuss the steps to make a site live, elaborate on points concerning maintenance of a website, and provide ways to document the websites to better facilitate that maintenance.
Fluidity
These aren’t discreet “steps” in that one must be finished before work on the other can begin. This kind of process would be very impractical. Instead, I like the approach Jesse James Garrett takes in his The Elements of User Experience. Garrett argues that work on each step should finish before work on the next can finish. So, for example, establishing the information architecture can’t be completely finished until you’ve finished figuring out what exactly you’re building.1 Work on all steps continues well into the next, but changes in one step can mean that the team has to revisit previous steps. This approach provides a much more fluid, flexible work process, but also requires lots of dependencies and clear communication among all involved.
Any code or files I use will be included with each article for download. I really hope you find the series useful. Check back next week for Part One: Figuring it Out.
- 1 Jesse James Garrett, The Elements of User Experience: User-Centered Design for the Web, New York: AIGA and New Riders, 2003, 27.
Hi Jeremy; To ride two favorite hobbyhorses: where do discussions of cumulative scholarship and sustainability fit in this model? How will the steps outlined here lead to a project that: (a) takes full advantage (with citation) of prior work on content and tools in order to reduce the cost and cumulate skills and knowledge in the digital humanities; and (b) gives serious thought throughout the design and building stages to the question of how the resulting project will be sustained?
From what I’ve seen, failure to consider those questions poses at least as serious a threat to most DH projects as does choice of the wrong technology or information architecture. If you don’t have a sustainability plan, IA won’t save you; if you haven’t scanned the environment and avoided reinventing wheels, IA won’t get you through the funding peer review….
I don’t disagree with your outline as far as it goes, but if you’re trying to give good advice to prospective digital humanists, perhaps you ought to include a strategic layer as well as the purely technical guidance?
I’m very much looking forward to this series. It will be valuable for anyone who wants to emulate the work of CHNM. Thanks for making not just your projects but your knowledge open-source.
@Chris. Thanks so much for the comments. I think my series was aiming more toward how a project team has to work together as a group, and I planned to write this more from the prospective of a designer/developer. But, I think your questions are very good, and do indeed influence the things I had planned to discuss. A few responses:
I don’t think the steps here, in and of themselves, will necessarily lead to a project that will take advantage of prior work; I think that’s a philosophy the project team has to have before beginning the process, and one that shapes decisions throughout that process. I do think its an important philosophy, one that we work by at CHNM and one that influences my own work. In the first part of the series I plan to talk about how the team comes together to make decisions about content, scope, and use for a project. That phase certainly includes discussing what kinds of technologies to use, what developers are capable of working with, and how to use or improve upon technologies/resources/services already available. I think a great example of this is Zotero’s choice to use several tools developed by SIMILE to allow its users to see data they’ve collected in different ways (specifically the timeline feature in Zotero). The Zotero team didn’t decide to build something from scratch, but rather chose to implement something already built, which cut costs and made for faster development.
We’re doing the similar things for Omeka: Taking code/standards/services already in existing in open-source and using them to build the system and build plugins. We’ve been inspired by the open source community surroundin WordPress. We’re building on code developed for earlier grant funded work at CHNM and elsewhere, and using tools such as iPaper, Google Maps, and various SIMILE projects for plugins. One of our developers is even reworking Simon Fraser University’s Public Knowledge Project OAI-PHM Harvester for data migration utilities. I think this does raise the question of whether most digital humanities project HAVE valued reuse and openness to all, for more cooperation and for building upon previous work. I don’t that has been a key tenant of digital humanities until the last couple of years.
I allude to this somewhat near the end of the post; that these phases aren’t completely divorced from the others, and that decisions made during one of those phases can have dramatic consequences for previous and future phases. I plan to discuss specific of maintenance and sustainability in the last part of the series, but the project team must certainly be aware of issues regarding sustainability at the beginning of the project, and those issues influence decisions throughout the life of the project. I agree that sustainability is an important consideration for any project, not just a digital humanities project, and that should also be part of the initial discussion from the beginning.
But I think your two questions are actually tied together, in that I don’t think any digital humanities project can expect sustainability without valuing the need to build upon pre-existing work and share work with others, or vice versa. Thus, for a digital humanities to be successful in my opinion, it must value cooperation over competition, and reuse over re-creation.
@Lincoln: Thanks!
It’s not quite a reply, but I used your step 1 as a jumping off point for a post yesterday.
This looks great. I have only one quibble – you should have posted this series 2 years ago, before I started working in this digital projects business. If our big launch this month goes all wrong, I’m going to blame you…
If I had only thought about this stuff two years ago, Sharon, I would have posted it! Good luck on the big launch!
Anxiously awaiting part II. Any ETA?
Just published!