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.