Last week I shared a story of classroom success, so it seems only fair that this week I share a story of failure. Hopefully that story will lead to a productive discussion about how to manage moments when technology fails, which often happens in public with embarrassing results.
We’ve written about WordPress quite a bit at ProfHacker: guest author David Parry argued that WordPress is a better CMS; Kathleen explained how to backup WordPress blogs, as well as how to move them; Julie explained WordPress plugins; Ethan helped us find good themes for academic WordPress installations; Brian helped us enable Zotero with WordPress; Jeffrey used WordPress to hack an alternative department site; and guest author Derek Bruff explained how he administers reading quizzes through WordPress. Indeed, as of yesterday, ProfHacker (and all the Chronicle blogs) are produced in WordPress. All of these articles convinced me to install WordPress 3.0 and set up separate blogs for all of my classes using its multisite feature, which would allow me to manage separate blogs for each of my classes through one administrative interface. On the first day of class I enthusiastically described my hopes for these blogs, and asked my students to register for accounts on the blogs for their individual classes. I added links to each course blog on the Moodle page for each class.
My students being students, most of them didn’t follow these links or attempt to register on the sites until the night before their first blog posts were due. And, unbeknownst to me, the “register” button on the individual blogs was sending students not to the registration page for their individual class blogs, but instead to the registration page of my main blog. Registering for accounts there did not give them access to the class blogs. I hadn’t realized that I would need to log in to the main administrative interface and set each of them up for the correct class blog individually. The next day, I woke up to a number of frustrated student emails, and I knew that, in a few hours, I would walk into classes full of justifiably frustrated students.
WordPress wasn’t at fault for this problem—I was. I should have tried registering for a student account before my students, to ensure that it would work as I expected. I’d used WordPress in class before (a single installation), and I relied too casually on that experience. My failure ended up costing me a day of class time. That morning before class I called the library and managed to schedule a computer lab for my class. I spent class helping students register for accounts on the correct blog, re-teaching them how to log in and post, and consulting with them as they wrote their first blog assignments in class. In short, I had to own up to my mistake and work with my students to resolve it. In the end the situation turned out well. My students got a peek into the backend of WordPress, and we had a healthy conversation about the benefits and potential problems that come with classroom technology.
This incident speaks to a larger issue that I know the ProfHacker community faces: how to manage moments when technology publicly fails. Sometimes that failure is the tech’s fault—internet access in a building drops away during a web-based presentation, for example. Other times it’s user error, as with my class blogs. Many observers, however, won’t distinguish between machine- and user-generated failures. Either way, then, these can be anxious moments for known Profs. Hacker—departmental techies who not only use lots of tech, but who lobby for greater use of technology in their departments, libraries, colleges, or universities.
Profs. Hacker often face resistance from colleagues, some who don’t understand the benefits technology might offer their research and teaching—and others who are vocal Luddites, worrying loudly and publicly that their students and junior colleagues have become the “tools of their tools.” Moments of dramatic tech failure seem to validate those opinions, to hoist the Prof. Hacker by his own iPetard. So my question for you is this: how do you manage those moments of public tech failure? Can these moments become pedagogical moments for our students and colleagues? Let me hear your thoughts in the comments.
[Creative Commons licensed photo by Flickr user Justin Marty.]
Follow Profhacker through your favorite RSS reader: 
11 Responses to When Technology (Publicly) Fails
danquigs - October 12, 2010 at 11:27 am
I often find that my attitude in face of these “disasters” is crucial. If I have a tech failure and walk into class and start getting upset, railing against the tech staff who “never get it right” or otherwise blow my cool, then the “disaster” really becomes one, with students spreading word of either my incompetence or how the institution “never gets it right.”
However, if I go in with a “well, we’ll skip using that tool for awhile until I get the bugs worked out, lets move on to something else” the situation usually stays manageable. In the case you cite above, if students were to get something posted the day you walked in and were not able to, then they get a pass on that one assignment (even give them all 100 for that one posting if needed) and then straighten things out for the next class.
As I continually tell my luddite friends who won’t try technology in the class because they are afraid of it failing, the students are still going to learn in the class, they are still going to be better off for having taken the class with the technology, even if it takes a little time to straighten things out. Remember, its education, not brain surgery. If you make a mistake in the classroom, technology related or not, the student isn’t going to suffer irreparable harm…they will just need to catch up a little later.
cardinalham - October 12, 2010 at 11:58 am
IME it’s pretty important to acknowledge the students’ frustration with a simple, “You’re mad, I get it, I’m sorry. I’m annoyed too.” Then I usually take the opportunity to talk (again) about why I choose to use the tool even though it’s not 100% perfect. Students are usually happier to try again if they understand what my pedagogical goals are, or if they get that the alternative is going to be even less convenientd.
mhigbee - October 12, 2010 at 4:18 pm
At my university, we rather often suffer collapses of perhaps the campus’s most prominent IT system – the university email system. These collapses are never explained once they are fixed, and never announced on the university website either; instead, the IT department is content to let hundreds and thousands of people wonder when and if email will be restored. Once it took a week; today it took maybe two hours.
The lesson here may be — you don’t have to explain a technology failure if you’re not in front of people who you are supposed to be serving with the technology. If you’re far removed from the actual users, you can ignore them.
Not good practice, but still, standard practice. For years, they’ve promised to announce system failures while they are underway, but they never do.
aeonelpis - October 12, 2010 at 4:46 pm
I think cardinalham is absolutely right — students often want their feelings acknowledged. Offering that costs little, but seems to move the conversation forward productively, from “this is frustrating” to “how can we fix it.” Tech failure provides an excellent opportunity to manage expectations and talk about the difference between a fail-safe mindset (try to prevent failure at all costs!) and a safe-fail mindset (failure will occur at some point, so what will we do when that happens?). Tech, just like many other things in life, will, at some point, fail them, and learning how to cope with that productively offers a lesson more valuable than they might have learned if the tech worked.
jrlupton - October 13, 2010 at 8:04 am
Whenever I lecture with slides (for teaching or at conferences), I try to have a Plan B: a way to present my materials *without* my gorgeous InDesign images. And I try to slip seamlessly into Plan B without constantly referring to the slides I *would* be showing if the *#@? technician or system hadn’t ‘failed’ me. Whoever or whatever is to blame for the snafu of the moment, the buck stops with the presenter, who must be willing to fly solo when her digital wings have been clipped.
mykg3041 - October 13, 2010 at 8:25 am
My career-long heuristic (as a self-avowed advocate of technology) has been “Technology will confound you, it will embarrass you, and it will fail you at the times you need or trust it most.” As per jrlupton – I have a printed copy of the PowerPoints when I present. And I learn every day that failure is a wily and unrelenting educator.
rjr8222 - October 13, 2010 at 8:27 am
So long as every individual faculty member is responsible for all aspects of the technology used in the classroom, failures will occur too often. As described in this article, getting everything set up correctly the first time is hard, so the initial deployment of almost any high-tech service often has a shake-out period.
In an ideal world, the IT department of an educational institution will provide a basic set of on-line tools (blogging, class web pages, video and audio production and distribution, templates for many content creation systems, etc) that instructors can use without having to constantly reinvent wheels.
One of the basic buzz word phrases around IT is the need for IT to be “aligned” with the strategic goals of the enterprise. If delivering educational materials to students isn’t part of the strategic goals of a university, I don’t know what is.
mlaumakis - October 13, 2010 at 12:21 pm
I teach 500 students in each of two sections of Intro Psych. I use a considerable amount of technology in these courses, including clickers, lecture capture, and live online sessions in Wimba. I know that there will be days when the technology doesn’t cooperate, so I tell my students on the first day of class to expect problems to crop up. I also tell them that we’ll deal with it. In predicting these problems, I set myself up for one of two outcomes, either there are no problems and I look like a genius as I use these technologies or there are problems and I’ve covered myself by predicting that such problems would arise. Either way, it’s okay.
crankycat - October 13, 2010 at 1:01 pm
I routinely deal with software, microphone, gyromouse, and projector malfunctions – as a consequence I can field strip a remote mic and replace the battery in about 45 seconds while continuing to lecture.
You just roll with it. Either the mic will work or it won’t. Either the mouse is charged, or it isn’t – the show goes on. The best armature against getting tripped up is good familiarity with the system, with a back-up, and with your material.
(And -I’ll admit it – it’s kind of FUN when you get to improvise on the fly.)
mcleods - October 13, 2010 at 1:02 pm
I have enjoyed reading the comments posted to this article. Here is mine: Whenever I am about to give a. presentation that involves technology, I simply remind myself that, whatever the technology does, I am going to give a presentation. That simple declaration helps to decrease stress.
bekka_alice - October 20, 2010 at 2:32 pm
I’m old enough to have had several of these, often when traveling to present – and my main bylaw now is that for whatever I am going to present using technology, I work to have a non-tech version as backup. I’ve had a laptop with a set of a hundred online links to sites and images fail when my presentation was put in a second-floor hotel conference area that didn’t have network access (and since the co-presenter had not read the lecture notes despite being sent several missives on it, improvisation did not come easily). I should have had slides or handouts with the images, and a printed handout list of the URLs for later reference for the attendees.
On the other hand when I put the laptop aside to work with the (I hoped) more reliable in-hand transparencies, I’ve had a conference organizer completely forget a projector for them despite being reminded several times in advance (and since I was in another state I didn’t have an easy way to get a replacement when I found this out on site), in which case I had to hand the transparencies around and it would have been nice if I’d had a white sheet taped to the top of them in advance which could be flipped out of the way for overhead display or flipped down to the back of the sheet to make it easier for people to see when handed around. The transparencies had mixed images on one sheet which when displayed on the overhead let me simply cover the currently irrelevant side of the image – teaches me not to cheap out – everything now gets its own sheet in case of bulb failure. The handaround solution also turned a two-hour lecture into a three-hour lecture because of the time to let people see the images, so these days I set up lectures longer than a half hour in incremental sections so that if something goes terribly wrong with the timing I have a clean “chapter break” where the end can be dropped off smoothly without apologies that something is obviously missing/the end is obviously ragged.