Month: May 2011

Posted on

Digital History: The Course That Never Ends

This is the third post in a multi-post series reflecting on the digital history course I taught this Semester at American University. For more on this you can read initial post about the course, the course syllabus, my first post in the series on the value of a group public blog and the second post on how technical to get in a digital history course.

92 blog posts,

195 comments,

20 projects.

This is the digital foot print of my digital history seminar.

I think we learned a lot this semester. My students reviewed and used a range of digital tools and engaged deeply with analyzing and interpreting a range of digital media. This was my first course. When I designed it I did what came naturally. I set up a public course blog. That blog served as our common place to publicly think aloud and work together. It served a valuable role in the face-to-face class. But I think it is going to serve an even more valuable role in the future.

Knowledge Base: Rethinking a course as knowledge production

I am not taking down the site. Like everything, there are varying degrees of quality to the content of the posts and the discussions, but there are some real jems in the posts. Tom Kenning’s reaction to YouTube time machine and the subsequent discussion is not only one of the only reviews of this project but it is also a great introduction to some of very interesting issues that emerge in the differences between academic and amateur (meant in the best possible way) approaches to history on the web. Similarly, Jordan Hillman’s post about the Euclid project started a great conversation about digital interfaces to cultural heritage. The content from this site will persist, and I imagine that in many cases some of this will end up as top hits for idiosyncratic Google searches and continue to provide fodder for conversation in the future.

Like a beaver dam the Dighist.org we built together will house the next generation

In Supersizing the Mind Embodiment, Action, and Cognitive Extension philosopher Andy Clark talks about niche construction, a term he builds off of the evolutionary biology notion of environmental niche construction, as a way to think about how we make use of tools. Niche construction refers to “varying degrees, organisms chose their own habitats, mates, and resources and construct important components of their local environments such as nest, holes, burrows, paths, webs, dams, and chemical environments.” (2008, p.131) In each of these cases, animals behavior has altered their environment, and those alterations then become the basis for further adaptation. One of the primary examples of this is the spider’s web. “The existence of the web modifies the sources of natural selection within the spider’s selective niche, allowing subsequent selection for web-based forms of camouflage and communication.” (Clark, 2008, p.61) The spider’s web is interesting as an example of an individual organism and its tools, but beyond this the example of a beaver’s dam brings in far more complexity. Dams are created and inhabited by a collective group of individual beavers and further, are extended over time, outliving the lives of the individual beavers who occupy them. Further, beavers adapt to the niche which the beavers before them had created and the altered physical landscape which that dam has produced. What matters for Clark in this case is that “niche-construction activity leads to new feedback cycles.” (2008, p.62).

I intend dighist.org to be exactly this kind of beaver dam. While different students register and take the class at different times their thinking and work, as manifest in the structure of the content they have produced, will play an active role in future students that occupy the space.

In other words this course will never end…

Ok, fine. According to American University the course is over. End of semester. Students got their grades. Moving on. But frankly, grades are the least interesting part. Not only am I keeping the content up, I intend to use this same wordpress instance for future iterations of the course. Whoever joins future digital history courses I teach is going to register for this blog and start posting. I will move the current syllabus to an archived syllabus page, and post the next set of student projects right above the existing set.

Some of the particularly interesting reviews of tools and are going to become course content on future iterations of the syllabus. Some of the particularly interesting student web projects are going to become examples. Some of the particularly interesting student papers will become course readings. Students from this first session of the course will be welcome to continue posting if they like and further are invited to continue to comment on the course. When I created my course I said that the blog would be the course readings that we write ourselves. Now, even more, some of that content will become part of the readings for future iterations of the course.

Posted on

How Technical To Get When Teaching Digital History

This is the second in multi post series reflecting on the digital history course I taught this Semester at American University. For more on this you can read initial post about the course, the course syllabus and my first post in the series on the value of a group public blog.

Technical Skills: Training vs. Education

I decided early on that I would not be teaching HTML, CSS, PHP or JavaScript in my digital history seminar. While I know this kind of technical competency is valuable, the course was not intended to be about technical training. I think that was the right decision.  I also decided I would not require students to buy a domain name and hosting. I wanted student’s projects to lead them to what they would need to do. If a hosted option like WordPress.com or Omeka.net suited their needs they could go ahead and do that. I feel less confident about that decision.

There were several points in course discussions when my decision to not require students to have their own hosting and domain would hit me in waves. For example, when we talked about Omeka and WordPress I explained that these were both software that anyone could run on their own, and further edit and tweak to their hearts content. To demonstrate I downloaded them and opened up the files in a text editor. But I realized that many of the students had never clicked view source on a page before, and thus had no idea what even the HTML in the files meant. I was able to give a quick high level overview of what was going on in the files, but I felt like I really was not doing this justice.

Still, the projects are better because of this lack of a technical focus

With this said, I have no doubt that my students took on more sophisticated projects because they were not focused on developing technical competencies. Students were able to jump right into making some solid historical web projects. That is to say, the students who pick up wordpress.com or omeka.net for their projects did not get bogged down in learning how to use floats in their design, they were not fighting with the projects respective codexes to get a handle on what kinds of calls they can make to the database to display the total number of items or posts. Instead, for the most part, they made decisions about the technologies that were available to them and decided how they could bend those technologies to their purpose. The result is that they spent much more of their time thinking about audience, doing an environmental scan, developing content, and thinking about how they should evaluate their work. This resulted in much more polished, and as far as I am concerned more thoughtful projects than those I have seen come out of courses that started from first principles with HTML, CSS, PHP, etc.

So how do we teach things like HTML, CSS, and PHP when the real answer at this point is to decide on a content management system and bend it to your will?

I am largely happy with how this turned out, but I am concerned about what I have lost by taking out some of that technical focus. While the projects may be better, and frankly the intellectual work I am most interested in having my students engage in (thinking about audience, content, evaluation, and design) I am concerned that my students are not going to take courses that get them to develop deeper core competencies for working on the web. To this end, if/when I teach this course again I am going to require students to get into this at least as deep as cPanel.

I wanted to shy away from spending time on training when the goal of this course was still to serve as part of a liberal education. With that said, I have come around to  Jim Groom’s insistence that students buy hosting and at least one domain of one’s own. In this case, the education part comes from understanding how web hosting works.  In future versions of this course I will require students to buy a year of hosting on a shared host and at least one domain name. In lab sessions I would then require students to install WordPress and Omeka. I still don’t think it makes sense for a course like this to start with first principles and teach HTML, CSS, PHP and JavaScript. I would instead encourage them to play with available themes and show them how to use Firebug to pick out elements in those themes to tweak to bend them to their whims.

What I like about the idea of requiring students to use a shared host is that they get the simplicity of working with any of the hosted services (at this point many shared hosts have one click installs for WordPress and Omeka) but at the same time we can spend a bit of lab time poking around under the hood. We can take a look at the database, and we can make some tweaks to theme HTML, CSS, and PHP. I can take a little bit of time with them to get a working understanding of HTML and CSS in the context of working with these systems. I feel like this strikes a better balance of still letting us, jump right into work with all the benefits these systems provide but still having both the full range of possibilities that working with your own copy of the software provides and also getting a deeper sense of how the web and databases work.

So how technical is technical enough? I think I have a better sense of how I think the balance can work in this course in the future, but how do you think one should try to strike this balance? Further, where do we see the lines between training people to use particular tools and providing an education?

Posted on

Why A Public Course Group Blog? Reflections on My Digital History Course

This spring I had the pleasure of teaching a digital history seminar at American University. This post is the first in a multi-post series reflecting on teaching the course. For some context, I have posted the course description bellow. For more on this you can read my initial post about the course and the course syllabus.

This course will explore the  current and potential impact of digital media on the theory and practice of history. We will focus on how digital tools and resources are enabling new methods for analysis in traditional print scholarship and the possibilities for new forms of scholarship. For the former, we will explore tools for text analysis and visualization as well as work on interpreting new media forms as primary sources. For the latter, we will explore a range of production of new media history resources. As part of this process we will read a range of works on designing, interpreting and understanding digital media. Beyond course readings we will also critically engage a range of digital tools and resources.

Group Blogging Digital History on the Public Web

One of my three course goals was for students to “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.” Beyond learning about digital history I wanted my students to do digital history. In that capacity I wanted them to engage with the public web and practice public writing. This, in part, meant developing a voice as a blogger and as a blog commenter. I decided to approach this goal through a group blog. I was excited about the prospect us all working and commenting in the same space. My experience participating in PlayThePast over the last six months has opened my eyes to how powerful participating in a group blog can be and I wanted students to get a taste for that.

Beyond meeting this goal I think this approach brought with it a few other benefits.

Blogging enabled an emergent curriculum

A digital history course is fundamentally different from many other kinds of courses. The field is nascent, there are fascinating developments in digital history on the open web that have little to do with the academy, and novel projects, papers, and online resources are appearing almost daily. I was excited to see the blog serve as a mechanism for enabling a more emergent curriculum as students began to wade in the constant stream of new work and ideas in digital history.

I was thrilled to see this emergent curriculum in the first post, which covered content which was nowhere to be found on the syllabus. One of my students stumbled across Youtube Time Machine and blogged about it. Importantly, the brief conversation we had about Youtube Time Machine on the blog, and subsequently in class broached many of the issues I wanted to get into in the course. It provided a point of reflection on armature vs. academic histories online, and more importantly provided a moment to think about how a seemingly technical detail (assigning a datetime to an object) can itself be a sophisticated hermeneutic problem. (Is this the date the thing is about? The date it was recorded? Should this be the date range of the time the creator worked on it? Should this be the date range of the movement the artist was a part of? What do we do with this remix of a video from 1920 that includes a song from 1980 and was clearly remixed in 2007?).

This site, and our discussion of it, ended up serving as a invaluable point of reference for our later discussions. In future versions of the course I think I am going to plan on building in this kind of “show and tell” component into a formal assignment and require all of the students to, at some point, interject their thoughts on some found content into the curriculum.

Posts as conversation starters and sustainers

Every week we had between 2-5 blog posts reacting to course content. Each of those posts would have 1-4 comments. Students who blogged about a piece of writing were supposed to use their post as a means to kick off discussion of the text. Students who blogged about a piece of software were supposed to demo the software and engage the class in a discussion of the implications of the software for the study and practice of history.  This worked quite well. In particular, it meant there were already lively discussions going on around the texts and tools and that anyone giving a presentation absolutely could not wing it.

Everyone had at least the prop of their post to refer to as they lead discussion or demoed a tool. When I woke up Wednesday mornings and reviewed all of the posts and comments they would generally fit together quite nicely, further if we hit a lul in the conversation I had a list of comments to pull from. Lastly, as I picked all of these tools and texts for a reason, I was able to hit home points that appeared in student posts and bring up  issues I thought were critical that had not emerged in the discussions. In short, the kind of externalized thought embodied in the posts and comments was invaluable for allowing me to start, sustain, and have a sense of what students were taking away from our work.

Class Blogging Brought Out Different Voices

Some of my students talked a lot in class, some of them talked a lot on the blog. By making part of our weekly discussions occur asynchronously online I was able to hear different voices and fold those into our in class discussions. Beyond this, it became clear that some students were developing different voices in their public writing on the blog. Specifically, students were assuming familiarity in class that they were not assuming on the blog. I was particularly happy about this as it represented students embracing the notion of writing and speaking to different audiences.

My course was of a bit of an awkward size and makeup and we met in a bit of an awkward space. I had 20 students, which is a too large for my tastes for a seminar style class. Further, ten of them were undergraduate students and ten were graduate students. The student distribution was a more or less statistically normal distribution (a few PhD students, a good number of MA students, a good amount of advanced undergraduates and a few freshmen). Lastly, our class met in a computer lab, one of those spaces set up for traditional instruction where everyone sits at their computer in rows facing toward a screen. Having students use the blog as another communication channel helped make these classroom discussions work. Further, providing the course blog as another communication channel meant that I heard from everyone, not just the most talkative.

In future versions of this course I think I will make this lesson a bit more clear. First, I will require more commenting. This time around I required everyone to write at least six substantive comments. In the future I think I will require everyone to write a substantive comment on at least one post a week. Beyond that, I intend to make clear in the participation section that talking in class and talking on the blog are both very valuable ways to participate in the course. If students tend to be shy in class I still would encourage them to talk more, but I would also make it clear that they can also put more energy into communicating on the blog.

Note to self: Put more of this on the web

I am feeling that in the future it might be better to explicitly plan the class to generate a certain level of content on an ongoing basis. I would like the class to be generating enough content to not only sustain our conversation with each other but also invite conversation with the broader digital history community. In this framework I would try to schedule this a bit more tightly, having different students stagger posting their project proposals so that everyone could agree to review each other’s work.