Select any filter and click on Apply to see results
Table of Contents
Technology Administration for / by / in the Humanities
“Technology is a human activity.”
—Martin Heidegger, The Question Concerning Technology
From 2002–4, as postdoc-cum-director of computers and writing at a large university’s writing center, in addition to studying the emerging field of technology and pedagogy, I stocked and maintained a five-classroom lab, hired tech support personnel, and encouraged humanities faculty to use computers in their classrooms. How did a freshly minted PhD in creative writing find herself in this position? Like many of my generation (X), I had been pulled toward teaching with technology while in graduate school. Those who experimented with computers were given better courses and classrooms—sometimes even free machines.
After receiving my degree, the pull became stronger; this time, it came from institutions offering correspondence-style online courses. I preferred face-to-face, computer-enhanced teaching and learning, but competition was fierce and employment opportunities were few. So while actively on the teaching market, I took the tech-heavy administrative job at the writing center. The following is a summary of the useful things I learned over two years of “guerrilla technology administration.” It is meant to inspire—dare I say empower—even the most right-brained of people.
Cutting edge, bleeding edge
In 2002, we had to rebuild our computer lab from scratch after a tropical storm rolled through. As soon as our tech vendors learned of the damage to our facility, they lined up outside our door (now three floors up). One sales representative came by with a “cute new box with a tiny footprint” (read: a PC that takes up little room on your desk).
I said, “it’s so small you can’t even tell where the diskette goes!”
He said, “it doesn’t go anywhere! There is no diskette drive!”
(Remember, this was 2002.)
“But our students still use diskettes,” I said. “We sell them every day.”
He said, “that’s phasing out pretty soon, you know. You don’t want to stay behind the times, do you?”
The slippery slope is a formidable argument in technology sales. It usually appeared after I persisted in any sort of critical questioning, and seemed rooted in what my rhetoric professors would call an “argument from technology”: treating the vast and variously performed theater of inquiry called technology as a single or monolithic enterprise that leads to the discovery of truth (Trail 1996). The medium—not our message—was what mattered. This was mystifying, but it was just the beginning. I was often blindsided by a second argument asserting that new technologies were necessary in order to “maintain our image as an innovative facility.” Implicit, of course, was that our image needed maintenance. But I also knew that we had a closet full of cutting-edge “pro-educational” devices—electric pens for electric whiteboards, tablet PCs, Palm Pilots—that were overly expensive, difficult to use, buggy, and/or ill-suited to our needs.
In my new job, I often fought against the critical thinking skills I’d carefully cultivated as a humanities student. I was ashamed at my ignorance: in the geek world, I was a total dweeb. Thankfully, the students using the lab confirmed my suspicion that most regular people don’t live on the cutting edge; they just want to put their diskette or flash drive into a computer and have it work. Needless to say, we didn’t buy the diskette-less machines (though we did get extra USB ports). And believe it or not, everything was fine. Even today, in 2008, everything is still fine.
Eventually, I began to insist that a large gap (in time) remain between what was “cool” and what was actually needed in the lab, much to the chagrin of sales reps like my friend above (and unfortunately, a few of my colleagues). Steven W. Gilbert, who helped build the technology-in-higher-education nonprofit Educause, has coined the term “low threshold applications” to describe products that are cheap, easy to use, and ubiquitous. His guidelines (see www.tltgroup.org) helped me greatly. I asked staff in our Information Technology (IT) department what students were using at home, what discounts the university offered students and teachers, and what our lab computers could tolerate. Adopting Gilbert’s guidelines also helped me keep an eye on the most common problems our university’s tech support people were solving. When I told these people that we were cloning all of our lab computers to last year’s operating system, they didn’t exactly turn cartwheels, but neither did they get out the tar and feathers. “It’s what you’ve got to do to stay sane around here,” they’d say. Then their pagers would go off and they’d disappear.
My advice to decision makers who would rather be doing research . . . in their fields? Stay off of what instructional designers call “the bleeding edge.” Doing so will free up a great deal of time for other things, like deciding who really deserves a course reduction in your department or figuring out the real point in your essay about twentieth-century film interpretations of the Robin Hood myth. And stick to your instincts when dealing with vendors. Ask questions that will intimidate them: Which methodologies were used in determining the efficacy of this technology? Who has used and, more importantly, who has assessed this technology? Who owns this technology, and how much has my university invested in it? And finally, learn to say no.
In 2002, when I began my work at the writing center, we employed a tech guy I’ll call Joe. Expensive, powerful machines lined Joe’s desk. One day, I came to him with a question: which Web-building software would he recommend for teachers? He pulled out a telephone book–sized manual called HTML. When I timidly suggested that my students had learned to convert Word documents to HTML at the touch of a button, he threw up his hands.
I tried again. “But you realize that English professors don’t have time to learn to code.”
“Would you assign the Cliff’s Notes version of Hamlet,” he asked, “in a Shakespeare class?”
Joe’s successor was a young IT student who wore a T-shirt proclaiming, “been there; hacked that.” When we had problems with our network, his suggestion was to convert the whole facility to Linux—“because it’s cool.”
Consider this: you may not need a “professional”! Ellie Chambers (2000, 251) of the UK Open University’s Institute of Educational Technology recommends hiring “lower-tech” people to manage your department’s use of technology—preferably someone with a background in your field who understands and respects what you teach. Savvy graduates from your programs tend to be loyal and to know both the campus’s IT weaknesses and your department’s strengths. The nice, capable work-study tech person we eventually hired cost so much less than a professional that we were able to hire her full time. Since the winter of 2002, she has taken care of 125 computers, mostly by herself.
Toward an entry-level computing facility
Prioritizing connections among people at a large, publicly funded campus was an unusual way for me to do my job as a technology administrator, but I was good at it. It was, arguably, what my humanities background trained me to do. When classes began in the spring of 2002, the computers worked, the printers printed, the remotes were cabled down. And I began receiving calls from faculty members. Some wanted to learn Java; a few weren’t sure what the right mouse button did. It soon became clear that our writing center needed a technology mission statement with clear boundaries—the most important boundary being its ceiling. This was when I coined the term “entry-level computing facility.” (I encourage you to use it.) After all, we were part of the English department! When I learned that the education department taught advanced software applications for specific purposes—video editing, Flash, and Cold Fusion, to name a few—my message to those who came into our lab asking where the videography desk was became, “Dr. X in education will make your wishes come true.” People quickly stopped expecting me to tweak their server-side software, and I was able to return guilt-free to my beginners (who were beginning to do interesting things).
I eventually created a brochure that outlined a three-step, three-semester plan for teaching with technology. The first step consisted of teaching a face-to-face course in one of the writing center’s computer classrooms, using technology as a supplementary tool. The second added a course management system to the mix. The third step shifted from the course management system to an independent course Web site, with or without student Web portfolios. Teachers could enter at any step, wherever they felt comfortable, and stop at any time. Baby steps were good: the important thing was the setting of low-stress goals over a longer period of time. In this way, content and confidence were guaranteed to rule. Soon, our Web site showcased more than twenty wonderful course projects, many of which continued from semester to semester. Ironically, the most frequent comment I received from visitors was, “how did you teach them so much so quickly?
In my short time as a poet-cum-tech administrator, I came to learn (remember?) that active critical thinking—not thinking like a computer—can transform technology from a mystifying force into a fascinating tool. When employed humanistically, this tool enhances rather than obstructs the subjects we really love to teach. So who is best qualified to make technology decisions for our academic departments? IT? Distance Ed? Educational Technologies? No. These difficult, often crucial decisions are best made by those deeply invested in interpersonal communication—in other words, faculty. We can do it.
Chambers, E. 2000. Computers in humanities teaching and research. Computers and the humanities 34 (3): 245–54.
Trail, G. 1996. Reading writing: A rhetoric and reader. Orlando, FL: Harcourt Brace.
Julie K. Chisholm is assistant professor of composition and rhetoric at the California Maritime Academy.
To respond to this article, e-mail firstname.lastname@example.org, with the author’s name on the subject line.