<?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 Editing</title>	<link>http://tc.eserver.org/dir/Articles/Editing/Technical-Editing</link>
	<description>A listing of the most recently indexed works about Articles and Editing and Technical Editing in the field of technical communication.</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 Editing</title>
		<link>http://tc.eserver.org/dir/Articles/Editing/Technical-Editing</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>Understanding the Value of a Technical Editor</title>
		<link>http://tc.eserver.org/35639.html</link>
		<guid>http://tc.eserver.org/35639.html</guid>
		<description>Not all companies understand why it&apos;s important for them to have technical editor(s). In fact, many technical editors must justify their existence on a regular basis.</description>
	</item>
	<item>
		<title>Demonstrating the Value of Editing</title>
		<link>http://tc.eserver.org/35640.html</link>
		<guid>http://tc.eserver.org/35640.html</guid>
		<description>Like all other technical communicators, we editors must sometimes struggle to prove our worth to employers. We know our value, and the more clueful of our authors understand, but sometimes it takes a bit more work to convince senior managers that we serve a useful purpose. Managers generally require specific examples, usually supported by hard numbers. In this article, I’ve provided a few random facts and figures that I’ve accumulated over the years that you can share with management.</description>
	</item>
	<item>
		<title>Creating an Anthology on Editing</title>
		<link>http://tc.eserver.org/35007.html</link>
		<guid>http://tc.eserver.org/35007.html</guid>
		<description>Pulling together New Perspectives on Technical Editing, an anthology on editing, was a complex, yet exhilarating experience. The process fell into four stages.</description>
	</item>
	<item>
		<title>Paper, Screen, or Scissors? Editing on Hard Copy or Soft Copy</title>
		<link>http://tc.eserver.org/35008.html</link>
		<guid>http://tc.eserver.org/35008.html</guid>
		<description>The question posted in our discussion list: Should editors edit on hard copy or soft copy? The answer: Yes. Or, it depends. Essentially it is not a matter of should; it is a matter of personal preference and what works best in different situations.</description>
	</item>
	<item>
		<title>Why the Focus on Review Practices?</title>
		<link>http://tc.eserver.org/34793.html</link>
		<guid>http://tc.eserver.org/34793.html</guid>
		<description>improving document review practices is of great concern to many in the biopharmaceutical industry.  The reason for this interest can be explained by the following observations which provide some insight as to why review is, or needs to be, a central focus for improving knowledge propagation and dissemination.</description>
	</item>
	<item>
		<title>Creating Perspective Shadows</title>
		<link>http://tc.eserver.org/33545.html</link>
		<guid>http://tc.eserver.org/33545.html</guid>
		<description>Perspective—it’s one of the first things you learn about in any art class. The basic idea is that it’s the way your eye actually sees something, represented on a flat surface such as paper or a monitor. A simple example is drawing a group of objects: You represent an object in the distance by making it smaller, while making objects close to the viewer larger—make sense?&#xD;&#xD;In this tutorial, I’m going to show you how to create perspective shadows in Adobe Photoshop CS3. The result is dynamic, but the technique is a breeze!</description>
	</item>
	<item>
		<title>Jabberwock</title>
		<link>http://tc.eserver.org/32134.html</link>
		<guid>http://tc.eserver.org/32134.html</guid>
		<description>Technical editors are constantly required to edit and revise pieces that they don’t fully understand - or even have much information about. That’s part of the game.</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>Syntax or Sin Tax: Which Should an Editor Choose?</title>
		<link>http://tc.eserver.org/29689.html</link>
		<guid>http://tc.eserver.org/29689.html</guid>
		<description>Proficiency and accuracy are necessary to edit technical communication, but both can be diminished by the conflict of standards and rules from respected sources. This difficulty is further compounded with the differing expectations of audiences, employers, and companies. To resolve potential problems, editors need to refresh their basic skills through workshops, professional journal articles, and the study of updated authoritative sources. Editors then need to address their audience expectations by developing appropriate style guides. By focusing upon the needs of the audience, editors draw upon a variety of sources, some of which may not agree upon the same standards and rules. In such cases, the editor may also break or bend rules to achieve the consistent, accurate communications that best serve the individual audience.</description>
	</item>
	<item>
		<title>The Art Of Editing: User&apos;s Guides Versus Technical Documents</title>
		<link>http://tc.eserver.org/30287.html</link>
		<guid>http://tc.eserver.org/30287.html</guid>
		<description>While contemplating topic areas for a presentation at this year&apos;s conference, our biggest challenge was the fact that not all technical editors edit the same type of documents. Presentations at STC conferences are heavily concentrated toward user documentation and software instructional manuals. With that as our prime focus, we identified six common elements that we both consider as we edit a document. We then compared our methods of approaching these elements. One of us edits primarily user&apos;s guides and procedural manuals; the other edits scientific and technical documents.</description>
	</item>
	<item>
		<title>Substantive and Technical Editing: How Far Do You Go?</title>
		<link>http://tc.eserver.org/29256.html</link>
		<guid>http://tc.eserver.org/29256.html</guid>
		<description>Authors who cannot answer queries create a barrier to improvement of manuscripts. Some authors resist the idea that their papers might need major changes. Other authors depend on the editor to make changes that the author can and should make. Language barriers can require creative solutions. Also, there is the question of how far to go as an editor in reframing a report (for example, should an editor reframe the purpose of a paper?) and in correcting an author&apos;s errors (for example, a claim of a trend when none is shown).</description>
	</item>
	<item>
		<title>A SIG Transformation: Past, Present, and Future</title>
		<link>http://tc.eserver.org/28164.html</link>
		<guid>http://tc.eserver.org/28164.html</guid>
		<description>A recent discussion about the STC&apos;s Technical Editing Special Interest Group (TE SIG) provided insights into the evolving role of communities of interest in the Society. At a meeting of the Carolina Chapter&apos;s local TE SIG, Diane Feldman, who is the manager of the Society-level SIG, provided members with an update on SIG activities.</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>Indexing Technical Documents: An Interview with Lori Lathrop</title>
		<link>http://tc.eserver.org/26025.html</link>
		<guid>http://tc.eserver.org/26025.html</guid>
		<description>Indexes are as important to your documentation as your documentation is to the product. Just as it would be difficult, if not impossible, for people to use your product without any documentation, it is equally difficult for people to use documentation without a good index.</description>
	</item>
	<item>
		<title>Controlled Languages in Industry</title>
		<link>http://tc.eserver.org/25310.html</link>
		<guid>http://tc.eserver.org/25310.html</guid>
		<description>A Controlled Language is a form of language with special restrictions on grammar, style, and vocabulary usage. Typically, the restrictions are placed on technical documents, including instructions, procedures, descriptions, reports, and cautions. One might consider formal written English to be the ultimate Controlled Language: a form of English with restricted word and grammar usages, but a standard too broad and too variable for use in highly technical domains. Whereas formal written English applies to society as a whole, CLs apply to the specialized sublanguages of particular domains.</description>
	</item>
	<item>
		<title>Substantive Editing: With an Eye on the User</title>
		<link>http://tc.eserver.org/24910.html</link>
		<guid>http://tc.eserver.org/24910.html</guid>
		<description>This workshop focuses on substantive editing with workshop materials that show fast and easy ways to analyze a piece of writing, especially writing that needs the concentrated effort of both the editor and the writer to turn it into a usable document. The workshop is practical in its focus providing tips, checklists, and techniques for approaching material that needs a heavy substantive edit.</description>
	</item>
	<item>
		<title>Seven Discrete Principles for Content Editing</title>
		<link>http://tc.eserver.org/24611.html</link>
		<guid>http://tc.eserver.org/24611.html</guid>
		<description>One of many lessons I learned in 30 years of Technical Editing was to separate myself from the crowd by learning to edit technical content, using seven reader-oriented techniques.</description>
	</item>
	<item>
		<title>Mystery Fiction and the Technical Communicator: The Editor&apos;s Role</title>
		<link>http://tc.eserver.org/24352.html</link>
		<guid>http://tc.eserver.org/24352.html</guid>
		<description>Technical editors can learn much from editors of mystery fiction. Both orchestrate elaborate game-playing and structuring as they serve as the reader&apos;s advocate.</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>Ask the Indexer: Get Answers to your Indexing Questions from Experienced Technical Indexers</title>
		<link>http://tc.eserver.org/23799.html</link>
		<guid>http://tc.eserver.org/23799.html</guid>
		<description>After brief introductions by 4 panelists who are all members of the Indexing SIG (and experienced indexers and technical writers), we&#xD;plan to discuss Frequently Asked Questions (FAQs) about indexing, and allow plenty of time for questions.</description>
	</item>
	<item>
		<title>Knowledge Management - Challenge for Technical Editors</title>
		<link>http://tc.eserver.org/23453.html</link>
		<guid>http://tc.eserver.org/23453.html</guid>
		<description>Knowledge management - is it a challenge for technical editors? Shouldn&apos;t knowledge management be more than just taken for granted in technical editing? And isn&apos;t the technical editor also the knowledge manager, per se?</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>Editing Tables of Data</title>
		<link>http://tc.eserver.org/22125.html</link>
		<guid>http://tc.eserver.org/22125.html</guid>
		<description>Tables should allow readers to easily and accurately: see what subject matter and variables are being described; find out absolute values; observe relationships between variables. When you edit a table, it is useful to assess just how well it achieves these ends. Readers will feel confident with your table if they can quickly navigate around and absorb the data.</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>Working Electronically</title>
		<link>http://tc.eserver.org/22117.html</link>
		<guid>http://tc.eserver.org/22117.html</guid>
		<description>Editors need to know some basic techniques for dealing with files if they are going to be editing them electronically. These techniques apply to files in any format, but exactly what you do depends on which word-processor, desktop publishing program, help authoring system, or other software you are using.</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>Indexing Technical Documents</title>
		<link>http://tc.eserver.org/21380.html</link>
		<guid>http://tc.eserver.org/21380.html</guid>
		<description>If a document contains the information that a reader needs, but if the reader cannot find that information, then the document is useless. Worse than useless, it’s a hindrance. If I know that some information is not available, I won’t waste my time looking for it. However, if I think the information is available, and if I can’t find it after a period of fruitless searching, all I will have achieved is frustration.</description>
	</item>
	<item>
		<title>Coping with Wordslaughter and the &quot;Good Enough&quot; Syndrome</title>
		<link>http://tc.eserver.org/21317.html</link>
		<guid>http://tc.eserver.org/21317.html</guid>
		<description>Connatser provides advice for technical editors who aren&apos;t granted enough time or money to perform extensive revisions on poorly written documents.</description>
	</item>
	<item>
		<title>Let Editors Edit&#xD;</title>
		<link>http://tc.eserver.org/21305.html</link>
		<guid>http://tc.eserver.org/21305.html</guid>
		<description>We technician editors need not worry about declining employment if we can show companies the value of the technology of English. If we can demonstrate how editors can make turgid technical authors communicate better with words, sentences, paragraphs, and overall organization, we will be in demand for jobs that are more prestigious and careers that are infinitely more interesting -- because the need is so great.</description>
	</item>
	<item>
		<title>The ABCs of Writing a Technical Glossary</title>
		<link>http://tc.eserver.org/21216.html</link>
		<guid>http://tc.eserver.org/21216.html</guid>
		<description>This article identifies and explains format rules, style rules, and lexicographic conventions that have been shown to improve clarity and precision in a technical glossary. Rationale for the rules of language, presentation, and style are examined. The need to allow flexibility in following the rules is discussed in terms of strengthening the technical merit and vitality of the glossary.&#xD;&#xD;&#xD;This article also describes the computer-display techniques and file-management system used in committee to develop U.S. Federal Standard 1037C, Glossary of telecommunication terms, and to display the results both in the meeting room and on the Internet between meetings.</description>
	</item>
	<item>
		<title>Technical Editors: Are We Are Own Worst Enemies? Strategies For Working With Authors</title>
		<link>http://tc.eserver.org/20751.html</link>
		<guid>http://tc.eserver.org/20751.html</guid>
		<description>The authors explore two studies of cognitive assessments, the Myers Briggs Type Indicator and Boundary Spanning of technical communicators, give readers an opportunity to score themselves, and then they argue that knowing the cognitive differences between technical communicators and the authors they edit can help them&#xD;improve working relationships with authors. When&#xD;copyediting, they suggest making suggestions rather than&#xD;dictates; providing rationale for suggestions; basing&#xD;suggested changes on style guides, standard references&#xD;and communication research; and using a levels- of-edit&#xD;approach.</description>
	</item>
	<item>
		<title>Situational Editing: A Rhetorical Approach for the Technical Editor</title>
		<link>http://tc.eserver.org/20571.html</link>
		<guid>http://tc.eserver.org/20571.html</guid>
		<description>Argues that the rhetorical approach to communication considers situations individually and is necessary for technical editors because their work comprises a series of individual rhetorical decisions.&#xD;&#xD;Proposes a rhetorical theory of technical editing.</description>
	</item>
	<item>
		<title>Editing Mathematics</title>
		<link>http://tc.eserver.org/20190.html</link>
		<guid>http://tc.eserver.org/20190.html</guid>
		<description>Editing mathematics is like editing a foreign language, with its own conventions, symbols, and rules of grammar. Various typographic rules must be followed&#xD;exactly since deviations from them change the meaning&#xD;of the material. Like poetry, placement of the&#xD;information on the page is important for the meaning.&#xD;The editor often must be a cryptographer, decoding&#xD;esoteric handwritten material.</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>
	<item>
		<title>The Technical Editor and Document Databases: What the Future May Hold</title>
		<link>http://tc.eserver.org/13835.html</link>
		<guid>http://tc.eserver.org/13835.html</guid>
		<description>Technical editors ensure a document communicates with the reader.  With XML, active server pages, and dynamic document creation, Web pages are no longer simple hand-crafted text objects, but dynamic groupings of text assembled moments before the reader views the page.  With dynamic documents, high-level editing tasks will be, at best, vaguely defined during text creation.  To maximize the information content, future technical editors require tighter control over information consistency and content.</description>
	</item>
	<atom:link href="http://tc.eserver.org/dir/Articles/Editing/Technical-Editing.xml" rel="self" type="application/rss+xml"/>
</channel>
</rss>