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.

My target audience for this probably doesn’t include programmers; Most of the programmers and developers I know and have worked with have already drank the open source Kool-Aid. Perhaps this has skewed my opinion on the role open-source development should play in DH, but I’m OK with that. Really, my audience for this post are two groups: Lone, individual scholars who either never considered sharing their code or who may think the code they’re writing isn’t worth sharing, and digital humanities centers or groups who are building significant projects but are afraid/uncertain/indifferent to the idea of sharing the code for their projects. I want to address these groups by discussing a bit of my own experience sharing code.

My Experience Sharing Code

When I began working at CHNM in 2003, I barely knew HTML, and honestly didn’t know much of anything else. (It may be a miracle I was even selected a GRA.) The first year I was there, I spent a lot of time just browsing the files on the CHNM server, opening up files I never knew existed on projects, and seeing how the code helped generate the content I saw in the browser. It was eye-opening to say the least, a bit nerve-wracking, but also empowering to see all the code that made these sites go. Of course, what I was looking at wasn’t publicly available, but my point here is that just looking at the code, tinkering with it, copying/pasting into my own projects was an incredible learning experience. Making code like that more open makes it possible for anyone to learn from it.

I’ve started sharing more of my code on my GitHub account. Some of my projects include phpZotero (a PHP class for working with Zotero), clioweb-theme (the WordPress theme I use on my personal site), and cw-authorbase (WordPress plugin to let you change the base for author URLs). But I’ve also developed open-source code elsewhere. ScholarPress Courseware is a plugin to do simple course management on a WordPress blog. I started it with Josh Greenberg initially to scratch an itch I had about how to set up my own course website when I started teaching. We wrote it mainly to satisfy my needs at the time, but I shared it with others, who then suggested features, and found bugs that I (and others!) could fix. Dave Lester added BibTeX import. Zac Gordon updated the admin interface to work with a later version of WordPress. Now, Stas Sushcov is using Courseware as part of a Google Summer of Code project. After looking over phpZotero, Wayne Graham wrote a Ruby wrapper for the Zotero API, and we did a bit of Zotero hacking at THATCamp in May based on that work. If I hadn’t developed any of this as open source, and instead had hidden away the code, these kinds of collaborations and branches likely wouldn’t have happened. There are plenty of other digital humanities folks on GitHub, all doing more or less the same thing. Following these people, and having them give me comments back on my code, has been so helpful.

At CHNM, we’ve started to do this with more of our projects. Right now, both Zotero and Omeka are open source. Their code is freely available to download, either via handy zip file or through a Subversion repository. (For example, here is Omeka’s SVN repository, and ticketing/bug system.) Anyone can view the source and the tickets, and can request an account to submit tickets or patches if interested. Similarly, Omeka’s addons repository uses SVN and has a ticketing system. Anyone who wants to develop and Omeka plugin or theme can either request access to the addons repository, or set up their own.

This week, I started a GitHub account for CHNM, and started sharing some source code I’ve written for some of our projects, namely the WordPress themes for Hacking the Academy and One Week | One Tool. We’re planning to share more code from our individual projects, like any Omeka or WordPress themes, plugins, just about anything we develop that we can share. (Expect THATCamp-in-a-Box to be up there in some form sometime this summer!) So if anyone wants to use the Hacking the Academy or One Week themes as the basis for their own themes, they can just check out our code. If they find a bug in there and want to tell us about it, we’d be very grateful! I’m not sure how much we’ll put up there that we’ve already written for past projects. But we want to give code back whenever possible, so anyone can learn from and use our code, and so we might get feedback and improvements from the others, too.

The “how” part for sharing code is fairly straight-forward, and there are any number of ways to do it: Sign up for a GitHub, Google Code, or some other project hosting service, and commit code there. Or install your own Git, Subversion, or other repository system on your own server. You may have to learn some kind of versioning system; There’s a great piece by Julie Meloni that provides a gentle introduction to version control. Or you could just make a zip file of your code available on your project site. Add links to these on your project website and on your personal or institution website. Add a colophon or technical explanation of your site. Basically, whether you’re a lone digital humanist coding stuff just for you, or a larger center or institution building grant-funded projects, get your code out there so others can see it! As an individual graduate student and digital humanities scholar, and as a project manager at CHNM, I’ve had nothing but positive experiences with sharing code, and I hope others do, too.

Why Share Code?

Encourage more thorough evaluation, and replication our work.

Most reviews of digital humanities projects are only of the “surface” of the project, and rarely ever deal with the code underneath. I don’t think digital work can be thoroughly and critically evaluated if the evaluators have neither the technical knowledge nor the access to the source code for the digital work. And they both seem to go hand-in-hand. We should start asking projects that wish to be evaluated in any kind of review process to make their code open for the same kind of review. We could go even further and demand that projects include a technical statement or colophon explaining design and development decisions on the project. But baby steps first…

As for replication, think of it this way: We ask for footnotes in articles and monographs to prove we’ve done the research, and that the reader can, at any time, replicate that research if so desired. Likewise, our digital humanities projects should be more replicable than they are. It doesn’t seem too much of a stretch to be able to build new digital humanities projects based on work already done and available from a previous project. Can you image how differently we would build DH projects if we knew the source code would be part of the evaluation, or that it could be possible to replicate some or all of the results of a DH project using the same source code? I know I would write better code!

Increase status and/or credit for code writing in DH.

The potential for more thorough evaluation and replication of work could certainly lead to an improvement in how we allocate reputation and credit for writing code. As it stands now, much of the work that goes into DH projects is hidden. Sharing code in the digital humanities would make the craft of creating that code much more important and prized in DH work, and would go a long way toward making that work could for things like tenure and promotion. But think of all the opportunities for collaboration on projects, and gaining reputation or credit for contributing bug fixes or features to projects. There is, of course, a whole different conversation to be had about how design and development of DH projects should count toward promotion or play into academic reputation and credit.

Encourages sustainability.

I occasionally hear questions about sustainability with regards to digital humanities projects. Writing code with the intent of sharing it makes knowledge transfer much easier, which helps make sustainability even more possible. Eric Raymond points out that, with open source projects, there is an unwritten rule that if the developer of a project feels unable to continue for whatever reason, she/he should find a suitable replacement to keep the project going, and should relinquish control over the project once someone steps up to take on that role. I’m not sure how many orphaned DH projects are out there, but I know there are a lot. I don’t know if there is anyone out there who could take over some of those projects, but I would hope there are a few. Regardless, we’ll never know until we begin build projects as open-source, share them, and see if there are others able and willing to contribute to their sustainability. This is especially important if, as a recent issue of Digital Humanities Quarterly addressed, work on DH projects is rarely ever done.

Knowledge exchange.

As I already mentioned, I learned more from looking at the source code for CHNM projects than I ever have from reading a programming book. I’ve learn more from talking to developers directly about their code, about specific projects they’re working, than from working with a book discussing abstract programming terms. Given how many conversations I’ve seen among folks in DH lamenting the lack of training opportunities or examples for developing DH projects, I’m amazed we don’t share more code to help remedy these issues. Having more DH projects with open code can help make others in digital humanities much more aware of, and literate in, using that code. Imagine how much we could learn from having the code for Valley of the Shadow or every project published by the Vectors journal. More to the point, imagine if our projects were written with the idea that we are contributing knowledge through our code, and that others would be looking at the code to gain some insight into our projects. Just like with peer review and evaluation, we might write better code, and think more about how we would explain it to others.

There are, I know, plenty of unanswered questions. What would support models for shared code be like? What license should you release code under? Plenty of others. These are legitimate questions, and should be dealt with on institutional, personal, and/or per-project bases. But we should have serious discussions about how to share code on digital humanities projects, and about how that sharing should come into play in our broader professional work. Talk to your institution or employers about it. But I think we should encourage others to reuse our work and build off of it. I’m concerned about digital humanities work becoming lost and/or irrelevant, especially since we increasingly seem to be living in a era of black boxes. We should fear our projects atrophying because their code is hidden. We should fear being irrelevant in broader discussions regarding technology and standards. We should fear not learning from all the wonderful projects we’re all creating, because we’re afraid of sharing our code for whatever reason.

I don’t think digital humanities cannot afford to leave the programming and developing to non-humanists. I totally agree with the fine folks at NiCHE that it leaves us at the mercy of the people who do code. We should start actively write code with the intent to share it, and share as much as possible, so we might become better developers together. We should write code with an audience in mind, like digital humanities community, who may want to reuse our code. We should share our code so others can learn from us, and so we can learn from others. More than anything, though, we should share code because it’s academic work, and I think academic work should be shared openly, critiqued, and improved.

When a history professor is researching and writing a book, for example, she isn’t necessarily concerned with what her “users” would like to read about. Maybe some are, but most academics are concerned less with meeting audience needs than they are with teaching the audience something new. In fact, they see one of their goals as contributing new knowledge, knowledge those academics think will be useful to their profession as a whole. They don’t necessarily write monographs to make it easier for, say, K-12 teachers to use them in class. In a lot of ways, usability is prescribed in the format of the academic monograph: table of contents, chapter headings, page numbers, paragraphs, footnotes, the occasional figure or appendix. And, if I may speculate, this prescribed format may undermines the need for the creators of academic scholarship to really think about usability.

Most websites, however, are built with user needs primarily in mind, at least most commerce-based websites. Business do focus-group testing, user testing, and marketing to try to meet particular user needs. In that sense, websites try to provide something users want, without uses have to think about how to get what they want. In fact, one of the leading web usability book in print is titled “Don’t Make me Think!” and argues that websites should strive to create interfaces and experience that require little thought to use.

Digital humanities websites, it seems, have to walk a fine line between two very different goals: On the one hand, we do want to provide information and tool that we, as experts, think the audience should use and need. On the other, we can’t simply offer it and expect that our audience will find it valuable. The trick with digital humanities projects, it seems, is to encourage users to think about specific things, think we want them to think about, while providing tools and methods for doing that kind of thinking in an unencumbered, clumsy web interface.

In Train of Thoughts, John Lenker argues there are three parts to providing a effective experience on the Web:

1. Entice – Get the audience interested in your topic
2. Inform – Provide some meaningful information to the audience; Educate audience about a particular topic.
3. Invoke – Encourage a response from the audience, ensure that the information you’ve given them can be put into meaningful action somehow.

Traditional academic scholarship is almost exclusively focused on the second part: Inform. It may dabble in the Entice part, with catchy titles or discussions at book clubs or on the web. And while scholars certainly want to invoke a response from colleagues, the product itself doesn’t encourage a variety of responses. Digital humanities, though, has the means of combining all three into a meaningful, usable experience. In fact, I would argue that any work in the digital humanities needs to accomplish all three to be effective.

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.

Instructor as Role Model

I think any instructor using technology, in the class or out, should think of themselves as a role model for how those technologies can be used for responsible, beneficial goals. One way I do this is to be completely transparent with students regarding my use of technology. I provide links to my blog, my Twitter account, my Flickr account, my YouTube and Vimeo users, my Facebook page, and my instant messenger screennames. I encourage them to follow me, and contact me through any of these methods. I set up rules for contacting me, though, which are followed 99.9% of the time, and that 0.1% is not enough of a problem for me to change my transparency. I also show students how I’ve used my blog, Twitter feed, and other accounts to build a professional network and share information. While others warn about the ill effects of putting too much of yourself online (which can be true), I try to show students how I use technology to expand my opportunities, not limit them. Overall, I’ve had positive feedback from students about my openness. I think that I use technology and social media responsibly (though I could work on the efficiency part). Setting an example that students can follow is important if we want those students to be more critical about their use of technology.

Instructor as Tech Support

When utilizing social media and technology in my courses, I’ve found myself serving as the primary tech support person when students run into trouble. With my tech background, I’m comfortable with this, but I suspect a lot of teachers are not. Explaining the technical aspects of blogging, wikis, RSS, YouTube, and Flickr can take up time spent on other things in class and out, but I think its very important to take on this role. In a lot of cases, support involves me showing students how to find answers to their questions on the Web, on support forums, or other resources. In other cases, support involves me taking 5-10 minutes at the end of class to explain how a particular technology works. While this can be TONS of work, serving as tech support has, I think, given my students more confidence in my ability to teach with and use technology (going back to Instructor as Role Model).

For example, I have an assignment that asks students to research and write an article on Wikipedia. Its not a big article (~500 words), but the assignment does ask a lot from students: Learn how to do proper formatting for Wikipedia, research an article, and try as hard as they can to ensure their article isn’t vandalized or deleted AND encourage other users to contribute to the article. Learning these things requires a lot of my time for tech support: Explain how Wikipedia works, how to format footnotes, headings, et cetera, and how to find guidelines to follow if a student’s article is up for deletion. This is not the kind of task I’d ask general University tech support, because the assignment is as much about learning these technical things as it is learning about collaborative writing and research. The fact that I can take on a role of tech support helps make the assignment successful.

Instructor as Cheerleader

Out of the three, I think the role of Instructor as Cheerleader is the most important. I really think that there’s a lack of cheerleading or positive reinforcement in higher education in general,  particularly when trying to teach students to use new kinds of technology or social media. At the beginning of the semester, usually after the first class when I’ve introduced all the things we’ll be doing with computers, I get a few emails from students saying something to the effect that “I’m not good with all this computer stuff.” And they probably aren’t; I’m not convinced that this generation, like previous generations, is that tech savvy. But I do think every student I have is capable of becoming more proficient with technology than before they entered my class, and can learn how to use the technology they’re exposed to every day in new, meaningful, efficient ways.

The prospect of editing a Wikipedia article, to go back to that example, is a strange (and sometimes frightening) proposition for my students. Learning how to format footnotes in Wikipedia, insert images, write the proper code for headings and bulleted lists can be daunting to many, let alone connecting with a few dozen completely unknown Wikipedians to discuss the merits of their articles as some face deletion. Encouragement and genuine interest in the success of each students project is imperative, as is patience. There may be some hand-holding involved as students negotiate with sometime rude Wikipedia admins (I’ve done this) or spending some extra time during office hours explaining wiki formatting while encouraging student that they are in fact smart enough to do all this computer stuff (I’ve also done this). Pointing out successes in class, even if its as simple as successfully inserting a YouTube clip into a blog post, goes a long way to get students vested in the assignments and class as a whole.

Results

All of these roles help me accomplish one of my goals in class: Help my students become more savvy, more responsible consumers and producers of media and technology. I think trading of some time covering some particular historical topic to teach students how to extend learning beyond my classroom is more than worth it. In the end, I get more students interested in exploring history and help shape more responsible social technology users. Even if I only influence a handful of students, I’ll consider my class a success.

I’m still going to think about these roles, refine them, and perhaps come up with more as my teaching evolves. I probably missed a few roles that you think are important, or your courses may be different enough to warrant different roles when using technology in class. What others have you acquired while teaching with technology? What are the drawbacks and merits of them?

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.

I would advise that in this phase, you try to answer the following:

• What is the site?
• What content will be on the site?
• Who is the audience? How will we want them to use the site? How will they use the site in other ways?
• What specific components are needed on the site? What technologies? Static HTML? Need dynamic content? Need a CMS? Need a custom web application or interactive features?
• What is the timeframe for completing specific phases of the project? What is the timeframe for completing the entire project? What other projects are vying for time?
• Who is on the project team? What are their responsibilities? How much of their time do we have, or can get?

Questions

What is the site?

If you can’t answer this, it will be very difficult for everyone on the team to actually build it. Its OK for the definition or description of the site to evolve over time. In fact, you should probably expect this, as your user base grows or you get new content. The project team does need to hash out, in a paragraph or two, what exactly the site is about, what it offers that other sites do not, and why it is important. If you can’t justify building the project, you should consider whether you should build it at all.

What content will be on the site?

It is very helpful to everyone on the team to have a discusion of what kinds of content will be on the site. This isn’t saying that the content needs to be done at this point; only that a good idea about what content and how much will be on the site. Is is primarily images? Text? Video? Some combination thereof? Is the content something the team is preparing, or something collected from the public? Is it a “web translation” of a physical exhibit or a book? Is it web-native? The kinds of content, its origins, and the expected interaction between users and the content, will influence answers about who the target audience is and what technologies are needed for the site.

Who is the audience?

The answer to this question has important consequences for the development of the site. Even if you have a solid answer for what the site is, and what content will be on the site, the audience for your site greatly affection how you present that content on the site. A teaching site on the history of the Spanish-American war may look and be organized differently if the primary audience is elementary or high school students instead of teachers. The language used on the site, the content for the site, and the design are all affected by the target audiences.

Needed technologies?

From the very beginning, before one line of code is written or one pixel moved in Photoshop, the team needs to decide what kinds of technologies will be needed for the website. Answers to this question depend on answers regarding what the site is about.

Do not have a “feature-centric” mindset when discussing options for a project. Think about what your want the site to accomplish, and then decide what technologies will best help and why they will help.

The development team specifically needs to help answer this question. Following Tom Watson’s advice, the project team should come together to discuss problems to solve, and what technologies will best solve those problems. You do not, for example, need to use a robust content management system like Drupal if your project consists of only a dozen static HTML pages.You do not need AJAX simply becuase other sites have AJAX; You do not need a blog because other sites have a blog. In other words, do not have a “feature-centric” mindset when discussing options for a project. Think about what your want the site to accomplish, and then decide what technologies will best help and why they will help. Have a reason for everything!

I would say that the development team needs to be the lead on answering this question. They will (or should) have the most experience with determining which technologies will solve specific problems. But its generally good to talk about the problems first, so the development team can decide on which techology solution will best solve those problems.

Timeframes?

All of the previous answers can be fantastic and full of possibility until you talk about the most important aspect of a project: time. Time can be a harsh master. It is a very a good idea to set deadlines and milestones, to keep the project moving forward and give everyone a sense of how long things will take and when they’ll be done. In some cases, work by each team member can continue simultaneously. In others, one team member must complete a requirement before another team member can start or finish her/his requirements.

In some cases, deadlines are set by grants: “We promised a fully-function site to collect public reflections by May 2009,” for example. Those absolutely should be met. Others can be a little more flexible, but not so flexible that the project never gets finished. Here’s a quick process for setting milestones and criteria:

1. Figure out what milestones are needed (content complete, CMS installed, wireframes completed, etc)
2. Set deadlines for each milestone, for specific phases of the project
3. Associate specific criteria for completing milestones by the deadline
4. If those requirements aren’t met, decide whether to move the deadline for the milestone up to allow for completing the criteria or to remove specific criteria as unnecessary.

In other words, deadlines should be stable enough to provide direction and purpose for the team, but flexible enough to account for unexpected contingencies. If you’ve reached the deadline for a milestone, but do not have all the criteria done for the milestone, consider whether those criteria are necessary to move on. Its OK to say that some criteria are, in the end, unnecessary to consider a milestone complete, and to move those criteria to other milestones and deadlines.

Having milestones, set criteria for meeting those milestones, and deadlines for milestones help keep the project on track, and prevent “feature-creep” or “scope-creep.” By this I mean the tendency for a project to take on new features or new scopes that were not set in the beginning of the process, and cause deadlines to be missed. Its fine to add new features, or change the scope of the project, so long as everyone on the team understands that the timeframe and deadlines may have to shift because of those new requirements.

Team Members

Everyone on the team should be introduced to each other, with a brief discussion of each person’s specific skills and responsibilities for the project. This not only helps build camaraderie, it also lets someone know who to contact for specific questions or issues. Having trouble finding or using the project logo? Ask the designer. Having a problem with a specific aspect of the CMS? Ask a developer. Not sure where the content is for a specific section? As a content lead or project manager.

Management Hubs

This is a lot of information to manage, a lot of tasks to track, and a lot of people to potentially know and talk to. You shouldn’t even try to manage it all on paper, or in your head. The project team needs a central location to go retrieve information about the project, manage tasks, and learn more about other phases of the project. In comes a management hub.

Screenshot of CHNM Basecamp page.

At CHNM, we use Basecamp, a service created and offered by 37 signals. We manage dozens of projects on our Basecamp account, with each project having a homepage, Messages, To-Dos, Milestones, Writeboards, and a place for file uploads. There is a list of everyone involved with the project, with roles and contact information. You can associate a specific to-do list to a milestone, and can thus determine if you can “complete” a milestone if you have completed all the tasks in the associated to-do list. You can assign to-dos to a specific person. We use Writeboards for meeting agendas, notes, and any other documentation we want to keep (styleguides, ideas, etc), and we tend to use the Messages feature more than email to send correspondence concerning a project, that way everyone has an archived copy of the message in Basecamp. As CHNM has grown, Basecamp has become indispensable for managing all our projects.

Alternatively, you could easily use a wiki to manage your projects in much the same way as Basecamp. Free wiki services abound on the web (PBWiki is great, for instance). While not as feature-rich as Basecamp, wikis can fulfill all the needs for project management, with a little work and devotion to organization. You could set up a PBWiki with the following pages:

• Homepage—The “dashboard” with the description of the project, the goals for a project, and list of team members with responsibilities. Links to other sections:Timeframe, To-Dos, and Notes.
• To-Dos—divided by person or aspect of a project, marked off as they’re completed.
• Notes—any meeting notes, archived discussions, or ideas you want to archive.
• Timeframe—a running list of milestones, with criteria listed for successful completion of each milestone.

In any case, the hubs should at least contain the following:

Description of the project

A paragraph or two stating what the purpose of the project is, what it encompasses, who its target audience is, and what the site will offer.

Goals for the project

A well-defined list of goals or deliverables for the successful completion of the project. This helps keep everyone on target, and ensures that any decisions made during the development of a project should only contribute to, and not add or detract from, the goals.

Project team members

I recommend devoting an entire page, or section on the main page, for listing team members, with their roles or list of primary responsibilities listed and contact information. Perhaps even a link to personal webpages or profiles.

Timeframe

Deadlines, criteria for completion of the project, and major milestones.

To-Do lists

Pretty straight-forward: lists of things that need to get done for a project. This can be divided by person, by team (design team, development team, content team) or by sections of the site. its helpful to have these in once place, so that everyone on the project has a sense of the amount of work everyone is facing. Good especially if someone asks for new features not part of the original description or goals for the project.

Meeting notes, various content pages, links as needed

Good to keep in one central location for all team members to contribute to and refer to throughout the project.

You should totally feel free to set up a wiki however you want, but you goals should be: keep everyone informed, archive project progress, and keep the scope of the project clear and visible.

All Alone?

If you’re your own project manager, have this meeting with yourself. Before you type one line of code or color one pixel in Photoshop, go through this process. Set up a project hub. Take meeting notes. Create a timetable. Make to-dos. Some of it may be meaningless (like list of team members), but it helps to formalize the development of a project. And, if you end up getting a grant or someone volunteers to help you with the project, you’ll easily be able to orient them and integrate them into the workflow for the project. If it helps, have someone else around to talk through ideas and get things down more concretely, or pretend you’re explaining the project to someone else.

What’s Next?

After doing all of this, either in one meeting or several, you should be set to move into the next phase of development: Information Architecture. I’ll cover this next week!

1. 1 See Kelly Goto and Emily Cotler, Web ReDesign 2.0: Workflow that Works, Berkeley, CA: Peachpit Press, 2005, 40.
2. 2 Jesse James Garrett, The Elements of User Experience: User-Centered Design for the Web, New York: AIGA and New Riders, 2003, 23.

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.