<?xml version="1.0" encoding="UTF-8"?><rss version="2.0" xmlns:atom="http://www.w3.org/2005/Atom">
categoryallspace2-Articles Editing
<channel>
	<title>Articles&gt;Editing</title>	<link>http://tc.eserver.org/dir/Articles/Editing</link>
	<description>A directory of resources about articles and editing in the field of technical communication.</description>
	<language>en-us</language>
	<atom:link href="http://tc.eserver.org/dir/Articles/Editing.xml" rel="self" type="application/rss+xml" />
	<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</title>
		<link>http://tc.eserver.org/dir/Articles/Editing</link>
	</image>
	<item>
		<title>Good Writing and Editing: Are They Dying Arts? And, Should We Care?</title>
		<link>http://tc.eserver.org/31516.html</link>
		<guid>http://tc.eserver.org/31516.html</guid>
		<description>The answer to both questions: &quot;YES!&quot; Like us, you may be dismayed by the growing quantity of poor writing that bombards us. We see it everywhere, in publications, web sites, newspapers and corporate materials—writing that is not just full of grammatical mistakes and misused words, but is also poorly thought-out, unclear and contains downright confusing language.</description>
	</item>
	<item>
		<title>Editing Your Own Work</title>
		<link>http://tc.eserver.org/31416.html</link>
		<guid>http://tc.eserver.org/31416.html</guid>
		<description>One of the most difficult things a writer can do is to edit his or her own work. It&apos;s great to have someone else, preferably a trained editor, review what you&apos;ve written. But you may not always have that luxury, and even if you do, you should never be satisfied with a first draft.</description>
	</item>
	<item>
		<title>Editing Your Own Work, Part II</title>
		<link>http://tc.eserver.org/31432.html</link>
		<guid>http://tc.eserver.org/31432.html</guid>
		<description>Someone once asked Lillian Hellman what was hardest about writing. &quot;Killing your little darlings,&quot; she said. For a playwright, &quot;the little darling&quot; can be a favorite character or a hard-fought scene or a bit of sparkling dialogue—anything that, while dear to one&apos;s heart, doesn&apos;t contribute to the dominant theme. A similar challenge faces every writer, whether we work in the realm of reportage, marketing or employee communication.</description>
	</item>
	<item>
		<title>Final Check: Dotting Those i’s and Crossing Those t’s</title>
		<link>http://tc.eserver.org/31226.html</link>
		<guid>http://tc.eserver.org/31226.html</guid>
		<description>You’ve worked long and hard on your article, newsletter, press release, promo brochure or report. Now it’s time to move your baby off your screen and into the world. Not so long ago your baby would have gone either onto a printed page or onto the Web. These days, your words will probably head for both. Even materials such as newsletters, white papers, reports and advertorials that are first published on paper are quite likely to be reprinted, archived or otherwise reused on the Web, perhaps even as an audio file or podcast. People may even blog about your content.&#xD;&#xD;What does this mean for you as a business communicator?</description>
	</item>
	<item>
		<title>Combine Writing, Editing and Design in Your Employee Publication</title>
		<link>http://tc.eserver.org/31234.html</link>
		<guid>http://tc.eserver.org/31234.html</guid>
		<description>After more than a decade of working in the corporate environment, I have finally accepted that readers need to be enticed by more than the promise of a good read: They need proof. They want a visual two-second test-drive before they decide whether or not to spend precious minutes on a particular page.&#xD;&#xD;This is not to say that corporate readers are not discerning or that sloppy copy reads any better when dressed up with elaborate design. The truth is that in any corporate publication, a great article won&apos;t be read if the layout is poor. Similarly, a stunning design falls flat if the content doesn&apos;t live up to it.</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>Patterns of Revision in Online Writing</title>
		<link>http://tc.eserver.org/31047.html</link>
		<guid>http://tc.eserver.org/31047.html</guid>
		<description>This study examines the revision histories of 10 Wikipedia articles nominated for the site&apos;s Featured Article Class (FAC), its highest quality rating, 5 of which achieved FAC and 5 of which did not. The revisions to each article were coded, and the coding results were combined with a descriptive analysis of two representative articles in order to determine revision patterns. All articles in both groups showed a higher percentage of additions of new material compared to deletions and revisions that rearranged the text. Although the FAC articles had roughly equal numbers of content and surface revisions, the non-FAC articles had fewer surface revisions and were dominated by content revisions. Although the unique features of the Wikipedia environment inhibit strict comparisons between these results and those of earlier revision studies, these results suggest revision in this environment places unique structural demands on writers, possibly leading to unique revision patterns.</description>
	</item>
	<item>
		<title>Multi-Track Mixing for Location Dialogue</title>
		<link>http://tc.eserver.org/31030.html</link>
		<guid>http://tc.eserver.org/31030.html</guid>
		<description>Stereo is rarely recorded as such in the field. Instead, we record monaural sounds and wait until post-production is nearly complete to re-assign these sounds to the audience&apos;s left, right, and in-between. Until the film is edited, there is no way to know just where all of the audio elements need to end up. For instance, out on production, it might seem logical to record a car that passes from left to right in stereo, so that you can hear the &apos;pass by&apos; in your phones whoosh from the left ear to the right ear.</description>
	</item>
	<item>
		<title>Foley on a Shoestring</title>
		<link>http://tc.eserver.org/31033.html</link>
		<guid>http://tc.eserver.org/31033.html</guid>
		<description>The post-production process known as &apos;Foley&apos; refers to the art of recording &apos;live&apos; sync sound effects to picture. It is akin to looping the dialogue, but instead of recording the actors performing their lines while watching themselves on screen--skilled craftspeople known as &apos;Foley artists&apos; will walk, run, and act out any sync sound effects to match what the actor is seen (or implied) doing in the picture.</description>
	</item>
	<item>
		<title>Critiquing Critiques: A Genre Analysis of Feedback Across Novice to Expert Design Studios</title>
		<link>http://tc.eserver.org/31020.html</link>
		<guid>http://tc.eserver.org/31020.html</guid>
		<description>In the discipline of design,&#xD;the most common presentation genre is the critique, and the most central&#xD;aspect of this genre is the feedback. Using a qualitative framework, this&#xD;article identifies a typology of feedback, compares the frequencies of feedback&#xD;types between different levels of design studios ranging from novice to expert,&#xD;and explores what the feedback reflects about the social and educational&#xD;context of these design studios. Results suggest that the feedback socialized&#xD;students into egalitarian relationships and autonomous decision-making identities&#xD;that were perhaps more reflective of academic developmental stages or idealized&#xD;workplace contexts than of actual professional settings--therefore potentially&#xD;complicating the preprofessional goals of the critique.</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 Guidelines for Software Documentation</title>
		<link>http://tc.eserver.org/30814.html</link>
		<guid>http://tc.eserver.org/30814.html</guid>
		<description>Software documentation can be difficult to review, so it helps to have some editing guidelines to keep you focused. Let&apos;s face it; software documentation isn&apos;t exactly exciting reading material. But you should be able to complete the job in a productive manner if you keep your coffee cup full and follow the editing guidelines below.</description>
	</item>
	<item>
		<title>Substantive Editing: Building the Logical Inner Sanctum</title>
		<link>http://tc.eserver.org/30584.html</link>
		<guid>http://tc.eserver.org/30584.html</guid>
		<description>The inner sanctum of any good piece of writing is a solid, logical core. To produce the logical core, a writer frequently has to synthesize complex information, which means understanding it well enough to transform often muddled and random detail to clear and easy to apprehend expression. Synthesis of new information, being one of the most difficult thinking skills, can require more of a writer than the writer has time for. An editor&apos;s job, from the first draft to the last, is to help build the writing around an appropriate logical core. In this workshop, participants will practice techniques that editors can use to make sure that they find, or help the writer find, the core - what users need to know, and the order in which they need to know it. Participants will form groups to scan a document, using a checklist of tips to spot problems in the document&apos;s structure. Each group will report its findings to the larger group.</description>
	</item>
	<item>
		<title>Editing for International Audiences</title>
		<link>http://tc.eserver.org/30553.html</link>
		<guid>http://tc.eserver.org/30553.html</guid>
		<description>To remain competitive, companies must increase content reuse and multilingual usability while reducing volume and eliminating culturally sensitive language. Rushanan shows how editors can increase their value to their employers by functioning as leaders in the translation and localization process.</description>
	</item>
	<item>
		<title>Reviewing a Peer&apos;s Work</title>
		<link>http://tc.eserver.org/30564.html</link>
		<guid>http://tc.eserver.org/30564.html</guid>
		<description>If we&apos;ve been asked by a peer to review his or her work before it is sent out to be scrutinized by the world, our job is to neither edit nor rewrite the information. Our job is to give helpful, specific feedback about where the information communicates well and where it needs work. The more we understand about how to review a peer&apos;s work effectively, and how doing this is different from editing, the better feedback we can provide.</description>
	</item>
	<item>
		<title>Now That We&apos;ve Written It, What Do We Do With It?</title>
		<link>http://tc.eserver.org/30531.html</link>
		<guid>http://tc.eserver.org/30531.html</guid>
		<description>Maintaining documents after they are published (making technical corrections and clarifications, adding mussing information) is a large and important task - a task that is often pushed aside or overlooked entirely by writing departments. Our writing department was frequently behind in this maintenance work and wanted 10 improve our maintenance service to our customers. We needed to find a new, efficient way to handle the work -- quite a challenge given a shrinking work force and growing workloads. This paper describes the solution we devised, its early successes and its obstacles.</description>
	</item>
	<item>
		<title>Editing a Malcolm Baldridge Application - A Novice Baldridge Editor Speaks</title>
		<link>http://tc.eserver.org/30485.html</link>
		<guid>http://tc.eserver.org/30485.html</guid>
		<description>This paper discusses how the audiences and the experience of the application writers affect the editing time for a Malcolm Baldrige application. The mystery for this novice Baldrige editor -- Why did IBM want one full time editor for seven months to edit 75 pages? What was the catch? Was this job a boondoggle? As it turned out, the criteria for the Malcolm Baldrige application are rigorous and examiners forbid exceptions. The criteria led to a challenging editing job when combined with the diverse background of the audience and the practice of using subject matter experts as writers rather than people who are trained as writers.</description>
	</item>
	<item>
		<title>Electronic Image Manipulation - Technological Advances and Ethical Considerations</title>
		<link>http://tc.eserver.org/30489.html</link>
		<guid>http://tc.eserver.org/30489.html</guid>
		<description>Electronic imaging has enabled the desktop publisher to capture and manipulate images to produce documents that are both attractive and cost-effective. In addition to making basic corrections such as balancing colors and improving highlight and shadow detail, the desktop publisher can retouch photographs and other artwork to repair damaged areas, eliminate distracting elements, or alter composition. However, the ease of manipulation has, in some cases, overshadowed the many ethical issues that desktop publishers need to consider. Integrity of the image, ownership of artwork, and copyright laws are some of the issues that desktop publishers must confront.</description>
	</item>
	<item>
		<title>Indexing Standards and Usability Tests</title>
		<link>http://tc.eserver.org/30508.html</link>
		<guid>http://tc.eserver.org/30508.html</guid>
		<description>This paper provides reference information and complements the demonstration: &apos;Using Indexing Standards and Usability Tests&apos; by Deborah Swain and Rebecca Oliver. Information covered in the paper includes historical background on indexing and on the ANSI Z39.4 standard for indexes. Questions about the effectiveness of standards are discussed. In addition, the paper describes one way to conduct a usability test on a back-of-the-book index: random analysis. (Three testing methods will be explained in the demonstration.)</description>
	</item>
	<item>
		<title>A Commitment to Excellence: A Systematic Approach to Training Editors</title>
		<link>http://tc.eserver.org/30370.html</link>
		<guid>http://tc.eserver.org/30370.html</guid>
		<description>Creating and maintaining a high quality work environment that attracts and retains talented editors requires a commitment to excellence at all levels of a company or organization. A company dedicated to a nurturing work environment for its employees provides systematic training opportunities for professional growth. This paper describes how a company can meat its ongoing training needs for editors by offering formal and informal training programs and fostering learning at the group, department, division, and company levels.</description>
	</item>
	<item>
		<title>Barriers and Approaches to Reviewing Documentation</title>
		<link>http://tc.eserver.org/30347.html</link>
		<guid>http://tc.eserver.org/30347.html</guid>
		<description>This article discusses some important issues in implementing a software documentation review process. If you are part of a small development organization and have few reviewer resources available, you may have to improvise techniques for providing the services and procedures suggested here.</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>Nancy&apos;s Wordsmithy: Rules You Don&apos;t Have to Obey, Part III</title>
		<link>http://tc.eserver.org/30356.html</link>
		<guid>http://tc.eserver.org/30356.html</guid>
		<description>The funny thing is, this rule should be running out of steam, because certain standards of written English have changed in ways that make the rule at least partly obsolete. Learning it is kind of like learning to change a cloth ribbon on an old manual typewriter.</description>
	</item>
	<item>
		<title>The Role of Indexing in Technical Communication</title>
		<link>http://tc.eserver.org/30339.html</link>
		<guid>http://tc.eserver.org/30339.html</guid>
		<description>The success of a technical document depends heavily on the index. The task of indexing a technical document often cannot begin until insufficient time remains to do a good job. However, for many users of the document, a good index is mandatory to its usability.</description>
	</item>
	<item>
		<title>To Err is Human, But Can It Be Forgiven?: Effects and Economics of Typos</title>
		<link>http://tc.eserver.org/30266.html</link>
		<guid>http://tc.eserver.org/30266.html</guid>
		<description>Technical communicators dread typos. A piece of work that contains one or more typos is seen as shoddy, not something to be proud of. Finding and correcting these errors, however, takes time and costs money. Might there be a better way to spend resources?- ways that might produce more usable information.? Effects of errors, value added by correcting them, and the economics of error detection will be discussed.</description>
	</item>
	<item>
		<title>Editor as Teacher, Writer as Student: Building a Relationship for Corporate Writing Improvement</title>
		<link>http://tc.eserver.org/30250.html</link>
		<guid>http://tc.eserver.org/30250.html</guid>
		<description>Corporate writing skills deficits may be minimized by effective technical writer training programs. One way to effect long-term writing improvement is to cast a skilled technical editor in the role of resident writing teacher. The successful editor-as-writing-teacher must confront personal writing processes and attitudes, develop a positive and trusting relationship with clients, develop writing assessment skills, analyze and understand the corporate culture and language, and keep abreast of new techniques and tools in writing education. Acquistion of these attributes and skills is a realistic goal for a seasoned technical communicator.</description>
	</item>
	<item>
		<title>Becoming a Journal Peer Reviewer </title>
		<link>http://tc.eserver.org/30082.html</link>
		<guid>http://tc.eserver.org/30082.html</guid>
		<description>This session will help participants understand the process for reviewing manuscripts submitted to</description>
	</item>
	<item>
		<title>More Than Just Error Correction: Students&apos; Perspectives on Their Revision Processes During Writing</title>
		<link>http://tc.eserver.org/29807.html</link>
		<guid>http://tc.eserver.org/29807.html</guid>
		<description>Drawing on the second phase of a 2-year study of students&apos; linguistic and compositional processes, this article describes students&apos; reflections on their online revision processes, those revisions made during the process of translating thoughts into written text. The data collected were from classroom observation and post hoc interviews with 34 students, who were observed during a writing task in the English classrooms and interviewed subsequently to elicit their reflections and understandings of their own revising processes. The analysis indicates that students tend to conceptualize revision as a macro-strategy and as a task that is predominantly undertaken as a posttextual production reviewing activity. It also indicates that students engage in multiple revising activities during writing, including many revisions that are not concerned with simple matters of surface accuracy, and many students are able to talk about these perceptively and with insight.</description>
	</item>
	<item>
		<title>Professional Editing Strategies Used by Six Editors</title>
		<link>http://tc.eserver.org/29808.html</link>
		<guid>http://tc.eserver.org/29808.html</guid>
		<description>Identifying the approach used by those revision experts par excellence--that is, professional editors--should enable researchers to better grasp the revision process. To further explore this hypothesis, the author conducted research among professional editors, six of whom she filmed as they engaged in their practice. An analysis of their work approach strategies showed their detection strategies to consist in anticipating errors and in comparing the author&apos;s text with the editor&apos;s knowledge, which appears in a range of states: certitude, uncertainty, and ignorance. Furthermore, the participating editors used problem-solving strategies to automatically solve more than half of the problems encountered in the text. Otherwise, they used immediate or postponed strategies. This description of professional editors in action opens a number of avenues for the further research and development of in-class instruction of self-revision and professional editing.</description>
	</item>
	<item>
		<title>Working Memory in an Editing Task</title>
		<link>http://tc.eserver.org/29806.html</link>
		<guid>http://tc.eserver.org/29806.html</guid>
		<description>A number of studies have found that writers produce text in bursts of language. That is, when creating a text, writers produce a few words, pause, produce a few more words, pause, and so on. Chenoweth and Hayes (2003) hypothesized that language bursts occur when writers translate ideas in to new language. This study tested this hypothesis against the following two alternative hypotheses: (a) Language bursts are caused by proposing new ideas rather than by translating ideas in to written language and (b) language bursts depend on the form of the input to the writing process rather than on the translation process. The study employed an editing task in which participants were required to translate a written language input. The alternative hypotheses led to contradictory predictions about writers&apos; performance in this task. The study also explored the impact of working memory restrictions on task performance.</description>
	</item>
	<item>
		<title>Double Take</title>
		<link>http://tc.eserver.org/29790.html</link>
		<guid>http://tc.eserver.org/29790.html</guid>
		<description>When I peer-review a four-page document and insert the word the seventeen times, I wonder: Is this what my company is paying me to do? Am I truly adding value for my customers?</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>Improving Your Editing Efficiency: Software Skills, Soft Skills, and Survival Skills</title>
		<link>http://tc.eserver.org/29655.html</link>
		<guid>http://tc.eserver.org/29655.html</guid>
		<description>Editing efficiently involves a mix of software skills, soft (human) skills, and strategies for surviving chaos. Although software skills are certainly important--we never have as much time as we need, and computers really can help--we must still nurture author-editor relationships. Knowing the strategies battle-scarred editors have developed over the years can save you from duplicating those scars. In this paper, I&apos;ll discuss the software skills you&apos;ll need to work efficiently, how to cope with the human factors involved in editing, and some strategies for managing the often-chaotic editorial life.</description>
	</item>
	<item>
		<title>Sentence Diagramming: Making Sense of Sentences</title>
		<link>http://tc.eserver.org/29684.html</link>
		<guid>http://tc.eserver.org/29684.html</guid>
		<description>Sentence diagramming is an important tool for technical communicators to use in analyzing their own writing and editing. Sentence diagramming is also a neutral basis from which to discuss and evaluate technical documentation with colleagues and with other co- workers, such as subject-matter experts, who are not professional communicators. Through visual examples, this paper illustrates how to diagram three types of sentences (simple, compound, and complex), how sentence diagramming shows an objective view of three common syntactical errors (misplaced modifier, lack of parallel structure, and dangling modifier), and how the revised sentences make sense as sentences and as diagrams.</description>
	</item>
	<item>
		<title>Strategies for Working with Authors: How to Foster Productive Author-Editor Relationships</title>
		<link>http://tc.eserver.org/29884.html</link>
		<guid>http://tc.eserver.org/29884.html</guid>
		<description>Learning to be a good editor requires much more than learning the rules of grammar, diction, spelling, and punctuation. Editing requires a complex skill set, including an eye for document design, an awareness of how different document features affect readability, an understanding of how to manage the document development process, including the role of an editor in that process, and the ability to work with a variety of not just documents, but the creators of those documents--the authors. This paper discusses strategies to enable editors to develop productive, collaborative relationships with authors. Within the context of a capstone course in technical editing, students describe various strategies they used to develop editing plans, negotiate levels of edit and conduct editor/author conferences, and how they managed editing projects involving real authors and their documents.</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>Writing And Editing Stem Overview</title>
		<link>http://tc.eserver.org/30290.html</link>
		<guid>http://tc.eserver.org/30290.html</guid>
		<description>As part of the process of developing this overview I went back to some of the Proceedings for STC conferences that were held 10 years ago. I also reviewed issues of Technical Communication that were published at the same time.</description>
	</item>
	<item>
		<title>Typography and Page Layout: Proofreaders&apos; Marks</title>
		<link>http://tc.eserver.org/29486.html</link>
		<guid>http://tc.eserver.org/29486.html</guid>
		<description>A collection of professional proofreaders&apos; marks.</description>
	</item>
	<item>
		<title>Typography and Page Layout: Proofreading</title>
		<link>http://tc.eserver.org/29485.html</link>
		<guid>http://tc.eserver.org/29485.html</guid>
		<description>Proofreading involves a critical comparison of the author&apos;s copy and the typesetter&apos;s proof to be sure that the live copy (the typeset proof) matches the dead copy (the author&apos;s copy) word for word, and letter for letter.</description>
	</item>
	<item>
		<title>The Physics of Reviewers</title>
		<link>http://tc.eserver.org/29436.html</link>
		<guid>http://tc.eserver.org/29436.html</guid>
		<description>Subject-matter experts, managers, and other reviewers tenaciously resist our nagging to review documents properly, often delaying reviews until it&apos;s too late to do a good job. It&apos;s not that they inherently oppose quality control; rather, the problem&apos;s in the amount of work required to review something thoroughly, and &apos;work&apos; is a physics concept. Conveniently, reviewers--like falling objects--follow the same laws of physics as the rest of the universe, and understanding those laws helps you predict reviewer behavior and take appropriate countermeasures.</description>
	</item>
	<item>
		<title>Defining Editing and the Top Five Rules</title>
		<link>http://tc.eserver.org/29428.html</link>
		<guid>http://tc.eserver.org/29428.html</guid>
		<description>Do no harm: this means no harm to the author&apos;s intended meaning, reputation, or legal liability; no harm to the reader, such as by omitting necessary safety information; and no ethical harm, such as by knowingly distorting the truth.</description>
	</item>
	<item>
		<title>The Editor as Translator (or: How Do You Say That in Calculus?)</title>
		<link>http://tc.eserver.org/29425.html</link>
		<guid>http://tc.eserver.org/29425.html</guid>
		<description>Sometimes English just isn&apos;t the most elegant way to say something. It might be so much easier if we write for a math journal, because the correct language for the explanation can be, in fact, mathematics.</description>
	</item>
	<item>
		<title>Sometimes Playing Dumb Makes Things Work Better</title>
		<link>http://tc.eserver.org/29430.html</link>
		<guid>http://tc.eserver.org/29430.html</guid>
		<description>I&apos;ve learned how to forget for a period of time that I know almost as much as my authors about their subject, and this lets me play dumb and trip over things that the author&apos;s peers and I could both figure out with a little work--or a lot of work, occasionally. Once I understand why I tripped over a particular wording, I can figure out how to fix it so that nobody else, even if they really were as idiotic as I sometimes pretend to be.</description>
	</item>
	<item>
		<title>Writer-Editor Relationships in Revisions</title>
		<link>http://tc.eserver.org/29413.html</link>
		<guid>http://tc.eserver.org/29413.html</guid>
		<description>Editors, professional or otherwise, can be annoying individuals. The trick is to focus on the helpful parts of that annoyance and try to ignore the less-helpful parts.</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>Communicating Style Rules to Editors of International Standards: An Analysis of ISO TC 184/SC4 Style Documents</title>
		<link>http://tc.eserver.org/29056.html</link>
		<guid>http://tc.eserver.org/29056.html</guid>
		<description>Committees within international standards organizations write standards. Prior to approval, these standards must pass through several reviews for technical accuracy and stylistic appropriateness. The style considerations are based on documents published by both the umbrella organization (International Organization for Standarization, or ISO) and the various committees and subcommittees within it. Because authors and editors who use these documents frequently do not have English as a first language, the documents must explain unambiguously just how committees should prepare their documents. This study looks at a sample of those instructional documents using Restricted and Elaborated Code and metadiscourse analysis to determine how easily users can read and understand the material. The findings suggest that the documents do not send a clear message to authors and editors and can be stylistically hard to understand. Consequently, the approved standards themselves are hard to read and interpret.</description>
	</item>
	<item>
		<title>Noteworthy Observations About Note-Taking by Professionals</title>
		<link>http://tc.eserver.org/29130.html</link>
		<guid>http://tc.eserver.org/29130.html</guid>
		<description>In this article we focus on professional readers who have to write recommendations in an online environment. We address the question whether taking notes on screen influences the reading process and the quality of the recommendations in terms of applicability, completeness, and persuasiveness. Seven participants each composed two pieces of advice on technical communication issues. They could use an electronic Notepad whenever they wished. Taking notes appeared to influence advice quality negatively, which may be caused by attention shifts from reading to taking notes on screen. Although we could not find a relationship between the contents of the notes and advice quality, we noted differences in note-taking approaches between the participants.</description>
	</item>
	<item>
		<title>Readers Background Characteristics and Their Feedback on Documents: The Influence of Gender and Educational Level on Evaluation Results</title>
		<link>http://tc.eserver.org/29059.html</link>
		<guid>http://tc.eserver.org/29059.html</guid>
		<description>What is the influence of demographic variables such as gender and educational level on the reader feedback collected under the plus-minus method? To answer this question, an analysis was made of the problems detected in four public information brochures. The average amount of feedback per participant did not vary among the four brochures, but the severity of the problems did. Male participants mentioned more problems than female participants, but the problems detected by female participants were on average more severe. Highly educated participants detected more problems than participants with a lower level of education. No differences in problem types mentioned were found between male and female participants, and only one difference was found between the two educational levels: Highly educated participants focused more strongly on the structuring of information. In general, brochure characteristics had more effect on the types of feedback collected than the two demographic participant characteristics.</description>
	</item>
	<item>
		<title>The Fine Art of Editing</title>
		<link>http://tc.eserver.org/28813.html</link>
		<guid>http://tc.eserver.org/28813.html</guid>
		<description>Editing is an art that needs to be cultivated and fine-tuned just like any other. When one is novice, the editing goals are to proofread, to clean up the text, and to correct &apos;grammatical&apos; errors. The entire focus is on words and phrases. So, when they edit, they read the text as it comes and edit the words to make the text read better. What is it that they really miss? They often miss the big picture, the whole idea, and the context.</description>
	</item>
	<item>
		<title>The User Edit Method for Evaluating the Usability of Documentation</title>
		<link>http://tc.eserver.org/28493.html</link>
		<guid>http://tc.eserver.org/28493.html</guid>
		<description>A &apos;user edit&apos; (also known as a &apos;usability edit&apos;) enables you to evaluate the usability of documentation (Schriver, 1991). Participants in a user edit study can either think aloud as they use the documentation to complete tasks or they can mark up the pages of the documentation to indicate where they had problems. The think-aloud protocols or marked-up pages are then reviewed for usability problems. The user edit report lists the problems and recommendations about how to improve the usability of the documentation.</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>Designing an Effective Review Process</title>
		<link>http://tc.eserver.org/27985.html</link>
		<guid>http://tc.eserver.org/27985.html</guid>
		<description>Review processes can easily become frustrating and complicated. Hart shows how to create and revive a review process that can be tailored to the needs of your situation.</description>
	</item>
	<item>
		<title>Order from Chaos: Developmental Editing</title>
		<link>http://tc.eserver.org/27844.html</link>
		<guid>http://tc.eserver.org/27844.html</guid>
		<description>The definition varies from publisher to publisher and from client to client, but basically a developmental editor helps an author develop ideasâ€”or develop a manuscript if it already exists--into a coherent, readable work.</description>
	</item>
	<item>
		<title>Practical Tips for Language: The Ladder to the Top</title>
		<link>http://tc.eserver.org/27830.html</link>
		<guid>http://tc.eserver.org/27830.html</guid>
		<description>We the Technical Editors are spared of one worry which our colleagues from journalism generally have: In our work we need not pay &apos;so much&apos; attention to &apos;as much as possible&apos; large number of editions. But the situation is different, if we--as is always the case--are to also look after the company&apos;s web presence. What is an edition in the context of printing is here the so-called &apos;page ranking&apos; among the major search engines like Google and Yahoo. Many imagine that a listing in the hits lists depends on chance or, that it is mainly due to some technical means. That is all wrong: by employing some clever textual work the chances of web pages being found can be significantly increased. In reality, even elaborate techniques can lower the chances of hits: Frames, JavaScript and Flash Intros often derail the search engines. And the results may look all right, but regrettably the page will no longer be found.</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>Why I Hate The Body of Your Article</title>
		<link>http://tc.eserver.org/26712.html</link>
		<guid>http://tc.eserver.org/26712.html</guid>
		<description>I really don&apos;t care what you write about. I am more interested in the format of the article, not your view or take on the subject matter.</description>
	</item>
	<item>
		<title>Why I Hate Your Article Headlines</title>
		<link>http://tc.eserver.org/26713.html</link>
		<guid>http://tc.eserver.org/26713.html</guid>
		<description>Iâ€™m a publisher for numerous sites. Hereâ€™s why I hate your headline and what you can do about it.</description>
	</item>
	<item>
		<title>Defining Glossaries</title>
		<link>http://tc.eserver.org/26458.html</link>
		<guid>http://tc.eserver.org/26458.html</guid>
		<description>Glossaries are lists of specialized word definitions contained in technical documentation that can assist the nontechnical user to comprehend fully the technical topic at hand. In a joint project with SAS Institute, I sought to discover how glossaries were first developed, what guidelines are available for technical writers in the writing of glossaries, and what rhetorical technique might be of value for glossary writers. I found that glossaries are much more than simple word lists; they are, in fact, an opportunity for the technical writer to outline and protect the parameters of technical discourse between a company and its customers across multiple communications channels, and different languages. In an increasingly global technical environment, an explicit connection between the rhetorical technique of definition and the writing of glossary definitions should be made to aid technical writers in this task.</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>Creating, Implementing, and Maintaining Corporate Style Guides in an Age of Technology</title>
		<link>http://tc.eserver.org/25242.html</link>
		<guid>http://tc.eserver.org/25242.html</guid>
		<description>This article details a step-by-step process for creating, implementing, and maintaining a corporate style guide to ensure consistency in organizational communication. Through literature research, analysis of sample style guides, and practitioner interviews, this article provides recommendations for gaining management support, building a process to develop a style guide, determining content, encouraging employee buy-in, and maintaining a corporate style guide.</description>
	</item>
	<item>
		<title>Strategies for Peer-Reviewing and Team-Writing</title>
		<link>http://tc.eserver.org/25114.html</link>
		<guid>http://tc.eserver.org/25114.html</guid>
		<description>When you peer-review other people&apos;s writing, remember above all that you should consider all aspects of that writing, not just--in fact, least of all--the grammar, spelling, and punctuation.</description>
	</item>
	<item>
		<title>Not a Style Guide: Creating a Quick Reference Grammar Guide for Writers</title>
		<link>http://tc.eserver.org/25029.html</link>
		<guid>http://tc.eserver.org/25029.html</guid>
		<description>When approached by a group of curriculum design specialists to develop a job aid that would help analysts and trainers solve some of their most common writing problems, the Multinational Customer and Service Education (MC&amp;SE) editing group from Xerox Corporation went to work to produce The Write Stuff: When to Use a Comma and Other Writing Rules. This paper focuses on the Leadership Through Quality process the editors used to develop this reference tool. It also describes how The Write Stuff addresses some of the most common writing problems editors encounter in the course of a working day.</description>
	</item>
	<item>
		<title>Flexible Diff-ing in a Collaborative Writing System</title>
		<link>http://tc.eserver.org/24959.html</link>
		<guid>http://tc.eserver.org/24959.html</guid>
		<description>Discusses the use of computer-generated information about what has been revised in the display of editing in word processors.</description>
	</item>
	<item>
		<title>Collecting Books about Editing</title>
		<link>http://tc.eserver.org/24926.html</link>
		<guid>http://tc.eserver.org/24926.html</guid>
		<description>Intercom&apos;s &apos;friendly editor&apos; discusses his extensive collection of dictionaries, grammars, and other books of interest.</description>
	</item>
	<item>
		<title>Beginning to Edit Physics</title>
		<link>http://tc.eserver.org/24908.html</link>
		<guid>http://tc.eserver.org/24908.html</guid>
		<description>A physicist-turned-editor shows you the basics required for copyediting physics papers (physical quantities, symbols, units, scientific notation, the structure of mathematical expressions, the nature of graphs), and points the way to learning enough &apos;editorial physics&apos; to begin substantive editing.</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>How to Think (and Act) Like an Editor: Training for Editors</title>
		<link>http://tc.eserver.org/24894.html</link>
		<guid>http://tc.eserver.org/24894.html</guid>
		<description>In this workshop, participants will experience portions of a performance-based training program for technical editors. The program emphasizes the skills that STC Fellow Lola Zook calls &apos;learning not only what the editor is to do, but what the editor ought to be.&apos;</description>
	</item>
	<item>
		<title>&quot;Why Do We Need Editors Anyway?&quot; Overcoming the Obstacles Facing a New Editing Group</title>
		<link>http://tc.eserver.org/24888.html</link>
		<guid>http://tc.eserver.org/24888.html</guid>
		<description>In the corporate arena, an editing group (particularly a newly formed one) sometimes finds it difficult to be accepted as part of a communications team and may spend an inordinate amount of its energy seeking to justify its existence. Barriers to acceptance and credibility include lack of trust and misunderstanding about what editors do or what value editing imparts. Editors can overcome these obstacles, however, through a combination of consistent work practices, clear and frequent communication with writers, and an ongoing program aimed at demonstrating the practical value of editing.</description>
	</item>
	<item>
		<title>The Nature of the Interchange Between Editors and Authors</title>
		<link>http://tc.eserver.org/24731.html</link>
		<guid>http://tc.eserver.org/24731.html</guid>
		<description>Editors, if allowed to interact with authors on a level above the comma, could often help authors negotiate new meaning as authors struggle to translate their ideas into writing.</description>
	</item>
	<item>
		<title>Into the 21st Century: The Changing Role of Editors</title>
		<link>http://tc.eserver.org/24716.html</link>
		<guid>http://tc.eserver.org/24716.html</guid>
		<description>The historical perception that defined editors as guardians of the language falls short in describing editors in high-technology environments today. Essential skills for the 21st century require technical editors who can demonstrate sophisticated and extensive tool knowledge, product knowledge, and an appreciation for current professional trends—in addition to being guardians of the language.</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>From the Margins to the Center: The Future of Annotation</title>
		<link>http://tc.eserver.org/24565.html</link>
		<guid>http://tc.eserver.org/24565.html</guid>
		<description>This article describes the importance of annotation to reading and writing practices and reviews new technologies that complicate the ways annotation can be used to support and enhance traditional reading, writing, and collaboration processes. Important directions for future research are discussed, with emphasis on studying how professionals read and annotate, how readers might use annotations that have been produced by others, and how the interface of an annotation program affects collaboration and communication on revision. In each area, the authors emphasize issues and methods that will be productive for enhancing theories of workplace and classroom communication as well as implications for the optimal design of annotation technologies.</description>
	</item>
	<item>
		<title>Factors in Reader Responses to Negative Letters: Experimental Evidence for Changing What We Teach</title>
		<link>http://tc.eserver.org/24500.html</link>
		<guid>http://tc.eserver.org/24500.html</guid>
		<description>This article summarizes the scholarly discussion about negative messages and reports the results of two pretests and two experiments using negative letters. The results show that buffers did not significantly affect college students&apos; responses to simulated letters refusing credit and denying admission to graduate school, and strong resale was counterproductive. Students responded least favorably to rejection when they were surprised by it and when their other options were limited. On the basis of these experiments and the published literature, the author recommends that negative letters normally begin with the reason for the refusal, using a buffer only if one of several exceptions apply. If the reason makes the company look good, it should be spelled out in as much detail as possible. If an alternative or compromise exists, the writer should suggest it. Although a positive ending is not necessary, if one is used, a bland positive is better than a strong one, especially in letters to clients or customers.</description>
	</item>
	<item>
		<title>Creating Editing Metrics</title>
		<link>http://tc.eserver.org/24448.html</link>
		<guid>http://tc.eserver.org/24448.html</guid>
		<description>Using simple templates, you learn how to customize editing metrics to represent your department processes.</description>
	</item>
	<item>
		<title>Editing—We Meet Again</title>
		<link>http://tc.eserver.org/24425.html</link>
		<guid>http://tc.eserver.org/24425.html</guid>
		<description>Three papers on editing presented at the 1967 STC Conference are revisited to emphasize the belief that editing in 1996, despite changes introduced by modern technology, is still much the same as it was 30 years ago. Editors still make changes (in language, structure, and mechanics). Editors still can work more effectively when they have a basic knowledge of production processes (composition, illustration, photography, printing). Editors still need &apos;uncommon skills&apos; in managing work people, and time.</description>
	</item>
	<item>
		<title>The Influence of Text Factors on Readers</title>
		<link>http://tc.eserver.org/24394.html</link>
		<guid>http://tc.eserver.org/24394.html</guid>
		<description>The objectives of the research study presented here are to increase the discipline&apos;s knowledge about reader performance with technical documents, help writers and editors better allocate their efforts, and explore multivariate studies of text variables.  For this study, subjects read and recalled one of two technical texts. Their recall protocols were analyzed for syntactic and semantic characteristics.  Preliminary results suggest that information has a greater chance of being recalled if it is in clauses, independent clauses, more important idea units, or the first paragraph of the document. Additional results will be discussed at the conference.</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>No Pain, No Shame Editing</title>
		<link>http://tc.eserver.org/24345.html</link>
		<guid>http://tc.eserver.org/24345.html</guid>
		<description>Editing the works of others is truly a tricky business.  The balancing act required in dealing with an author’s ego is no less precarious than that of teetering, with toes and teeth clenched, on a high wire.  Maintaining a steady equilibrium between the principles of good writing on the one hand and the human factors involved in the process on the other is paramount if editors are to avoid falling—falling from both the reader’s and the author’s favor, that is.  Recognizing that editors are advocates for readers as well as for authors makes the endeavor less painful and less shameful for both editors and authors.</description>
	</item>
	<item>
		<title>The Tantalizing Technology of English</title>
		<link>http://tc.eserver.org/24299.html</link>
		<guid>http://tc.eserver.org/24299.html</guid>
		<description>The English language is tantalizing and altogether fascinating.</description>
	</item>
	<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 Web Pages: A Second Look</title>
		<link>http://tc.eserver.org/24202.html</link>
		<guid>http://tc.eserver.org/24202.html</guid>
		<description>How to edit Web pages--with revision tracking--using Microsoft Word.</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>Using Editors to Win Proposals</title>
		<link>http://tc.eserver.org/24182.html</link>
		<guid>http://tc.eserver.org/24182.html</guid>
		<description>Paradoxically, engineers are often forced to seek jobs by pursuing a skill at which they are, admittedly, often inferior: expository writing. To win proposals for new business, they have to put their worst foot forward. This unhappy situation presents a great opportunity for editors.</description>
	</item>
	<item>
		<title>Implementing On-Screen Editing</title>
		<link>http://tc.eserver.org/24172.html</link>
		<guid>http://tc.eserver.org/24172.html</guid>
		<description>On-screen editing offers obvious advantages over paper editing, including greater accuracy, shorter turnaround times, and improved consistency. Because authors don’t have to retype handwritten edits, there’s less risk of misreading  or  missing  corrections. Moreover, the edits have already been typed and spellchecked, so no new typos are introduced. Most editors can also enter corrections faster with a keyboard than with a pen, particularly when complex edits require restructuring of the document or extensive rewording, and eliminating the retyping phase further reduces turnaround times. Last but not least, using the search tools makes it easier to achieve consistency in long or complex documents.</description>
	</item>
	<item>
		<title>Electronic Editing in Technical Communication: A Model of User-centered Technology Adoption</title>
		<link>http://tc.eserver.org/24159.html</link>
		<guid>http://tc.eserver.org/24159.html</guid>
		<description>This article connects the research into electronic editing reported by the author in two previous articles to a well-established theory of innovation adoption and diffusion. Everett M. Rogers&apos;s theory is first summarized, with emphasis on the perceived characteristics of innovations central to the innovation-decision process. The three most important of these categories for organizing personal judgments about an innovation are used to develop a model of the innovation-decision process with regard to electronic editing in technical communication. The central role of reinvention in the gradual, erratic diffusion of diverse e-editing practices in technical communication is discussed. The author explains and advocates a user-centered ethic of technology adoption, a perspective that values the agency of workplace communities in selectively adopting and reinventing innovations to support the work they do while preserving or enhancing their quality of life on the job.</description>
	</item>
	<item>
		<title>Trust Your Instincts As You Write</title>
		<link>http://tc.eserver.org/24143.html</link>
		<guid>http://tc.eserver.org/24143.html</guid>
		<description>As I write, and even after I have finished and am proofing my work, I have to be sure to be tuned in to a diminutive little editor who sits to one side of my mind.</description>
	</item>
	<item>
		<title>How Careful Should Editors Be?</title>
		<link>http://tc.eserver.org/24058.html</link>
		<guid>http://tc.eserver.org/24058.html</guid>
		<description>Three recent incidents prompt me to ask, How careful do editors have to be in checking facts? Is it possible for publications people to be too careful?</description>
	</item>
	<item>
		<title>How Do Editors Do It?</title>
		<link>http://tc.eserver.org/24063.html</link>
		<guid>http://tc.eserver.org/24063.html</guid>
		<description>Do you ever feel you&apos;d like a second opinion on a particularly miserable paragraph you&apos;ve been editing?</description>
	</item>
	<item>
		<title>Keeping Things Consistent When You&apos;re the &apos;Guest&apos; Editor</title>
		<link>http://tc.eserver.org/24061.html</link>
		<guid>http://tc.eserver.org/24061.html</guid>
		<description>Consistency is the cornerstone of intelligent editing. In these days of leaner staffs and smaller budgets, however, many organizations don&apos;t employ full-time editors and depend on contract or freelance editors to make sure their publications are written in a consistent — and thus coherent — manner.</description>
	</item>
	<item>
		<title>Editing a Moving Target</title>
		<link>http://tc.eserver.org/24047.html</link>
		<guid>http://tc.eserver.org/24047.html</guid>
		<description>I&apos;d like to assume that most of us find ourselves having to edit a moving target only occasionally, but from the horror stories I&apos;ve been hearing, it seems that more and more people are being expected to edit well in a ridiculously short time.</description>
	</item>
	<item>
		<title>Editing All the Legalese the Law Allows</title>
		<link>http://tc.eserver.org/24046.html</link>
		<guid>http://tc.eserver.org/24046.html</guid>
		<description>Strictly speaking, legalese isn&apos;t intended for use outside a judicial context, but quasi-legalistic writing, with its officious tone, wordiness, and complex terms, percolates into business, government, and public interest documents. It&apos;s a parroting of the real thing -- which is already hard to swallow -- and there&apos;s a lot of it around. That kind of legalese demands to be edited, because people will do almost anything to avoid reading it.</description>
	</item>
	<item>
		<title>Beyond Gutenberg</title>
		<link>http://tc.eserver.org/24015.html</link>
		<guid>http://tc.eserver.org/24015.html</guid>
		<description>Editing must change for the Web, but perhaps not so much as you think. In paper publishing, different documents require different rules and procedures: An annual report requires more editing and more attention to detail than an office memo. Similarly, not all Web documents are equal.</description>
	</item>
	<item>
		<title>A Copyeditor&apos;s Adventures in Multimedia Land</title>
		<link>http://tc.eserver.org/24020.html</link>
		<guid>http://tc.eserver.org/24020.html</guid>
		<description>Publication in the 1990s encompasses worlds that most copyeditors never dreamed of when, with a mixture of delight and mistrust, we cautiously approached the first spell checkers. At least we could relate to the idea of mechanically checking spelling. The whole idea of multimedia is a little more unnerving. </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>Overcoming Objections to Onscreen Editing</title>
		<link>http://tc.eserver.org/23742.html</link>
		<guid>http://tc.eserver.org/23742.html</guid>
		<description>Although onscreen editing has been available for many years, it remains underused in many workplaces. Editors offer many reasons for their reluctance to embrace this technology, and by understanding these reasons, it becomes possible to mitigate the problems and help editors begin using the technology. By doing so, managers can implement a process that is more efficient for both the editor and the authors being edited.</description>
	</item>
	<item>
		<title>E-Editing for Global Audiences</title>
		<link>http://tc.eserver.org/23647.html</link>
		<guid>http://tc.eserver.org/23647.html</guid>
		<description>The role of the technical communicator, including that of the technical editor, has evolved to encompass a broad range of responsibilities and skills. The familiar editing processes can be streamlined into four levels of editing, thus providing a basis for a business model for highperformance, global teams.&#xD;By combining the familiar levels of editing with the latest innovations of one-page business plans, a streamlined e-editing&#xD;model can be used by high-performance teams to produce high-quality information in a timely and an&#xD;efficient manner for global audiences.</description>
	</item>
	<item>
		<title>Creating an Editing Policy</title>
		<link>http://tc.eserver.org/23557.html</link>
		<guid>http://tc.eserver.org/23557.html</guid>
		<description>As an editor, you realize how important it is to edit information consistently. What you might not realize how important it is to let the writer know how you are going to edit, what you are going to edit, and what you expect from the writer. An editing policy lets you communicate these things to the writer. When you and the writer know what to expect from each other, you are able to work together as a team to produce a quality document.</description>
	</item>
	<item>
		<title>Substantive Editing: The Art of the Alchemist</title>
		<link>http://tc.eserver.org/23547.html</link>
		<guid>http://tc.eserver.org/23547.html</guid>
		<description>For any number of reasons — and it&apos;s often not the writer&apos;s fault — an editor is asked to help transform a document. Water into wine, a specification into a user document. The editor job, from the first draft to the last, is to ensure that the Writing meets the user&apos;s need, which sometimes means the document goes through a transformation: lead into gold.</description>
	</item>
	<item>
		<title>CRT - in a New Look</title>
		<link>http://tc.eserver.org/23495.html</link>
		<guid>http://tc.eserver.org/23495.html</guid>
		<description>Although CRT is small in numbers, it is already acquainted with the &apos;big&apos; sister societies, such as tekom (Germany), ISTC (Great Britain) and other Technical Communicator groups in Europe. We were very pleased with the initial contacts made in Brussels early in 2001 aimed at establishing a new umbrella organization for technical communicators in Europe.</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>Writing Across the Curriculum</title>
		<link>http://tc.eserver.org/23334.html</link>
		<guid>http://tc.eserver.org/23334.html</guid>
		<description>The phrase &apos;writing across the curriculum&apos; is relatively new, as far as I am aware. I want to examine its underlying meaning, its various administrative forms, and its implications for the faculties of colleges and of high schools to look at the theory, the practice, and occasionally the history of the notion.</description>
	</item>
	<item>
		<title>Writing Programs and the English Department</title>
		<link>http://tc.eserver.org/23345.html</link>
		<guid>http://tc.eserver.org/23345.html</guid>
		<description>A couple of years ago John Gerber, in an article in the &lt;i&gt;ADE Bulletin,&lt;/i&gt; urged a broadened definition of &apos;literacy,&apos; one that would encompass all study relating to linguistic artifacts, from the most elementary reading and writing to the most differentiated scholarship and composing. Nearly all college English departments do include much of this broad range, but the inclusion is rarely an integration. Instead, there&apos;s the English major and the freshman composition program and the creative-writing courses and, sometimes, the courses for nonmajors: film, popular culture, folklore; business and technical writing; and so forth. In large departments different faculty members may specialize in one or another of these units, and the chairman, who is supposed to be running the whole six-ring circus, can scarcely get the different sorts to talk to one another. What integration occurs begins and ends with the yearly departmental cocktail party.</description>
	</item>
	<item>
		<title>Planning and Leading a Successful Review Meeting</title>
		<link>http://tc.eserver.org/23149.html</link>
		<guid>http://tc.eserver.org/23149.html</guid>
		<description>Experienced and novice technical communicators can plan and lead successful review meetings by following this 4-step process: l—Plan ahead. 2—Use an agenda as a road map. 3—Wrap up. 4—Follow up. Although a faceto- face meeting is often the easiest way to get formal feedback on an information product, there are situations in which you should not hold a meeting. If a meeting is appropriate, however, there are specific things you can do to prevent or handle typical problems. Leading a successful meeting involves making a series of conscious choices to make better use of everyone’s time.</description>
	</item>
	<item>
		<title>When You Have to Edit Your Own Writing</title>
		<link>http://tc.eserver.org/23151.html</link>
		<guid>http://tc.eserver.org/23151.html</guid>
		<description>Many technical writers work without the benefit of professional editing. While there is no substitute for a seasoned editor, writers can and should learn to perform some checks themselves. Checklists narrow the focus of editing and provide a systematic approach to polishing familiar prose. Numerous tips can also make editing easier and more effective.</description>
	</item>
	<item>
		<title>Developing a Company Style Guide</title>
		<link>http://tc.eserver.org/22838.html</link>
		<guid>http://tc.eserver.org/22838.html</guid>
		<description>Every company that produces external publications--whether brochures, research papers, or reference manuals-benefit from a company style guide. This paper discusses the advantages of&#xD;a style guide, why a company-specific style guide is&#xD;preferred, how to develop a style guide, and what a&#xD;style guide should (and should not) include.</description>
	</item>
	<item>
		<title>Writer-Editor Interactions: What Works?</title>
		<link>http://tc.eserver.org/22839.html</link>
		<guid>http://tc.eserver.org/22839.html</guid>
		<description>Successful writer-editor relationships require a commitment&#xD;from both parties to teamwork, open communications, and&#xD;shared accountability for the success of each project. The&#xD;benefits from this ejj?ort include better igformation products&#xD;for users and a more congenial working environmentfor you.&#xD;Equally important, your clients will develop cor@ence and&#xD;trust when they see a project’s writer and editor combining&#xD;their skills and collaborating on shared project goals.</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>Developing Evaluation Criteria</title>
		<link>http://tc.eserver.org/22767.html</link>
		<guid>http://tc.eserver.org/22767.html</guid>
		<description>We encourage you to adapt criteria to your specific communication assignments. You might specify, for example, the technical or scientific content for which your students are responsible. You might also specify how students will address communication concerns such as audience, purpose, context, organization, support, design, and expression.</description>
	</item>
	<item>
		<title>Incorporating Peer Review</title>
		<link>http://tc.eserver.org/22769.html</link>
		<guid>http://tc.eserver.org/22769.html</guid>
		<description>Peer review is an exercise in which students review each other&apos;s written work. Peer review is often connected to revision, a part of the writing process in which writers refine and make substantive changes to their written work.</description>
	</item>
	<item>
		<title>Incorporating Revision</title>
		<link>http://tc.eserver.org/22768.html</link>
		<guid>http://tc.eserver.org/22768.html</guid>
		<description>Revision refers to the process of reviewing one&apos;s work and making changes (either local or global) to improve the writing.  Most teachers of writing encourage students to revise their work by creating drafts and going through a process of review -- either by having teacher review drafts or having other students review drafts.</description>
	</item>
	<item>
		<title>Using Virtual Peer Review through the Online Writing Center</title>
		<link>http://tc.eserver.org/22770.html</link>
		<guid>http://tc.eserver.org/22770.html</guid>
		<description>Virtual Peer Review is an exercise in which students review the written work of other students in online or Internet-based settings. Just like peer review--an activity in which readers make suggestions for improvement on another person&apos;s writing--virtual peer review supports revision in the writing process. The difference is that this review process is conducted using online technologies.</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>An Editor Can Help Your Business</title>
		<link>http://tc.eserver.org/22631.html</link>
		<guid>http://tc.eserver.org/22631.html</guid>
		<description>Your business must get its message out to succeed. An editor can help make your message clear, correct, attractive, and appropriate to your market.</description>
	</item>
	<item>
		<title>The Fine Art of Copyediting</title>
		<link>http://tc.eserver.org/22276.html</link>
		<guid>http://tc.eserver.org/22276.html</guid>
		<description>Even though you might not be a copyeditor in a publishing house, the information that Stainton provides can be useful to any editor as well as to any writer.</description>
	</item>
	<item>
		<title>Electronic Editing in Technical Communication: The Compelling Logics of Local Contexts</title>
		<link>http://tc.eserver.org/22172.html</link>
		<guid>http://tc.eserver.org/22172.html</guid>
		<description>Reports a qualitative study of e-editing practices and attitudes in specific workplace contexts. Sheds light on how specific workplace contexts influence perceptions and interpretations of e-editing&apos;s benefits and drawbacks.</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>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>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>
</channel>
</rss>