<?xml version="1.0" encoding="UTF-8"?><rss version="2.0" xmlns:atom="http://www.w3.org/2005/Atom">
categoryallspace2-Style Guides
<channel>
	<title>Style Guides</title>	<link>http://tc.eserver.org/dir/Style-Guides</link>
	<description>A directory of resources about style guides in the field of technical communication.</description>
	<language>en-us</language>
	<atom:link href="http://tc.eserver.org/dir/Style-Guides.xml" rel="self" type="application/rss+xml" />
	<copyright>Copyright (c) 2005-08 by the EServer. All rights reserved.</copyright>
	<managingEditor>tclib-editorial@eserver.org (TC Library Editorial Board)</managingEditor>
	<webMaster>webmaster@eserver.org (Geoffrey Sauer)</webMaster>
	<image>
		<url>http://tc.eserver.org/images/newlogo.gif</url>
		<title>Style Guides</title>
		<link>http://tc.eserver.org/dir/Style-Guides</link>
	</image>
	<item>
		<title>Style Guides? Dictionaries? Who Cares?</title>
		<link>http://tc.eserver.org/31331.html</link>
		<guid>http://tc.eserver.org/31331.html</guid>
		<description>You should! Whether you&apos;re a corporate or a freelance communicator, a style guide and a dictionary are among your most important tools. And all the departments in your company or your client&apos;s company should be using the same ones, designated by their communication departments.</description>
	</item>
	<item>
		<title>404 File Not Found: Citing Unstable Web Sources</title>
		<link>http://tc.eserver.org/30998.html</link>
		<guid>http://tc.eserver.org/30998.html</guid>
		<description>Researchers, including students, must accommodate to the mutating character of hyperlinks on the World Wide Web. A small study of citations in three volumes of BCQ demonstrates the phenomenon of &apos;URL rot,&apos; the disappearance of sites cited in the sample articles. Digital technology itself is now being used to create pockets of permanence, but with the understanding that preservation of content is only one ingredient in the mix of media and format migration. Databases like JSTOR offer digitally preserved copies of many scholarly journals. Online journals and search engines may offer their own archives. In general, researchers should cite digital articles in databases where possible and consider avoiding references to online journals with print editions.</description>
	</item>
	<item>
		<title>Microsoft Manual of Style for Technical Publications</title>
		<link>http://tc.eserver.org/30813.html</link>
		<guid>http://tc.eserver.org/30813.html</guid>
		<description>Understanding the user interface can be a confusing experience for customers. By using a consistent set of terminology and style, you can help customers navigate the product user interface successfully. Once customers become familiar with this system, they can jump seamlessly between content about different products.</description>
	</item>
	<item>
		<title>Editing the Baldridge Quality Award Application</title>
		<link>http://tc.eserver.org/30486.html</link>
		<guid>http://tc.eserver.org/30486.html</guid>
		<description>Editing the Baldrige award application requires unique plans for the writing, editing, reviewing, and publishing cycle. The editor’s role includes training nonwriters to write, establishing style guidelines, setting reasonable schedules, and editing each draft.</description>
	</item>
	<item>
		<title>Designing Automated Custom Templates as Part of A Global Corporation&apos;s Style Guide</title>
		<link>http://tc.eserver.org/30134.html</link>
		<guid>http://tc.eserver.org/30134.html</guid>
		<description>When CH2M HILL staff ignored the Times 12 standard for document production and began inventing their own formats, they often bypassed the company&apos;s Publications groups, resulting in client bewilderment and anger. We will orient the audience to how creative thinking and innovative programming made it easy for staff to produce consistently attractive and effectively formatted documents. We also will demonstrate the final Toolset version and supply information about how you can apply the benefits of a Toolset product in your company&apos;s environment.</description>
	</item>
	<item>
		<title>Developing a Corporate Style Guide</title>
		<link>http://tc.eserver.org/29642.html</link>
		<guid>http://tc.eserver.org/29642.html</guid>
		<description>Developing corporate style guides helps documentation departments or any other group apply the same standards when writing documents for publication or presentation. Three types of style guides exist: static, dynamic, and multi-level. The information that goes into a style guide depends upon corporate and department guidelines. Publishing, promoting, and maintaining style guides are the responsibility of the responsible department. In many corporations this may be the technical documentation department, while for others it may be the corporate marketing or internal communications departments.</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>The Blue Book of Grammar and Punctuation</title>
		<link>http://tc.eserver.org/28137.html</link>
		<guid>http://tc.eserver.org/28137.html</guid>
		<description>If you are still struggling to decode the complex jargon and structure of English grammar with a long list of reference books, relax. The long wait for a reader-friendly book on English grammar is over. With her straightforward and perfectly-logical approach, Jane Straus reveals the mysteries of grammar and punctuations in her book The Blue Book of Grammar and Punctuation. The book is extremely well-organized, allowing readers to quickly locate the required topics. Concepts are described in clear and simple phrases, backed with examples from everyday language usage.</description>
	</item>
	<item>
		<title>Web Design Standards: 10 Organizational Secrets</title>
		<link>http://tc.eserver.org/27389.html</link>
		<guid>http://tc.eserver.org/27389.html</guid>
		<description>The practices and processes that facilitate the organizational development needed to create a successful Web design standard.</description>
	</item>
	<item>
		<title>Apple Publications Style Guide</title>
		<link>http://tc.eserver.org/27313.html</link>
		<guid>http://tc.eserver.org/27313.html</guid>
		<description>The Apple Publications Style Guide provides editorial guidelines for text in Apple instructional publications, technical documentation, reference information, training programs, and the software user interface.</description>
	</item>
	<item>
		<title>Intelligent Terminology Management</title>
		<link>http://tc.eserver.org/27272.html</link>
		<guid>http://tc.eserver.org/27272.html</guid>
		<description>Using multiple terms to refer to the same concepts can be a major cause of confusion. Ray explains how to implement a process to consolidate the terminology used by your organization.</description>
	</item>
	<item>
		<title>Style Guides</title>
		<link>http://tc.eserver.org/26836.html</link>
		<guid>http://tc.eserver.org/26836.html</guid>
		<description>Style guides are used to provide a consistent look and feel. They should be defined as part of usability requirements and conformance should be monitored during development.</description>
	</item>
	<item>
		<title>Social Rules for Creating a Style Guide</title>
		<link>http://tc.eserver.org/26744.html</link>
		<guid>http://tc.eserver.org/26744.html</guid>
		<description>Creating a style guide may initially seem like a terminology affair (&apos;option button&apos; or &apos;radio button&apos; - pick one), but the real challenge lies in persuading the department to adopt new style principles. Some writers will feel threatened by change, and respond in bizarre and unpredictable ways. Whisper campaigns and ambushes may lie in wait for you. Beware, innovative editor! Before you even think about the literary details of style, prepare to do battle with the true Goliaths and Grendyls: the department itself. By following these five rules below, you can avoid an unexpected apocalypse when you reveal the new guide.</description>
	</item>
	<item>
		<title>DocBook Element Quick Reference Card</title>
		<link>http://tc.eserver.org/26195.html</link>
		<guid>http://tc.eserver.org/26195.html</guid>
		<description>A one-page reference card for DocBook elements.</description>
	</item>
	<item>
		<title>Keep Spelling Consistent With a Style Sheet</title>
		<link>http://tc.eserver.org/26152.html</link>
		<guid>http://tc.eserver.org/26152.html</guid>
		<description>Consistent spelling and punctuation increases your website&apos;s credibility. Often it&apos;s your decision: &apos;inhouse&apos; or &apos;in-house&apos;, for instance? Either one is correct, but you must use the same punctuation throughout.</description>
	</item>
	<item>
		<title>Corporate Pages 2002-2004 (Part 2)</title>
		<link>http://tc.eserver.org/26138.html</link>
		<guid>http://tc.eserver.org/26138.html</guid>
		<description>When training web authors, I prefer to use good examples of their kind, so these must have been either typical or among the best I could find at the time. However, they certainly did not contain content to skite about.</description>
	</item>
	<item>
		<title>Standards for Online Content Authors</title>
		<link>http://tc.eserver.org/26128.html</link>
		<guid>http://tc.eserver.org/26128.html</guid>
		<description>The standards on this page include non-technical standards relevant to all web authors and technical standards relevant to some web authors.</description>
	</item>
	<item>
		<title>Guideline Dogma</title>
		<link>http://tc.eserver.org/26087.html</link>
		<guid>http://tc.eserver.org/26087.html</guid>
		<description>Nobody would deny that usability guidelines, applied in context by a usability professional, are extremely valuable in guiding a website evaluation. The problem occurs when non-professionals apply these guidelines out of context. This can result in an unimaginative site that looks bland and homogenous. To design usable sites that truly engage customers we need to replace simple guidelines with a customer-centred design process.</description>
	</item>
	<item>
		<title>Microsoft Manual of Style for Technical Publications</title>
		<link>http://tc.eserver.org/26068.html</link>
		<guid>http://tc.eserver.org/26068.html</guid>
		<description>Microsoft is one of the largest software companies in the world. Thus, with their rich experience in documentation it is only natural that they share it with the rest of the IT industry. The Microsoft Manual of Style for Technical Publications, Third Edition (MSTP) is the latest step in this direction and takes care of latest technologies and technical terms.</description>
	</item>
	<item>
		<title>Confusing Words</title>
		<link>http://tc.eserver.org/25797.html</link>
		<guid>http://tc.eserver.org/25797.html</guid>
		<description>Confusing Words is a collection of words that are troublesome to readers and writers. Words are grouped according to the way they are most often confused or misused.</description>
	</item>
	<item>
		<title>Fear of Punctuation</title>
		<link>http://tc.eserver.org/25796.html</link>
		<guid>http://tc.eserver.org/25796.html</guid>
		<description>So maybe you do know how to add memory to your computer or program your cell phone, but do you know where to put a comma in a sentence? If you have a sentence followed by a list, do you use a semicolon or a colon? Does the period go inside or outside of quotation marks? How do you keep up with changing rules of grammar and punctuation when you can&apos;t remember where to put the apostrophe? People often fear punctuation because the rules have changed and they continue to do so.</description>
	</item>
	<item>
		<title>GrammarNOW</title>
		<link>http://tc.eserver.org/25798.html</link>
		<guid>http://tc.eserver.org/25798.html</guid>
		<description>This site is dedicated to answering grammar, composition, or formatting questions.</description>
	</item>
	<item>
		<title>Five FAQs About Business Writing</title>
		<link>http://tc.eserver.org/25785.html</link>
		<guid>http://tc.eserver.org/25785.html</guid>
		<description>A few style guide tips for novice business writers.</description>
	</item>
	<item>
		<title>Colour Design and Tools</title>
		<link>http://tc.eserver.org/25754.html</link>
		<guid>http://tc.eserver.org/25754.html</guid>
		<description>With cartography on the Web, the use of colour plays an important role in the visualization and analysis of data. The correct application of colour for the display of thematic map data, allows for the better observation of interrelationships and patterns.</description>
	</item>
	<item>
		<title>European Union Interinstitutional Style Guide</title>
		<link>http://tc.eserver.org/25311.html</link>
		<guid>http://tc.eserver.org/25311.html</guid>
		<description>One of the European Union’s vital tasks is to circulate and disseminate information in 11 languages. People are not generally aware of the scale and complexity of this task, and the ever-increasing amount and multilingual character of the documentation to be distributed, and it is only through continual development of the techniques used and constant rationalisation that the task can be accomplished each day. The Interinstitutional style guide has been produced with these things in mind.</description>
	</item>
	<item>
		<title>Sample IEEE Documentation Style for References</title>
		<link>http://tc.eserver.org/25309.html</link>
		<guid>http://tc.eserver.org/25309.html</guid>
		<description>References to sources should be numbered sequentially by order of mention in the text, with the number placed in brackets and printed on line (not as a super- or subscript) like [1].</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>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>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>EERE Communication Standards and Guidelines</title>
		<link>http://tc.eserver.org/24671.html</link>
		<guid>http://tc.eserver.org/24671.html</guid>
		<description>The development and dissemination of new communication standards and guidelines are evolving processes that require cooperation, teamwork, and clear communication.</description>
	</item>
	<item>
		<title>Polished Panache: The Empowered Corporate Style Guide</title>
		<link>http://tc.eserver.org/24421.html</link>
		<guid>http://tc.eserver.org/24421.html</guid>
		<description>A customized style guide is a document that defines the specific formatting, mechanical, punctuation, and spelling standards for your department or company. When you decide that you need a customized style guide, many questions arise: Where do you start? How do you get there? Exactly where is it you want to go? Are there more issues you need to define? Deciding that you need a customized style guide is the first hurdle. Persuading upper-level management to fund the guide is the second hurdle. And then it’s off to the races...</description>
	</item>
	<item>
		<title>Using a Doc Spec for Printed Books</title>
		<link>http://tc.eserver.org/24277.html</link>
		<guid>http://tc.eserver.org/24277.html</guid>
		<description>All technical documentation projects benefit from a good content plan or &apos;doc spec.&apos; The doc spec is a blueprint for a document. It identifies the product, users, source materials, and subject matter experts (SMEs). It also provides a preliminary outline of topics and estimates the work effort to produce the document. The doc spec template is simply a tool that guides you through the document planning and estimating process. Your customized doc spec serves as a record of the who, what, when, why, and how of your project.</description>
	</item>
	<item>
		<title>Using a WWW Development Design Document to Create a Comprehensive Web Site</title>
		<link>http://tc.eserver.org/24275.html</link>
		<guid>http://tc.eserver.org/24275.html</guid>
		<description>Technical Communicators are eminently qualified for Web publishing as it is a natural extension of our writing abilities. However, we must be careful to avoid the pitfalls of Web publishing and contribute to the host of glamorous Web sites that lack content, are difficult to navigate, and do not satisfy the ultimate goals of the organization or institution the site represents. One proven technique for planning and implementing a Web site is the creation of a WWW Development Design Document. By championing the development of this document, communicators return to their knowledge roots of organization and writing.</description>
	</item>
	<item>
		<title>Reconsidering Some Prescriptive Rules of Grammar and Composition</title>
		<link>http://tc.eserver.org/24162.html</link>
		<guid>http://tc.eserver.org/24162.html</guid>
		<description>Technical writers and editors are beset with rules. As authoritative as they are, published style guides such as The Chicago manual of style, MLA, APA, and Gregg do not address reading theory but hang their prescriptions on the flimsy mantle of tradition. This article challenges some putative rules of grammar and mechanics in an effort to improve technical texts for the people who read them.</description>
	</item>
	<item>
		<title>Technical Report Overview</title>
		<link>http://tc.eserver.org/24117.html</link>
		<guid>http://tc.eserver.org/24117.html</guid>
		<description>This outline is provided to help introduce the Technical Report and to clarify the acceptable format and level of achievement that is considered essential for successful completion of the Technical Report.</description>
	</item>
	<item>
		<title>The Economist Style Guide</title>
		<link>http://tc.eserver.org/24076.html</link>
		<guid>http://tc.eserver.org/24076.html</guid>
		<description>This guide is based on the style book which is given to all journalists at &lt;i&gt;The Economist&lt;/i&gt;.</description>
	</item>
	<item>
		<title>Handling Internet Addresses in Text</title>
		<link>http://tc.eserver.org/24062.html</link>
		<guid>http://tc.eserver.org/24062.html</guid>
		<description>How to present complete and intelligible Internet addresses and where to break long strings of letters, digits, punctuation, and symbols on the page.</description>
	</item>
	<item>
		<title>The Curse of Yocto</title>
		<link>http://tc.eserver.org/24033.html</link>
		<guid>http://tc.eserver.org/24033.html</guid>
		<description>Several years ago, four new prefixes, for representing very large and very small measurements, were introduced into the International System of Units (Système International d&apos;Unités, or SI): yotta, zetta, zepto and yocto.</description>
	</item>
	<item>
		<title>Hand-Picked Descriptive Words</title>
		<link>http://tc.eserver.org/24034.html</link>
		<guid>http://tc.eserver.org/24034.html</guid>
		<description>Writing a good description is fun, but it&apos;s delicate work. We recognize vivid writing when we come across it, and we know the bad stuff, too -- it makes us squirm instinctively. Here are some types of descriptions the world can do without.</description>
	</item>
	<item>
		<title>Necessary Transition</title>
		<link>http://tc.eserver.org/24042.html</link>
		<guid>http://tc.eserver.org/24042.html</guid>
		<description>As writers and editors, we understand instinctively that readers need transitions, but we also work at getting rid of unnecessary words.</description>
	</item>
	<item>
		<title>Scientific Style Manual Aspires to International Scope</title>
		<link>http://tc.eserver.org/24031.html</link>
		<guid>http://tc.eserver.org/24031.html</guid>
		<description>Despite what some U.S. editors may see as flaws or debatable recommendations, sooner or later anyone who edits scientific writing will consult &lt;i&gt;Scientific Style and Format.&lt;/i&gt; Some may disagree with its style conventions, but they can be defended as serving the editors&apos; stated goal of achieving a uniform international style for scientific publications. </description>
	</item>
	<item>
		<title>Verbs with -ize: Efficient or to Be ... Ostracized?</title>
		<link>http://tc.eserver.org/24032.html</link>
		<guid>http://tc.eserver.org/24032.html</guid>
		<description>A discussion of whether neologisms such as &apos;prioritize&apos; have &apos;arrived&apos; yet.</description>
	</item>
	<item>
		<title>Catching Errors in Internet Addresses</title>
		<link>http://tc.eserver.org/24018.html</link>
		<guid>http://tc.eserver.org/24018.html</guid>
		<description>Internet addresses have been proliferating in publications, and they&apos;re not going to go away. Editors unfamiliar with the Net may see these addresses as incomprehensible blocks of characters that can&apos;t be understood or analyzed into components. But learning a little about their structure can help prevent you from publishing erroneous addresses.</description>
	</item>
	<item>
		<title>GNOME Documentation Style Guide</title>
		<link>http://tc.eserver.org/23963.html</link>
		<guid>http://tc.eserver.org/23963.html</guid>
		<description>The GNOME Documentation Style Guide provides guidelines for authors who want to contribute to the GNOME Documentation Project.</description>
	</item>
	<item>
		<title>A Handful of New Style and Usage Guides</title>
		<link>http://tc.eserver.org/24013.html</link>
		<guid>http://tc.eserver.org/24013.html</guid>
		<description>Style and usage guides seem to have proliferated, and it&apos;s not always easy to discriminate between the valuable and the less so at a glance. Here are three that have come to hand recently and deserve mentioning for different reasons.</description>
	</item>
	<item>
		<title>Localization Guidelines for Language and Terminology</title>
		<link>http://tc.eserver.org/23959.html</link>
		<guid>http://tc.eserver.org/23959.html</guid>
		<description>How does your writing style affect localization? The following list of suggestions provides some language and terminology guidelines that should ease localizing your application.</description>
	</item>
	<item>
		<title>Localization Guidelines for Your User Interface</title>
		<link>http://tc.eserver.org/23960.html</link>
		<guid>http://tc.eserver.org/23960.html</guid>
		<description>When delivering your product in foreign languages, it is important to consider how the user interface will appear to users around the world. While there are no hard-fast rules, the following suggestions provide some guidance in facilitating localization in regard to your user interface.</description>
	</item>
	<item>
		<title>Concise Writing Guide</title>
		<link>http://tc.eserver.org/23901.html</link>
		<guid>http://tc.eserver.org/23901.html</guid>
		<description>Provides alternatives to overstated, pompous words; wordy, bureaucratic phrases; and verbose, sometimes amusing redundant phrases.</description>
	</item>
	<item>
		<title>Garbl&apos;s Style Manual</title>
		<link>http://tc.eserver.org/23899.html</link>
		<guid>http://tc.eserver.org/23899.html</guid>
		<description>This manual mostly follows Associated Press style but also follows advice of other excellent books on writing and Web sites listed in Garbl&apos;s Writing Resources Online -- and my selection and interpretation of their guidelines. This guide focuses on U.S. standards for spelling, punctuation, definitions, usage, style and grammar.</description>
	</item>
	<item>
		<title>Terminology Made Simple</title>
		<link>http://tc.eserver.org/23910.html</link>
		<guid>http://tc.eserver.org/23910.html</guid>
		<description>This paper describes the types of terms that you should include in software product glossary and describes how to write definitions for these terms. It also describes a method for controlling word usage and managing terminology for software projects.</description>
	</item>
	<item>
		<title>Writing Resources Online</title>
		<link>http://tc.eserver.org/23900.html</link>
		<guid>http://tc.eserver.org/23900.html</guid>
		<description>This annotated directory features Web sites focusing on English grammar, concise writing, style and usage, the writing process, words, plain language, creativity, word play, action writing, reference sources, online writing experts, books on writing, and favorite fiction writers. You&apos;ll also find lists of Web sites on punctuation, avoiding bias, overcoming writer&apos;s block, spelling, vocabulary, and writing for the Web.</description>
	</item>
	<item>
		<title>Basic Prose Style and Mechanics</title>
		<link>http://tc.eserver.org/23813.html</link>
		<guid>http://tc.eserver.org/23813.html</guid>
		<description>This pamphlet is designed to introduce you to, or remind you of, the basic principles of prose style and mechanics. The Prose Style Section describes twelve basic principles of good prose style and illustrates most of these principles with examples. Since most writers and editors agree about the importance of these twelve basic principles, I have drawn from a wide variety of sources. However, I would especially recommend two texts: The Elements of Style by William Strunk and E.B. White and Style: Ten Lessons in Clarity &amp; Grace by Joseph Williams.</description>
	</item>
	<item>
		<title>Do-It-Yourself Style Guides for All Occasions</title>
		<link>http://tc.eserver.org/23791.html</link>
		<guid>http://tc.eserver.org/23791.html</guid>
		<description>A style guide is a formal set of editorial decisions for a specific set of documents. It can serve many functions, and can apply to many kinds of &apos;documents&apos;. Whenever&#xD;you have a number of similar documents to create or&#xD;edit, a style guide can save time and energy (thus&#xD;reducing costs), and improve the final product. The&#xD;contents and structure of your guide can be form-fitted&#xD;to meet your needs. If you start small and follow these&#xD;suggestions, you can easily generate a style guide that&#xD;will be welcomed and used.</description>
	</item>
	<item>
		<title>Using Manual Quality Tables To Improve Manual Quality</title>
		<link>http://tc.eserver.org/23783.html</link>
		<guid>http://tc.eserver.org/23783.html</guid>
		<description>Technical writers need to decide what information is to go into a manual, and in how much detail. Such decisions can have a crucial effect on manual quality. Poor decisions can result in published manuals that lack required information, contain unsuitable or unnecessary information, or repeat information in other manuals. To help make better decisions, Hitachi technical writers use Manual Quality Tables. The tables specify what type of information is to go into a manual, the required level of detail, and sources for the information. These tables enable writers to itemize the required contents of a manual before starting to write the manual. In addition,&#xD;during later revisions, the tables enable writers or&#xD;reviewers to easily discover any topics that were left out&#xD;in the original version.</description>
	</item>
	<item>
		<title>Style, Grammar, and Usage</title>
		<link>http://tc.eserver.org/23726.html</link>
		<guid>http://tc.eserver.org/23726.html</guid>
		<description>Information on style, grammar, and usage.</description>
	</item>
	<item>
		<title>Capitalization of Headings and Titles</title>
		<link>http://tc.eserver.org/23493.html</link>
		<guid>http://tc.eserver.org/23493.html</guid>
		<description>The following summarizes the replies to the question of &apos;capitalization of headings and titles&apos; in the mailing list tcf-gen in recent months.</description>
	</item>
	<item>
		<title>Do Technical Writers Need an International Standard for English-Language Spelling?</title>
		<link>http://tc.eserver.org/23501.html</link>
		<guid>http://tc.eserver.org/23501.html</guid>
		<description>He demonstrates how ministers of state who speak different languages often choose English as the most convenient language of communication. He cites the 11-nation European Central Bank in Frankfurt as a typical organization that works only in English. And he notes that many of the journals published by respected international organizations such as the Pasteur Institute also are published in English. TC-Forum is another example.</description>
	</item>
	<item>
		<title>Engineering Communication Centre</title>
		<link>http://tc.eserver.org/23503.html</link>
		<guid>http://tc.eserver.org/23503.html</guid>
		<description>Language Across the Curriculum in Applied Science and Engineering at the University of Toronto helps students to communicate in writing and orally.</description>
	</item>
	<item>
		<title>Guidelines for Technical Writing</title>
		<link>http://tc.eserver.org/23502.html</link>
		<guid>http://tc.eserver.org/23502.html</guid>
		<description>The rules here apply to all classes in the Chemical Engineering Department at Ohio University. Most of them will apply in &apos;the real world&apos;, too, although your employer may have some specific format requirements.</description>
	</item>
	<item>
		<title>The Current Demand for Style Guides</title>
		<link>http://tc.eserver.org/23466.html</link>
		<guid>http://tc.eserver.org/23466.html</guid>
		<description>During my research for a book project, I have found style guides in a wide variety of forms. Some are only a couple of pages. Others consist of hundreds of pages, delivered in ring binders. Some companies produce well-printed and bound books (for example, Microsoft and Sun). A lot of style guides, differing in quality and size, are in the Internet. Most of them cover the design of web pages; only a few deal with document design in general. From one company I received a multimedia CD containing their style guide. It is a well-designed piece of software, presenting graphic arts, sound and video.</description>
	</item>
	<item>
		<title>Do Not Forget Bibliographical Data in Technical Documentation!</title>
		<link>http://tc.eserver.org/23401.html</link>
		<guid>http://tc.eserver.org/23401.html</guid>
		<description>Information products, e.g. manuals, drawings etc, must, besides the technical message, contain certain formal data, which too often is left out. Proper formal data contributes to good order and favours the producer as well as the user of information products.</description>
	</item>
	<item>
		<title>An Exchange of Views</title>
		<link>http://tc.eserver.org/23435.html</link>
		<guid>http://tc.eserver.org/23435.html</guid>
		<description>A discussion about INTECOM&apos;s project for researching and establishing English-language documentation guidelines.</description>
	</item>
	<item>
		<title>Spelling in TC-Forum</title>
		<link>http://tc.eserver.org/23396.html</link>
		<guid>http://tc.eserver.org/23396.html</guid>
		<description>There are several ways of spelling English – the English/Canadian style, and the American style. Both are correct.</description>
	</item>
	<item>
		<title>The Use of Capitals</title>
		<link>http://tc.eserver.org/23407.html</link>
		<guid>http://tc.eserver.org/23407.html</guid>
		<description>The question to the list-subscribers was I am looking for studies dealing with the difference between small letters and capitals. Are small letters easier to read? In France, road signs are written in capitals but it is not the case in the US or Canada.</description>
	</item>
	<item>
		<title>Developing a Company Style Guide</title>
		<link>http://tc.eserver.org/22838.html</link>
		<guid>http://tc.eserver.org/22838.html</guid>
		<description>Every company that produces external publications--whether brochures, research papers, or reference manuals-benefit from a company style guide. This paper discusses the advantages of&#xD;a style guide, why a company-specific style guide is&#xD;preferred, how to develop a style guide, and what a&#xD;style guide should (and should not) include.</description>
	</item>
	<item>
		<title>Guide to Effective Formatting</title>
		<link>http://tc.eserver.org/22485.html</link>
		<guid>http://tc.eserver.org/22485.html</guid>
		<description>This guide supplements work instruction PR2-W3 - Document Formatting. It gives a detailed outline of the recommended document formatting standards for reports. You should use the standard Word template, which has been configured to conform with these guidelines.</description>
	</item>
	<item>
		<title>Guide to Effective Report Writing</title>
		<link>http://tc.eserver.org/22486.html</link>
		<guid>http://tc.eserver.org/22486.html</guid>
		<description>The &lt;i&gt;Guide to Effective Report Writing&lt;/i&gt; outlines a practical method for IT professionals to develop and maintain reports which address the needs of the reader and which are expressed in language easily understood by the reader.</description>
	</item>
	<item>
		<title>Making Guidelines Part of the Team</title>
		<link>http://tc.eserver.org/22481.html</link>
		<guid>http://tc.eserver.org/22481.html</guid>
		<description>Guidelines. We seem to have a love-hate relationship with them. At the same time we construct them, we worry they’ll come back to haunt us. How did guidelines get such a bad reputation?</description>
	</item>
	<item>
		<title>Fear of Dusty Tomes</title>
		<link>http://tc.eserver.org/22409.html</link>
		<guid>http://tc.eserver.org/22409.html</guid>
		<description>Many grammar reference works take what is a relatively simple subject and, with unnecessary expansion and elaboration, turn it into an impenetrably dull experience for the reader. In this article, I&apos;ll take a brief look at three books that offer an easy and readable alternative.</description>
	</item>
	<item>
		<title>Language Style Guide for Software Developers</title>
		<link>http://tc.eserver.org/22365.html</link>
		<guid>http://tc.eserver.org/22365.html</guid>
		<description>This style guide is designed to help software developers with the language aspects of screen design. It is not comprehensive, but it does cover the most common problems. For comprehensive style guidelines for documentation see the Microsoft Manual of Style for Technical Publications. TechScribe is based in the UK, and although we produce documentation for both the US and the UK markets, we have used British English in this guide. The document can be printed on both US Letter and A4 size paper.</description>
	</item>
	<item>
		<title>Writing Processes</title>
		<link>http://tc.eserver.org/22230.html</link>
		<guid>http://tc.eserver.org/22230.html</guid>
		<description>Our Writing Guides help you locate information quickly on specific topics. These guides focus on a range of composing processes as well as issues related to the situations in which writers find themselves.</description>
	</item>
	<item>
		<title>Terminology and Spelling for Web-Related Concepts</title>
		<link>http://tc.eserver.org/22135.html</link>
		<guid>http://tc.eserver.org/22135.html</guid>
		<description>Generally speaking, &apos;Web&apos; as a short form of &apos;World Wide Web&apos; is capitalized, with one exception (webmaster). However, your company style may prefer the lower-case version.</description>
	</item>
	<item>
		<title>Use of Hyphens</title>
		<link>http://tc.eserver.org/22134.html</link>
		<guid>http://tc.eserver.org/22134.html</guid>
		<description>This page collects a series of notes from readers of my newsletter, and my responses to those notes, arising from an article in &lt;A HREF=&quot;http://www.jeanweber.com/news/tenews60.htm&quot;&gt;issue 60, 13 May 2002&lt;/A&gt;. I thank those who took the time to write and explain &lt;i&gt;why&lt;/i&gt; some hyphen usage is considered to be correct or incorrect.</description>
	</item>
	<item>
		<title>You Send Me: Getting It Right When You Write Online</title>
		<link>http://tc.eserver.org/22105.html</link>
		<guid>http://tc.eserver.org/22105.html</guid>
		<description>This book addresses the issues of online writing and particularly writing e-mail, which should concern all us who spend a good chunk of our days in front of a computer screen creating and replying to e-mail messages. The book is structured in three parts: &apos;The virtual mensch,&apos; &apos;Alpha mail,&apos; and &apos;Words of passage.&apos;</description>
	</item>
	<item>
		<title>Standards and Style Guides</title>
		<link>http://tc.eserver.org/22048.html</link>
		<guid>http://tc.eserver.org/22048.html</guid>
		<description>A bibliography of style guides useful for technical writers.</description>
	</item>
	<item>
		<title>A Visual Guide to Document Design and Layout</title>
		<link>http://tc.eserver.org/21979.html</link>
		<guid>http://tc.eserver.org/21979.html</guid>
		<description>Technical publications departments in their infancy seem to have great difficulty producing documentation that is well designed and consistent in appearance throughout all documents. As the department matures, it attempts to &quot;consistify&quot; the appearance of the documentation, but, unless there is an experienced template designer on board, this is often a drawn-out process involving focus groups and much squabbling. Once the design is complete, however, it tends to be nearly identical to the templates designed by every other technical publications department in the world. Aside from a handful of design features that distinguish the look and feel of one company&apos;s documentation from that of its competitors, everything else is pretty much the same. Whether the focus group spends six months or two years designing templates, they all discover that a well-designed user guide contains some specific and standard design elements.</description>
	</item>
	<item>
		<title>Writing Style Guide</title>
		<link>http://tc.eserver.org/21661.html</link>
		<guid>http://tc.eserver.org/21661.html</guid>
		<description>The following is a description of Florida Institute of Technology&apos;s in-house writing style for everything except technical papers and reports. This guide is set up alphabetically and contains listings that will allow you to standardize everything you write for the university. Reference materials include The Associated Press Stylebook And Libel Manual (Fully Revised and Updated 1998 Edition), Webster&apos;s Ninth New Collegiate Dictionary and McGraw-Hill Dictionary of Scientific and Technical Terms (Fourth Edition).</description>
	</item>
	<item>
		<title>Guide to Citation Style Guides</title>
		<link>http://tc.eserver.org/21628.html</link>
		<guid>http://tc.eserver.org/21628.html</guid>
		<description>An annotated collection of links to the best and most up-to-date citation guides that show how to properly cite resources from the Internet. Style guides for APA, MLA, Chicago, Turabian, BSE, styles and a description of how to cite references from Lexis/Nexis.</description>
	</item>
	<item>
		<title>Microsoft Manual of Style 3.0</title>
		<link>http://tc.eserver.org/21592.html</link>
		<guid>http://tc.eserver.org/21592.html</guid>
		<description>Complete styles and guidelines for publishing a variety of technical publications.</description>
	</item>
	<item>
		<title>Style Sheets and Grammar</title>
		<link>http://tc.eserver.org/21534.html</link>
		<guid>http://tc.eserver.org/21534.html</guid>
		<description>A collection of online resources about style guides and reference sites about grammar.</description>
	</item>
	<item>
		<title>Legal Research and Citation Style in the USA</title>
		<link>http://tc.eserver.org/21349.html</link>
		<guid>http://tc.eserver.org/21349.html</guid>
		<description>The format for citations to legal materials is different from the format for scholarly citations to books and periodicals in general. This handout is a terse guide to legal citation in the USA. &#xD;&#xD;The generally accepted style manual for legal citations in the USA is the Bluebook: A Uniform System of Citation, which is published by the editors of four prestigious law reviews at Columbia University, Harvard, Univ. of Pennsylvania, and Yale Law Schools. A copy of theBluebook can be purchased in any law school bookstore. A comprehensive set of rules from the Bluebook is available on the Internet from Peter W. Martin at Cornell Law School. In contrast, this handout here contains a terse set of rules that agree with the Bluebook, but does not contain all of the fine points and options in the Bluebook. &#xD;&#xD;Opinions of some courts use a different format from the Bluebook, but these alternative citation formats contains the same information. Be aware that citations in opinions of state or federal courts may not be the correct bibliographic style according to the Bluebook.Furthermore, the proper format according to the Bluebook changes with time, so old sources (both cases and law review articles) do not use the modern format for citation.</description>
	</item>
	<item>
		<title>Building a Better Style Guide</title>
		<link>http://tc.eserver.org/20926.html</link>
		<guid>http://tc.eserver.org/20926.html</guid>
		<description>Why are style guides so frequently created, but so rarely successful? All too often, businesses ask for a style guide as a&#xD;means to create a common look and feel, in the belief that it will solve usability problems and establish consistency&#xD;between applications – only to be disappointed in the results. Even if such a style guide is followed carefully, the&#xD;resulting interfaces may not meet usability goals.. This paper explores strategies for creating a style guide that is more&#xD;than a simplistic rules book. By making the style guide part of the process, it can be used to promote a shared vision, to&#xD;help the product meet business and usability requirements for consistency and…it may actually be used.</description>
	</item>
	<item>
		<title>Diggin’ It?!</title>
		<link>http://tc.eserver.org/20954.html</link>
		<guid>http://tc.eserver.org/20954.html</guid>
		<description>The buried treasures of typography: comprising the Style Guide of the Type Club of Toronto, with illustrations, and an Expert Font Guide.</description>
	</item>
	<item>
		<title>Choosing the Right Style Manual(s)</title>
		<link>http://tc.eserver.org/20798.html</link>
		<guid>http://tc.eserver.org/20798.html</guid>
		<description>Editors should consider at least four points in selecting, or reevaluating, primary and secondary manuals.</description>
	</item>
	<item>
		<title>Look at Common Style Differences in Choosing Manuals</title>
		<link>http://tc.eserver.org/20797.html</link>
		<guid>http://tc.eserver.org/20797.html</guid>
		<description>Style manuals often differ on important points, and one way to choose a manual is to compare them on some of those points.</description>
	</item>
	<item>
		<title>Painless Ways to Improve Colleagues&apos; Grammar </title>
		<link>http://tc.eserver.org/20799.html</link>
		<guid>http://tc.eserver.org/20799.html</guid>
		<description>Instead of confronting individuals, raise all staff members&apos; awareness. Use humor to help people recognize errors and remember correct usage.</description>
	</item>
	<item>
		<title>Style Manuals and Guides for Technical Writing</title>
		<link>http://tc.eserver.org/20712.html</link>
		<guid>http://tc.eserver.org/20712.html</guid>
		<description>Style manuals show how to format bibliographies and footnotes; some also provide information on outlining, editing and writing. If your instructor has not specified a particular format or recommended a style manual, consult one of the following, widely-used manuals.</description>
	</item>
	<item>
		<title>Style Guides and Technical Writing</title>
		<link>http://tc.eserver.org/20707.html</link>
		<guid>http://tc.eserver.org/20707.html</guid>
		<description>A style guide consists of formats used when creating documentation. Some companies maintain a formal style guide and adhere to strict documentation standards. Other companies may be more informal, but still maintain some semblance of a style guide, even if it is only an example of the documentation they create.</description>
	</item>
	<item>
		<title>Appearing for Sentence</title>
		<link>http://tc.eserver.org/20465.html</link>
		<guid>http://tc.eserver.org/20465.html</guid>
		<description>Commas, semi-colons and colons are the sentence tidiers. Used correctly, they&apos;ll give your written language the &apos;punctuation&apos; that pauses, voice modulations and gestures provide when you speak.</description>
	</item>
	<item>
		<title>Are We Agreed?</title>
		<link>http://tc.eserver.org/20469.html</link>
		<guid>http://tc.eserver.org/20469.html</guid>
		<description>&apos;Agreement&apos; refers to elements in a sentence having the same number, gender, case or person. In English, it&apos;s probably an issue only for number (that is, singular vs plural) and case (that is, &apos;I&apos; vs &apos;me&apos;, &apos;he&apos; vs &apos;him&apos; and so on).</description>
	</item>
	<item>
		<title>Capital Punishment</title>
		<link>http://tc.eserver.org/20466.html</link>
		<guid>http://tc.eserver.org/20466.html</guid>
		<description>Many documents suffer from over-capitalisation. The writer sprinkles capitals everywhere in an attempt to make words stand out - with the result that nothing stands out. Here are some simple rules to help you avoid this capital offence.</description>
	</item>
	<item>
		<title>Caught in the Active</title>
		<link>http://tc.eserver.org/20471.html</link>
		<guid>http://tc.eserver.org/20471.html</guid>
		<description>Have you been told, perhaps by your computerised grammar checker, that too many of your sentences are passive? Have you heard the rule of thumb that at least 80 percent of the sentences in any passage should be active? If you&apos;ve had the problem or heard the rule, and wonder what the terms active and passive mean, and why one is good and the other frowned on, this article is for you.</description>
	</item>
	<item>
		<title>The Elusive Apostrophe</title>
		<link>http://tc.eserver.org/20464.html</link>
		<guid>http://tc.eserver.org/20464.html</guid>
		<description>Like teenagers and salespeople, apostrophes are frequently there when they&apos;re not wanted, and not to be seen when they&apos;re needed.</description>
	</item>
	<item>
		<title>Gender-Neutral Language</title>
		<link>http://tc.eserver.org/20472.html</link>
		<guid>http://tc.eserver.org/20472.html</guid>
		<description>One of the most significant changes taking place in English is the rejection of the way that &apos;man&apos; was assumed to include &apos;woman&apos;. Most of us want our writing to be friendly and inclusive. How can we avoid using &apos;man&apos;, &apos;he&apos;, and &apos;his&apos;? </description>
	</item>
	<item>
		<title>Making Sense</title>
		<link>http://tc.eserver.org/20468.html</link>
		<guid>http://tc.eserver.org/20468.html</guid>
		<description>When we are trying to communicate complicated ideas, it is important to be specific. One way to ensure that you will not be misunderstood is to look at your use of &apos;scope&apos;. &apos;Scope&apos; refers to which words go with which to form a &apos;sense unit&apos; in a sentence; for example, which nouns are covered by a particular verb or preposition. Often, poor punctuation or poor sentence construction messes the scope up. Scope isn&apos;t easy to explain, but you can get a handle on it once you have seen a few examples of how it works.</description>
	</item>
	<item>
		<title>Muddled Sentences</title>
		<link>http://tc.eserver.org/20470.html</link>
		<guid>http://tc.eserver.org/20470.html</guid>
		<description>Misplaced modifiers are usually obvious and easily fixed.</description>
	</item>
	<item>
		<title>Reported Speech: a Tense Issue</title>
		<link>http://tc.eserver.org/20474.html</link>
		<guid>http://tc.eserver.org/20474.html</guid>
		<description>The tense of the verb in a statement is, as a general rule, shifted back in time in reported speech.</description>
	</item>
	<item>
		<title>Sentenced to a Cruel End</title>
		<link>http://tc.eserver.org/20467.html</link>
		<guid>http://tc.eserver.org/20467.html</guid>
		<description>A simple definition of a sentence is: a set of words that expresses a complete thought and contains a subject and a predicate. Let&apos;s look at this.</description>
	</item>
	<item>
		<title>Using &apos;Which&apos; and &apos;That&apos;</title>
		<link>http://tc.eserver.org/20473.html</link>
		<guid>http://tc.eserver.org/20473.html</guid>
		<description>&apos;That&apos; clauses form a sense unit with the word they&apos;re attached to, and that&apos;s why they aren&apos;t preceded by a comma.</description>
	</item>
	<item>
		<title>Nonstandard Quotes: Superimpositions and Cultural Maps</title>
		<link>http://tc.eserver.org/20455.html</link>
		<guid>http://tc.eserver.org/20455.html</guid>
		<description>We regularly chastise students for placing quotation marks around words that are not direct quotations. Yet, as this research shows, professionals use nonstandard quotations routinely and to rhetorical advantage. After analyzing the various purposes nonstandard quotations serve, I argue student use of the marks jars us not because it departs from good practice but because, through them, students invoke voices we do not want to recognize.</description>
	</item>
	<item>
		<title>Creative Indents</title>
		<link>http://tc.eserver.org/20433.html</link>
		<guid>http://tc.eserver.org/20433.html</guid>
		<description>Indenting the first line of every paragraph is a habit most of us acquired in grammar school. However, for those daring souls who have always insisted on coloring outside the lines, it’s time to consider using a different style paragraph indent. There are more options than you might have realized!</description>
	</item>
	<item>
		<title>Stylesheet or Stylesite? A Case Study</title>
		<link>http://tc.eserver.org/20340.html</link>
		<guid>http://tc.eserver.org/20340.html</guid>
		<description>CNET’s Stylesite for the Technology Department’s Documentation and Training group provides an online resource for writers and trainers. The continuing development of this tool encompasses site development,&#xD;content creation, and a fluid process of drafting standards. The site observes many of the same rules &apos;imposed&apos; upon the writers, and offers them a rare opportunity to collaborate with their editor in the&#xD;production of a manual of style.</description>
	</item>
	<item>
		<title>Developing and Implementing Project Style Guides</title>
		<link>http://tc.eserver.org/20133.html</link>
		<guid>http://tc.eserver.org/20133.html</guid>
		<description>Style guides can be very effective tools for achieving uniformity in documentation. Their use can enhance the&#xD;appearance, readability, and tone of a document. In this&#xD;progression session, I would like to discuss why style&#xD;guides are needed, what should be included in them, and&#xD;how to create a style guide appropriate for your project.&#xD;I invite participants to bring style guides with them for&#xD;critique and discussion.</description>
	</item>
	<item>
		<title>Communicating in Spite of TLAs (Three-Letter Acronyms)</title>
		<link>http://tc.eserver.org/20095.html</link>
		<guid>http://tc.eserver.org/20095.html</guid>
		<description>The unchecked use of acronyms and initialisms in technical writing presents a huge obstacle to clarity and readability.&#xD;Although technical communicators are certainly more&#xD;aware of this problem than are the engineers, scientists,&#xD;and managers with whom they work, they need concrete&#xD;guidelines and at least a small degree of self-righteousness&#xD;on this subject to help them cope with the onslaught. That&#xD;acronyms frustrate communication is well-founded in&#xD;linguistic theory and common sense. Suggestions for&#xD;mitigating their effect include issues of audience, term&#xD;selectivity, frequency and occasion of use, and aesthetics.</description>
	</item>
	<item>
		<title>Getting Your Style Guide Written!</title>
		<link>http://tc.eserver.org/20075.html</link>
		<guid>http://tc.eserver.org/20075.html</guid>
		<description>This paper describes how to approach the project of writing a stand-alone Style Guide that provides technical writers and other employees with a reference for documentation procedures and policies. A Style&#xD;Guide project is often placed aside while other priority&#xD;projects forge ahead. This occurs for several reasons,&#xD;the most common being that writing a Style Guide is a&#xD;monumental task!&#xD;This paper provides you with the skeleton to manage a&#xD;Style Guide writing project and deliver the product on time</description>
	</item>
	<item>
		<title>Loose Ends: Standards and Styles</title>
		<link>http://tc.eserver.org/20029.html</link>
		<guid>http://tc.eserver.org/20029.html</guid>
		<description>Several readers have sent me e-mail comments and questions recently that might be of interest to others. (Even Eye readers who don&apos;t spend much time on the Web tell us they&apos;re interested in picking up this kind of information.) </description>
	</item>
	<item>
		<title>Usage Experts Change Their Minds, Too</title>
		<link>http://tc.eserver.org/20023.html</link>
		<guid>http://tc.eserver.org/20023.html</guid>
		<description>Many terms and constructions frowned on a generation ago have been admitted, like many new words, into mainstream parlance and have gained wider acceptance than before. An example is tycoon, in the sense of a wealthy businessman, labeled &apos;informal&apos; in the first edition of AHD but accepted in the third. Another example is balding, called &apos;entirely vulgar&apos; in a usage note by panelist Katherine Anne Porter in the first edition but entered without stigma in the third.</description>
	</item>
	<item>
		<title>The Reference Book That &lt;i&gt;Editorial Eye&lt;/i&gt; Built</title>
		<link>http://tc.eserver.org/20002.html</link>
		<guid>http://tc.eserver.org/20002.html</guid>
		<description>About three years ago we were asked whether we would be interested in writing a new and different kind of style manual:&#xD;&#xD;    * In addition to covering all the traditional style topics, such as capitalization and punctuation, it would have chapters on grammar, confusable words, usage (including bias-free language), and all aspects of production, from design and typography to desktop publishing and printing.&#xD;    * Its audience would be the vast majority of working writers and editors, not just those who work with scholarly manuscripts.&#xD;    * It would be written and organized in a friendly, easy-to-read style and reflect the impact of the computer on every aspect of the publishing process. &#xD;&#xD;Although we were a bit cowed at the thought of tackling such a big project -- it turned out to be 836 pages -- we didn&apos;t see how we could turn down the chance to create a guide that was truly useful.</description>
	</item>
	<item>
		<title>Shifty Adverbs</title>
		<link>http://tc.eserver.org/20004.html</link>
		<guid>http://tc.eserver.org/20004.html</guid>
		<description>Decide where to place the adverb in parentheses in these sentences to best advantage -- for the sound of it and for best sense. That is, place it near the word in the sentence you wish to emphasize. One sentence doesn&apos;t involve a decision about placement next to the verb at all.</description>
	</item>
	<item>
		<title>The Struggle for Gender-Free Language: Is It Over Yet?</title>
		<link>http://tc.eserver.org/20003.html</link>
		<guid>http://tc.eserver.org/20003.html</guid>
		<description>All current style manuals address in one form or another the need for bias-free, inclusive language. Most writers and editors deal with this issue regularly — we&apos;ve installed mental alarm systems that go off when we sense bias or something that can be construed as bias. In fact, some commentators say we&apos;ve gone too far toward what social commentator Christopher Cerf calls, with grave facetiousness, &apos;content-free writing,&apos; lest language offend anyone, anywhere.&#xD;&#xD;Does gender-free writing still present problems, and if so, how are most of us resolving them? After all these years of practice at being evenhanded, consider several litmus tests. </description>
	</item>
	<item>
		<title>Sample Paper Formatted Using CBE Style Guide</title>
		<link>http://tc.eserver.org/19769.html</link>
		<guid>http://tc.eserver.org/19769.html</guid>
		<description>A sample research paper, formatted using the CBE Style Guide.</description>
	</item>
	<item>
		<title>Sample Paper Formatted Using Chicago Style</title>
		<link>http://tc.eserver.org/19768.html</link>
		<guid>http://tc.eserver.org/19768.html</guid>
		<description>A sample research paper, formatted using the Chicago Style.</description>
	</item>
	<item>
		<title>Apple Publications Style Guide (2003)</title>
		<link>http://tc.eserver.org/19711.html</link>
		<guid>http://tc.eserver.org/19711.html</guid>
		<description>The May 2003 edition of the standard reference for Apple publications.</description>
	</item>
	<item>
		<title>When Technical Writers Don&apos;t Write Technically</title>
		<link>http://tc.eserver.org/19667.html</link>
		<guid>http://tc.eserver.org/19667.html</guid>
		<description>Technical writers are often asked to write more than just end-user manuals or online help systems. Due to company&#xD;size, layoffs, or a lack of&#xD;resources, the technical writer&#xD;might also be expected to deliver marketing&#xD;communication collateral, Web&#xD;site content, training materials, and&#xD;more. These additional tasks can daunt&#xD;those who have not been formally&#xD;trained in other writing styles or those&#xD;who do not switch writing styles easily.</description>
	</item>
	<item>
		<title>The Most Obvious Fault in Technical Writing</title>
		<link>http://tc.eserver.org/19636.html</link>
		<guid>http://tc.eserver.org/19636.html</guid>
		<description>The most obvious fault is wordiness. Fortunately, long-windedness is something that editors are particularly well equipped to fix.&#xD;Take a look at our manuals. They are huge, and their very bulk can make them inaccessible, especially when they are not&#xD;equipped with a good index or adequate&#xD;indicia in the corners of each page.</description>
	</item>
	<item>
		<title>The Style Guide is &apos;Dead&apos;: Long Live the Dynamic Style Guide!</title>
		<link>http://tc.eserver.org/19516.html</link>
		<guid>http://tc.eserver.org/19516.html</guid>
		<description>Nobody, least of all an editor like me, would argue that printed style guides are really dead--at least not in the sense that they&apos;re no longer with us and no longer useful. Yet there&apos;s no doubt that printed style guides are looking a little antequated these days. Despite how useful the guides are to writers and editors, they&apos;re simply too static for most writers, and don&apos;t take advantage of computer technology to make the writer&apos;s working life easier. But if you&apos;re thinking that online style guides are inherently better solutions, think again; using the computer to find static information certainly helps, but simply moving a paper guide online only exchanges one form of &apos;static&apos; for another.</description>
	</item>
	<item>
		<title>Guide to Chicago Style Documentation</title>
		<link>http://tc.eserver.org/19356.html</link>
		<guid>http://tc.eserver.org/19356.html</guid>
		<description>A guide to using the Chicago Style for writing.</description>
	</item>
	<item>
		<title>A Global Style Guide: Working Together Around the World</title>
		<link>http://tc.eserver.org/19260.html</link>
		<guid>http://tc.eserver.org/19260.html</guid>
		<description>As a result of acquisitions and mergers, companies can find themselves working together worldwide and sharing documentation to distribute in different markets. The original source documentation will probably need to be adapted by some of the companies in the distribution channel to accommodate different languages, branding&#xD;and content in order to meet the requirements of these different markets. This sharing and reuse of&#xD;documentation between companies worldwide is easier&#xD;when all the companies in the distribution channel share a common style guide.</description>
	</item>
	<item>
		<title>Writing Consistently Across Media: Ten Proofreading Tips</title>
		<link>http://tc.eserver.org/19019.html</link>
		<guid>http://tc.eserver.org/19019.html</guid>
		<description>Last time I wrote about consistency in online writing. Soon after, I received an email from Leslie Drechsler, a reader in Tustin, CA: &apos;As a Marketing Communications Specialist, I&apos;d love to hear your ideas on how to successfully implement consistency in an established business,&apos; she wrote. &apos;I thought developing a company style guide would solve the problem. But perhaps there are other ways to approach it.&#xD;&#xD;&apos;Perhaps this could be the subject of another article.&apos;&#xD;&#xD;Here&apos;s that article, Leslie. </description>
	</item>
	<item>
		<title>Frequently Asked Questions About English</title>
		<link>http://tc.eserver.org/18924.html</link>
		<guid>http://tc.eserver.org/18924.html</guid>
		<description>Asterisks.com answers some frequently asked questions about English usage.</description>
	</item>
	<item>
		<title>Style Sheets: The Abbreviated Answer</title>
		<link>http://tc.eserver.org/18872.html</link>
		<guid>http://tc.eserver.org/18872.html</guid>
		<description>As a project moves from writer to editor to designer and ack again, style sheets (abbreviated versions of style gides) offer quick access to answers during&#xD;documentation development. Style sheets provide&#xD;consistency, give a quick-reference point, set a project’s&#xD;style from the beginning, eliminate confusion on major&#xD;style points, and serve as a double check during revision.&#xD;Designed specifically for a project, style sheet formats&#xD;include laminated sheets and standees, and content&#xD;ranges from grammar references to contact information.</description>
	</item>
	<item>
		<title>A Guide for Writing Research Papers Based on Modern Language Association (MLA) Documentation</title>
		<link>http://tc.eserver.org/18852.html</link>
		<guid>http://tc.eserver.org/18852.html</guid>
		<description>The formatting of citations recommended in this guide is based on Modern Language Association recommendations. This guide may suffice for most students&apos; needs for most academic purposes, but for advanced research projects it is by no means a substitute for the Modern Language Association Handbook for Writers of Research Papers Fifth Edition (1999). That handbook can be purchased in most bookstores and copies should be available in every college and municipal library. A Guide similar to this one, but based on the APA style, is also available online (see link on the navigation bar). Your best source of advice on all these matters is, of course, your instructor and library professionals.</description>
	</item>
	<item>
		<title>Academic Writing: Reviews of Literature</title>
		<link>http://tc.eserver.org/18615.html</link>
		<guid>http://tc.eserver.org/18615.html</guid>
		<description>The format of a review of literature may vary from discipline to discipline and from assignment to assignment. A review may be a self-contained unit -- an end in itself -- or a preface to and rationale for engaging in primary research. A review is a required part of grant and research proposals and often a chapter in theses and dissertations. Generally, the purpose of a review is to analyze critically a segment of a published body of knowledge through summary, classification, and comparison of prior research studies, reviews of literature, and theoretical articles.</description>
	</item>
	<item>
		<title>A Matter of Style: On Writing and Technique</title>
		<link>http://tc.eserver.org/18471.html</link>
		<guid>http://tc.eserver.org/18471.html</guid>
		<description>Many editors and writers will find &lt;i&gt;A Matter of Style&lt;/i&gt; useful, but as readers, most will find it frustrating. Matthew Clark, a professor of classical literature and a musician, addresses the book to editors and writers, both creative and non-fiction, and especially to academic writers. The book is not an introduction and Clark assumes that his readers “already have a good grounding in the basics of grammar and style” (p. iv). He skips quickly through a chapter called “A Few Points of Grammar” to get to his real target, “questions of artistry” (p. 1).&#xD;&#xD;So far, so good, but problems soon develop around many of these nodes. The level of audience assumed by the book frequently varies. The book functions in many passages as an introduction to various classical arcana of questionable utility. Even more than questions of artistry, Clark deals with “questions about style” that are “questions of taste” and so “do not have definitive answers.” As many critics before him, he claims that “taste can still be discussed” (p. 14). The question is, “How?”</description>
	</item>
	<item>
		<title>Technical Writing Rules You Didn&apos;t Learn in RHET 101</title>
		<link>http://tc.eserver.org/18463.html</link>
		<guid>http://tc.eserver.org/18463.html</guid>
		<description>To hyphenate or not to hyphenate, that is the question.  As compound nouns evolve over time in Eng-&#xD;lish, they gradually move from being written &apos;open&apos; (data base) to being hyphenated (data-base) to&#xD;being written &apos;closed&apos; (database).  Just where your particular word might be in its evolution is often un-&#xD;clear and subject to the inscrutable and highly individual logic of copy editors.  Consult a recent edition of&#xD;a standard dictionary.</description>
	</item>
	<item>
		<title>Employee Directory Search: Resolving Conflicting Usability Guidelines</title>
		<link>http://tc.eserver.org/18453.html</link>
		<guid>http://tc.eserver.org/18453.html</guid>
		<description> Guidelines conflict on whether to limit intranet search to a single search box or dedicate an additional box to employee directory searches. There&apos;s theory to support both guidelines. What&apos;s up? </description>
	</item>
	<item>
		<title>Writing Better Reports: A Handbook for Civil and Environmental Engineers</title>
		<link>http://tc.eserver.org/18414.html</link>
		<guid>http://tc.eserver.org/18414.html</guid>
		<description>Based on faculty concerns, this handbook offers guidelines and exercises to help you improve your technical style.</description>
	</item>
	<item>
		<title>The Linux Documentation Project</title>
		<link>http://tc.eserver.org/18305.html</link>
		<guid>http://tc.eserver.org/18305.html</guid>
		<description>The Linux Documentation Project (LDP) is working on developing good, reliable documentation for the Linux operating system. The overall goal of the LDP is to collaborate in taking care of all of the issues of Linux documentation, ranging from online documentation (man pages, HTML, and so on) to printed manuals covering topics such as installing, using, and running Linux.</description>
	</item>
</channel>
</rss>