<?xml version="1.0" encoding="utf-8" ?><rss version="2.0" xmlns:atom="http://www.w3.org/2005/Atom">
<channel>
	<title>Articles&gt;Editing&gt;Collaboration</title>	<link>http://tc.eserver.org/dir/Articles/Editing/Collaboration</link>
	<description>A listing of the most recently indexed works about Articles and Editing and Collaboration in the field of technical communication.</description>
	<language>en-us</language>
	<copyright>Copyright (c) 2005-08 by the EServer. All rights reserved.</copyright>
	<managingEditor>tclib-editorial@eserver.org (TC Library Editorial Board)</managingEditor>
	<webMaster>webmaster@eserver.org (Geoffrey Sauer)</webMaster>
	<image>
		<url>http://tc.eserver.org/images/newlogo.gif</url>
		<title>Articles&gt;Editing&gt;Collaboration</title>
		<link>http://tc.eserver.org/dir/Articles/Editing/Collaboration</link>
	</image>
	<item>
		<title>Editors and Designers: 6 Ideas for Better Collaboration</title>
		<link>http://tc.eserver.org/35519.html</link>
		<guid>http://tc.eserver.org/35519.html</guid>
		<description>Demonstrates how collaboration between all involved in a project can improve the final product, improve the bottom line, and improve your own knowledge base. By understanding the point of view of your collaborators, you can present information better and be sure they understand your point of view better as well.</description>
	</item>
	<item>
		<title>Let Us Now Praise Editors</title>
		<link>http://tc.eserver.org/35010.html</link>
		<guid>http://tc.eserver.org/35010.html</guid>
		<description>Editors are craftsmen, ghosts, psychiatrists, bullies, sparring partners, experts, enablers, ignoramuses, translators, writers, goalies, friends, foremen, wimps, ditch diggers, mind readers, coaches, bomb throwers, muses and spittoons -- sometimes all while working on the same piece.</description>
	</item>
	<item>
		<title>How Did This Happen?</title>
		<link>http://tc.eserver.org/34860.html</link>
		<guid>http://tc.eserver.org/34860.html</guid>
		<description>Even a newspaper like The Times, with layers of editing to ensure accuracy, can go off the rails when communication is poor, individuals do not bear down hard enough, and they make assumptions about what others have done.</description>
	</item>
	<item>
		<title>Best Practices for Online Review</title>
		<link>http://tc.eserver.org/34700.html</link>
		<guid>http://tc.eserver.org/34700.html</guid>
		<description>Marking up paper is still the most common way to review documents, but online review is critical if you work as part of a distributed team. There are advantages to online review even if you sit only a cubicle away from your reviewer. Here are few tips for making your online reviews go smoothly.</description>
	</item>
	<item>
		<title>Interpreting Editorese</title>
		<link>http://tc.eserver.org/34524.html</link>
		<guid>http://tc.eserver.org/34524.html</guid>
		<description>Even if an editor loves, loves, loves your work, she is still likely to have to shepherd it through some kind of review process — either internally, in the case of a trade house, or to external academic readers. Many manuscripts die that way, despite the &quot;interest&quot; of the press. Those that are not outright killed can be wounded and sent back to you for some critical care.</description>
	</item>
	<item>
		<title>Off Site Reviews: Six Ways to Exchange Edits</title>
		<link>http://tc.eserver.org/33864.html</link>
		<guid>http://tc.eserver.org/33864.html</guid>
		<description>Coordinating a document review can be a tedious process. However, the task is even more difficult when reviewers work in another location and can&apos;t quickly exchange comments via paper. Fortunately, technology is presenting writers with new options for handling off-site reviews.</description>
	</item>
	<item>
		<title>The Under-Appreciated Art of Proofreading</title>
		<link>http://tc.eserver.org/32690.html</link>
		<guid>http://tc.eserver.org/32690.html</guid>
		<description>Although I hate to sound like a Luddite, the automatic tools are no guarantee that your document will be error free. Here are a few proofreading tips that may help you eliminate some common errors.</description>
	</item>
	<item>
		<title>Attaining Review Nirvana with Acrobat 8 Professional</title>
		<link>http://tc.eserver.org/32491.html</link>
		<guid>http://tc.eserver.org/32491.html</guid>
		<description>Getting documents reviewed has always been a tricky proposition for writers. From pleading to coercion to bribery just stopping short of third-degree torture, writers have documented many methods for getting reviews done effectively and in time. For those writers who gave up altogether and for those who just did not care too much for reviews, there is bad news coming – companies are asking for user feedback on the content that you wrote. Users, as we know them, can shame the most cynical movie critic when it comes to commenting. In my quest many a tool tried to lure me, but when Acrobat 8 strut its shared review stuff in front of me, I finally succumbed.</description>
	</item>
	<item>
		<title>Inspiring Reviewers to Review Your Documents</title>
		<link>http://tc.eserver.org/32228.html</link>
		<guid>http://tc.eserver.org/32228.html</guid>
		<description>To obtain good reviews, you must make the process as painless as possible for reviewers.</description>
	</item>
	<item>
		<title>Long-Distance Editing</title>
		<link>http://tc.eserver.org/31848.html</link>
		<guid>http://tc.eserver.org/31848.html</guid>
		<description>Check out seven tips that will help you and your team remain busy and useful when you have extra time or gaps between projects.</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>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>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>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>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>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>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>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>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>&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>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>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 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>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>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>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>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>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>The Knowledge Editor(SM): Innovative Editorial Solutions to Meet Your Quality Objectives</title>
		<link>http://tc.eserver.org/18848.html</link>
		<guid>http://tc.eserver.org/18848.html</guid>
		<description>This paper represents over 30 years cumulative work experience, as both corporate staff members and as consultants, and shares recommendations for providing highly valuable editorial contributions. The authors also introduce a new concept for innovative editorial methods that meet the technological and productivity challenges facing today’s information design organizations.</description>
	</item>
	<item>
		<title>You Lost Me in the Third Paragraph: A Guide to Gracious Criticism</title>
		<link>http://tc.eserver.org/18863.html</link>
		<guid>http://tc.eserver.org/18863.html</guid>
		<description>When a colleague comes to you for criticism, for help, for feedback, you are not helping that colleague if you say, &apos;Looks okay to me.&apos; An important skill in college and in the work force is that of giving solid, instructive criticism. This handout is designed to teach you this skill.</description>
	</item>
	<item>
		<title>The Technical Editor as Diplomat: Linguistic Strategies for Balancing Clarity and Politeness </title>
		<link>http://tc.eserver.org/18276.html</link>
		<guid>http://tc.eserver.org/18276.html</guid>
		<description>An essential component of technical editors&apos; work is to convey to writers how their documents would benefit from revision. This task is potentially sensitive, given writers&apos; intellectual and emotional investment in the documents they have created. The sensitive nature of the editing process is clear in Rude&apos;s (2001) advice to students of technical editing: &apos;[A]void words that suggest inappropriate editorial intervention, especially change &apos; (p. 43).&#xD;&#xD;Rude&apos;s advice suggests an awareness of the difficulty inherent in imposing oneself into the creative process of another person. Because of the defensiveness they might encounter in writers, editors must be cognizant of how they carry out their jobï¿the language they use to convey necessary changes to writers&apos; documents. The language editors use can either facilitate good working relationships with writers or degrade those relationships.&#xD;</description>
	</item>
	<item>
		<title>Getting Reviewers to Review</title>
		<link>http://tc.eserver.org/15139.html</link>
		<guid>http://tc.eserver.org/15139.html</guid>
		<description>Presents ten humorous suggestions for technical writers on how to persuade reviewers of documentation to do their jobs.</description>
	</item>
	<atom:link href="http://tc.eserver.org/dir/Articles/Editing/Collaboration.xml" rel="self" type="application/rss+xml"/>
</channel>
</rss>