Designing a Digital History Course: Part 1

This spring I will be teaching a graduate seminar for American University’s history program titled History in the Digital Age. I have been thinking a lot about how I can get the practices of the course to model some of the emerging practices in digital history. As part of that process I have narrowed the course goals down to the list of 4 below.  In keeping with the spirit of collaboration and open communication I hope to make a core part of the course. I thought I would also blog the process of creating the syllabus to refine these ideas in public. I hope to generate some conversation here and use that to refine the course.

Course goals

After the course students will be able to:

  1. Independently discover, evaluate, and implement novel digital tools and resources to support traditional scholarship, public projects, teaching and scholarly communications.
  2. Develop proposals for digital history resources with detailed plans for  project management, design, outreach, and evaluation.
  3. Synthesize analysis of born digital and digitized materials, (datasets, algorithms, spreadsheets, maps, video games, web sites, social networks, text corpora, etc.) with existing approaches to analysis of traditional primary and secondary source material to develop novel historical narratives.
  4. Thoughtfully and purposefully engage in dialog about history on the public web with a range of stakeholders in digital history; historians, archivists, museum professionals, educators, and armatures, etc.

To get at the first goal I intend to have students demo tools to the class and make case for what a given tool, for example voyer, could do for research, teaching, outreach, etc. The second two goals are going to be covered by writing short proposals (one for a paper and one for a digital tool or resource) and then following through on one of those proposals. I am still working on the details of those assignments, which I will share later, but I am on my way to articulating the assignment that gets at the last goal, students participation in a public course blog.

Here is how I am framing this assignment:

The course blog: Engaging in online public discourse about digital history

We are not simply going to learn about digital history in this course, we are also going to do digital history. That means we need to engage with the public web. To this end part of our course communication is going to happen in a public course blog.

On the first day of class I will show you how to use the blog. You are expected to post a minimum of two times, once about one of the readings and once about one of the digital tools or resources. We will sign up for who writes about what on the first day of class. These are blog posts, and as such they should not written like term papers. Part of the goal of this assignment is to become familiar with the genera and format of discourse on thoughtful blogs.  You need to get in, say something interesting, and get out. Ideally telling us what the thing is, why it is, what is particularly interesting here, and ending with an invitation to discussion. You should think of your posts as mixing the features of a well composed academic book review and the well conceived blog post (Do read those links). Posts for a given week must be on the web the Sunday before class (yes, if you want you can post it at 11:59 on Sunday).

Do not assume your reader has detailed knowledge of the thing you are writing about. One of the goals of the blog is to invite interested third parties into a conversation with our course. If we are doing this right you can expect comments and dialog with historians, humanists, librarians, archivists, curators, and bloggers who are not participating in the course as students but who are participating in the public conversation we initiate through the blog.

First decision: Your identity and the blog

This is public so one of our first considerations is going to be personal identity. While this is a practical matter it is also, very directly, part of the subject matter of the course. I would encourage you to blog with your real name, it is a good idea for you to start building a web presence for yourself. It has even been suggested that in this field you can either “be online or be irrelevant.”  With that said, if there is any reason that you are uncomfortable with sharing your name publicly, you should feel free to use a pseudonym.  If there is a reason that you do not want to share your work on the web please send me an email or meet with me after class. I feel that this public dialog is an important course goal, but I will of course understand and accommodate anyone that needs a different arrangement. If at the end of the course you would like to continue blogging I will be happy to show you how we can pull all your posts out and into a new blog of your own. We will talk about this identity decision on the first class day.

Keep the conversation going

Posting is not the end of the assignment. After posting you need to foster the discussion you are initiating. When people comment you need to give substantive responses. Try to engage everyone who comments in some fashion and try to use the comments to sustain a conversation you began at the end of your post.

Commenting is also an assignment

Beyond posting you are expected to contribute substantive comments to a minimum of six of your peers posts. Your comments should extend and contribute to the conversation. Good comments are an a important format unto themselves. Read profhacker’s guidelines for comments for a sense of the kind of comment ecosystem we are trying to produce here and then read how to write a great blog comment for some suggestions on the format for comments. Comment early so that others have a chance to read them (your comments need to be up before midnight on Monday).

The course blog is the required reading we write ourselves

Beyond posting and commenting everyone needs to read everything on the blog before class each week. This is the part of the course readings that we write ourselves and in all honesty this is the most important springboard for our in-class discussions.

Review of linked readings:

David Parry. 2010. Be Online or Be Irrelevant – academhack – Thoughts on Emerging Media and Higher Education. academhack. January 11.

Grammar Girl. 2009. How to Write a Great Blog Comment. March 20.

Patel, Neil. 2009. How To Write A Blog Post. July 21.

Profhacker People. n.d. About ProfHacker – Commenting and Community Guidelines.

Scheinfeldt, Tom. 2009. Brand Name Scholar. Found History. February 26.

Schrag, Zachary. 2003. How to Write a Review. September.

LMGTFY, Shame, and Collective Intelligence

Let me Google that for you (lmgtfy) is a snarky way to respond to someone asking an obvious question. It was created “for all those people that find it more convenient to bother you with their question rather than google it for themselves.” Lmgtfy has become a relatively popular way to respond in any number of web forums, but more broadly, I think it speaks to the kind of literacy that search is beginning to represent.

To break this down a little bit, when someone responds to your post asking how to pivot tables in excel, or how to tie a bow hitch on a web forum by posting a link to lmgtfy you are being told that the question you asked does not require a human to answer it. It has already been answered on the Internet and with a very simple search query, as demonstrated here, you could have found that answer. At the core of the idea of lmgtfy is the notion that a savoy digital citizen should be able to make specific assumptions about the kind of knowledge the web puts at their fingertips. Lmgtfu is supposed to be a shaming experience, and the possibility of that shame is predicated on a kind of literacy of collective intelligence.

Collective What?
Collective intelligence is a mushy term, in this case I am referring to Pierre Lévy’s notion. In Collective Intelligence (1997) Lévy proposed a vision for the kinds of changes the internet could generate in culture. Lévy suggested that in online culture “The distinctions between authors and readers, producers and spectators, creators and interpreters will blend to form a reading-writing continuum, which will extend from machine and network designers to the ultimate recipient each helping to sustain the activity of others.” (p.121) I think the shame lmgtfy is intended to evoke demonstrates a limited form of this collective intelligence.

Now lets be clear, while proponents of the idea of collective or distributed intelligence and cognition are often accused of proposing some magic brain in the sky that’s not what I’m referring to. Instead, the idea is that parts of the thinking process are always mediated by tools, pen and paper, print media, computer, or mobile device, each is embedded in the cognitive process of individual agents.

On one level, this is rather obvious. Many are advocating that search and google mean that trivia and facts are less important than the ability to find and interpret information. The point I am focusing on here is that there are few key elements involved relating to thinking like a search engine and generalizing from your experience to understand if the specific question is something the Internet should know.

Thinking like Google and Thinking like the Crowd
Who was president in 1832? What’s the best way to steam carrots? How does !important works in css?  Which iPhone 4 case is best? Where can I find some good Indian food in Fairfax, VA? All of these questions have relatively straight forward online answers available. In each case, we have developed a sense of specific, limited, notions of collective intelligence and our internal representation of the kind of information that should be out there to help make a given decision. The successful individual searcher has internalized a representation, a map, of both the way a database organizes information (search terms, where google maps data comes from, etc) as well as what kind of people would share that information (the kinds of folks that review restaurants on Yelp, the extent to which a given problem would be shared, the biases of reviewers of bargain hunters on a given do-it-yourself home improvement forum). Effectively, information literacy is developing this model. In essence this is about knowing three things.

  1. Knowing what kinds of knowledge should be out there on the web. (This is a assumption about the generality of your problem and the nature of information that is put online)
  2. Knowing what kind of search query will get you there. (This is about understanding a bit about how search works, knowing what kind of keywords will get you where you need to go)
  3. Knowing what the limitations of that kind of information are both in terms of kinds of questions one can ask and the biases of the sources one encounters. (This is the interpretive part, and it is once again about your theory for why someone would post this information online)

At the core, each of these are about developing 1) a sense of how computers, and more specifically databases and search engines, structure and organize information and 2) a sense for the kind of people that share specific information in a given context.

Knowing online is internalizing  the machine that is us/ing us
The two points, internalizing a sense of how a computer searches and internalizing a sense of what things people should have shared online to be searched is effectively internalizing a working model of the internet and it’s users in your mind. It is not that the internet is itself an intelligence, but instead that we are constantly updating our mental model of the web and its users through our own search experiences.

The following example of interpreting ratings on Yelp offers a furhter demonstration of how I am thinking of this and also offers a place to consider the idea of general notions of competence and their relationship to individual sites.

Site Specificity and Domain Generality of Collective Intelligence Heuristics
Like all knowledge domains there are idiosyncrasies of competence that are narrow and specific which are nested within broader notions of competence. For example, try this word problem on any Yelper. You want a sandwich, your Yelp search pulls up a restaurant with 4 stars and a restaurant with 5 stars. Which is the better restaurant? Answer: Insufficient information, I need to know how many total reviews there are for each establishment. In short, if the 5 star restaurant has that rating as the result of 3 reviewers and the 4 star restaurant has its score as the result of 124 reviewers it is likely that the 4 star restaurant is well established, and hey, your a Yelper, you know that for every 10 reviewers out there who give a great restaurant 5 stars there will always be a few snarks out there that feel like they can only give a 5 star review once every six months. Now, even if you are not a Yelper, but you are familiar with how reviews work on Amazon, you might have come to the same set of conclusions. In all likelihood the Yelper would have a better sense of how to read individual reviews, and reviewers profiles, in the process of making restaurant decisions. However, the individual with experience with Amazon’s similar system of reviews would transfers and translates that experience into a more general competence about interpreting online ratings and reviews.

Going to the Library of Congress

For just about the last four years I have had the distinct pleasure to work on Zotero and a range of other projects at the Center for History and New Media. It has been an amazing experience and opportunity, and I am grateful to CHNM’s senior staff for all the opportunities they have provided me to hone my skills related to this thing we now call the digital humanities. My time at the Center has shaped the way I think about software and scholarship.

I am very excited to bring this experience into my new position as an information technology specialist with the National Digital Information Infrastructure and Preservation Program (NDIIP) in the Office of Strategic Initiatives at the Library of Congress. I will be specifically working with the technical architecture team. I have been following NDIIP for a while, and not only are they working an array of important and fascinating projects, but everyone I have met who is associated with the program is fantastic.

I am still going to be around George Mason University. Over the years at CHNM I have been thrilled to have the opportunity to collaborate with so many of the folks in the History and Art History program, both through projects at CHNM and through my coursework in the MA program. While I won’t be on campus every day, I will still be around once a week for courses as I continue to work on my doctoral studies in the College of Education and Human Development.

I have a few weeks before I start my new position, and I find I have to pinch myself every once and a while. Growing up just outside of Milwaukee, I never imagined that I could end up working at a place like the Library of Congress. I couldn’t be more excited about the future.

New Omeka Zotero Plugin, or “penut butter in my chocolate”

You know those reese’s commercials where two people crash into each other on a street corner. One eating a chocolate bar and the other gulping down handfuls of peanut butter right out of the jar. They collide and mix the peanut butter and chocolate together, and then realize how fantastic the combination is. Well the open source scholarly software equivalent of that happened today. Thanks to Jim Safley for the launch of the new Zotero Import Plugin for Omeka. He did a great job of explaining it on the omeka blog, but I wanted to take a few moments to explain why getting some Omeka on your Zotero and some Zotero in your Omeka is such a neat thing.

Zotero Just Became a Publishing Platform
There are a lot of scholars with tons of interesting materials inside their Zotero libraries. For example, I have 120 tifs of postcards from my book on fairfax county inside my Zotero library. Zotero’s website has become a great platform for sharing and collaborating with folks to build out those collections, but it’s not really a platform for publishing them. Further, it is definitely not a platform for showcasing the often fascinating image, audio and video files associated with those items. By instaling this plugin on an Omeka site and pointing it at the collection you want to publish you can quickly migrate the content. You can then play with and customize an Omeka theme  and push out a great looking extensible online exhibit.

Omeka Just Got A Tool For Restricting And Structuring Data Entry
On the other side, folks interested in building an Omeka archive just got a very potent way to manage building their collections. One of Omeka’s strengths is its highly flexible data model. It’s ability to let you create item types and manage data schemas is fantastic. With that said, there are times when you actually don’t want all of that flexibility. It can be a bit overwhelming, particularly when you have a large group of people trying to do data entry and add files. Now, if Zotero’s default item types work for your archive you can simply have anyone who is going to add to the archive install Zotero and join your group. In this capacity, Zotero becomes a drag-and-drop UI for adding items and files to an Omeka exhibit. Once everything is in you can simply import all the info into your Omeka exhibit.

Outreach and Scholarly Software

A few months ago I had the distinct pleasure of sharing some of my experiences and thoughts on outreach and community building for scholarly software projects with the One Week One Tool team as part of the first two days of the summer institute. I was excited at the prospect of sharing my experience, but intimidated by the fact that so many of the participants had already done a considerable amount of work in this field. I like to think our outreach conversation went well!

With a little bit of time distancing myself from the actual event I thought I would work through some of the ideas I put forward to the group. My goal here is twofold, first I would like to share some of our discussion of software and community with folks who were not a part of the event and second I would be interested to hear from the participants about how my ideas did or didn’t resonate with the work they engaged in on anthologize. So below you will find 5 principles and 5 roles I see as critical to scholarly software outreach. I don’t by any means claim to have invented anything here, just trying to share my thoughts on practices. If you’re interested in a more extensive run down of the project I would suggest Tom’s interim report.

Trevor’s 5 Outreach Principles

  1. Outreach sounds like it starts at the end, but it should be a bit more ever present. It starts with a conception of audiences. Who are the end users? Who can I get to promote this to those end users? Make this part of your upfront planing process.
  2. Understand outreach as a value proposition for your end users. The more time and energy it takes to get your tool to do whatever it is supposed to do the better it’s payoff should be. Your competing for the end users attention and time. Those are scarce resources. Your tool’s site should establish the problem the tool solves and why this is a great way to solve that problem in as concise a way as possible.
  3. If possible, leverage existing communities. At this point, whatever you are trying to work on has already been worked on. Are there some interesting open standards that have some solid work behind them? Are there some abandoned tools who’s users you could pick up? If you can offer a clear value proposition to an existing group you don’t need to start from scratch.
  4. Spending time convincing people who convince people to use your tool can be far more effective than spending time convincing people to user your tool. This has always been the strategy on Zotero. The most effective parts of our outreach have been developing workshops to train folks to use the tool. There is a value proposition here too. If a tool really makes it, being able to teach someone how to use useful software is a credential.
  5. Look more reputable. People are scared that software will eat their data. Aside from making sure that doesn’t happen, you should try your hardest to make people feel like you are going to stick around for a while. This means that the design of your site matters. Things that look slick, that have active news feeds, that identify who funded them and what the plan for the future is are going to make folks more comfortable. Having a solid reputation is a great goal, but you need to start somewhere, you might even consider connecting the project with things people trust.

Trevor’s Five Components of Outreach

I like to think about outreach as building and engaging with existing communities of software users, evangelists, and potential code contributors. In this view outreach involves at least five very different roles/tasks. Other folks might cut these up and organize them differently, in a big project there could be a range of folks taking on these roles, in a small project they might all fall to the same person.

  1. Usability: If people are going to use the software you need to get a sense of how folks understand it. In my experience, starting with something like user personas in the initial design phases and pushing out functional software for public use and testing is great. In other cases it might make sense to do much more extensive testing.
  2. Marketing and publicity: This part is what a lot of folks think of as core outreach activity. Spreading the word about your tool, trying to get it mentioned in the right places, giving talks at the kinds of meetings and conferences your potential users go to, getting coverage of your tool in the kinds of publications your potential users read. This is great stuff, you can’t ignore it. On the most basic level its about crafting a message and getting it out there through a blog or news section. If you pitch your story right you could get picked up by some real big deal blogs and generate some traffic to your tool.
  3. User Guides and Documentation: After taking a quick look at your homepage the next stop for a lot of users is going to be your documentation. I think one of the biggest problems I see in different projects is that folks think of documentation as technical information and not as part of their outreach efforts. No matter how much you invest in getting people to visit your site, how much you put into getting an attractive homepage, it can all be for naught if you don’t make it as easy as possible for people to figure out how to do what they want to do with your too. The key point here is that documentation is not about describing what the software does it is about telling people how they can do what they want to do with your tool. While you might think the homepage of your site is the front, remember that web search means any page could be the first page someone sees.
  4. User Advocacy: Once a project has users it also has people outside of the development team that want the tool to do something. Now, a lot of tools don’t ever get here, but when they do it is critical to try to role their interests and voice into the project. If you want users to stay around and become advocates you need to need to have someone advocating for their needs.
  5. Sustainability: It’s a great word, and in the world of grant funded work it is, for good reason, THE big idea. If anyone is going to fund your project they want to know that they are not signing up to provide you with funding till the end of time. It is easy to gesture toward a user community as part of a sustainability plan, but it is much more difficult to turn people into users, users into promoters and coders, and those folks into a network that ultimately ensures a sustainable future for a tool.

So what do you think? Is this a reasonable way to think about outreach and scholarly software? Are there things missing from the picture? Are there things in here that you think shouldn’t be viewed as part of Outreach? For folks who participated in the One Week event, how did or didn’t these ideas come into play with Anthologize?

Works that shaped my ideas on users, software and community
  1. Brown, D. (2006). Communicating Design: Developing Web Site Documentation for Design and Planning. New Riders Press.
  2. Garrett, J. J. (2002). The Elements of User Experience: User-Centered Design for the Web. Peachpit Press.
  3. Jin, L., Robey, D., & Boudreau, M. C. (2007). Beyond Development: A Research Agenda for Investigating Open Source Software User Communities. Information Resources Management Journal, 20(1), 68-80.
  4. Krishnamurthy, S. (2005). Launching of Mozilla Firefox – A Case Study in Community-Led Marketing. URL