<?xml version="1.0" encoding="utf-8" ?><rss version="2.0" xmlns:atom="http://www.w3.org/2005/Atom">
<channel>
	<title>Style Guides</title>	<link>http://tc.eserver.org/dir/Style-Guides</link>
	<description>A listing of the most recently indexed works about 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>Style Guides</title>
		<link>http://tc.eserver.org/dir/Style-Guides</link>
	</image>
	<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>The BBC News Style Guide</title>
		<link>http://tc.eserver.org/35227.html</link>
		<guid>http://tc.eserver.org/35227.html</guid>
		<description>This style guide represents some of John Allen’s extraordinary wisdom surrounding the use of English in written and spoken communications. This is in many ways at the heart of what the BBC does and what it is respected for.This is not a “do and don’t” list but a guide that invites you to explore some of the complexities of modern English usage and to make your own decisions about what does and does not work. It should improve your scripts and general writing, not to mention making you feel better informed, challenged and amused.</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>Introduction to Basic Legal Citation</title>
		<link>http://tc.eserver.org/34550.html</link>
		<guid>http://tc.eserver.org/34550.html</guid>
		<description>This introduction to legal citation is focused on the forms of citation used in professional practice rather than those used in journal publication. It aims to identify the more important points on which there is divergence between the rules set out in two common manuals and evolving usage reflected in legal memoranda and briefs prepared by practicing lawyers.</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>Technical Writing Guide</title>
		<link>http://tc.eserver.org/34159.html</link>
		<guid>http://tc.eserver.org/34159.html</guid>
		<description>This set of guidelines was developed to help you understand the expectations for technical communication in CE 314K (Properties and Behavior of Engineering Materials). Successful technical communication requires practice. Therefore, you should allot sufficient time to write several drafts of each assignment before submitting the final version.</description>
	</item>
	<item>
		<title>A Guide to the Preparation of Theses and Dissertations in Science and Engineering</title>
		<link>http://tc.eserver.org/34163.html</link>
		<guid>http://tc.eserver.org/34163.html</guid>
		<description>This guide is intended to help you write the best thesis you can by anticipating and answering common questions about content, structure, format, figures, and language. We have also included some suggestions on how to manage the process of turning your research -- your testing and reading, your findings and conclusions -- into a clear, complete, well-written, and convincing thesis or dissertation.</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>Updating a Corporate Style Guide: Process and Reality</title>
		<link>http://tc.eserver.org/32547.html</link>
		<guid>http://tc.eserver.org/32547.html</guid>
		<description>Establish a company-wide team of writers and editors to process comments on the style guide. If applicable, aim for a geographically diverse group that represents all of your company&apos;s documentation groups.</description>
	</item>
	<item>
		<title>Punctuation Made Simple</title>
		<link>http://tc.eserver.org/31676.html</link>
		<guid>http://tc.eserver.org/31676.html</guid>
		<description>Some people write well but allow themselves to be disabled by a fear of punctuation and grammar. They know how to prewrite, organize, and revise, but proofreading for punctuation and grammar causes them difficulties. There’s no need to fear these conventions of standard written English. In fact, these conventions can help you become a more effective communicator.</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>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>
	<atom:link href="http://tc.eserver.org/dir/Style-Guides.xml" rel="self" type="application/rss+xml"/>
</channel>
</rss>