<?xml version="1.0" encoding="utf-8" ?><rss version="2.0" xmlns:atom="http://www.w3.org/2005/Atom">
<channel>
	<title>Hollis Weber, Jean</title>	<link>http://tc.eserver.org/authors/Hollis_Weber,_Jean</link>
	<description>A bibliography of works by Hollis Weber, Jean 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>Hollis Weber, Jean</title>
		<link>http://tc.eserver.org/dir/Hollis_Weber,_Jean</link>
	</image>
	<item>
		<title>Getting the Most from OpenOffice.org Writer Fields</title>
		<link>http://tc.eserver.org/26115.html</link>
		<guid>http://tc.eserver.org/26115.html</guid>
		<description>Fields are extremely useful features of Writer. This article describes how to use fields to solve common business and technical writing problems.</description>
	</item>
	<item>
		<title>OpenOffice.org and Me: An Introduction</title>
		<link>http://tc.eserver.org/26102.html</link>
		<guid>http://tc.eserver.org/26102.html</guid>
		<description>When I first tried OOo, it was at around version 1.0.0 or 1.0.1. The help files were pathetic in those days; I described them at the time as &apos;badly written, badly organized, badly indexed, and frequently wrong.&apos; To be fair, the help has improved a great deal since then, though the indexing still needs a lot of improvement.</description>
	</item>
	<item>
		<title>Writing, Editing, and Reviewing Documents</title>
		<link>http://tc.eserver.org/26104.html</link>
		<guid>http://tc.eserver.org/26104.html</guid>
		<description>OpenOffice.org Writer provides many ways to write, edit, review, and comment on documents. This chapter covers some of those techniques, plus some other tips.</description>
	</item>
	<item>
		<title>Technical Writing Using OpenOffice.org Writer</title>
		<link>http://tc.eserver.org/25697.html</link>
		<guid>http://tc.eserver.org/25697.html</guid>
		<description>If you&apos;re in the business of writing technical documents and you&apos;ve been using Word in particular, you could benefit by switching to OpenOffice.org Writer. OpenOffice.org Writer is a strong competitor to Word for both drafts and final layout (desktop publishing) of many technical documents because it combines some of the best features of Word and FrameMaker. Indeed, Writer does several things better or easier than each of them.</description>
	</item>
	<item>
		<title>Planning an Electronic Performance Support System Project</title>
		<link>http://tc.eserver.org/22865.html</link>
		<guid>http://tc.eserver.org/22865.html</guid>
		<description>Electronic performance support systems are programs that directly support a worker&apos;s ability to perform tasks. Such systems go beyond passive task-oriented online help. To be effective, EPS systems should be closely interlocked with the supported product&apos;s user interface and its online help. This paper outlines some of the planning considerations and steps involved in an EPSS project, and some of the problems and complications that arose during a specific project.</description>
	</item>
	<item>
		<title>Editing for an International Audience</title>
		<link>http://tc.eserver.org/22133.html</link>
		<guid>http://tc.eserver.org/22133.html</guid>
		<description>Here are some things to consider when editing for an international audience.</description>
	</item>
	<item>
		<title>Electronically Indicating Approvals or Rejections of Editorial Changes</title>
		<link>http://tc.eserver.org/22136.html</link>
		<guid>http://tc.eserver.org/22136.html</guid>
		<description>This technique (involving two macros) works in Word97, but not in Word6 or 7/95. The requirement is to indicate (for audit purposes) whether an editorial change was accepted or rejected by the author or other authority.</description>
	</item>
	<item>
		<title>Gender-Neutral Technical Writing</title>
		<link>http://tc.eserver.org/22132.html</link>
		<guid>http://tc.eserver.org/22132.html</guid>
		<description>In recurring discussions on the TECHWR-L list, many technical writers argue that they write in &apos;correct English&apos; and are not going to change their style just to suit the political-correctness police. &apos;I won&apos;t use &apos;they&apos; as a singular pronoun because it&apos;s not grammatically correct&apos; and &apos;Using contrived phrases such as &apos;s/he&apos; is just too awkward&apos; are arguments I&apos;ve heard frequently in the debate. But using &apos;incorrect English&apos; or contrived phrases is neither the goal nor the outcome of gender-neutral writing.</description>
	</item>
	<item>
		<title>Stressing What is Important in a Sentence</title>
		<link>http://tc.eserver.org/22131.html</link>
		<guid>http://tc.eserver.org/22131.html</guid>
		<description>In addition to expunging the usual collection of wordy phrases from documents, editors commonly attempt to tighten up writing to make it more direct, clear, and concise. For example, when editing business and technical material, I frequently change sentences containing &apos;it is,&apos; &apos;there is,&apos; and &apos;there are.&apos; Writers often ask me &apos;what was wrong with that sentence?&apos; I reply that although the sentence wasn&apos;t wrong grammatically, such phrases distract the reader from the important part of the message.</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>Alternatives to the Paragraph</title>
		<link>http://tc.eserver.org/22128.html</link>
		<guid>http://tc.eserver.org/22128.html</guid>
		<description>&apos;It&apos;s all in the manual.&apos; How many times have you heard that - or said it in frustration? After all, when you are the person who wrote the manual, you know that all the answers are there. But time and again readers can&apos;t find what they need to know, or don&apos;t understand the material. Before you blame the reader, look again at how you&apos;ve presented the material.</description>
	</item>
	<item>
		<title>Audience and Document Analysis</title>
		<link>http://tc.eserver.org/22116.html</link>
		<guid>http://tc.eserver.org/22116.html</guid>
		<description>Before you begin editing a document, try to find out as much as you can about the audience for the document and purpose of the document.</description>
	</item>
	<item>
		<title>Choosing and Using Help Topics</title>
		<link>http://tc.eserver.org/22119.html</link>
		<guid>http://tc.eserver.org/22119.html</guid>
		<description>This paper describes some common types of help topic and when to use each. Different applications require different mixes of help topics. Choose the topic types that are appropriate for the application you are documenting.</description>
	</item>
	<item>
		<title>Deciding What Needs to be Done</title>
		<link>http://tc.eserver.org/22115.html</link>
		<guid>http://tc.eserver.org/22115.html</guid>
		<description>Before you begin editing a document, you need to analyse it and plan what needs to be done. The exception is when your job is strictly limited (by your supervisor or the client) to correcting only the glaring errors of spelling, punctuation and grammar (a &apos;light edit&apos;). There is no point to attempting a more substantive edit if doing so will only get you into trouble (or if the client won&apos;t pay you for the time you spend).</description>
	</item>
	<item>
		<title>Editing Reports and Proposals</title>
		<link>http://tc.eserver.org/22124.html</link>
		<guid>http://tc.eserver.org/22124.html</guid>
		<description>Businesses, non-profit organizations, government departments, and other groups produce a lot of proposals and reports. This article summarizes some features of reports and proposals that are not the same as books, news items, manuals, magazine articles, memos and many other documents.</description>
	</item>
	<item>
		<title>Editing Single-Sourced Projects</title>
		<link>http://tc.eserver.org/22126.html</link>
		<guid>http://tc.eserver.org/22126.html</guid>
		<description>This article does not address the (important) questions of when a single-sourcing methodology is a good solution to an information delivery problem (&apos;good&apos; here meaning saving time and money while maintaining or improving the quality of the resulting deliverables). Instead, I&apos;m looking only at the editor&apos;s involvement in the project.</description>
	</item>
	<item>
		<title>Editing Tables of Data</title>
		<link>http://tc.eserver.org/22125.html</link>
		<guid>http://tc.eserver.org/22125.html</guid>
		<description>Tables should allow readers to easily and accurately: see what subject matter and variables are being described; find out absolute values; observe relationships between variables. When you edit a table, it is useful to assess just how well it achieves these ends. Readers will feel confident with your table if they can quickly navigate around and absorb the data.</description>
	</item>
	<item>
		<title>An Example of Substantive Editing</title>
		<link>http://tc.eserver.org/22122.html</link>
		<guid>http://tc.eserver.org/22122.html</guid>
		<description>Some years ago I edited a quarterly magazine for the users of a large Australian computing network. This example (from 1985) is fairly typical of the technical articles I received from department managers. I include here the unedited text and my revised version.</description>
	</item>
	<item>
		<title>Hints for Developing a Table of Contents</title>
		<link>http://tc.eserver.org/22127.html</link>
		<guid>http://tc.eserver.org/22127.html</guid>
		<description>Planning a project before beginning the detailed work is one of the vital steps to success in technical communication. Developing a table of contents is one of the steps in the planning process of a document. </description>
	</item>
	<item>
		<title>Planning an Electronic Performance Support System Project</title>
		<link>http://tc.eserver.org/22120.html</link>
		<guid>http://tc.eserver.org/22120.html</guid>
		<description>Electronic performance support systems are software programs that directly support a worker&apos;s ability to perform tasks. Such systems go beyond passive task-oriented online help. To be effective, EPS systems should be closely interlocked with the supported product&apos;s user interface and its online help. This paper outlines some of the planning considerations and steps involved in an EPSS project, and some of the problems and complications that arose during a specific project.</description>
	</item>
	<item>
		<title>Planning an Online Help Project</title>
		<link>http://tc.eserver.org/22118.html</link>
		<guid>http://tc.eserver.org/22118.html</guid>
		<description>This paper outlines some general principles you need to consider when planning an online help project and creating WinHelp files.</description>
	</item>
	<item>
		<title>The Role of the Editor in the Technical Writing Team</title>
		<link>http://tc.eserver.org/22113.html</link>
		<guid>http://tc.eserver.org/22113.html</guid>
		<description>Editing today covers far more than printed materials. In this discussion, I am assuming a technical editor may be required to deal with: printed materials (for example, books, pamphlets, quick reference cards); electronic (for example, online documentation, online help, web pages); video scripts; computer-based training materials. I am also assuming that the audience for the material being edited is not comprised of other technical people; or if it is, the editor is not the person responsible for ensuring the technical accuracy of the material.</description>
	</item>
	<item>
		<title>&quot;Use Cases&quot; and &quot;User Scenarios&quot; Explained</title>
		<link>http://tc.eserver.org/22121.html</link>
		<guid>http://tc.eserver.org/22121.html</guid>
		<description>This file contains the responses I received to a message I sent on January 21, 2000 to the TECHWR-L and WINHLP-L discussion lists. It was posted on the Techwhirl website for awhile but was removed during a reorganisation of the site. Other people&apos;s comments are included with their permission.</description>
	</item>
	<item>
		<title>Using Style Sheets</title>
		<link>http://tc.eserver.org/22114.html</link>
		<guid>http://tc.eserver.org/22114.html</guid>
		<description>Style sheets supplement the style manual (if there is one). You might also use one to summarise vital information for your own reference or to give to an editor. Record on a style sheet any decisions made for a particular product or publication.</description>
	</item>
	<item>
		<title>Working Electronically</title>
		<link>http://tc.eserver.org/22117.html</link>
		<guid>http://tc.eserver.org/22117.html</guid>
		<description>Editors need to know some basic techniques for dealing with files if they are going to be editing them electronically. These techniques apply to files in any format, but exactly what you do depends on which word-processor, desktop publishing program, help authoring system, or other software you are using.</description>
	</item>
	<item>
		<title>Taming OpenOffice.org Writer 1.1: Tips and Tricks for Academic, Technical, and Business Writers</title>
		<link>http://tc.eserver.org/21723.html</link>
		<guid>http://tc.eserver.org/21723.html</guid>
		<description>This book is for intermediate and advanced users of OpenOffice.org Writer. You may not have used this program before, but you have used another word processor (such&#xD;as Microsoft Word or Corel WordPerfect) and you are familiar with the basics of word&#xD;processing.&#xD;Typical users include academic writers, technical writers, and other business and&#xD;professional writers—anyone who produces books, research papers, proposals, or&#xD;other documents requiring the use of more than the basic features. For example, you&#xD;need to use styles instead of direct formatting of headings and other paragraphs, and&#xD;you need to include chapter information in the footers of pages, or you want to use&#xD;master documents to control a book containing many chapters, perhaps written by&#xD;different people.</description>
	</item>
	<item>
		<title>Escape From the Grammar Trap</title>
		<link>http://tc.eserver.org/19180.html</link>
		<guid>http://tc.eserver.org/19180.html</guid>
		<description>Too many editors focus on the details and don&apos;t pay enough attention to the bigger picture. Editors can--and should--add even more value through substantive, technical, and usability editing.&#xD;&#xD;Copyediting is important, but the details are only part of what an editor can and should be reviewing. After all, a document can be correctly spelled and punctuated, grammatically correct, use only approved terminology, and follow the style guide perfectly--and still not serve the audience&apos;s needs.&#xD;&#xD;This article covers some reasons why editors focus on details and not the bigger picture; describes how much attention technical communicators should pay to formal rules of grammar, punctuation, and usage; and describes how we can distinguish between essential and nonessential rules of grammar, punctuation, and usage.</description>
	</item>
	<item>
		<title>Gender-Neutral Technical Writing</title>
		<link>http://tc.eserver.org/18650.html</link>
		<guid>http://tc.eserver.org/18650.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>Taming a Telecommuting Team</title>
		<link>http://tc.eserver.org/18264.html</link>
		<guid>http://tc.eserver.org/18264.html</guid>
		<description>“Telecommuting” includes situations where members of a&#xD;group (department, team, other) are working in different&#xD;locations, communicating with each other and with clients&#xD;by phone, fax, and e-mail. The team may be dispersed&#xD;through an urban area, nationally, or internationally.&#xD;Telecommuting has advantages and disadvantages over&#xD;the traditional centralized working group and presents new&#xD;challenges to management and staff As a team leader of&#xD;telecommuting technical writers on software development&#xD;projects, I have dealt with many of these Issues. In this&#xD;discussion I cover some of the advantages and&#xD;disadvantages and some principles and rules of successful&#xD;telecommuting teams.&#xD;</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>Example Style Guide</title>
		<link>http://tc.eserver.org/14139.html</link>
		<guid>http://tc.eserver.org/14139.html</guid>
		<description>This document accompanies the TECHWR-L article &apos;&lt;A HREF=&quot;http://tc.eserver.org/14140.html&quot;&gt;Developing a Style Guide&lt;/A&gt;,&apos; and includes a sample outline of a style guide. Some of the sections include some detailed sample text; others do not. Please note that the examples shown here are not necessarily the &apos;correct&apos; choices, or the &apos;preferred&apos; choices, or the &apos;best&apos; choices; they are simply examples of things to include. Your project may require additional items, especially if your writing will be used on a Web site.</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>Working with a Technical Editor</title>
		<link>http://tc.eserver.org/13589.html</link>
		<guid>http://tc.eserver.org/13589.html</guid>
		<description>If you have never worked with an editor before, you may be wondering what to expect, and what the editor will expect from you. If you have worked with an editor before, you probably have some expectations about the relationship. Whether your past experiences were good or bad, you may be quite surprised to discover that the new editor&apos;s expectations are rather different from yours. This article looks at some aspects of the writer-editor relationship and what each of you can do to get the best results out of working together. </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>Choosing and Using a Technical Writer</title>
		<link>http://tc.eserver.org/10834.html</link>
		<guid>http://tc.eserver.org/10834.html</guid>
		<description>Offers advice for anyone looking to hire a technical writer on choosing a writer and using a writer.</description>
	</item>
	<item>
		<title>Ethics in Scientific and Technical Communication</title>
		<link>http://tc.eserver.org/10838.html</link>
		<guid>http://tc.eserver.org/10838.html</guid>
		<description>Discusses many ethical issues including: taking personal responsibility for one&apos;s actions, Behaviour toward colleagues, subordinates and others,Dealing with experimental subjects, interviewees, etc, Telling the &apos;truth&apos;, and choosing between advocacy and objectivity.</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>Editing Glossaries </title>
		<link>http://tc.eserver.org/10808.html</link>
		<guid>http://tc.eserver.org/10808.html</guid>
		<description>Traps for the unwary are common in technical writing. In my 20 years of editing, I&apos;ve seen a lot of things that have slipped by writers and reviewers.  </description>
	</item>
	<item>
		<title>Editing Online Materials</title>
		<link>http://tc.eserver.org/10809.html</link>
		<guid>http://tc.eserver.org/10809.html</guid>
		<description>Editing anything that is intended to be read on a computer rather than (or in addition to) being read on a paper copy.</description>
	</item>
	<item>
		<title>The Technical Editors&apos; Eyrie</title>
		<link>http://tc.eserver.org/10041.html</link>
		<guid>http://tc.eserver.org/10041.html</guid>
		<description>The newsletter is intended for editors who are, or need to be, working electronically. Much of the material will be relevant to electronic editors in any field. Some of the material will be most relevant to editors in technical fields such as computing and engineering.</description>
	</item>
	<atom:link href="http://tc.eserver.org/authors/Hollis_Weber,_Jean.xml" rel="self" type="application/rss+xml"/>
</channel>
</rss>