The Authority of Talking in a Shared Language technical language : technology usage :: grammar : composing If you just read that gobbledygook as “technical language is to technology usage as grammar is to composition,” pat yourself on the back—you can read testmaker’s analogies. Whatever else you think of a language that exists only for test-taking, realize that it can be a useful code for purposes you find worth questioning. I use this particular analogy in this particular code to call attention to the many ways the analogy can be understood:
And, you don’t know which one I mean, do you? Each one is plausible. My point is that it is impossible to avoid technical issues in wireless classrooms, and what you believe about technical language and technology usage will shape your pedagogy just as your beliefs about grammar shape how you teach composition. (1) Develop a click-here language. I am not a technical writer; my students are not technical readers; yet, we have to communicate about technical things. I highly recommend developing a shorthand notation for guiding students through technical processes. Blackboard > Discussion Board > Assignment 3, in my shorthand, tells students to log into Blackboard, select the Discussion Board, and select the Assignment 3 discussion board. Similarly, Word > File > Save As Versions > “d#lastname” means, in Word, go to the File menu, select Save As Version, and name each version by the number of drafts you’ve done and your last name. It is also important to tell students what to ignore: “3lastname.doc” as a filename means (1) don’t use the quotation marks in the filename, (2) supply your lastname in place of the word lastname as the filename, and (3) be sure that you have selected “Word Document (*.doc)” as the “Save as type” option, but don’t type “.doc” as part of the filename or you will end up with “3lastname.doc.doc”. These things may seem obvious to you, but they aren’t to a student who wants desperately to please you by doing exactly what you said to do. Click-here languages develop over time, and they are only useful if they are shared. (2) Develop a troubleshooting protocol. In class, troubleshooting is fairly easy because you can look over students’ shoulders. Outside of class, troubleshooting is more difficult. My mantra is, “You don’t have a problem I can help you solve until I have a description of your problem.” Students know that my troubleshooting protocol includes these questions:
This troubleshooting protocol reduces the number of emails or Instant Messages required to solve students’ problems, and that pleases everyone. (3) Allow for multiple methods. By my count, there are four equally efficient ways to copy something in Microsoft products:
Computer users usually have a preference, and mine is the keystroke CTRL-C. This preference can become a hindrance when I’m talking students through a multi-step process. I might say, “Highlight this part, then press CTRL-C,” and I see blank stares from everyone in the class who isn’t a keystroke copier. Avoiding this hindrance is easy, if you learn to not make your preference the default in your instructions. Say “Copy this part,” pause, and respond to the blank stares (if there are any) by listing the multiple ways to accomplish the task. The economy of prescribing one method of accomplishing a task contradicts, in my mind, a pedagogy that values students’ preferences. |