Like many ProfHackers, I’m constantly tinkering with my syllabi and assignments, looking to improve the experience for the students (and for myself). For many of my writing assignments, this tinkering has meant that the guidelines have grown longer and longer (as I address specific issues that have come up in previous iterations). However, in my senior undergraduate seminar, Adventures in Digital History, I’ve taken the opposite approach, giving students the broadest of guidelines and providing them with the opportunity to create their own assignments for their group digital history projects.
[A note about the course [2008 and 2010 iterations] and my goals for it: it is focused on digital history concepts and methods, and explicitly offers an alternative to the semester-long research paper that allows students to create something fun, interesting, lasting, and important, while engaging history majors in something substantively different (both in terms of technology and in terms of working with others) than the discipline as a whole. It is intended to push students out of their comfort zones, and, hopefully, provide them with some marketable skills.]
Overview of the Process
I give each group a broad topic, expose them to a variety of digital tools, and then have them write a contract (4-5 weeks into a 15 week semester) explaining what their plans are for the project, what tools they will use, and what their calendar is.
The four or five members of each group work on a particular project all semester. They begin with a broad topical direction from me (e.g., “do something on the history of our school”) and they begin doing research for themselves, working with me and various resources (sources and people) to come up with their own direction for the content of their project. At the same time (in those first four weeks), they are introduced to a variety of open-source/freely available tools for online discussion, content creation, and presentation, including Omeka, GoogleDocs, SIMILE/Timeline, WordPress (via UMW Blogs WPMU), WindowsMovieMaker/iMovie, and Zotero. The goal of these early semester sessions is not mastery of all these tools, but rather a brief introduction to the capabilities, strengths, and weaknesses of each so that the students can evaluate them for their own needs. If a tool looks like it might be useful, then they play around with it more to see 1) if it will meet their vision for their project and 2) if the learning curve is one they can manage in the course of the semester.
After weeks of playing, researching, exploring, and talking about their projects, each group uses Google Docs to write their contract and submit it to me, including the following:
- Mission statement, including a full description of the project, with its goals and audience(s)
- List of tools/software, with an explanation of how they will be used.
- Schedule of milestones (when critical pieces are ready to present)
I comment on the draft, addressing issues (most often with practicality of the time line, or clarity of goals); the group rewrites their contract and then they are posted to the course website (see here and here) so that we all agree what it is each group is working on. At the end of the semester, the groups are graded on how well they have met the contract that we agreed upon.
Three relevant points here:
- Each group can revise the contract as the semester goes on, though only with good reasons. [For example, good reasons include serious technological problems or issues with access to sources. They do not include problems related to poor effort or planning.]
- At the end of the semester, each student writes a brief explanation of how their group met their contract. [See here and here for examples.]
- I recommend an interim evaluation of the project at roughly 2/3 of the way through the semester (week 10 for our 15 week semester) so that students have some sense of your sense of how they’re doing.
Results of the open-ended contract
1) In my experience, the proposed projects are more ambitious than those I would have assigned had I been very precise about what I wanted. Although each time one or two of the groups may have to ultimately scale back their goals a little bit, thinking big is what I want them to be doing. [Scaling down is easier than scaling up, especially later in the semester.]
2) In most cases, the students come up with significantly more creative projects than I would have been able to design, and the projects are much better for it.
3) Students who have finished these group projects based on their contracts have an incredible sense of accomplishment, as well as skills in a variety of areas not traditionally taught to them in my discipline (project management, tool evaluation and selection, and group work, just to name the most obvious).
What experience have you had with having students write their own contracts? What advice do you have for those looking to do so?
[The image in this post is of one of UMW's seminar rooms from my flickr account. Based on my experience you'll have better results if you add students.]
Comments
1. Candace - March 02, 2010 at 10:56 am
Love this idea because students get to create something meaningful. They get to draw on their strengths or build new ones while working on a project that is interesting to them.
My question: is this a pass/fail course? If not, at what point do you develop evaluation criteria? Are students part of that process as well?
2. Jeff McClurken - March 02, 2010 at 11:20 am
No, it's not pass/fail. In the broadest sense, students' grades ultimately depend on meeting the terms of their contract.
However, over the course of the semester we have a series of discussions as a class about what constitutes a "good" digital history site so that we have general agreement on the criteria before the projects are finished. This process begins at the start of the semester by looking at other sites and talking about why some sites work better than others, leading us into discussions of user interface, site structure, tags, ease of searching/finding content, depth/breadth of content, audience, intellectual/historical rigor, citations, visual aesthetics, and a whole host of other issues. It continues on throughout as they present the early versions of their projects to each other and to me for comment and feedback.
3. Aileen Fyfe - March 04, 2010 at 10:53 am
Fascinating stuff! Next year, I'll be coordinating a group project module on our new MA programme in intellectual and cultural history. We've agreed that we want them to develop teamwork (etc) skills, that there should be an element involving reflection on how history is relevant/important today, and that there must be a public engagment element (e.g. a public outcome, not a research paper) - but beyond that, the module is still very much in its planning stages. I'd love to hear from anyone with experience of running this sort of module - particularly to hear what sorts of outcomes and projects proved successful.
Add Your Comment
Commenting is closed.