<?xml version="1.0" encoding="utf-8" ?><rss version="2.0" xmlns:atom="http://www.w3.org/2005/Atom">
<channel>
	<title>Technical Editors Eyrie</title>	<link>http://tc.eserver.org/publisher/Technical_Editors_Eyrie</link>
	<description>A listing of works published by Technical Editors Eyrie 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>Technical Editors Eyrie</title>
		<link>http://tc.eserver.org/dir/Technical_Editors_Eyrie</link>
	</image>
	<item>
		<title>Beyond Copy-Editing: The Editor-Writer Relationship</title>
		<link>http://tc.eserver.org/24233.html</link>
		<guid>http://tc.eserver.org/24233.html</guid>
		<description>Editing is often narrowly defined as making corrections after a document is written. This approach typically relegates the editor to a low-status role within the organisation.</description>
	</item>
	<item>
		<title>Editing for an International Audience</title>
		<link>http://tc.eserver.org/22133.html</link>
		<guid>http://tc.eserver.org/22133.html</guid>
		<description>Here are some things to consider when editing for an international audience.</description>
	</item>
	<item>
		<title>Electronically Indicating Approvals or Rejections of Editorial Changes</title>
		<link>http://tc.eserver.org/22136.html</link>
		<guid>http://tc.eserver.org/22136.html</guid>
		<description>This technique (involving two macros) works in Word97, but not in Word6 or 7/95. The requirement is to indicate (for audit purposes) whether an editorial change was accepted or rejected by the author or other authority.</description>
	</item>
	<item>
		<title>Gender-Neutral Technical Writing</title>
		<link>http://tc.eserver.org/22132.html</link>
		<guid>http://tc.eserver.org/22132.html</guid>
		<description>In recurring discussions on the TECHWR-L list, many technical writers argue that they write in &apos;correct English&apos; and are not going to change their style just to suit the political-correctness police. &apos;I won&apos;t use &apos;they&apos; as a singular pronoun because it&apos;s not grammatically correct&apos; and &apos;Using contrived phrases such as &apos;s/he&apos; is just too awkward&apos; are arguments I&apos;ve heard frequently in the debate. But using &apos;incorrect English&apos; or contrived phrases is neither the goal nor the outcome of gender-neutral writing.</description>
	</item>
	<item>
		<title>Stressing What is Important in a Sentence</title>
		<link>http://tc.eserver.org/22131.html</link>
		<guid>http://tc.eserver.org/22131.html</guid>
		<description>In addition to expunging the usual collection of wordy phrases from documents, editors commonly attempt to tighten up writing to make it more direct, clear, and concise. For example, when editing business and technical material, I frequently change sentences containing &apos;it is,&apos; &apos;there is,&apos; and &apos;there are.&apos; Writers often ask me &apos;what was wrong with that sentence?&apos; I reply that although the sentence wasn&apos;t wrong grammatically, such phrases distract the reader from the important part of the message.</description>
	</item>
	<item>
		<title>Terminology and Spelling for Web-Related Concepts</title>
		<link>http://tc.eserver.org/22135.html</link>
		<guid>http://tc.eserver.org/22135.html</guid>
		<description>Generally speaking, &apos;Web&apos; as a short form of &apos;World Wide Web&apos; is capitalized, with one exception (webmaster). However, your company style may prefer the lower-case version.</description>
	</item>
	<item>
		<title>Use of Hyphens</title>
		<link>http://tc.eserver.org/22134.html</link>
		<guid>http://tc.eserver.org/22134.html</guid>
		<description>This page collects a series of notes from readers of my newsletter, and my responses to those notes, arising from an article in &lt;A HREF=&quot;http://www.jeanweber.com/news/tenews60.htm&quot;&gt;issue 60, 13 May 2002&lt;/A&gt;. I thank those who took the time to write and explain &lt;i&gt;why&lt;/i&gt; some hyphen usage is considered to be correct or incorrect.</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>Audience and Document Analysis</title>
		<link>http://tc.eserver.org/22116.html</link>
		<guid>http://tc.eserver.org/22116.html</guid>
		<description>Before you begin editing a document, try to find out as much as you can about the audience for the document and purpose of the document.</description>
	</item>
	<item>
		<title>Choosing and Using Help Topics</title>
		<link>http://tc.eserver.org/22119.html</link>
		<guid>http://tc.eserver.org/22119.html</guid>
		<description>This paper describes some common types of help topic and when to use each. Different applications require different mixes of help topics. Choose the topic types that are appropriate for the application you are documenting.</description>
	</item>
	<item>
		<title>Deciding What Needs to be Done</title>
		<link>http://tc.eserver.org/22115.html</link>
		<guid>http://tc.eserver.org/22115.html</guid>
		<description>Before you begin editing a document, you need to analyse it and plan what needs to be done. The exception is when your job is strictly limited (by your supervisor or the client) to correcting only the glaring errors of spelling, punctuation and grammar (a &apos;light edit&apos;). There is no point to attempting a more substantive edit if doing so will only get you into trouble (or if the client won&apos;t pay you for the time you spend).</description>
	</item>
	<item>
		<title>Editing Reports and Proposals</title>
		<link>http://tc.eserver.org/22124.html</link>
		<guid>http://tc.eserver.org/22124.html</guid>
		<description>Businesses, non-profit organizations, government departments, and other groups produce a lot of proposals and reports. This article summarizes some features of reports and proposals that are not the same as books, news items, manuals, magazine articles, memos and many other documents.</description>
	</item>
	<item>
		<title>Editing Single-Sourced Projects</title>
		<link>http://tc.eserver.org/22126.html</link>
		<guid>http://tc.eserver.org/22126.html</guid>
		<description>This article does not address the (important) questions of when a single-sourcing methodology is a good solution to an information delivery problem (&apos;good&apos; here meaning saving time and money while maintaining or improving the quality of the resulting deliverables). Instead, I&apos;m looking only at the editor&apos;s involvement in the project.</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>An Example of Substantive Editing</title>
		<link>http://tc.eserver.org/22122.html</link>
		<guid>http://tc.eserver.org/22122.html</guid>
		<description>Some years ago I edited a quarterly magazine for the users of a large Australian computing network. This example (from 1985) is fairly typical of the technical articles I received from department managers. I include here the unedited text and my revised version.</description>
	</item>
	<item>
		<title>Hints for Developing a Table of Contents</title>
		<link>http://tc.eserver.org/22127.html</link>
		<guid>http://tc.eserver.org/22127.html</guid>
		<description>Planning a project before beginning the detailed work is one of the vital steps to success in technical communication. Developing a table of contents is one of the steps in the planning process of a document. </description>
	</item>
	<item>
		<title>Planning an Electronic Performance Support System Project</title>
		<link>http://tc.eserver.org/22120.html</link>
		<guid>http://tc.eserver.org/22120.html</guid>
		<description>Electronic performance support systems are software programs that directly support a worker&apos;s ability to perform tasks. Such systems go beyond passive task-oriented online help. To be effective, EPS systems should be closely interlocked with the supported product&apos;s user interface and its online help. This paper outlines some of the planning considerations and steps involved in an EPSS project, and some of the problems and complications that arose during a specific project.</description>
	</item>
	<item>
		<title>Planning an Online Help Project</title>
		<link>http://tc.eserver.org/22118.html</link>
		<guid>http://tc.eserver.org/22118.html</guid>
		<description>This paper outlines some general principles you need to consider when planning an online help project and creating WinHelp files.</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>&quot;Use Cases&quot; and &quot;User Scenarios&quot; Explained</title>
		<link>http://tc.eserver.org/22121.html</link>
		<guid>http://tc.eserver.org/22121.html</guid>
		<description>This file contains the responses I received to a message I sent on January 21, 2000 to the TECHWR-L and WINHLP-L discussion lists. It was posted on the Techwhirl website for awhile but was removed during a reorganisation of the site. Other people&apos;s comments are included with their permission.</description>
	</item>
	<item>
		<title>Using Style Sheets</title>
		<link>http://tc.eserver.org/22114.html</link>
		<guid>http://tc.eserver.org/22114.html</guid>
		<description>Style sheets supplement the style manual (if there is one). You might also use one to summarise vital information for your own reference or to give to an editor. Record on a style sheet any decisions made for a particular product or publication.</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>Taming OpenOffice.org Writer 1.1: Tips and Tricks for Academic, Technical, and Business Writers</title>
		<link>http://tc.eserver.org/21723.html</link>
		<guid>http://tc.eserver.org/21723.html</guid>
		<description>This book is for intermediate and advanced users of OpenOffice.org Writer. You may not have used this program before, but you have used another word processor (such&#xD;as Microsoft Word or Corel WordPerfect) and you are familiar with the basics of word&#xD;processing.&#xD;Typical users include academic writers, technical writers, and other business and&#xD;professional writers—anyone who produces books, research papers, proposals, or&#xD;other documents requiring the use of more than the basic features. For example, you&#xD;need to use styles instead of direct formatting of headings and other paragraphs, and&#xD;you need to include chapter information in the footers of pages, or you want to use&#xD;master documents to control a book containing many chapters, perhaps written by&#xD;different people.</description>
	</item>
	<item>
		<title>Courses for Technical Editors in Australia</title>
		<link>http://tc.eserver.org/13722.html</link>
		<guid>http://tc.eserver.org/13722.html</guid>
		<description>I don&apos;t know of any tertiary-level courses in Australia specifically for technical editors, although there are several programs for general editors or journalists. I&apos;ll add information to this page as I find it. </description>
	</item>
	<item>
		<title>Discussion Groups, Newsletters, and Related Websites</title>
		<link>http://tc.eserver.org/13721.html</link>
		<guid>http://tc.eserver.org/13721.html</guid>
		<description>A collection of links to online technical editors&apos; communities.</description>
	</item>
	<item>
		<title>Editing Macros for Word and WordPerfect</title>
		<link>http://tc.eserver.org/13723.html</link>
		<guid>http://tc.eserver.org/13723.html</guid>
		<description>Useful resources on a variety of relevant topics, including a collection of macros for Microsoft Word and links to a selection of Word resources.</description>
	</item>
	<item>
		<title>Grammar, Punctuation, Spelling</title>
		<link>http://tc.eserver.org/13719.html</link>
		<guid>http://tc.eserver.org/13719.html</guid>
		<description>The Web abounds with sites teaching grammar, punctuation, and spelling. Not surprisingly, most of these sites are provided by educational institutions, teachers, or business-writing consultants, presumably to make up for the lack of grammar teaching in so many school systems for the past several decades. Some are tutorials (masquerading as style guides) for technical communicators. Here are a few sites that I have found useful or that other people have recommended to me.</description>
	</item>
	<item>
		<title>Resources for Editors and Writers of Websites</title>
		<link>http://tc.eserver.org/13720.html</link>
		<guid>http://tc.eserver.org/13720.html</guid>
		<description>This &apos;starter list&apos; was originally compiled for a presentation on editing websites given at the Australian Society for Technical Communication (ASTC) annual conference in Sydney, NSW, Australia on 30 October 1998. Several of the sites listed have quite extensive lists of links to further information</description>
	</item>
	<item>
		<title>Editing for Gender Neutrality</title>
		<link>http://tc.eserver.org/10807.html</link>
		<guid>http://tc.eserver.org/10807.html</guid>
		<description>How to be politically correct without mangling the English language. The goal is that the reader should not notice the writing.  </description>
	</item>
	<item>
		<title>The Technical Editors&apos; Eyrie</title>
		<link>http://tc.eserver.org/10041.html</link>
		<guid>http://tc.eserver.org/10041.html</guid>
		<description>The newsletter is intended for editors who are, or need to be, working electronically. Much of the material will be relevant to electronic editors in any field. Some of the material will be most relevant to editors in technical fields such as computing and engineering.</description>
	</item>
	<atom:link href="http://tc.eserver.org/publisher/Technical_Editors_Eyrie.xml" rel="self" type="application/rss+xml"/>
</channel>
</rss>