The mix of emotions I’ve had making this decision was almost overwhelming. I’ve been at CHNM since the Fall of 2003, and since that time have done more things as a graduate student than I could have ever imagined. George Mason University was the only school I applied to, and I was ridiculously lucky enough to not only get in, but also get an assistantship at CHNM. Once I got here, each year was better than the next last! I honestly didn’t quite know or appreciate how much attending Mason and working at CHNM has changed my life until I decided to leave for someplace else. I’m incredibly sad to leave CHNM, the place where I practically learned everything I know about digital humanities. But, one great thing about this move is that I’ll get to keep doing the work I love, with people I’m fortunate enough to call friends and colleagues. I’ll still contribute to Omeka, thanks to the partnership CHNM and  Scholars’ Lab already have thanks to a Library of Congress initiative. And, I’ll still try to help out with THATCamp as much as possible.

But, if there is one other place in the world I’d like to work other than CHNM, it would be Scholars’ Lab. I’ve been a fanboy of theirs for a while now, and have had some great opportunities to collaborate with them over the past few years. Their approaches to research, teaching, and service are exactly in tune with how I want to spend my career. Plus, being a country boy at heart, the lure of the Shenandoah is too strong to resist. I am very excited and honored to join Scholars’ Lab, and am looking forward to all the challenges and opportunities this move will bring!

Speaking of experiments, there’s our comments section. Everybody knows inline blog comments are going the way of the BBS and Gopher sites of yore. We’re not ready to say “comments are dead” (we’ll leave that for Wired Magazine’s next cover story) but we have noticed the smell, and we’re doing something about it.

Kids today are more likely to respond to a blog post on Twitter than in the article’s comments section; so we’ve collocated our comments on Twitter. Share a tweet-length response here, and, with your permission, it will go there. If you are moved to respond with more than 140 characters, post the response on your website, and it will show up here. Clever, these Americans.

So, comments are done either via Twitter or through your own blog. Want to comment through Twitter? Compose your tweet on the Cognition post’s page and submit. Want to submit one of your own blog posts as a comment? Go write and publish that post, then come back to the Cognition post’s page and submit your post’s URL.

I have to say, I really like the idea of putting a textarea on the post page so readers can tweet a message. After reading the article, I can tweet a comment immediately, and send it to my Twitter feed, without having to go to Twitter.com, or open TweetDeck, or copy/paste the URL. But looking at the very first post on Cognition, there are over 350 responses, and a cursory glance over all of them indicates they’re all from Twitter. It is a first post, and a pretty big announcement, so this is probably expected. But I agree a lot with Jeff Croft, who in a comment on Airbag argued that this approach possibly adds unnecessary noise to Twitter (already pretty noisy). Croft suggests (and I agree) the tweeted comment should be an @reply (to @happycog perhaps, since @cognition is taken by someone else!) so only your followers who are following that Twitter account see the post. There’s a question of audience here: By posting comments through Twitter, my comment is sent to all my followers. Which raises a question about who I should write the comment for, Cognition’s post author, or my twitter followers?

I also like the idea of providing a spot to input a specific URL to a blog posts I’ve written as a response. It’s a little more deliberate than relying on a linkback system. There only seem to be a handful of these kinds of comments on Cognition’s first post, however, and those do get lost in all the other Twitter comments. I would value these comments much more, since they supposedly took a bit more time and effort to compose, and this is where I think good, meaningful, productive conversation and feedback would take place.

Of course, it seems both of these solutions have been, or can be, implemented on your blog now. There are several plugins for WordPress, for example, to collect “tweetbacks” to your blog posts. And much more established is the concept of linkbacks from one blog post to another. It seems the major difference between these solutions and the implementation on Cognition is that the reader explicitly has to write her/his tweet or add his/her post link through Cognition’s site.

One major problem I see with comments on Congnition, in either tweet or blog form, is the complete lack of a permalink back to the original tweet or blog post. Links to a comment author’s website have become pretty standard in commenting systems. Plus, comments have served to build community and readership. There is almost a gift culture with blog commenting, where regularly commenting on a blog encourages the blog author and other blog readers to check out your own site, and comment on your posts as well. Having no permalinks back to tweets or comment posts effectively negates this culture. Not sure if this is a feature or a bug, but I’m curious to know!

My comments are a sloppy mess, and I am inspired by Cognition’s approach to rethink commenting here, and to reconsider how I comment elsewhere. I’m definitely curious to see how their experiment evolves, and I hope it does evolve, because I think there are plenty of opportunities to improve. The folks at Happy Cog have been very receptive to praise and criticism of their commenting solution, so it’ll be fun to watch.

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.

So, let’s do it already.

Where should we start? Let’s try this first: If you’re going to an annual conference, try to organize an unconference yourself, either with support of the organization, or on your own off-site. Just do it. Tweet it. Blog it. Find a spot that has some rooms, whiteboards, and wifi. Check the local library or university and see if you can reserve some space. Or find a bar or restaurant with wifi that can reserve some space. Add your unconference to the Barcamp site, or make your own site, and post about the event on Twitter. Unconferences don’t have to be expensive; In fact, they should be as cheap as possible. The  most important thing is providing space for attendees to collaborate, discuss ideas, and turn those ideas into future projects. (Wifi would be nice, too!) If you can do that, you’re most of the way there. If this isn’t a conference hack, I don’t know what is.  Get the word out, see if there are interested people, and give it a try! If you can get support from conference organizers, even better! It doesn’t have to be associated with the conference itself (which may preclude you from using the conference venue as space), but it can involve folks attending the conference.

In fact, I’ll go so far as to say this: If it is within my power, I will make sure to host or help with some kind of unconference event at every academic conference I attend. I don’t know how often I’ll be successful, but I’m going to try it. The worst that can happen, it seems to me, is that the event doesn’t occur. The best that can happen is that we get an opportunity to share and discuss our work in ways ill-afforded by the reading-a-paper-at-you format. We’ll get to open our laptops, share our notes, and scribble on a whiteboard/chalkboard/napkin and come up with things to take with us and do after the conference.

We can also begin proposing unconference-like sessions or workshops during conferences themselves. This has already begun with much success; We held a session at the 2010 American Historical Association annual meeting on “Humanities in the Digital Age”, which incorporated aspects of the unconference format that was well-attended. Much broader in scope, the Digital Jumpstart project has been widely attended at several academic conferences, with more meetings in the works. With Digital Jumpstart, the goal is to bring humanists together to give their digital projects a boost, to hear about others’ issues or solutions, and even to find collaborators.

After some success with a few unconference-like sessions, we could then begin petitioning organizations to give even further support. The conference could devote an entire day to an unconference, limit it to the first 100 people that sign up, and have a coordinator to oversee the unconference. But it should mainly be user-generated as much as possible. Like THATCamp, conference attendees could propose session ideas ahead of time for the unconference day. The organization could set up a voting system, similar to Code4Lib and SXSW, where attendees voted for sessions to be included in the program. The ones with the most votes would get on the unconference program.

With the latter scenario, two of the most common arguments against academic unconferences—lack of funding for such events and lack of prestige or credit for the event—can be addressed. You would be proposing to lead a session, and it would be accepted through a potentially more competitive process that tradition academic papers. The session’s acceptance, number of votes, and eventual number of attendees could certainly contribute to academic credit in some form. And, since it would be an official part of the academic organization’s program, you should be able to receive travel funding for it as much as if you were doing a workshop or reading a paper.

A third argument against academic unconferences usually involves some form of the question: “What is actually produced because of an unconference?” And the hard thing about answering this is, all the productive, useful stuff that is produced isn’t always tangible until a while after the conference. Participants at THATCamp have forumlated projects (and have found collaborators) during the event, including web-based resources, research articles, other conference sessions or events, and course ideas. Some sessions themselves either try to produce something during their allotted time, or make plans to continue working to produce something after the event. With that in mind, and to address the skeptics’ question, here are few things actually produced from THATCamp:

• ProfHacker – The awesome blog about how academics can improve their workflow and talk about teaching and research techniques, now hosted at the Chronicle of Higher Education.
• Zoterofest – A one-day unconference/workshop at the University of Mary Washington, conceived by Jeff McClurken.
• Digital Jumpstart – Unconference-like workshop run by Sharon Leon and Sheila Brennan, whose goals are to help digital humanities project get off the ground.
• Ethical Hacking in the Humanities a group-edited syllabus on ethics in hacking for digital humanities, a session proposed by John M. Jones at THATCamp.

The broader thing to keep in mind is that sometimes things are actually produced during the sessions, sometimes afterwards, sometimes not at all. And in my experience, these results depend less on the unconference format itself, and depend more on the actual people leading and contributing to the session, and the unconference as a whole. With most academic conferences, you’re expect to come with fully baked soufflés, and if you don’t (or its a flop) then you face criticism. There isn’t a lot of space for intellectual playfullness and experimentation in most academic conferences, but unconferences provide those kind of outlets; In fact, they thrive on them. And that to me is what conferences should be all about.

Many have loathed the rigidity, formality, and expense of traditional academic conferences. In contrast, unconferences thrive on flexibility, collegiality, and thrift. More to the point, they rely heavily on the attendees themselves—their attitudes, motivations, and work ethics—for success or failure. At unconferences, it generally doesn’t matter who says something first; What matters more is who says something thoughtful, and what that thoughtful thing is. Discovery happens through group cooperation. Insight and knowledge are not guarded for the next publication; They’re shared openly, with hopes that others can contribute to ongoing conversations that make our work better.

And this really gets to the heart of the issue: Why do we attend conferences, and why do we contribute to them? Ideally, we give conference papers in hopes of sharing our research, getting recognition for such research, and getting critical feedback to take that research conference paper’s mere presence on the conference program grants it weight on CVs and tenure reviews, even if only half a dozen people actually came to the session to hear it read. What if instead we start fostering systems that reward you if your unconference session spawns half a dozen projects from attendees. The focus in this case is not on what you produce yourself, but what you help others produce.

Academic conferences as they are now are increasingly expensive, poorly attended (not necessarily in terms of registrations, but it terms of people actually attending sessions), and rarely seem to generate the kind of innovative work needed to meet the challenges of education and scholarship today. If we want to start hacking the academy, lets start hacking this cornerstone of academic culture by incorporating unconferences.  We should start small, test some things out, makes changes when necessary. But we should start, if for no other reason than to make the work we and our colleagues do better, and to make our experiences at conferences richer and more productive.

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.

The Assignment

The assignment consists of two phases, each graded separately:

Phase 1: Students choose a topic related to history that either doesn’t have a substantial article already written about it, or a topic that is listed on the history stubs page on Wikipedia. Then, they research the topic and contribute ~500 words to the article. The article must include footnotes, and reference at least two published books, two external websites, and link to at least two other Wikipedia pages. Students must use proper formatting for footnotes, headings, lists, links and other content per Wikipedia formatting guidelines. They must also create a user account, and log in with that user account when editing. If an article’s history doesn’t include the user name they sent to me at the beginning of the semester, they don’t get credit. No exceptions.

Phase 2: After publishing, students must watch the article, see if anyone contributes or changes their article, and if so connect with these users. The goal here is to improve the article, either with others users or individually. If their article is flagged for deletion, students must work to make sure the article isn’t deleted. But, regardless of outcome, students must write a ~500 word reflection on what happened to their article, and how their ideas about Wikipedia had changed as a result of the article.

Notes on Process

Topics

Choosing a topic is fairly straight-forward. I always encourage students to find a topic that interests them, that’s relevant to their major, their job, or even hobbies. Students have written about various historical topics related to psychology, sociology, engineering, sports, art, and theater, to name a few. If students can’t come up with a topic, point them to the stubs page. There are thousands of stub articles to choose from, including United States history, history of science, and military history. All topics have to be approved by me before continuing the assignment. I usually require topics related to U.S. history because that’s my primary field of study, and will approve topics if I think there’s enough secondary and tertiary sources available to allow for an adequate article.

Research

The research process is, more or less, the same kind of research process you’d expect when assigning a short term paper. We discuss how to find resources on particular topics, how to brainstorm, create outlines, et cetera. I introduce students to the librarian on staff who’s relevant to their field of study or topic. (Often, this is the first time students are introduced to these very valuable folks.) Wikipedia also has policies about citation, so I make sure students read the policy on citing sources and verifiability. Additionally, I discuss uses of different kinds of sources, and Wikipedia’s preference for secondary and tertiary sources over primary sources. Students articles must not be original research.

Writing and Formatting

Probably the trickiest part of the assignment is showing students how to write for Wikipedia, particularly the way Wikipedia articles are formatted. We take one class period and review “How to Edit a Wikipedia Article,” particularly the formatting section. There’s a great tutorial and sandbox where students can practice formatting before working on their articles. I demonstrate on-screen how to do different kinds of formatting: footnotes, headings, unordred lists, ordered lists, internal and external links, and inserting an image. There is a useful cheatsheet that details formatting methods for specific content elements.

Publishing and Participating

Like I said earlier, the assignment doesn’t end once the article is published. After they publish the article, they must watch and participate in any change that takes place to their article, for good or ill. I show them specifically two sections of their article to watch:

• History page – I encourage students not to revert things immediately, but to take the time to look at changes, determine if they help or hurt the article, and take the appropriate action.
• Talk page – This is where community members talk about the article in question, offering suggestions for improvement or declaring reasons that the article is irrelevant and show be deleted. Its here that students have to defend their articles, or learn from other Wikipedians about how to improve their articles.

Not infrequently, someone’s article will be recommended for deletion, or their changes reverted. In these cases I show students how to interact with Wikipedia admins, review their deletion policy and the process by which they do deletion review. I’ve had several students’ articles get recommended for deletion, and the students justified their articles well enough to save them.

Why Assign a Wikipedia Article?

I have several reasons why I ask students to write an article for Wikipedia:

• Learn how to do research: A no-brainer here. The assignment involves some basic research and writing skills, a modest but substantial amount for a 100-level survey course.
• Demystify Wikipedia: Most people have preconceptions about Wikipedia, but very little experience actually reading AND writing an Wikipedia article. Fewer people have experience communicating with other Wikipedia users, particularly admins and editors. This, in turn, influences how they interact with others on various social sites and services. Moreover, students learn that not just anything can be published on Wikipedia, there are rules and policies in place for the content that gets to stay on Wikipedia.
• Learn the difference between fact-only writing and analytical writing: Most of my students have a difficult time understanding how to make an argument, how to differentiate between fact-based “reporting” and analysis. By actually being forced to write a “just the facts” report, they have been able to see the difference between the two.

As I said earlier, this assignment is consistently one of my most successful assignments. Students find a topic they’re interested in, research it, learn how to write for different audiences, learn how to use Wikipedia more efficiently, and understand when its good to use Wikipedia and when its not. Furthermore, they get experience with community and collaborative writing, and can take those skills with them and use them long after the course is finished. It does take a bit of work on my part, to make sure students understand the assignment and the technology involved, but in my opinion its completely worth the effort. Its certainly much more meaningful to have students contribute to a larger, more public body of knowledge than to write a term paper for me that will get thrown away at the end of the semester. If this assignment can produce some good articles on Wikipedia, and gets students talking to others and learning outside of class, I consider it a success.

1. Make sure students graduate as skilled, thoughtful consumers and producers of digital media

Several smaller goals fit into this:

• Learn how to search – Read Bill Turkel’s blog. If you’re not convinced search is important, READ IT AGAIN. There is more to search than Google, and learning how various searches work—and, more importantly, how to make search for work you—is an incredibly valuable skillset beyond college.
• Learn how to manage information flow – For better or for worse, the information age is in overdrive, and all is in flux (thanks again, Bill). But there are tools and services to help you manage that flow, and it should be one of the goals of any university to help students learn how to manage that information. If we want to encourage students to expand their learning beyond the classroom (and I really think we should), then universities need to prepare students for managing the mass of information that comes with it.
• Learn how to produce meaningful, well-composed content and share it with others – Rob Wall argues that, in the 21st century, “creativity is the new technology.” Its incredible to think of the various ways people can produce and share content for equally various purposes. Anyone with an internet connection can sign up for a weblog right now, and begin producing and sharing content, right now. Anyone with an internet connection can produce and share data visualizations. Anyone with a computer and webcam can record and share video. Anyone who can search the web can find audio content, and create a podcast with it. With all of this opportunity for new ways to create narrative and share ideas comes a real need for universities to teach students new ways to compose those narratives and share those ideas.
• Learn how to critique content and methodology – Along with providing the ability to produce content in a variety of media, universities must provide the tools and skills to help students critique content, and discern the effectiveness and usefulness of particular technologies and media. One of the tenants of Mason’s PhD in History and New Media program is “critical optimism”. So, while we are optimistic about the changes that new media can bring to the practice of history, we’re critical about the specific methods that particular media employ. This is an approach that, I think, is already common in most classrooms. In my history course, I teach students how to critically read primary and secondary sources, and how to discern other methodological approaches to a particular issue. These skills are equally important—if not more important—when using and producing digital media.

2. Use free, open-source, and/or extensible tools whenever possible, and encourage faculty, staff, and students to do the same.

Universities spend countless millions on closed, proprietary systems like Blackboard and WebCT, systems that are very overbearing in their pedagogical approaches. In contrast, signing up for a weblog like WordPress is free (and there are plenty of other free options), and the uses for blogs in classes are limitless. While a little more difficult for the average instructor, Moodle is a free, open-source alternative to other learning management systems, and boasts a significant developer community contributing plugins and modules for extended functionality. There’s more this, though, than learning management systems: web browsers, word processing, screencasting, image editing, audio/video editing, to name a few. The specific tool, of course, should be chosen based on need and goals, but opting for extensible, open-source, and free alternatives will save universities money, provide more flexibility to instructors, and encourage the university community to do with software what it already tries to do with teaching and research: Contribute knowledge and resources back to the world.

3. Foster academic use of technologies that breaks down boundaries of the classroom, and the university as a whole.

As academic departments face budget cuts and lose staff positions if their enrollments are down, this may be the most difficult, but I think the most potentially beneficial, of all the goals. At the American Historical Association’s annual meeting in January, I presented on how I use technology to break down barriers to learning in my courses. Mills Kelly has written extensively on the future of the course, and argues that positive change in learning on university campuses will happen when students take individual responsibility for their own learning. Mills is particularly keen on the ideas of an iTunes-like class, where students can choose specific bits and pieces in a course that interests them. Others have spoken of the networked learner, and of learning environments that are not isolated from the rest of the world, but rather expand through a bottom-up approach. While I really like the potential for learning in a world without walls, I think there are some uses for the “artificial community” that is the classroom; Namely, that courses bring together people who would otherwise not talk to each other, and potentially allow for more diversity in perspectives. Learning based purely on social networking brings with it the danger of learning only inside the enclaves we create for ourselves based solely on who/what we like or who/what we’re comfortable with. But I think a balance can be struck, and I think universities should employ academic technologies to find and encourage that balance between classroom and independent learning.

So, there are at least three goals I think academic institutions should try to achieve regarding academic technology. Its certain good food for thought, and I’ll continue thinking about these goals for my own teaching and research. I imagine, though, that there are plenty more goals to add. So, lets help Jeff out. What would your academic technology goals be?

Frontiers in Digital History
The American Association for History and Computing (AAHC)
2009 Annual Conference
April 3–5, 2009
George Mason University

What frontiers in digital history are we only beginning to explore, or have yet to explore? What promising but under-utilized tools, techniques, and ideas exist in digital media that can help us do better history? Join the American Association for History and Computing for a lively discussion about the frontiers in doing history with digital media. This conference will be of interest to anyone charting new territory in digital history—both online and in the academic and public worlds—including museum professionals, archivists, librarians, historic preservationists, IT professionals, filmmakers, and academic historians.

Suggested topics for proposals include (but are not limited to):

* Museums and exhibits
* GIS
* Aggregating history
* Web 2.0 exhibits and archives
* Designing and developing digital history
* Teaching digital history
* Visualizing the past
* Networked Research

The conference committee encourages participants to go beyond theory and into the realm of practice through a variety of presentation formats, including:

* Project Demonstrations and prototypes
* Paper Presentations
* Roundtable Discussions
* Workshops

All presenters must be current members of the AAHC. Proposals for complete panels should include a chair. All proposals must include a 200-word abstract for each paper, along with a brief vita for each participant. Please be sure to indicate which member of the panel will serve as the contact person for future correspondence. Please include name, address, telephone number, and email address for each participant.

The deadline for proposal submissions has been extended to March 2, 2009. Send proposals (plain text, Word, RTF, or PDF) or inquiries to either:

Jeremy Boggs
Email: jeremy@clioweb.org

Or

Jillian Hinegardner
Email: jhinegardner@ursuline.edu

If you have questions, or are interested in participating, send me or Jillian an email. Hope we see you in April!

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.