<?xml version="1.0" encoding="utf-8" ?><rss version="2.0" xmlns:atom="http://www.w3.org/2005/Atom">
<channel>
	<title>Articles&gt;Editing&gt;Technical Writing</title>	<link>http://tc.eserver.org/dir/Articles/Editing/Technical-Writing</link>
	<description>A listing of the most recently indexed works about Articles and Editing and Technical Writing in the field of technical communication (and technical writing).</description>
	<language>en-us</language>
	<copyright>Copyright (c) 2005-08 by the EServer. All rights reserved.</copyright>
	<managingEditor>tclib-editorial@eserver.org (TC Library Editorial Board)</managingEditor>
	<webMaster>webmaster@eserver.org (Geoffrey Sauer)</webMaster>
	<image>
		<url>http://tc.eserver.org/images/newlogo.gif</url>
		<title>Articles&gt;Editing&gt;Technical Writing</title>
		<link>http://tc.eserver.org/dir/Articles/Editing/Technical-Writing</link>
	</image>
	<item>
		<title>Writing Great Documentation: You Need an Editor</title>
		<link>http://tc.eserver.org/35710.html</link>
		<guid>http://tc.eserver.org/35710.html</guid>
		<description>All good writers have a dirty little secret: they’re not really that good at writing. Their editors just make it seem that way. It doesn’t matter how well you’ve mastered the language; nobody, even grammar geeks, gets this stuff right on the first pass. If you really want to produce great documentation, it needs to be edited.</description>
	</item>
	<item>
		<title>Editing Modular Documentation: Some Best Practices</title>
		<link>http://tc.eserver.org/32036.html</link>
		<guid>http://tc.eserver.org/32036.html</guid>
		<description>Much has been said about the creation of modular documentation - from content management systems, to information architecture, to delivery forms, to the usability of modular content (content being easier to use, easier to understand, and easier to find), and so on. However, not much has been said about the editing of that content, and what the editor&apos;s role is in such an environment.</description>
	</item>
	<item>
		<title>Tech Writers, Grammar, and the Prescriptive Attitude</title>
		<link>http://tc.eserver.org/32043.html</link>
		<guid>http://tc.eserver.org/32043.html</guid>
		<description>Prescriptive grammar is useful for teaching English as a second language, but it has little value for the practicing writer. Clinging to it may provide emotional security, but only at the expense of making writing harder than it needs to be. The culture-wide devotion to it will not be changed in a moment. But conscientious writers can at least change their own habits, and make life easier for themselves.</description>
	</item>
	<item>
		<title>Technical Writing&apos;s Big Secret</title>
		<link>http://tc.eserver.org/31939.html</link>
		<guid>http://tc.eserver.org/31939.html</guid>
		<description>The big secret in technical writing is that most of the harder documents aren&apos;t written by the technical writers at all. In fact, many &quot;technical writers&quot; never do any writing at all. Instead, the drafts are written by engineers or marketers. The technical writers perform editorial functions and provide publications services -- copy-editing, layout, review management, and so on.</description>
	</item>
	<item>
		<title>Developing Indexes</title>
		<link>http://tc.eserver.org/31098.html</link>
		<guid>http://tc.eserver.org/31098.html</guid>
		<description>As a technical writer, you&apos;ll typically have to create indexes for the print books and for online helps you develop. The type of index we mean here is the classic back-of-book index that shows page numbers on which topics and subtopics occur within the book. An online index is much the same except that you supply hypertext links rather than page numbers.</description>
	</item>
	<item>
		<title>Hockey Sticks and User Assistance: Writing in Times of Resource Constraints</title>
		<link>http://tc.eserver.org/30818.html</link>
		<guid>http://tc.eserver.org/30818.html</guid>
		<description>If you have all the resources you need, do the very best job you can in all respects. But if your resources are tight, ask yourself whether you are writing the essential stuff at a level of quality users will notice. Also, ask whether the value of the documentation you are producing aligns with the economic pressures on your company.</description>
	</item>
	<item>
		<title>Editing Yourself</title>
		<link>http://tc.eserver.org/30361.html</link>
		<guid>http://tc.eserver.org/30361.html</guid>
		<description>Here are some tips that helped me edit my own writing.</description>
	</item>
	<item>
		<title>Experiencing Technical Writing as Textual Coordination</title>
		<link>http://tc.eserver.org/29647.html</link>
		<guid>http://tc.eserver.org/29647.html</guid>
		<description>This paper describes a recent study of how of four technical writers managed the many artifacts (existing texts and information technologies for producing and manipulating text) that mediated their writing process. The author describes the study and characterizes several recurrent patterns of mediation, including textual reuse, remediation of information, and the staging of texts and software programs. The author describes the value of a repertoire of information technologies to technical writing and argues that technological skill should be considered a core competency of the field.</description>
	</item>
	<item>
		<title>Now That You&apos;ve Got a Double Agent, What Do You Do With &apos;Em?</title>
		<link>http://tc.eserver.org/27461.html</link>
		<guid>http://tc.eserver.org/27461.html</guid>
		<description>Having demonstrated the importance of acquiring a double agent for writing projects, we now want to explain the best ways to successfully indoctrinate a double agent. This paper will help you prepare for, orient, train, and become a mentor for a double agent to help make him or her an effective member of your writing team.</description>
	</item>
	<item>
		<title>Technischer Redakteur</title>
		<link>http://tc.eserver.org/26967.html</link>
		<guid>http://tc.eserver.org/26967.html</guid>
		<description>Der Technische Redakteur erstellt und aktualisiert aussagefähige, umsetzbare, verständliche technische Dokumentationen aller Art.</description>
	</item>
	<item>
		<title>The Fault of Vacuity</title>
		<link>http://tc.eserver.org/24197.html</link>
		<guid>http://tc.eserver.org/24197.html</guid>
		<description>I labeled wordiness the most obvious fault in technical writing. In retrospect, I think I was wrong. I believe the greatest fault our writing can have is vacuity, or lack of substance. We too often write words that say nothing.</description>
	</item>
	<item>
		<title>Technical Translation: Craft, Not Commodity</title>
		<link>http://tc.eserver.org/22791.html</link>
		<guid>http://tc.eserver.org/22791.html</guid>
		<description>Describes the work of translators and suggests strategies buyers can use to find the best translator for their needs.</description>
	</item>
	<item>
		<title>Grammar Stammer</title>
		<link>http://tc.eserver.org/22691.html</link>
		<guid>http://tc.eserver.org/22691.html</guid>
		<description>Don&apos;t you think that it is a tragedy that 95 percent of the people who desire to be technical writers have a poor command over the language? I am sure all of us make a mistake or two, once in a while. But to make it in every sentence and paragraph shows utter disrespect for readers.</description>
	</item>
	<item>
		<title>Learning the Fine Art of Reviewing</title>
		<link>http://tc.eserver.org/22690.html</link>
		<guid>http://tc.eserver.org/22690.html</guid>
		<description>If you asked me what the most painful part of being a technical writer is, my answer would be: &apos;Getting reviews on time. Getting good feedback and inputs on your work.&apos; For me technical writing has been very pleasurable because I hardly got any review comments. My morale has therefore been very high. Project managers, developers and others are so busy trying to come up with good software (read trying to fix all the goof-ups and bugs!) that they usually tend to give documentation lesser importance. User manuals, who reads them anyway? We do not have time for it!</description>
	</item>
	<item>
		<title>One Hundred Simple Tech Writing Errors</title>
		<link>http://tc.eserver.org/22687.html</link>
		<guid>http://tc.eserver.org/22687.html</guid>
		<description>Here are the 100 writing errors that the author has encountered in his experience. (Followed by the subsequent article &apos;&lt;a href=&quot;http://tc.eserver.org/22688.html&quot;&gt;Ten More Errors in Technical Writing&lt;/a&gt;.&apos;)</description>
	</item>
	<item>
		<title>Ten More Errors in Technical Writing</title>
		<link>http://tc.eserver.org/22688.html</link>
		<guid>http://tc.eserver.org/22688.html</guid>
		<description>So, well, here are 10 more errors. This time we will focus on grammar and punctuation. Most of these are simplistic and obvious. But then they are too common. As usual, I have slipped in some content for the advanced writers too. (This article is a follow-up to &apos;&lt;a href=&quot;http://tc.eserver.org/22687.html&quot;&gt;One Hundred Simple Tech Writing Errors&#xD;&lt;/a&gt;.)</description>
	</item>
	<item>
		<title>Alternatives to the Paragraph</title>
		<link>http://tc.eserver.org/22128.html</link>
		<guid>http://tc.eserver.org/22128.html</guid>
		<description>&apos;It&apos;s all in the manual.&apos; How many times have you heard that - or said it in frustration? After all, when you are the person who wrote the manual, you know that all the answers are there. But time and again readers can&apos;t find what they need to know, or don&apos;t understand the material. Before you blame the reader, look again at how you&apos;ve presented the material.</description>
	</item>
	<item>
		<title>The Role of the Editor in the Technical Writing Team</title>
		<link>http://tc.eserver.org/22113.html</link>
		<guid>http://tc.eserver.org/22113.html</guid>
		<description>Editing today covers far more than printed materials. In this discussion, I am assuming a technical editor may be required to deal with: printed materials (for example, books, pamphlets, quick reference cards); electronic (for example, online documentation, online help, web pages); video scripts; computer-based training materials. I am also assuming that the audience for the material being edited is not comprised of other technical people; or if it is, the editor is not the person responsible for ensuring the technical accuracy of the material.</description>
	</item>
	<item>
		<title>Editing Your Own Documentation</title>
		<link>http://tc.eserver.org/21411.html</link>
		<guid>http://tc.eserver.org/21411.html</guid>
		<description>Technical writers sometimes fall into the trap of thinking that the user is stupid. I have often heard technical writers say things like &apos;well, if the user can&apos;t figure that out, maybe he’s in the wrong job!&apos;</description>
	</item>
	<item>
		<title>How to Edit for Content</title>
		<link>http://tc.eserver.org/19673.html</link>
		<guid>http://tc.eserver.org/19673.html</guid>
		<description>Editing involves more than just formatting and inserting page numbers. You need to ask, &apos;How can I improve the communication?&apos;&#xD;</description>
	</item>
	<atom:link href="http://tc.eserver.org/dir/Articles/Editing/Technical-Writing.xml" rel="self" type="application/rss+xml"/>
</channel>
</rss>