As Bethany Nowviskie has already announced, I’m going be a visiting scholar for Scholars’ Lab at the University of Virginia for the Fall semester. To say that I’m honored would be an understatement. The work that comes out of Scholars’ Lab is incredible, and having opportunity to work along side the folks here is really a privilege. What’s great is that I’ll be working on a project that utilizes tools that both Scholars’ Lab and the Center for History and New Media have been working on the past several years. I’ll be using Omeka and Neatline to create a digital archive and scholarly exhibit on residential segregation in Richmond, Virginia in the early 20th century, and along the way explore some issues in doing scholarship in the digital humanities.

A little background: From about 1910 to 1929, both the city of Richmond and the state of Virginia passed and amended several ordinances that established racially-segregated residential areas. These ordinances basically determined whether a street was a “white” or “colored” street, and hence restricted residence based on those designations.

My interest in this topic was sparked by a controversy I stumbled upon while doing research for my Master’s thesis. In July 1914, the congregation of Emanuel Baptist Church in Richmond sought to sell its church property to a black congregation from Leigh Street Methodist Church. Emanuel Baptist sat on the northeast corner of 5th St. and Leigh St (a corner that no longer exists, thanks to the convention center in Richmond). According to Richmond’s 1910 residential segregation ordinance, the block of Leigh Street where Emanuel Church stood was a white block, while the block of 5th Street was black. Because the address and front door of Emanuel Church was on Leigh Street, the parties involved decided that, to circumvent the segregation ordinance, they would move the front door and address to 5th Street, and thus still adhere to spirit of the ordinance.

Of course, this “solution” didn’t fly too well with city government, or with a hundred or so white residents near the church who created and signed two petitions asking the city to halt the sale of the church. So, the city passed a new ordinance in October 1914 that contained language to redefine the section of 5th Street on which Emanuel Baptist Church sat as a white street. Even though the 1914 ordinance was passed specifically to prevent the sale of Emanuel Baptist Church, its definition also applied to the rest of the city, thus potentially changing the racial designation of other streets in Richmond. Residential segregation ordinances across the US were ruled unconstitutional by the Supreme Court in 1929, but their effects certainly continued beyond that.

I’ll use Omeka to create an archive of primary sources related to Emanuel Baptist Church, and Richmond’s residential segregation laws in general. I’ll also use Omeka’s ExhibitBuilder plugin to create the essay. I’ll use Neatline to display GIS data collected for this project. I’m particularly interested in how the residential designations of the city changed with each ordinance. So I plan to map how the drawing of segregated streets changed over time with each new ordinance. I also hope to create several other maps, including a map of the addresses for each person who petitioned the city to prevent the sale of Emanuel Church, and a map for each case brought before city courts that violated residential segregation ordinances.

In addition to the specific historical research, I’ll also be exploring some issues in digital history/humanities:

• Potential uses for HTML5 for digital humanities projects. I’ve been eagerly reading about developments on HTML5 for some time now, and am interested to see how it can be used for digital humanities work. I plan to use HTML5 for my project’s site, and explore as much of the spec and its features as I can. I’ve got a post series outline just for this, and plan for my work at Scholars’ Lab to contribute to those posts. I’ll also develop an Omeka theme that uses HTML5, and release that to the public sometime this Fall.
• Potential uses for Omeka and plugins as platforms for digital scholarship. This is a topic we discuss occasionally among the Omeka team. Even though Omeka is designed as an archiving and exhibiting platform, and marketed mainly to institutions instead of individuals, I think it has lots of potential as a platform for publishing scholarship. So I hope my work on this project will help to flesh out that potential.
• Design approaches for digital scholarship. I’m keenly interested in how we can better use design in humanities scholarship, digital or other wise. I think it’s important for the DH community to discuss this more, and hope I can contribute something to this while I’m at Scholars’ Lab. For folks following recent conversations on Twitter and blog posts about user testing in DH, I’ll be making plans for user testing, but also thinking/writing about how digital scholars can and should integrate user testing into their scholarly work. I’ve had a post still in draft with thoughts on this from last week that I hope to publish soon.

I’m incredibly grateful to Bethany and the rest of the folks at Scholars’ Lab for giving me this opportunity. I’m also grateful to Tom Scheinfeldt and CHNM for letting me spend some time in Charlottesville. I just arrived at Scholars’ Lab yesterday, and will be in Charlottesville for the next two weeks. Then I’ll spend some more time here this Fall. At the end of this, in December, I’ll give a presentation about my research and the final product. All the work I do on this project will, I hope, contribute in positive ways back to Omeka and Neatline. And of course any code I create will be open source.

When Brian Croxall asked about advice to give to new grad students, I tweeted “Do everything you can to do work you enjoy, and enjoy the work you do. Otherwise, it truly is not worth it.” I’ve been doing work I enjoy, and enjoying the work I do, for so long now I forget that I’m a grad student. This, what I am doing right now, with Scholars’ Lab and with CHNM every day, is truly worth it.

Last year’s camp was without a doubt the most productive, enjoyable, and rewarding academic conference I’ve ever attended. Calling it just a conference is a injustice. Its a conference/workshop/tutorial/networking/tinkering/playing-around kind of gathering, perfect for folks interested in a variety of aspects in digital humanities who want to expand their skills and knowledge. Its a true working weekend, where people show things their working on, get feedback, toss around ideas, and connect with others equally excited about the possibilities of digital humanities. We don’t read papers, and don’t sit around while others read to us. We brainstorm for ideas. We talk about problems. We come up with solutions.

If THATCamp sounds like you’re kind of event, check out the website, and fill out the application form to see if you can get a spot! If you have questions, send us a note by email to info@thatcamp.org or a message by Twitter to @thatcamp.

Go check out the new stable release, download and install a few plugins, and let us know what you think!

Site Maintenance

Once a site is live, it will still need to be maintained at some level. If you use a content management system like Omeka or WordPress, you will need to keep up with software upgrades and bug fixes, and apply those to your site as needed. Subscribe to the news blog or email listserv for your particular CMS to keep up-to-date with new releases and bug fixes. For projects at CHNM, I’m subscribed to listservs and blogs for WordPress, Drupal, bbPress, and a variety of plugin comment threads.

When upgrading software, I find it best to perform the upgrades on a copy of the site in a undisclosed folder on your server. If you have a development server, use it. Or you can perform upgrades and maintenance on your local computer if you’ve set up a web development environment on it. (I detail how I set up my web development environment on my wiki.) Of course, be sure to backup any files and databases when performing upgrades.

Documentation

In addition to maintaining the software, you’ll need to provide ways for your content team to continue maintaining content on the site. If your website requires regular content updates, and if you expect the site to be relevant and sustainable long after development is done, its prudent to create some documentation for how current and future members of your project team can update the site.

A styleguide is particularly useful for advising the content team on proper markup and formatting for site content, and for future designers and developers who may have to do more significant upgrades to the site’s design. The styleguide at the New York Public Library is a perfect example. It outlines the DOCTYPE that webpages on the NYPL website should use, proper markup for things like headings and lists, and how to use/modify CSS on the website. You could easily write something similar for your own site, assuming you made some concrete decisions about layout, typography, and colors during the design and development phases. You did that, right?

User Feedback and Community

After launch, its good to provide some means for direct user feedback. Despite all the planning and testing prior to launch, user feedback is vital to the sustainability of a site and ensures you can adapt your site to the needs of your visitors. Also, it provides a way for users to contribute to the life of the project. Hopefully you can build a regular group of users vested in the success of your project, and recommend it to others. User feedback can come in several forms, from suggestions for improvement to troubleshooting. Methods for soliciting and managing feedback can depend on several factors:

1. How much feedback you expect
2. How much time/how many people you have to deal with user feedback
3. How public you want feedback to be.

At the least, you should provide an email address for users to content for site errors and general questions. If you find yourself dealing with the same questions regularly, though, it would be beneficial to create a Frequently Asked Questions page on your site. You could then funnel inquiries through that page, and if a user’s question isn’t addressed in that FAQ page, they can then continue to some other process for feedback. This saves time for both you and your users.

More robust forms of feedback could involve setting up a separate section for forums, in which individual users can have accounts, post questions to a forum, and have admins (and other forum members) respond. CHNM uses this on Zotero and Omeka. Omeka in particular uses a free software platform called bbPress, from the makers of WordPress, to power its forums. We set up forum topics for different areas to focus conversations and make it easier for users interested in similar aspects of the project to interact.

With some of the WordPress plugins I’ve helped develop, I rely on the WordPress forums for user feedback and assistance. I subscribe to the RSS feeds for the ScholarPress Courseware tag, and try to respond to posts there whenever I can. One of the great things about having the support forum there is that other WordPress users can (and do) respond to posts about plugins I help develop. If the code for your project is hosted elsewhere, check if those repositories can also help you set up space for user feedback.

Indirect feedback is also important. This kind of feedback includes blog posts, Twitter messages, and any other things written about your project. Its good to keep up with this activity, and respond when useful, because you should be actively interested in how your project is received by others and encourage others to write about your project. For example, I get Google alerts email for any news and blog posts that link to the Omeka website, I subscribe to the RSS feed for tweets that include “omeka,” and I subscribe to the RSS feed for the delicious tag “omeka.” There are a few others, but the point is to find a few social app and services, see if people using those services are talking about your project and connect with them. Humanities scholars should see the importance of indirect user feedback and engaging with that feedback. While its great to get people to ask you questions at a conference, its also great to have people cite your work in their own scholarship, write reviews of your work, or recommend your work to their colleagues. Being able to track this kind of feedback, and follow up on this feedback when warranted, is an important part of tracking the impact of your project across a variety of audiences on the Web.

Wrapping Up

That’s it! I must apologize for the time it took to complete the series. I hope the series has been useful nonetheless, but I also hope that you take anything I’ve outlined and modify it for your own needs. This is a good process, but its also good to adapt to the changing needs of your project, your team, and your users. In the end, those are the most important things to consider when framing a design and development process for your project.

Front-end development usually can’t take place until decisions have been made about the front-end design (discussed in the last post). At CHNM, we’ve build projects where there was one designer, one front-end developer, and one back-end developer, all working in concert to build a project. And, we’ve built projects that had one person doing all three. Whatever your staffing situation, here’s what goes on in this phase:

• Photoshop mockups are translated into working HTML/CSS mockups
• Naming conventions in code are set and documented.
• Design is tested in browsers.
• HTML templates are then used to build out the final version of the site (in CMS, or as static pages)

1) Create HTML Mockups

To facilitate faster development of HTML mockups, I’ve created a “starter kit” that is essentially a directory with a basic file structure and pre-coded files for HTML, CSS, and JavaScript. You can download my example starter kit and take a look at how I set it up. The file structure I generally follow is:

	
/starter/
	index.php
	/c/
		screen.css
		print.css
		...any other CSS files.

	/j/
		global.js
		...any other necessary javascript files or libraries.

	/i/
		...any necessary images for the design. Background
                images, logos, etc.
	

My HTML and CSS files also have a basic structure I usually follow. My starter HTML file looks like this:

<body>
	<div id="skiplink" class="hide"><a href="#content">Skip to Content</a></div>
	<div id="wrap">
		<div id="header">
			<h1 id="site-title">Site Title</h1>
			<ul id="sitenav" class="navigation">
				<li><a href="#">Lorem</a></li>
				<li><a href="#">Ipsum</a></li>
				<li><a href="#">Dolor</a></li>
				<li><a href="#">Amet</a></li>
			</ul>
		</div>
		<div id="content">
			<div id="primary"></div>
			<div id="secondary"></div>
			<div id="tertiary"></div>
		</div>
		<div id="footer">
			<p>Footer Info</p>
		</div>
	</div>
</body>

This is a good point for the front-end developer to come up with (and stick to!) naming conventions for various ids and classes used throughout the site. I’ve found that using #primary, #secondary, #tertiary, and so on, gets me thinking less about the presentation of that content, and more about its relative importance. Its not a perfect solution, and sometimes I have to ditch this convention in favor of others, but the point is that you have a convention, and you follow it throughout your site.

My CSS file starts with generic styling of basic elements, followed by any global classes I use throughout the site, then moves on to each section of the page (wrap, header, content, footer). Here’s an example:

	

/* == Reset == */
@import url("reset.css");

/* == Generic styles ======== */
body {font:62.5% "Helvetica Neue", Helvetica, Arial, sans-serif; color:#222;
    background:#fff;}

/* Headings */
h1 {font-size:3.6em; line-height:1em; margin-bottom:1em;}
h2 {font-size:3em; line-height:1em; margin-bottom:1em;}
h3 {font-size:1.8em; line-height:1em; margin-bottom:1em; font-weight:bold;}
h4 {font-size:1.5em; line-height:1.2em; margin-bottom:1.2em; font-weight:bold;}
h5 {font-size:1.5em; line-height:1.2em; margin-bottom:1.2em; color: #999;}
h6 {font-size:1.2em; line-height:1.5em; margin-bottom:1.5em; font-weight:bold;}

/* Links */
a:link {}
a:visited {}
a:focus {}
a:hover {}
a:active {}

h1 a, h2 a, h3 a {text-decoration:none;}

/* Misc Elements */
p,ul,ol,dl,blockquote,address {font-size:1.2em; line-height:1.5em;
    margin-bottom:1.5em;}
ul {}
ol {}
dl {}
blockquote {}
address {}

/* == Wrap == */
#wrap {width:882px; margin:0 auto;}

/* == Header == */
#header {}

/* == Content == */
#content {}

	#primary {}
	#secondary {}
	#tertiary {}

/* == Footer == */
#footer {}
		
	

As you can see, I start out with some things already filled in (typography—font sizes, line-heights, margins), but some things I leave blank and fill in as I go. This is a personal preference, and I change things around from project to project. But this gets me started.

Using this starter kit, I build out HTML/CSS mockups based on the Photoshop mockups created in the last stage. I generally try to build the same pages that were presented to the project team, and strive to make the HTML version look and feel the same as the color mockups as much as possible. But, its important to remember than a design will never completely look the same in Photoshop and in the browser, and will rarely look the same across different browsers. Striving for pixel perfection to the color mockup across browsers, while sounding noble, ends up being a significant waste of time. The goal should be to make the HTML mockups look like the color mockups as much as possible, but also be usable and useful to the end-user. If one section of a site is bigger by one point on one browser, its probably not worth the time to figure out why. If its using a completely different typeface, then maybe you have a problem.

2) Test Mockups in Browsers

The advantage to doing HTML mockups before diving straight into the entire project is that you can 1) do the prototypes quickly, and 2) test the design in browsers before doing all the work to apply the design to dynamic content. At CHNM, we test in the following browsers:

Windows

• Firefox 3
• Internet Explorer 6
• Internet Explorer 7
• Opera

Macintosh

• Firefox 3
• Opera
• Safari

I try my best to test every single page, but I usually miss a few pages, so its good to have one or more people test your site on different browsers. When taking notes, I generally make a list that starts with the browse in quest, then a subheadings with the title and path of the page I’m looking at, and then specific issues for that page. For example:

Internet Explorer 6

Items Browse page – example.com/items/browse/

• Items content extends past page boundary
• Individual item titles not showing up
• Layout for main column and sidebar is broken (aren’t showing up side by side)

This allows me to first focus on a particular browser, then focus on a particular page (and know what its URL is), and get those issues working for that browser. I’ve found that a lot of issues on one page are similar to other pages, so solving it once usually fixes it globally. But, I like to note each problem on each page, because there may be other issues at play.

3) Applying to Dynamic Content

After you’ve completed HTML mockups and tested them in various browser, its time to use them when working with dynamic content. If your project is just going to be static pages, simply keep building out HTML pages as you did for the HTML mockups. But if you’ll be working with data in a database, now’s the time to learn a little bit about the kind of code you’ll be using to pull data into your HTML dynamically.

One piece of advice I can give on back-end development is: avoid reinventing the wheel as much as possible. That is to say, look to see if there are solutions available to make your development process easier before deciding to write something from scratch. With Omeka, the project team met early on and explored options for doing the kinds of things with wanted to do with other content management systems (Drupal, WordPress), and determined that the problems we wanted to solve required that we write something new. But even then, we did completely start from scratch. We use a PHP framework, Zend, as the base for the application, which makes development much more rapid and stable than if we wrote our own framework from scratch.

The data needs for a project can greatly impact the kinds of technology a project will need to use (or can’t use). I recommend that the development person/team make a list of any available content management systems, frameworks, and libraries and rate their qualities based on what your project needs to accomplish. For example, at CHNM we’ve use Drupal, Omeka, and WordPress for different projects based on their needs. We build Omeka, and we think it rocks, but its not right for every site. Neither is Drupal or WordPress, or any other CMS out there.

When I’m choosing a CMS or library or framework, I like to give myself some time to figure out how I would build the site with each one (if possible), determine which is most efficient and maintainable, and then go with the best choice.

Some examples:

Content Management Systems

• Drupal
• ExpressionEngine
• Joomla
• Moodle
• Omeka
• WordPress

PHP Frameworks

• CakePHP
• CodeIgniter
• Symfony
• Zend

JavaScript frameworks and libraries

• Dojo
• jQuery
• Prototype
• MooTools
• Yahoo UI

Many of you will be developing projects that rely on some kind of content management system that employs a theme API to pull content from a database. WordPress and Omeka are two such systems that I’ve worked with very closely, but other such as Drupal, Joomla, and ExpressionEngine are others that you might be using. One of the final jobs of the front-end developer is take the static HTML mockups she/he has created, and apply the HTML structure to the template files used in one of those systems. In some cases your front-end and back-end developer (if they’re two different people) will need to work together to make sure their individual contributions to the project can work together. A back-end developer, for example, may need to explain to a front-end developer about how certain theme API calls work and where to put them in the HTML template, while a front-end developer may need to explain to a back-end developer than the content a plugin generates needs to be in an unordered list with a specific id and class attribute. In short, there’s a point where the two types of development merge, usually a few weeks before the site launches.

This will also be a time when the front-end developer will have to account for specific kinds of content not covered in the HTML mockups. This will happen as content for the site gradually gets added to the database, and all the sections and pages for the site outlined in the site map emerge. You may have to add some specific styles for certain content. But the work you’ve already done will make this process much faster. Once you’ve done all of this, maybe run some more browser testing for anything new you’ve added since the HTML mockups, your site should be ready for launch!

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. 1 Jesse James Garrett, The Elements of User Experience: User-Centered Design for the Web, New York: AIGA and New Riders, 2003, 27.

Even though I had taken a digital history documentary class a few years ago, it still surprised me how much work creating a podcast involved. Like Dave, though, I’m pretty happy with what we came up with, despite getting a little rushed. Dave did a lot of work at the end, so most of the credit for the success of the first show should go to him. Thanks, Dave.

Our plan is to roll out a new THATPodcast show once a month. In February our show will cover Omeka, the free, open source platform for managing collections and exhibits now in development at the Center for History and New Media. We’re going to time episode two with the public release of Omeka, so be sure to check back next month!

ScholarPress

CHNM News and Dave have already pointed this out: Dave and I have started ScholarPress, a suite of WordPress plugins with academics in mind. We have two already out in the world, being downloaded as we speak, and a few more in the works.

The first plugin is Dave’s WPBook plugin, which acts as a bridge between a WordPress blog and a Facebook application. I’ve used the plugin to put my course information, pulled directly from my course website, in an application on Facebook that students can add to their profiles. Just another way to make course information available to students.

The second plugin, Courseware, was originally created by me and Josh Greenberg over the summer of 2006. I’ve used it for all of the classes I’ve taught so far. It gives you the ability to manage a syllabus, bibliography, and assignments through a WordPress blog. I’ve always set up a WordPress blog for my course site, and used Courseware to publish class assignments and meetings. The schedule page includes a link to subscribe to the schedule in a calendar application; it parses events marked up with microformats and creates a vCal file.

A few other plugins in the works:

• Gradebook—a plugin that works with Courseware to give instructors the ability to store and share grades securely with students.
• Bibliographer—I’m considering making the bibliography portion of the Courseware plugin separate, and beefing it up to do multiple reading lists, reviews, ratings, etc. Of course, it would work with Courseware.
• Footnoter—Would give post writers the ability to easily and quickly add footnotes to blog posts through the WYSIWYG editor of WordPress, and have the footnotes appear when hovering over the superscripted note.
• Highlighter—This plugin would allow readers to select a portion of a blog post or page and associate a comment with that selection.

Omeka

The biggest project I’ve been working on at CHNM for the past few months is Omeka. Put simply, Omeka is a simple platform to allow cultural institutions (museums, historical societies, libraries), or pretty much anyone, to manage and publish items, collections, and exhibits on the Web. We’ve used earlier versions of Omeka to power the Hurricane Digital Memory Bank and Object of History, and we’re using the latest releases of Omeka to run a few projects currently under development, like Gulag: Many Days, Many Lives, which is set to launch at the end of November.

If you’re interested in getting on the list of beta testers before the public release (which is early March), visit Omeka’s website for more information.