<?xml version="1.0" encoding="utf-8" ?><rss version="2.0" xmlns:atom="http://www.w3.org/2005/Atom">
<channel>
	<title>Articles&gt;Style Guides</title>	<link>http://tc.eserver.org/dir/Articles/Style-Guides</link>
	<description>A listing of the most recently indexed works about Articles and Style Guides 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;Style Guides</title>
		<link>http://tc.eserver.org/dir/Articles/Style-Guides</link>
	</image>
	<item>
		<title>What’s More Important, Content or Process?</title>
		<link>http://tc.eserver.org/35825.html</link>
		<guid>http://tc.eserver.org/35825.html</guid>
		<description>While style guidelines can be useful for maintaining consistency across a set (or several sets) of documentation, the editors that I worked with viewed the style guidelines as sacrosanct. Any deviation, no matter how small, was punishable by a nasty email and a sharply worded note to the offending writer’s manager.</description>
	</item>
	<item>
		<title>Sometimes, You&apos;ve Got to Break the Rules</title>
		<link>http://tc.eserver.org/35788.html</link>
		<guid>http://tc.eserver.org/35788.html</guid>
		<description>Sometimes, you don’t need documentation made up of perfectly-chosen words and phrases. Instead, you need something that can be easily scanned, easily understood, and easily digested. Documentation that distills the main points quickly.</description>
	</item>
	<item>
		<title>Writing Great Documentation: Technical Style</title>
		<link>http://tc.eserver.org/35709.html</link>
		<guid>http://tc.eserver.org/35709.html</guid>
		<description>Now that I’ve discussed what kinds of technical documentation to write, I can move on to the question of how to actually develop a writing style that produces great technical documentation. So how do you learn to write (anything) well? There’s only one answer: you’ll learn to write well if you write. A lot.</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>Controlled Language – Does My Company Need It?</title>
		<link>http://tc.eserver.org/35678.html</link>
		<guid>http://tc.eserver.org/35678.html</guid>
		<description>Controlled languages use basis writing rules to simplify sentence structure. Here is how they work and how your company can benefit from introducing a controlled language.</description>
	</item>
	<item>
		<title>Style Manuals: The Politics of Selection</title>
		<link>http://tc.eserver.org/35518.html</link>
		<guid>http://tc.eserver.org/35518.html</guid>
		<description>Bette Frick and Betsy Frick discuss how a style manual can save time and money, how to select the proper style manual and get buy-in, and how to create a style guide to use in conjunction with a style manual.</description>
	</item>
	<item>
		<title>Consistency and Community-Generated Content</title>
		<link>http://tc.eserver.org/35525.html</link>
		<guid>http://tc.eserver.org/35525.html</guid>
		<description>I’ve been collecting examples of wildly inconsistent writing lately. I’m not sure why these have stuck out to me, but when I think of book sprints and community writing events, consistency is an important, though sometimes difficult, goal and outcome.</description>
	</item>
	<item>
		<title>Style Rules for Job Position Names and Titles in Policies &amp; Procedures</title>
		<link>http://tc.eserver.org/35402.html</link>
		<guid>http://tc.eserver.org/35402.html</guid>
		<description>Have you struggled with job position names and titles in your policies and procedures (P&amp;P) content? Here are several style rules to follow. </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>The Missing Manual Authors’ Guide</title>
		<link>http://tc.eserver.org/35126.html</link>
		<guid>http://tc.eserver.org/35126.html</guid>
		<description>This Authors’ Guide tells you everything you need to know to write Missing Manual. It starts out by giving you a brief introduction to the Missing Manual way of explaining things and then takes you through the nitty gritty of style guidelines, figure formatting, and so on.</description>
	</item>
	<item>
		<title>The Global English Style Guide</title>
		<link>http://tc.eserver.org/34701.html</link>
		<guid>http://tc.eserver.org/34701.html</guid>
		<description>A review of &quot;The Global English Style Guide: Writing Clear, Translatable Documentation for a Global Market&quot; by John R. Kohl.</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>A Web Policy is a Policy, Not a Standard</title>
		<link>http://tc.eserver.org/34451.html</link>
		<guid>http://tc.eserver.org/34451.html</guid>
		<description>I&apos;ve noticed recently that people (and organizations) often interchange the policies and standards labels as if there is no difference between them... like those who insist the Web and the Internet are the same. I&apos;m not one for splitting hairs, but in this case, policies are truly not the same as standards and it&apos;s important to be clear about the distinction.</description>
	</item>
	<item>
		<title>Fifty Years of Stupid Grammar Advice</title>
		<link>http://tc.eserver.org/34206.html</link>
		<guid>http://tc.eserver.org/34206.html</guid>
		<description>April 16 is the 50th anniversary of the publication of a little book that is loved and admired throughout American academe. Celebrations, readings, and toasts are being held, and a commemorative edition has been released.&#xD;&#xD;I won&apos;t be celebrating.&#xD;&#xD;The Elements of Style does not deserve the enormous esteem in which it is held by American college graduates. Its advice ranges from limp platitudes to inconsistent nonsense. Its enormous influence has not improved American students&apos; grasp of English grammar; it has significantly degraded it.</description>
	</item>
	<item>
		<title>How to Use the Bulleted Lists Properly in Your Technical Document?</title>
		<link>http://tc.eserver.org/34039.html</link>
		<guid>http://tc.eserver.org/34039.html</guid>
		<description>Bulleted lists are important in technical writing. They summarize information in a manner that is easy to read and absorb. Use them whenever you can to get your information across quickly. Bullets are ideal for things-to-do, equipment, sets, collections, cooking ingredients, and all kinds of other lists.</description>
	</item>
	<item>
		<title>The Global English Style Guide: A Review</title>
		<link>http://tc.eserver.org/33526.html</link>
		<guid>http://tc.eserver.org/33526.html</guid>
		<description>Many good style guides exist. Why do technical writers need another style guide? Unlike other style guides, this book covers grammatical structures, not only particular terms. The book has more than 200 pages of text (plus 4 appendices) that give detailed explanations of both good practice and bad practice.</description>
	</item>
	<item>
		<title>One Space Or Two Spaces?</title>
		<link>http://tc.eserver.org/33450.html</link>
		<guid>http://tc.eserver.org/33450.html</guid>
		<description>When I began writing technical documentation and courseware for Guru Labs, I asked a question during training about whether we should be putting two spaces after a period, colon, question mark and exclamation point, or one. The answer shocked me, as I was hoping for the standard answer as a means of teaching the rest of my colleagues. The answer was ONE space, not two. Then, I listened to the argument.</description>
	</item>
	<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>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>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>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>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>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>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>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>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>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>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>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>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>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>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>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>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>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>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>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>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 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>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>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>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 documentation development. Style sheets provide consistency, give a quick-reference point, set a project’s style from the beginning, eliminate confusion on major style points, and serve as a double check during revision. Designed specifically for a project, style sheet formats include laminated sheets and standees, and content ranges from grammar references to contact information.</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>Design Guidelines for Written Assignments</title>
		<link>http://tc.eserver.org/18186.html</link>
		<guid>http://tc.eserver.org/18186.html</guid>
		<description>This paper discusses design guidelines educators can use to format their assignment instructions. The purpose of formatting is to avoid students&apos; misinterpretation of the assignment and to receive more readable papers. Topics covered are design awareness and formatting tips on using headings, chunking information, and using special features.</description>
	</item>
	<item>
		<title>Understanding the Importance of Style Guides</title>
		<link>http://tc.eserver.org/14937.html</link>
		<guid>http://tc.eserver.org/14937.html</guid>
		<description>Style guides describe conventions for virtually every aspect of writing, ranging from such things as spelling, punctuation, and word usage, to structural and formatting issues. With the myriad of style guides in use, the dilemma for many writers is deciding which one to learn and apply in the trade.&#xD;&#xD;The answer to this is easy: learn at least one style guide thoroughly and keep a selected few others for backup. In the course of recruiting technical and generalist writers and editors for nearly a decade, I am sometimes shocked at the low level of familiarity with long-established style guides by people who claim to be seasoned professionals in this business. The reality is that it is plainly obvious to spot writers who “claim” to know a style guide and those who have actually taken the time to study it. The proof is in the pudding, as they say. The quality and consistency of a writer’s or editor’s output is the litmus test to how proficient he or she is in applying a given style guide.</description>
	</item>
	<item>
		<title>Documentation through the Discovery Process</title>
		<link>http://tc.eserver.org/14753.html</link>
		<guid>http://tc.eserver.org/14753.html</guid>
		<description>Kloss describes a process of composing documentation that requires the writer&apos;s involvement at every phase of product development.</description>
	</item>
	<item>
		<title>Elegant Documentation</title>
		<link>http://tc.eserver.org/14699.html</link>
		<guid>http://tc.eserver.org/14699.html</guid>
		<description>Blank discusses the benefits of using consistent styles in documentation.</description>
	</item>
	<item>
		<title>Still Another Rule?</title>
		<link>http://tc.eserver.org/14660.html</link>
		<guid>http://tc.eserver.org/14660.html</guid>
		<description>Bush questions the wisdom of rigid grammatical rules that do not take into consideration the complexities of English.</description>
	</item>
	<item>
		<title>The Style Guide is Dead: Long Live the Dynamic Style Guide</title>
		<link>http://tc.eserver.org/14629.html</link>
		<guid>http://tc.eserver.org/14629.html</guid>
		<description>Arguing that printed style guides are too static to be useful, Hart recommends using a dynamic style guide, a system of templates, macros, and reference materials that actually guides writers through their work. The article also advocates direct interaction between editors and writers as a non-technical approach to a dynamic style.</description>
	</item>
	<item>
		<title>Developing a Departmental Style Guide</title>
		<link>http://tc.eserver.org/14140.html</link>
		<guid>http://tc.eserver.org/14140.html</guid>
		<description>As a technical writer, you may be asked to develop a style guide for the hardcopy and online documents you produce. Sounds easy enough. After all, commercial style guides and, potentially, examples shared by your colleagues should provide enough information to get you started. In researching your task, though, you may find a variety of definitions and explanations of what a style guide is and why companies use them. What&apos;s more, you many find that style guides don&apos;t seem to have consistencies among them that can help guide you in developing one.</description>
	</item>
	<item>
		<title>Master Documents</title>
		<link>http://tc.eserver.org/28361.html</link>
		<guid>http://tc.eserver.org/28361.html</guid>
		<description>This chapter ventures deeply into Microsoft heresy. A heretic is someone who preaches heterodoxy, or mixed doctrines. Unlike a lot of official MS and MVP speak, this topic advocates the usage of a certain feature that can be said to be generally considered as broken - Master Documents, or Masters. As so little information is forthcoming on this&#xD;subject from other sources, yet many writers use them regularly because there is no&#xD;other choice, it is fully covered here.</description>
	</item>
	<item>
		<title>The Passive In Technical and Scientific Writing</title>
		<link>http://tc.eserver.org/13975.html</link>
		<guid>http://tc.eserver.org/13975.html</guid>
		<description>Almost every discussion of technical or scientific style mentions the passive voice, usually as a stylistic evil to avoid. While I doubt that many of us would endorse such extreme prescriptions as &apos;Always use the active voice,&apos; or &apos;A writer will almost automatically improve his style when he shifts from passive to active constructions,&apos; we may be more ready to accept Freedman&apos;s position in &apos;The Seven Sins of Technical Writing.&apos; His Sin 6 is &apos;the Deadly Passive, or, better, deadening passive; it takes the life out of writing, making everything impersonal, eternal, remote and dead,&apos;3 but he adds that &apos;frequently, of course, the passive is not a sin and not deadly, for there simply is no active agent and the material must be put impersonally.&apos;</description>
	</item>
	<item>
		<title>The Rhetoric of the Paragraph: A Reconsideration</title>
		<link>http://tc.eserver.org/13976.html</link>
		<guid>http://tc.eserver.org/13976.html</guid>
		<description>Efforts to define the fundamental structures that enable meaning in discourse have a long history, beginning with ancient speculation. Classical logic, rhetoric, and grammar imposed restrictions on the processes of composing, as well as the shapes of finished texts, in order to safeguard the truth by attending to prerequisites for its effective communication. From earliest times, a concern for vindicating some larger moral order, and for teaching others to appreciate it, has often motivated pronouncements on the nature of verbal form. From Quintilian to the present, for example, teacher-scholars have striven to insure that logical and aesthetic values celebrated in the classical doctrine of decorum are made suitably manifest in student performance, as though to enforce publicly accepted styles of thought and action by reference to acceptable forms of language.</description>
	</item>
	<item>
		<title>The Grammar Instinct</title>
		<link>http://tc.eserver.org/13761.html</link>
		<guid>http://tc.eserver.org/13761.html</guid>
		<description>Back in 1990, Leonard and Gilsdorf presented 45 instances of questionable usage, in full-paragraph contexts, to both academics and working business executives. These usage&#xD;elements included sentence fragments, assorted punctuation&#xD;problems, pronoun–antecedent (dis)agreement, and various&#xD;examples of questionable word choice. Their intent was to assess the “botheration level” of each usage “error”; their conclusions were that 1) academics are (nearly) always&#xD;bothered by usage “errors” more than executives and 2) usage elements that bothered survey respondents the least&#xD;were evolving over time into acceptable English usage.&#xD;&#xD;Just over ten years later, these same researchers have followed up on their original study and have drawn similar conclusions from the more recent data.</description>
	</item>
	<item>
		<title>Grammar, Punctuation, Spelling</title>
		<link>http://tc.eserver.org/13719.html</link>
		<guid>http://tc.eserver.org/13719.html</guid>
		<description>The Web abounds with sites teaching grammar, punctuation, and spelling. Not surprisingly, most of these sites are provided by educational institutions, teachers, or business-writing consultants, presumably to make up for the lack of grammar teaching in so many school systems for the past several decades. Some are tutorials (masquerading as style guides) for technical communicators. Here are a few sites that I have found useful or that other people have recommended to me.</description>
	</item>
	<item>
		<title>Gender-Neutral Technical Writing</title>
		<link>http://tc.eserver.org/13363.html</link>
		<guid>http://tc.eserver.org/13363.html</guid>
		<description>Gender-neutral writing uses language that does not stereotype either sex nor appear to be referring to only one sex when that is not the writer&apos;s intention. In this article, you&apos;ll see why gender-neutral writing is important for technical writers to use, what gender-neutral writing is not, and how you can use gender-neutral writing in the documents you develop.</description>
	</item>
	<item>
		<title>Guidance on Style Guides: Lessons Learned</title>
		<link>http://tc.eserver.org/11744.html</link>
		<guid>http://tc.eserver.org/11744.html</guid>
		<description>This article highlights some of the lessons that I’ve learned about the process of creating style guides and implementing processes for ensuring that a product is consistent in a number of dimensions. I discuss the purposes and benefits of a style guide, a process for creating a style guide, the many types of consistency, reasons why style guides fail, methods for ensuring consistency, and some references that discuss these issues in more detail.</description>
	</item>
	<item>
		<title>Using a Style Guide to Build Consensus</title>
		<link>http://tc.eserver.org/11745.html</link>
		<guid>http://tc.eserver.org/11745.html</guid>
		<description>Style guides are often requested as a way to promote a common look and feel but do little to address the real problems in the way user interfaces are developed. In many situations, a collection of rules for visual design and the use of controls can seem like a band-aid; promoting surface-level consistency rather than solving the real usability problems. Even when a good style guide is created, it is often ignored after release. Worse, the style guide can become a weapon where a user-centered design process is needed. In either case, the style guide has failed to produce the desired effect. What’s missing is a consensus on the scope, ownership, or content. Solving this problem requires a change in the way style guides are developed, distributed, and used. Three suggestions for teams developing style guides are to start early, to make the emerging style guide widely available, and to plan for long-term maintenance of the guidelines.</description>
	</item>
	<item>
		<title>Tips for Technical Writers</title>
		<link>http://tc.eserver.org/10874.html</link>
		<guid>http://tc.eserver.org/10874.html</guid>
		<description>Begin by getting familiar with your corporate style. If there is no existing style guide, either review existing manuals to determine what has been done in the past ( Pay special attention to the language, assumed prior knowledge, general organization and presentation of how-tos (task-based or informational)) or choose a style guide.</description>
	</item>
	<item>
		<title>Editing for Gender Neutrality</title>
		<link>http://tc.eserver.org/10807.html</link>
		<guid>http://tc.eserver.org/10807.html</guid>
		<description>How to be politically correct without mangling the English language. The goal is that the reader should not notice the writing.  </description>
	</item>
	<item>
		<title>But the Stylebook Says...</title>
		<link>http://tc.eserver.org/10616.html</link>
		<guid>http://tc.eserver.org/10616.html</guid>
		<description>You might think a chapter about how to read a dictionary is a waste of paper, but you&apos;d be wrong. Stylebook entries are designed to be even more explicit in their explanations than dictionary definitions are, but writers and editors still manage to miss the point. When members of the American Copy Editors Society were asked to cite examples of often-misused words, John McIntyre of the Baltimore Sun nominated &apos;stylebook.&apos; The most common form of stylebook abuse is the use of an affirmative entry as a negative entry. Boneheaded editors see x in the stylebook and decide that means they must never, ever use y. A lot of stylebook entries do work this way, but the authors of the stylebook are giving us a little credit and figuring that we can tell which y they&apos;re discouraging. One entry, for example, reads &apos;spaceship.&apos; This doesn&apos;t mean all other words in the language are banned; it means simply that AP does not use &apos;space ship&apos; as two words.</description>
	</item>
	<item>
		<title>When Metaphors Fail to Keep Their Distance</title>
		<link>http://tc.eserver.org/10617.html</link>
		<guid>http://tc.eserver.org/10617.html</guid>
		<description>Was I being too literal when I made the following change? I don&apos;t think so. A name-brand financial columnist wrote the following paragraph in a piece about Web-based credit cards: Most issuers mail you a plastic card, usually a MasterCard or Visa, which you also can use in stores. At Citibank, however, plastic has become uncool. Instead, it&apos;s offering ClickCredit, a virtual card (www.clickcredit.com). It acts like a credit card, but exists only in Citi&apos;s computer. You use it solely for making purchases on the Web. The problem is, I have one of these Citibank cards, and while it&apos;s true that it&apos;s not an ordinary credit card that you carry around in your wallet and use at stores, it&apos;s also true that the ClickCredit people do mail you a card, and it&apos;s made of plastic.</description>
	</item>
	<item>
		<title>Disciplinary Style Manuals as Reliable Guides to Scientific Discourse Norms</title>
		<link>http://tc.eserver.org/10322.html</link>
		<guid>http://tc.eserver.org/10322.html</guid>
		<description>Style manuals sponsored by professional associations in various scientific disciplines have received virtually no scholarly attention. These manuals, however, specify many disciplinary discourse norms that writers need to follow in publishing scientific research. Consequently, these manuals provide an important and reliable source of information about how communities of working scientists conceptualize, construct, and publish their scientific texts. The disciplinary norms that these style manuals promulgate derive both from general scientific research practices and from the practical demands of scientific publishing. Because of their unique normative nature and their connection with scientific practice, disciplinary style manuals should be categorized separately from other types of scientific style manual, and the material they contain can reliably be used in technical writing and editing.</description>
	</item>
	<item>
		<title>The Scientific Style Manual: A Reliable Guide to Practice?</title>
		<link>http://tc.eserver.org/10272.html</link>
		<guid>http://tc.eserver.org/10272.html</guid>
		<description>Is the scientific style manual a reliable guide with regard to the organization and content of the typical scientific article? The answer is, yes and no. Style manuals do provide much sound advice based on their authors&apos; personal experience. However, they also pass on some advice at odds with recently published literature regarding how scientists actually conduct research and write up their findings. This article presents a revised model for the scientific article, a model base don information in recently published research on communication in science. </description>
	</item>
	<item>
		<title>User Attitudes Toward Corporate Style Guides: A Survey</title>
		<link>http://tc.eserver.org/10283.html</link>
		<guid>http://tc.eserver.org/10283.html</guid>
		<description>Little information is known on user attitudes toward corporate style guides (CSGs). A national survey shows that an overwhelming 93% of users and 85% of non-users advocate CSG usage primarily to generate consistency in documents, to save time generating documents, and to create a professional look in documents. As corporations face the future by restructuring, usually by downsizing, and by competing more in a global economy, CSG usage will be more prevalent in corporate America, as the results of this survey indicate that CSGs are an economical quality tool that benefits both the user and the corporation. </description>
	</item>
	<item>
		<title>Online Style Guides: Getting Past Caps and Commas</title>
		<link>http://tc.eserver.org/10234.html</link>
		<guid>http://tc.eserver.org/10234.html</guid>
		<description>Style, and style guides, are perennial hot topic in the online content business. Many content professionals seem preoccupied with finding the ultimate, authoritative source with the final word on whether &apos;Internet&apos; should be capitalized, or whether &apos;Web site&apos; is one word or two. But in reality, such questions are among the least important concerns of online style. Where you put the punctuation doesn&apos;t matter nearly as much as how you shape and deliver your messages.</description>
	</item>
	<atom:link href="http://tc.eserver.org/dir/Articles/Style-Guides.xml" rel="self" type="application/rss+xml"/>
</channel>
</rss>