English 249, "Introduction to Technical Writing" Fall 2012 MW 2:00-3:15 408 Stevenson Jim Kalmbach (kalmbach@ilstu.edu) 421H Stevenson 438-7648 http://my.ilstu.edu/~kalmbach Office Hours: M 3:30-4:30 T Not Available W 3:30-4:30 R 10-12 & 2:30-3:30 by appointment only F 12-2 in 408 Class blogging site: http://blogs.english.ilstu.edu/eng249 Any student needing to arrange a reasonable accommodation for a documented disability should contact Disability Concerns at 350 Fell Hall, 438-5853 (voice), 438-8620 (TDD). Texts Redish, Ginny. (2007). Letting Go of the Words. Morgan Kaufman. Alred, Brusaw, & Oliu. (2012). Handbook of Technical Writing. Bedford/St. Martin 10th edition. If you have an earlier edition, you can probably make it work, though you will have to translate page numbers. Additional Reference Guides: Barton, Kalmbach and Lowe. (2011). The Writing Spaces Web Writing Style Guide. Writing Spaces. Open Access textbook available at http://writingspaces.org/wwsg/. Letting Go of the Words: Technical Writing in a Web 2.0 World If you have already purchased the textbooks for this class, you are either excited or terrified that I have asked you to purchase the same web writing textbook that I use in my 300 level web design class. What is this class: Web Design Nano? 351 Air? EEK! Not at all. Using Letting Go of the Words is an experiment on my part and may well bomb. I decided to use this book, because web writing and technical writing are becoming synonymous in many contexts and because many chapters of this book are exactly the things I want to teach, topics such as: Her approach to audience analysis through Personas, Scenarios, and ethnographic research. Her view of writing as a conversation, as answering people s question, as grab and go. Her emphasis on the importance of design. Her section on style Her discussion of lists, tables, and headers. Her emphasis on testing. 1
Like it or not, the best technical writing going on today in public spaces is taking place on the web. When you have a problem with a new gadget, do you read the manual or google the problem? My feeling is assigning Redish s book was that it presents an argument that (most) technical writing and (most) web writing are becoming the same thing. We are in a strange new world. People are on the web doing more reading and writing than ever in history: blogs, tweets, forums, wikis, email, etc. etc. At the same time, long form reading whether with books or Kindles seems to be thriving even as publishers of printed books, magazine, and newspapers struggle to make a profit. It is a world of digital natives, of young people who seemingly pick up the use of technology without reading manuals (which I don t believe). In such a world what role does technical writing play? If digital natives won t read the manual, if everyone solves their gadget problems by googling them, why even bother? That s an excellent question and it does not have a simple answer. If your idea of technical writing is a 500 page reference guide stored in a three ring binder for which you receive monthly page updates and you are expected to remove the old pages and replace them with new pages, then yes, technical writing may well be dead and THANK GOD. If, however, you believe (as I do) that technical writing resides not in genres, but in purposes and relationships between readers and writers: the urge to convince someone to change a policy, or purchase wisely. If you believe that technical writing is about helping people develop productive identities in complex worlds (using to become), then you will see technical writing everywhere. The forms may have changed, the media may have changed, but the need to use language and various forms of visual and temporal media to take action in the world is the same as it ever was. In truth, my fundamental conception of technical writing has not changed since I began teaching these classes in 1980: Technical Writing is writing that gets people to take action in the world. Technical Writing is writing that gets work done. The contexts of that writing may have changed (no computers back then), but the basic relationship in TW between writers and readers have not. This view of technical writing is closely aligned with activity/genre theory, which is the theoretical approach that informed your English 101 class (if you took the class at ISU). It is a view of writing that is incredibly situated: it sees writing as a concrete activity that takes place within in a specific network of people to achieve a specific action. I continue to believe that students do their best technical writing when they are writing to real audience (people who they know) for real purposes, to achieve real actions. So when I ask you who is the audience of this project, don t answer: Anyone. Projects 2
You will do six projects this semester in overlapping cycles (by that I mean we will start new projects while old projects are wrapping up). In brief those projects are a letter and resume for a real internship or entry level job, an informal report or proposal written to a real decision maker, a documentation project written for real users, a substantial technical writing project on a topic, genre, and media of your choice, a powerpoint (or prezi or keynote) presentation, and a portfolio. Following are some notes on each of these projects and on the support documents you will write for those projects. Letter and Resume (10%) We will start the class working on your application letter and resume. You will prepare a print letter and resume aimed at a real internship or a real entry-level job, though you do not have to actually submit the letter and resume. After we do some initially introductory work, and a draft, we will shift our attention back to the report. Meanwhile, I will expect you to submit a revised draft of your letter and resume every week until I give you an A on this project which I will do when I can t find any changes to make. After I have given you an A on the project, you will create a text-only version of your resume suitable for submission in an email or a database system. Informal Report/Proposal (20%) Your informal report/proposal must solve a real problem for a real organization. As part of your planning for this project, you will have to interview the person who would make the decision if you actually submitted the report. Documentation Project (20%) After the report project and while you are still wrapping up your letter and resume, you will do a small documentation project aimed at a real audience. You will need to be able to interview a member of this audience during your planning process, and do user testing of your documentation. Note the project can be done for the same organization as your report or a totally different one. Documentation projects can be done in print or online as long as they address a real need for a real audience. Major Technical Writing Project in Any Genre (30%) After completing two technical writing projects in the major genres, you will complete a third project on a topic of your choice. This project can be related to your first two projects or totally different, but it must be more substantial and ambitious. For this project I will be more lenient in terms of requiring you to write to a real decision maker or audience. This project can be paper-based or online. It can be a video or some other media. Your project can be one large document or series of small related documents. Your major project can also be a substantial collaborative project. Oral Presentation (5%) You will do a PowerPoint Presentation based on one of your projects. This oral presentation must use some sort of presentation software such as PowerPoint, Keynote, Prezi, Google Slides or some other software I have never heard of. I want you to use presentation software so that I can spend a day walking circles around the room telling you you have too much text in your slides. Way too much text. A Technical Writing Portfolio (5%) You will complete the class by turning in a portfolio of your projects. I will base my grading on the quality of the work in your portfolio. Every English of Communications major who seeks work in writing or editing job needs a strong portfolio. Support Documents (10%) 3
In addition to your portfolio, you will produce a number of support documents about your projects during the semester. These support documents include responses to each of the assigned readings posted to our class blog. I am looking for reflective responses that engage with the ideas in the text and not ones that summarize the reading or dismiss it (it was great or it sucked). Responses that are one to two screens long are a good general goal while one of two sentences is a bad goal. I really don t care if you hate a reading (or love one), just tell me why and ground your observations in the text. I assign reading responses in lieu of tests because I believe that people learn more when they write about what they read, so please take these responses seriously. Other support documents will include project proposals, audience analyses, peer group reports and a variety of other informal documents. These documents will not be graded and should not be included in your final portfolio, but they are an important part of the class, and I will reduce your grade if you do not do them. While the primary payoff for doing a good job in these support documents will be in better projects and a better portfolio, I will recognize and reward strong work on these documents, and if your support documents are particularly weak, I will ask you to revise them. Policies These policies cover revision, late drafts, computer use, attendance, and support documents. My goal here is to create structures that are fair while helping you to succeed. You should read these policies carefully now and reread them around midterms and towards the end of the semester. Attendance I follow the department s standard policy on attendance: I reduce your grade one level for each three unexcused absences. If you can t be in class, please let me know. One Week Rule In general, I will try to return first drafts of documents the next class period. Beyond first drafts, however, I follow a one week rule: I take one week to read and return drafts. I have had to implement this policy to protect my sanity. This policies has two implications: (1) Don t ask about a draft until I have had it for a week and (2) If it has been over a week, please ask. I may have lost it or I may be having a bad week, but either way, you should check in. Revision Revision is extremely important in my classes. I firmly believe that expertise in writing comes through hard work, through repeated revision until your documents are as good as you can make them. Consequently, you may revise your projects throughout the semester. If you hate to revise your work and like to do everything the night before it is due, you should drop the class now. Submitting Your Work Most of your projects can be submitted in electronic form via email. (I will let you know which assignments need to be printed.) Please put your name and page number in the header or footer of each submission, and the nature and status of what you are submitting in the subject line of the email (example: Letter and Resume draft 2). Although I accept electronic submissions, I usually print work to read it. I print to a shared printer in our typing pool along with approximately 150 other teachers. If your draft is just a sea of text with no page numbers and no names, it will get lost when printed. Please put your name and page number on each page using the page number tool in your word processor. I will return unpaginated drafts to you with a request to update before I read. 4
Grading In general, I do not grade projects unless I have read them three or more times (and even when I do, you still have the option of revising the paper for a higher grade). I do this because grading drafts that are in process is counter-productive. There is no way to represent in a grade the potential a draft project may have. On the other hand, by the end of the semester. you may not have submitted any of your projects three times and thus not have a good sense of how you are doing in class. I do not mean for you to write out of fear or apprehension. If at any point, you would like to know how you are doing, bring your work with you to my office and I will be happy to discuss your likely grade range. As a general rule, if you have attended class regularly, turned in the assigned drafts on time and made a sincere effort to improve your work, you can expect to get at least a C in the course. To get a B, you generally need to have done all of the work, more than the minimum number of drafts, and have produced good quality projects. To get an A in addition to revising a lot, the quality of the projects in your portfolio must be exceptional. Specifically, the projects in an A portfolio must be substantial and ambitious. The content of these documents must appropriate to the audience and purpose. The organizational structure and style must be clear and appropriate. There should be few surface errors. In general, A projects are ready to be used easily and effectively by their intended reader. They can go from you to me to your audience. B portfolios contain good solid projects that either are fairly modest in scope or one or more of the projects may have serious structural problems. These projects usually have been revised less but still more than the minimum. B work should be good quality technical writing C portfolios have more serious problems or are very modest in scope and ambition. The author has usually done the minimum possible, Although these projects may have problems, I must be convinced that they can succeed with their intended audience. The readers of a manual can use that manual to complete a task, the readers of a report can use the evidence in the report to make an informed decision. Your projects must be usable by your readers to get a C or better. When reading individual projects, I value the following characteristics of technical writing in the following order: Content Does the project contain appropriate information for its purpose and audience? Organization Is the project organized clearly and effectively for its purpose and audience. Ambition Is the project ambitious? Does it attempt to solve a significant problem? Formatting Is the visual format of the document attractive and appropriate? Is the document easy to use? Style Is the style of the prose appropriate for the discourse community it is intended? After working through all of these different criteria, I find that there are still students who teeter on the edge between one grade or another. In such cases, I use the following criteria to decide whether to bump up or drop the student s grade. If you teeter between an A and a B, I look to see if one or more of your major projects is polished to a high sheen, that is there are virtually no changes left to be made on it. I am also influenced by extremely ambitious projects, but am most strongly swayed when at least one thing you ve written is stellar. 5
If you fall between a B and a C, I look particularly at the ambition of your projects. If these (or at least two of these) are substantial and ambitious, I will probably bump your grade up. If you fall between a C and a D I look at class participation and to a lesser degree at the nature of your projects. If you have participated regularly and if your projects started out as good ideas aimed at real organizations which for one reason or another have gone south, I will probably give you a C. 6