Troubleshooting (and Failure)Beyond reviewing the table in Chapter 6 on the troubleshooting process, to learn the basic steps of troubleshooting -- which allows you to train yourself before a problem occurs -- try examining one or some of the many great posts from LifeHacker. Go straight to all posts tagged “troubleshooting” by clicking here. Common PC problems are covered here. For a Mac, start here. If you have access to help but don’t know how to explain your problems or work with IT people, read this. These issues are general troubleshooting problems that could be experienced by anyone, but there are some resources geared toward teaching. This post explains how to troubleshoot projector problems; if you already know if the problem is due to the lamp, image, or input, click the right option from this list of FAQs, and if you already know the issue but do not know how to solve it, go here. If the problem occurs while you are trying to hook up a laptop to a project system, go here for PC and go here for Macs. For other problems, try searching for the word “troubleshoot” plus the name or the device or program you are trying to use; alternately, search for the name of the device plus a natural or vernacular language description of the problem (e.g., type in your problem as if you were asking a human being in front of you).
But sometimes, no number of troubleshooting guides can fix the problem. Nor can even an infinite number of good-willed IT services folk return your lost class time to you. However, if you give yourself some time to regroup and try again, you will find that the rest of the programs we recommend using for activities and assignments, both in chapters 5 and 7 and in the web companion’s list of sample activity prompts and assignment sheets, boast a robust online community of users and programmers who love to help one another. Online fora are common; look there to ask for help (check out the Omeka forum, the Readdle knowledge base for ScannerPro, and the WordPress support forum for examples). Make sure you search existing threads there, as your issue may have already been discussed, and if it isn’t, when you post on one of these fora, describe your problem in the greatest detail as possible. In other cases, look at the official documentation, such as Voyant Tools’s documentation. (It’s also worth noting that Voyant’s makers are very responsive via their Twitter accounts.) Screen caps are also a good tool to have when asking others to help you problem-solve. (Look back in the “In Case of Total Failure” part of Chapter 6 to refresh your memory on other strategies for dealing with unexpected problems.)
No matter what, remember that, in the digital humanities, “failure” is not the dirty word that it seems to be in our generally perfectionistic world of academia. Brian Croxall and Quinn Warnick, as mentioned in the book, have curated the Failure keyword in the MLA’s Digital Pedagogy in the Humanities collection. This piece classifies four types of failure, each of which can be harnessed productively in the classroom, and then provides an annotated bibliography of other resources related to these four types of failed pedagogy in the digital humanities. You can read more about the genesis of this chapter on Croxall’s blog.
Elizabeth Losh has also written a fascinating piece on failure, “Learning from Failure: Feminist Dialogues on Technology, Part II.” Writing about the origins of FemTechNet, Losh interviews Anne Balsamo about her approach to failure. Summarizing Balsamo’s approach, Losh writes, “The ability to learn from failure — and to help students learn how to learn from failure — is a teacher’s highest responsibility.” Accepting failure, and teaching students how to bounce back from failure, becomes the last, and critical, part of the puzzle that is the collaborative classroom. (For more from Losh about these issues, you can read the first part of this duo of blog posts, available here.)
In our chapter, we mention Clay Shirky’s Here Comes Everybody: The Power of Organizing without Organizations. We first became aware of this piece, and its commentary on failure in teaching, through Alex Reid’s post, “The Changing Economics of Classroom Management,” on his blog, Digital Digs: An Archaeology of the Future. Although it’s quite understandable that not everyone is persuaded by Shirky’s utopian thesis on the affordances of Web 2.0, we still like how Reid focuses on the classroom applications of Shirky’s writings about failure. As Reid concludes, “in all truth, there is as much to learn from a failure as from a success. So even if your ventures fail 9 out of 10 times or 99 out of 100 times, that failure can still move you toward your curricular goals as much as your success might.” You will likely maintain a far better success rate, but keep this very humble statistic in mind if you fail only a handful of times during an entire course!
Facilitating Group WorkMany of the activities we offer in Chapter 5 work best when students work in groups rather than in isolation. So much of our graded, take-home work is done in isolation, so we recommend using groups in class to emphasize collaborative learning and help students teach each other the skills that they will -- later, through graded assignments -- be evaluated on. Of course, groupwork in general is not a DH-specific tactic and is employed in nearly every discipline. However, because of the exploratory nature of DH activities, you may find yourself with some specific challenges in managing group work that involves tech, and you will find other digital pedagogues particularly excited to negate the way classrooms tend to reinforce authoritarian models of pedagogy as information “dissemination.” As Julie Thompson Klein has explained, in digital learning, “Group work and projects are common and, echoing the constructivist theory of learning, students build new knowledge through exploration and the actual “doing” of a subject rather than passive receipt of predetermined meaning. Innovative pedagogies are common as well.” Cathy Davidson and David Theo Goldberg have called defined this strategy of “de-centered pedagogy” as “a pedagogical method also based on collective checking, inquisitive skepticism, and group assessment.”
In his excellent series of blog posts, “Notes from the Collaborative Classroom,” Anderson discusses a variety of collaborative tactics, but two of these posts are particularly wise about group work. “Groups and Group Work” contains helpful advice about how to manage non- or under-participating group members; how to select randomized groups via Moodle; how these groups should communicate; and how group work should be turned in. The second post, “Mechanics and Workflow of Grading Group Work,” discusses how to parse projects into digestible units; how to incorporate crowdsourced, peer grading; how to manage grades with spreadsheets. Along the way, he also discusses why he finds rubrics useful and the pros and cons of various platforms he uses for rubrics and grading, from his institution’s LMS to Excel to SurveyMonkey. Some of the platforms and methods described are ones he abandoned, and at least one platform is now-retired (Adobe Forms Central), but in general, his manner of breaking down his record-keeping processes will certainly help you make your own process more efficient. Just becoming familiar with his spreadsheet-based record-keeping is worth reading the whole post! His recommendation to ask students to evaluate their peer evaluators (if you use peer grading) is also well worth considering.