<?xml version="1.0" encoding="utf-8" ?><rss version="2.0" xmlns:atom="http://www.w3.org/2005/Atom">
<channel>
	<title>Articles&gt;Editing</title>	<link>http://tc.eserver.org/dir/Articles/Editing</link>
	<description>A listing of the most recently indexed works about Articles and Editing in the field of technical communication.</description>
	<language>en-us</language>
	<copyright>Copyright (c) 2005-08 by the EServer. All rights reserved.</copyright>
	<managingEditor>tclib-editorial@eserver.org (TC Library Editorial Board)</managingEditor>
	<webMaster>webmaster@eserver.org (Geoffrey Sauer)</webMaster>
	<image>
		<url>http://tc.eserver.org/images/newlogo.gif</url>
		<title>Articles&gt;Editing</title>
		<link>http://tc.eserver.org/dir/Articles/Editing</link>
	</image>
	<item>
		<title>Unlocking the Special Powers of the English Language</title>
		<link>http://tc.eserver.org/35716.html</link>
		<guid>http://tc.eserver.org/35716.html</guid>
		<description>Editing really is a wonder– it’s like a multiplication of the writer’s brain, a dialogue among various copies of the author. First-draft author is an admirable workman but a bit of a hack; he writes down whatever pops into his head. Second-draft author is slower-paced but has a clearer eye for how the larger story structure fits together, or at least how it should fit once he’s done with it. Third-draft author has a remarkable knack for turning familiar and overused phrases into fresh, surprising stuff, by masticating each line. And so on. All these guys team up to make something great, and none of them could have done it alone.</description>
	</item>
	<item>
		<title>How to Change 100 Screenshots to the Same Size with a Single Click</title>
		<link>http://tc.eserver.org/35717.html</link>
		<guid>http://tc.eserver.org/35717.html</guid>
		<description>All the screenshots in your Word document are different sizes. What’s the quickest way to get them all the same size? Is there a shortcut? Yes!</description>
	</item>
	<item>
		<title>How To Write Documents Faster </title>
		<link>http://tc.eserver.org/35718.html</link>
		<guid>http://tc.eserver.org/35718.html</guid>
		<description>Most people don’t know what the AutoCorrect feature in Word really does. I use to correct the document AS I WRITE and to enter long strings of text automatically.</description>
	</item>
	<item>
		<title>What Everybody Ought to Know About Digital Photo Retouching</title>
		<link>http://tc.eserver.org/35703.html</link>
		<guid>http://tc.eserver.org/35703.html</guid>
		<description>Today we take a look deeper into the hidden art of digital retouching where skies can always be blue and imperfections simply disappear.  Whether you like it or hate it, think it’s necessary or not, retouching is here to stay.</description>
	</item>
	<item>
		<title>Writing Great Documentation: You Need an Editor</title>
		<link>http://tc.eserver.org/35710.html</link>
		<guid>http://tc.eserver.org/35710.html</guid>
		<description>All good writers have a dirty little secret: they’re not really that good at writing. Their editors just make it seem that way. It doesn’t matter how well you’ve mastered the language; nobody, even grammar geeks, gets this stuff right on the first pass. If you really want to produce great documentation, it needs to be edited.</description>
	</item>
	<item>
		<title>Choosing the Right Style Guide</title>
		<link>http://tc.eserver.org/35628.html</link>
		<guid>http://tc.eserver.org/35628.html</guid>
		<description>Style guides can improve the quality and presentation of documentation. They establish a layer of professionalism that may not have been there before. They also reduce arguments and ‘loose cannons’ within the department, as the style guide becomes the acknowledged reference. There are at least four points to consider when selecting a style guide.</description>
	</item>
	<item>
		<title>Understanding the Value of a Technical Editor</title>
		<link>http://tc.eserver.org/35639.html</link>
		<guid>http://tc.eserver.org/35639.html</guid>
		<description>Not all companies understand why it&apos;s important for them to have technical editor(s). In fact, many technical editors must justify their existence on a regular basis.</description>
	</item>
	<item>
		<title>Demonstrating the Value of Editing</title>
		<link>http://tc.eserver.org/35640.html</link>
		<guid>http://tc.eserver.org/35640.html</guid>
		<description>Like all other technical communicators, we editors must sometimes struggle to prove our worth to employers. We know our value, and the more clueful of our authors understand, but sometimes it takes a bit more work to convince senior managers that we serve a useful purpose. Managers generally require specific examples, usually supported by hard numbers. In this article, I’ve provided a few random facts and figures that I’ve accumulated over the years that you can share with management.</description>
	</item>
	<item>
		<title>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>Do I Really Need a Style Guide?</title>
		<link>http://tc.eserver.org/35211.html</link>
		<guid>http://tc.eserver.org/35211.html</guid>
		<description>Style guides recommend certain styles. In the domain of technical communication, we refer to guides for writing style, presentation of content in user documentation and technical documents, and graphical user interface of software and web sites.</description>
	</item>
	<item>
		<title>More Tips for Writing Well</title>
		<link>http://tc.eserver.org/35090.html</link>
		<guid>http://tc.eserver.org/35090.html</guid>
		<description>Be vicious when you edit. Vicious. Follow these recommendations with zealous fervor. They help your writing say what it should in a way we’ll understand.</description>
	</item>
	<item>
		<title>Examining Editor-Author Ethics: Real-World Scenarios from Interviews with Three Journal Editors</title>
		<link>http://tc.eserver.org/35000.html</link>
		<guid>http://tc.eserver.org/35000.html</guid>
		<description>Those who submit manuscripts to academic journals may benefit from a better understanding of how editors weigh ethics in their interactions with authors. In an attempt to ascertain and to understand editors&apos; ethics, we interviewed 3 current academic journal editors of technical and/or business communication journals. We asked them about the ethical dilemmas they encountered while working with authors, whether the editors formally or informally followed a &quot;code of ethics,&quot; and if they felt obligated to maintain any ethical codes in particular. In this article, we discuss the ethical dimensions of editorial practices using specific ethical scenarios provided by these three editors. We then analyze these scenarios using traditional ethical models in our field but also in terms of a less-known but powerful model of ethical analysis originally proposed by the philosopher C. S. Peirce. We argue that Peirce&apos;s &quot;community of inquiry&quot; ethics model best describes these journal editors&apos; ethics when working with authors.</description>
	</item>
	<item>
		<title>Creating an Anthology on Editing</title>
		<link>http://tc.eserver.org/35007.html</link>
		<guid>http://tc.eserver.org/35007.html</guid>
		<description>Pulling together New Perspectives on Technical Editing, an anthology on editing, was a complex, yet exhilarating experience. The process fell into four stages.</description>
	</item>
	<item>
		<title>Paper, Screen, or Scissors? Editing on Hard Copy or Soft Copy</title>
		<link>http://tc.eserver.org/35008.html</link>
		<guid>http://tc.eserver.org/35008.html</guid>
		<description>The question posted in our discussion list: Should editors edit on hard copy or soft copy? The answer: Yes. Or, it depends. Essentially it is not a matter of should; it is a matter of personal preference and what works best in different situations.</description>
	</item>
	<item>
		<title>Editorial Ethics: The Role of the Editor Before Peer Review</title>
		<link>http://tc.eserver.org/35009.html</link>
		<guid>http://tc.eserver.org/35009.html</guid>
		<description>Editors who work with authors before a manuscript is sent for review face certain challenges. Since we’re often the first to see a manuscript, we sometimes encounter problems we must help solve before they come back to bite the author. These problems fall into a variety of categories, of which I see three repeatedly in my work. In this article, I’ll discuss the nature of these problems, provide examples from my own career as a science editor, and suggest how similar problems might arise in other types of editing.</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>Edifying Editing</title>
		<link>http://tc.eserver.org/34914.html</link>
		<guid>http://tc.eserver.org/34914.html</guid>
		<description>It is a management truism that having a vision based on false hypotheses is better than a lack of vision, and like all truisms it is probably false some &#xD;of the time, but the same feature holds true in editing: the editor’s main job is to decide what is published, and what is not.</description>
	</item>
	<item>
		<title>Unproductive Review Practices: Why They’re Still Around Even Though People Know Better…</title>
		<link>http://tc.eserver.org/34910.html</link>
		<guid>http://tc.eserver.org/34910.html</guid>
		<description>I have a theory about why we continually see subject matter expertise for review applied to the task of copy-editing, and why that practice is so hard to change. The theory is built around how we: learn to write, learn to review, and ask for review.</description>
	</item>
	<item>
		<title>Misplaced Modifier – Even WSJ Falls For It</title>
		<link>http://tc.eserver.org/34884.html</link>
		<guid>http://tc.eserver.org/34884.html</guid>
		<description>“Misplaced modifier” is a frequently committed logical error that even the most prominent publications fall for occasionally. Solution? Move the modifier clause right next to the subject of the sentence.</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>The Construction of Author Voice by Editorial Board Members</title>
		<link>http://tc.eserver.org/34840.html</link>
		<guid>http://tc.eserver.org/34840.html</guid>
		<description>Studies of blind manuscript review have illustrated that readers often form impressions of or speculate about unknown authors&apos; identities in the manuscript review task. In this article, the authors extend that work by examining the discursive and nondiscursive features that play a role in readers&apos; active construction of author voice. Through a survey completed by 70 editorial board members of six journals in applied linguistics and rhetoric and composition, the authors identify quantitative and qualitative trends in reviewers&apos; practices regarding voice construction. Findings indicate that many readers do build impressions of an author&apos;s identity when reviewing anonymous manuscripts and that the rhetorical nature of the review task may lead readers to attend more to some discursive features than to others.</description>
	</item>
	<item>
		<title>Why the Focus on Review Practices?</title>
		<link>http://tc.eserver.org/34793.html</link>
		<guid>http://tc.eserver.org/34793.html</guid>
		<description>improving document review practices is of great concern to many in the biopharmaceutical industry.  The reason for this interest can be explained by the following observations which provide some insight as to why review is, or needs to be, a central focus for improving knowledge propagation and dissemination.</description>
	</item>
	<item>
		<title>Copywriting Tip: Have the Computer Read Your Writing Back To You</title>
		<link>http://tc.eserver.org/34746.html</link>
		<guid>http://tc.eserver.org/34746.html</guid>
		<description>You don’t have an office mate willing to read your work aloud? Don’t want to bug someone to read your two paragraph blog post? Have your computer read it to you!</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>How to &quot;Proof&quot; a Translation</title>
		<link>http://tc.eserver.org/34594.html</link>
		<guid>http://tc.eserver.org/34594.html</guid>
		<description>As the global economy expands, American companies are translating large numbers of documents into multiple languages. As a technical writer, my job is to read documents in German, Italian, Danish, French, Spanish, Greek, and Polish among other languages. I also review documents in Chinese, Japanese, and Korean, but the process is harder and less productive. This article will provide a few practical tips for &quot;proofing&quot; translations of Western documents.</description>
	</item>
	<item>
		<title>How to Save Money on Translation By Editing the Source Text</title>
		<link>http://tc.eserver.org/34595.html</link>
		<guid>http://tc.eserver.org/34595.html</guid>
		<description>If translators had a list of FAQ&apos;s, the number one question would undoubtedly be &quot;What can we do to cut the cost of our translations?&quot; There are a number of answers to this question, but the simplest is to reduce the number of words in your documents before translating. Translation is usually priced by the word; therefore the fewer words for translation, the less it costs.</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>Do I Really Need a Style Guide?</title>
		<link>http://tc.eserver.org/34443.html</link>
		<guid>http://tc.eserver.org/34443.html</guid>
		<description>So, after all, I must follow those infernal style guides. I am straight-jacketed. Am I not?</description>
	</item>
	<item>
		<title>Editing Modular Documentation: Some Best Practices</title>
		<link>http://tc.eserver.org/34350.html</link>
		<guid>http://tc.eserver.org/34350.html</guid>
		<description>The authors have come up with eight guidelines and three concrete suggestions on best practices for editing modular documentation, including ensuring that all topics are standalone, that titles are unique and descriptive, and more.</description>
	</item>
	<item>
		<title>Comparing Featured Article Groups and Revision Patterns Correlations in Wikipedia</title>
		<link>http://tc.eserver.org/34286.html</link>
		<guid>http://tc.eserver.org/34286.html</guid>
		<description>Collaboratively written by thousands of people, Wikipedia produces entries which are consistent with criteria agreed by Wikipedians and of high quality. This article focuses on Wikipedia’s Featured Articles and shows that not every contribution can be considered as being of equal quality. Two groups of articles are analysed by focusing on the edits distribution and the main editors’ contribution. The research shows how these aspects of the revision patterns can change dependent upon the category to which the articles belong.</description>
	</item>
	<item>
		<title>Regular Expressions - a Simple User Guide</title>
		<link>http://tc.eserver.org/34211.html</link>
		<guid>http://tc.eserver.org/34211.html</guid>
		<description>There is no gentle beginning to regular expressions. You are either into hieroglyphics big time - in which case you will love this stuff - or you need to use them in which case a headache may be your only reward.</description>
	</item>
	<item>
		<title>Editing and Publishing</title>
		<link>http://tc.eserver.org/34212.html</link>
		<guid>http://tc.eserver.org/34212.html</guid>
		<description>Once the main text has been written, you edit it.  Editing means breaking text into sub-documents; pointing out connections to other texts; making sure the document as a whole is in good shape; adding indices and outlines.  Editing doesn&apos;t necessarily happen after the first text has been written - I mix those stages all the time - but it deserves to be thought of as an independent discipline, because the problems it deals with are different.  Most of what people do on the World Wide Web is really editing, not writing. </description>
	</item>
	<item>
		<title>Speaking UNIX, Part 9: Regular Expressions</title>
		<link>http://tc.eserver.org/34214.html</link>
		<guid>http://tc.eserver.org/34214.html</guid>
		<description>Virtually all non-trivial problems require you to filter good data from bad. Discover the many UNIX command line utilities that use regular expressions to discern the relevant from the irrelevant.</description>
	</item>
	<item>
		<title>InDesign CS3: Search Using GREP Expressions</title>
		<link>http://tc.eserver.org/34207.html</link>
		<guid>http://tc.eserver.org/34207.html</guid>
		<description>On the GREP tab of the InDesign Find/Change dialog box, you can construct GREP expressions to find alphanumeric strings and patterns in long documents or many open documents. You can enter the GREP metacharacters manually or choose them from the Special Characters For Search list. GREP searches are case-sensitive by default.</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>Graphic Thoughts: My Top 10 Photoshop Moves, Part 1</title>
		<link>http://tc.eserver.org/33533.html</link>
		<guid>http://tc.eserver.org/33533.html</guid>
		<description>Almost every time I speak to an audience about graphics or Photoshop, I’m asked if I went to school to learn what I know about the application. The truth is that while I spent more than 3 years in an Advertising Art degree program, I ultimately switched gears and got a Bachelor of Business Administration degree in marketing (Mom and Dad were thrilled with this news!), and that was in the early ’90s—pretty much in the infant stages of Photoshop.</description>
	</item>
	<item>
		<title>Graphic Thoughts: Creating Great Backgrounds in A Snap</title>
		<link>http://tc.eserver.org/33540.html</link>
		<guid>http://tc.eserver.org/33540.html</guid>
		<description>Recently, I had the chance to go with my in-laws to City Museum in St. Louis. What an amazing place to get lost in by crawling through inventively designed tunnels that go underground to many stories below the city streets. The most impressive thing to me was how the place was constructed—they used everyday items, such as metal storage bins, bottles, and gears (plus what looked like a million other items) to create elaborate mazes of artwork.</description>
	</item>
	<item>
		<title>Adding High-Impact Filters to Your Titles</title>
		<link>http://tc.eserver.org/33544.html</link>
		<guid>http://tc.eserver.org/33544.html</guid>
		<description>Words go so well with video. They can give an emotional punch to a scene or simply announce what is going to happen next. I love using romantic quotes, Bible passages, and other forms of text in my work. The best part is that you can be just as creative with how those words are presented as you are in picking out the text in the first place.</description>
	</item>
	<item>
		<title>Creating Perspective Shadows</title>
		<link>http://tc.eserver.org/33545.html</link>
		<guid>http://tc.eserver.org/33545.html</guid>
		<description>Perspective—it’s one of the first things you learn about in any art class. The basic idea is that it’s the way your eye actually sees something, represented on a flat surface such as paper or a monitor. A simple example is drawing a group of objects: You represent an object in the distance by making it smaller, while making objects close to the viewer larger—make sense?&#xD;&#xD;In this tutorial, I’m going to show you how to create perspective shadows in Adobe Photoshop CS3. The result is dynamic, but the technique is a breeze!</description>
	</item>
	<item>
		<title>Crop Images Contextually</title>
		<link>http://tc.eserver.org/33127.html</link>
		<guid>http://tc.eserver.org/33127.html</guid>
		<description>Crop images contextually for faster downloads and higher impact. By cropping maximally and resizing you can convey meaning without slowing down your web pages.</description>
	</item>
	<item>
		<title>Appropriate Use of Alternative Text</title>
		<link>http://tc.eserver.org/32877.html</link>
		<guid>http://tc.eserver.org/32877.html</guid>
		<description>Adding alternative text for images is the first principle of web accessibility. It is also one of the most difficult to properly implement. The web is replete with images that have missing, incorrect, or poor alternative text. Like many things in web accessibility, determining appropriate, equivalent, alternative text is often a matter of personal interpretation. Through the use of examples, this article will present our experienced interpretation of appropriate use of alternative text.</description>
	</item>
	<item>
		<title>Relative Sizing and Images</title>
		<link>http://tc.eserver.org/32908.html</link>
		<guid>http://tc.eserver.org/32908.html</guid>
		<description>Few people realize that with today&apos;s modern browsers, relative sizing can in fact be added to images as well as text elements on your web page. Making the image scale with the text may aid in accessibility, despite the degradation of quality.</description>
	</item>
	<item>
		<title>How Microsoft Pushed QuickTime&apos;s Final Cut </title>
		<link>http://tc.eserver.org/32713.html</link>
		<guid>http://tc.eserver.org/32713.html</guid>
		<description>Apple&apos;s work to aggressively build upon QuickTime and compete in the market against Microsoft--rather than just handing its technology over and “partnering” with the company--launched Apple ahead and established major new markets for the Mac platform. Final Cut Pro initially established the Mac as an essential tool among editors.</description>
	</item>
	<item>
		<title>Forty Beautiful Grunge Photoshop Tutorials</title>
		<link>http://tc.eserver.org/32717.html</link>
		<guid>http://tc.eserver.org/32717.html</guid>
		<description>In this collection, we present to you 40 excellent, high-quality grunge Photoshop tutorials. So fire up Photoshop and get ready to get your hands… dirty!</description>
	</item>
	<item>
		<title>Quick, Quality Indexing for Environmental, Safety, and Health</title>
		<link>http://tc.eserver.org/32684.html</link>
		<guid>http://tc.eserver.org/32684.html</guid>
		<description>Indexing for environmental, safety, and health texts, you provide sure, quick access to critical information in times of need.</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>How to Manage Out of Date Content</title>
		<link>http://tc.eserver.org/32534.html</link>
		<guid>http://tc.eserver.org/32534.html</guid>
		<description>Organizations are in urgent need of professional review processes for their intranets and public websites. Out of date content is growing year by year, and there are many horror stories about out-of-date content waiting to happen. It’s time for management to get serious and professionally manage their websites.</description>
	</item>
	<item>
		<title>Drawing Hilbert Curves with SVG</title>
		<link>http://tc.eserver.org/32549.html</link>
		<guid>http://tc.eserver.org/32549.html</guid>
		<description>Hilbert curves are a type of space-filling curve that can be constructed with the SVG polyline element, using a basic design and then aggregating.</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>Lost in Translation: Contributions of Editors to the Meanings of Text</title>
		<link>http://tc.eserver.org/32274.html</link>
		<guid>http://tc.eserver.org/32274.html</guid>
		<description>Authors of scientific articles in one language are often required to provide abstracts of their papers in a second language, and they use a variety of ways to achieve this.</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>Jabberwock</title>
		<link>http://tc.eserver.org/32134.html</link>
		<guid>http://tc.eserver.org/32134.html</guid>
		<description>Technical editors are constantly required to edit and revise pieces that they don’t fully understand - or even have much information about. That’s part of the game.</description>
	</item>
	<item>
		<title>Editing Modular Documentation: Some Best Practices</title>
		<link>http://tc.eserver.org/32036.html</link>
		<guid>http://tc.eserver.org/32036.html</guid>
		<description>Much has been said about the creation of modular documentation - from content management systems, to information architecture, to delivery forms, to the usability of modular content (content being easier to use, easier to understand, and easier to find), and so on. However, not much has been said about the editing of that content, and what the editor&apos;s role is in such an environment.</description>
	</item>
	<item>
		<title>Tech Writers, Grammar, and the Prescriptive Attitude</title>
		<link>http://tc.eserver.org/32043.html</link>
		<guid>http://tc.eserver.org/32043.html</guid>
		<description>Prescriptive grammar is useful for teaching English as a second language, but it has little value for the practicing writer. Clinging to it may provide emotional security, but only at the expense of making writing harder than it needs to be. The culture-wide devotion to it will not be changed in a moment. But conscientious writers can at least change their own habits, and make life easier for themselves.</description>
	</item>
	<item>
		<title>Technical Writing&apos;s Big Secret</title>
		<link>http://tc.eserver.org/31939.html</link>
		<guid>http://tc.eserver.org/31939.html</guid>
		<description>The big secret in technical writing is that most of the harder documents aren&apos;t written by the technical writers at all. In fact, many &quot;technical writers&quot; never do any writing at all. Instead, the drafts are written by engineers or marketers. The technical writers perform editorial functions and provide publications services -- copy-editing, layout, review management, and so on.</description>
	</item>
	<item>
		<title>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>How to Avoid Proofreading Blunders</title>
		<link>http://tc.eserver.org/31662.html</link>
		<guid>http://tc.eserver.org/31662.html</guid>
		<description>The following tips are to help you avoid embarassing--and costly--bloppers and blunders.</description>
	</item>
	<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>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>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>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>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>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>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>Regular Expression Basics</title>
		<link>http://tc.eserver.org/26327.html</link>
		<guid>http://tc.eserver.org/26327.html</guid>
		<description>Regular expressions, sometimes referred to as regex, grep, or pattern matching, can be a very powerful tool and a tremendous time-saver with a broad range of application. As an extended form of find-and-replace, you can use a regular expression to do things such as perform client-side validation of email addresses and phone numbers, search multiple documents for strings and patterns you wish to change or remove, or extract a list of links from source code. Regex is supported by most languages and tools, but because there can be varying implementations, this article will cover basic principles that are commonly used.</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>
	<atom:link href="http://tc.eserver.org/dir/Articles/Editing.xml" rel="self" type="application/rss+xml"/>
</channel>
</rss>