• Back to Design and Manufacture
of Monuments • Main Page •
Comments on Site Design • Concerns
about Access •
Copyright and Web Publishing • Tips for Teaching • The Technology Club • Who am I? • Why this Project? • Writing with Hyperlinks • References •
"It's like some secret club. And if you don't know the
password they never let you in."
--a fellow graduate student, a computer whiz, consoling me as I expressed my frustration at all the jargon used by people knowledgeable about computers
A transcript of a recent phone call I made to the Office of Information Technology:
"Help Desk, this is John speaking." [Note: I've changed the names of the OIT workers.]
"Hi, John, this is Heidi McKee. I have a question about Dreamweaver. Is there someone there who can help me?"
"Hi, Heidi. This is Matt. What can I help you with?"
"Hi, Matt. I have FTPed my files over to the OIT server, but when I check on the pages in the browser I get a 404. And I was wondering if I might have made a mistake in the root directory."
"What folder did you put them in?"
"In the public_html."
"Did you set your access parameters?"
"Yes, I did that chmod command in Telnet, and I can see my index_html file."
Phew! Just typing all that jargon gives me a headache. Yet I also feel a sense of pride and, oddly, power that I at least know some of the lingo to be able to ask the questions. But I also feel frustrated and, I'll admit, annoyed about the way computer jargon can be used as a means of intentional or unintentional exclusion.
The people at Help Desk here at the University of Massachusetts, Amherst, and those who worked at the high school where I taught have been all very helpful, concerned, and considerate, but sometimes I don't think they realize how intimidating and confusing computer jargon can be to people. Because they have an understanding of both the larger systems and how individual programs interact with those systems, they have a frame of reference from which to build and add new experience and information. But those of us starting from virtual scratch have no such framework, so when we hear phrases like root-command pathways, we can become lost quite quickly.
Until recently, when I got lost in the jargon, I just zoned out, excusing my behavior by thinking, "I don't need to understand all this. As long as I can type papers and send emails on these machines, what else do I really need to know?" I never attempted to gain the knowledge that would make the jargon make sense because, to be honest, it just felt like too much hassle, and I think in part, it scared me.
Yet as I explore using the computer for more than a glorified typewriter, email-exchanger, and web-crawler, I realize that I need to learn the computer terminology relevant to the systems and programs with which I'm working. Often to get the help I need, I have to know at least a few key terms to be able to ask the questions. And I'm finding that the terminology, while daunting at first, reduces to a key word or phrase a whole complex series of processes that would take a lot longer to explain. But even as I learn this language, I don't want to forget how much it annoys and intimidates me right now, so that when I incorporate new technologies into the classroom, I will remember to speak with footnotes. That is, I'll use the jargon, but provide immediate and relevant translations.
Back to Top