<?xml version="1.0" encoding="utf-8" ?><rss version="2.0" xmlns:atom="http://www.w3.org/2005/Atom">
<channel>
	<title>Hart, Geoffrey J.S</title>	<link>http://tc.eserver.org/authors/Hart,_Geoffrey_J.S</link>
	<description>A bibliography of works by Hart, Geoffrey J.S 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>Hart, Geoffrey J.S</title>
		<link>http://tc.eserver.org/dir/Hart,_Geoffrey_J.S</link>
	</image>
	<item>
		<title>Demonstrating the Value of Editing</title>
		<link>http://tc.eserver.org/35640.html</link>
		<guid>http://tc.eserver.org/35640.html</guid>
		<description>Like all other technical communicators, we editors must sometimes struggle to prove our worth to employers. We know our value, and the more clueful of our authors understand, but sometimes it takes a bit more work to convince senior managers that we serve a useful purpose. Managers generally require specific examples, usually supported by hard numbers. In this article, I’ve provided a few random facts and figures that I’ve accumulated over the years that you can share with management.</description>
	</item>
	<item>
		<title>When Statecraft Fails: Tips on Surviving the Great Game</title>
		<link>http://tc.eserver.org/35516.html</link>
		<guid>http://tc.eserver.org/35516.html</guid>
		<description>Following up on his article in the September/October issue, Hart explores how to avoid “rats” in office politics and offers advice on combating coworkers who might not have your best interests in mind.</description>
	</item>
	<item>
		<title>Editorial Ethics: The Role of the Editor Before Peer Review</title>
		<link>http://tc.eserver.org/35009.html</link>
		<guid>http://tc.eserver.org/35009.html</guid>
		<description>Editors who work with authors before a manuscript is sent for review face certain challenges. Since we’re often the first to see a manuscript, we sometimes encounter problems we must help solve before they come back to bite the author. These problems fall into a variety of categories, of which I see three repeatedly in my work. In this article, I’ll discuss the nature of these problems, provide examples from my own career as a science editor, and suggest how similar problems might arise in other types of editing.</description>
	</item>
	<item>
		<title>The Limitations of Mental Models</title>
		<link>http://tc.eserver.org/34512.html</link>
		<guid>http://tc.eserver.org/34512.html</guid>
		<description>As human beings, we create conceptual models that enable us to understand the complex world around us. Hart believes that information designers should understand mental models as a tool for creating the best possible communications.</description>
	</item>
	<item>
		<title>Typography 101B: The Role of White Space in Making Words Readable</title>
		<link>http://tc.eserver.org/33401.html</link>
		<guid>http://tc.eserver.org/33401.html</guid>
		<description>Hart continues his dissection of typography in this second installment, in which he discusses the important of spacing for the readability of words and sentences.</description>
	</item>
	<item>
		<title>Why Certification by the STC Won’t Work</title>
		<link>http://tc.eserver.org/32687.html</link>
		<guid>http://tc.eserver.org/32687.html</guid>
		<description>The virtues of certification cannot be ignored, but they are outweighed by the drawbacks: There’s no evidence that employers will value certification; it can be highly subjective; and it requires ongoing renewal, even for experienced practitioners, to avoid diluting its value. The more important task must be to demonstrate our value to employers. Only once they understand our value will certification provide a means to assure employers that they can expect to receive that value.</description>
	</item>
	<item>
		<title>Implementing Onscreen Editing: A Four-Step Process</title>
		<link>http://tc.eserver.org/32545.html</link>
		<guid>http://tc.eserver.org/32545.html</guid>
		<description>Four technological or organizational barriers interfere with change, each leading to an implementation step. To overcome resistance to change, harness the energy of existing processes rather than trying to fight them.</description>
	</item>
	<item>
		<title>Inspiring Reviewers to Review Your Documents</title>
		<link>http://tc.eserver.org/32228.html</link>
		<guid>http://tc.eserver.org/32228.html</guid>
		<description>To obtain good reviews, you must make the process as painless as possible for reviewers.</description>
	</item>
	<item>
		<title>Ten Technical Communication Myths</title>
		<link>http://tc.eserver.org/32155.html</link>
		<guid>http://tc.eserver.org/32155.html</guid>
		<description>Technical communication has accumulated its share of mythical rules of thumb, but the good news about our profession&apos;s myths is that they too contain grains of truth and insights into things that are truly important to us. (This work is a reprint of &lt;a href=&quot;http://tc.eserver.org/10500.html&quot;&gt;http://tc.eserver.org/10500.html&lt;/a&gt;, but not locked for STC members only.)</description>
	</item>
	<item>
		<title>The Economics of Membership</title>
		<link>http://tc.eserver.org/32127.html</link>
		<guid>http://tc.eserver.org/32127.html</guid>
		<description>Members often ask what advantages they receive for their membership dollars. The answer is so obvious we sometimes fail to see it. With apologies to the kind souls at MasterCard, a few thoughts on the value of your STC membership.</description>
	</item>
	<item>
		<title>Much Ado about Nothing, Part 2: Deconstructing a Page</title>
		<link>http://tc.eserver.org/31362.html</link>
		<guid>http://tc.eserver.org/31362.html</guid>
		<description>In a continuation of his January column, Hart sheds some light on page layout and design—and gives color to a seemingly “black-and-white” concept.</description>
	</item>
	<item>
		<title>Much Ado about Nothing, Part I: The Importance of White Space</title>
		<link>http://tc.eserver.org/30782.html</link>
		<guid>http://tc.eserver.org/30782.html</guid>
		<description>White space is a paradox: by definition it contains no information, yet it clearly communicates despite lack of content. Hart describes how to incorporate white space into the information design process.</description>
	</item>
	<item>
		<title>Reader-Centered Documentation Provides the Necessary Context</title>
		<link>http://tc.eserver.org/30555.html</link>
		<guid>http://tc.eserver.org/30555.html</guid>
		<description>A features-based approach to documentation is appropriate for reference manuals, where the goal is to provide information on something the reader already knows. This article explores how to meet the needs of the reader when providing documentation for user manuals.</description>
	</item>
	<item>
		<title>Bridging the Gap between Cultural Studies Theory and the World of the Working Practitioner</title>
		<link>http://tc.eserver.org/30296.html</link>
		<guid>http://tc.eserver.org/30296.html</guid>
		<description>Cultural studies is an academic field that focuses on understanding the unchallenged assumptions that constrain and shape communication and related interactions among people. Although the field has made considerable progress in the last half-century, many practitioners have either never encountered the field, or have encountered it only through extremist advocates who do the field a great disservice. As a result, they have lost the ability to benefit from the insights provided by cultural studies. In this paper, I review the recent book Critical Power Tools to provide an update on the current thinking in the field, and to demonstrate how the modern form of the field has much to teach technical communications practitioners who are willing to listen to what the theoreticians have to say.</description>
	</item>
	<item>
		<title>Hierarchies in Online Information: Balancing Depth and Breadth</title>
		<link>http://tc.eserver.org/30123.html</link>
		<guid>http://tc.eserver.org/30123.html</guid>
		<description>Hart explains how understanding hierarchies--the order in which information is grouped--can help you choose an appropriate balance between the depth and breadth of your online information.</description>
	</item>
	<item>
		<title>Bridging the Gap between Cultural Studies Theory and the World of the Working Practitioner</title>
		<link>http://tc.eserver.org/29917.html</link>
		<guid>http://tc.eserver.org/29917.html</guid>
		<description>Cultural studies is an academic field that focuses on understanding the unchallenged assumptions that constrain and shape communication and related interactions among people. Although the field has made considerable progress in the last half-century, many practitioners have either never encountered the field, or have encountered it only through extremist advocates who do the field a great disservice. As a result, they have lost the ability to benefit from the insights provided by cultural studies. In this paper, I review the recent book Critical Power Tools to provide an update on the current thinking in the field, and to demonstrate how the modern form of the field has much to teach technical communications practitioners who are willing to listen to what the theoreticians have to say.</description>
	</item>
	<item>
		<title>Improving Your Editing Efficiency: Software Skills, Soft Skills, and Survival Skills</title>
		<link>http://tc.eserver.org/29655.html</link>
		<guid>http://tc.eserver.org/29655.html</guid>
		<description>Editing efficiently involves a mix of software skills, soft (human) skills, and strategies for surviving chaos. Although software skills are certainly important--we never have as much time as we need, and computers really can help--we must still nurture author-editor relationships. Knowing the strategies battle-scarred editors have developed over the years can save you from duplicating those scars. In this paper, I&apos;ll discuss the software skills you&apos;ll need to work efficiently, how to cope with the human factors involved in editing, and some strategies for managing the often-chaotic editorial life.</description>
	</item>
	<item>
		<title>Surviving a Busy Year: The Marathon of Chapter Presidency</title>
		<link>http://tc.eserver.org/29688.html</link>
		<guid>http://tc.eserver.org/29688.html</guid>
		<description>Every year, the annual conference offers potential chapter leaders a session entitled &apos;The Marathon of Chapter Presidency&apos;. They&apos;re not kidding. My year as president of STC Montreal was a long, steady, exhausting haul--but a very pleasant one now that I can look back on our achievements. In this paper, I&apos;ll pass along tips learned from other presidents and tips I learned while coping with my own duties. Try out as many tips as your time, energy, and volunteers permit!</description>
	</item>
	<item>
		<title>Mental Models: Laying Foundations to Support Readers</title>
		<link>http://tc.eserver.org/29467.html</link>
		<guid>http://tc.eserver.org/29467.html</guid>
		<description>Technical communication is often no more complicated than clearly describing the steps in a procedure, but sometimes we must create new models for each key part of a complex procedure.</description>
	</item>
	<item>
		<title>Combining the Print and Online Media Offers Synergies</title>
		<link>http://tc.eserver.org/29440.html</link>
		<guid>http://tc.eserver.org/29440.html</guid>
		<description>Companies had decades of experience in using printed materials to persuade readers to contact them, whether by phone, mail, or in person. This model of interaction with customers had worked so well and so predictably that we simply moved it online, largely unmodified. That was by no means wrong, but as Web technology and our comprehension of that technology both evolved, the approach proved limiting.</description>
	</item>
	<item>
		<title>Content is King</title>
		<link>http://tc.eserver.org/29443.html</link>
		<guid>http://tc.eserver.org/29443.html</guid>
		<description>Not all content is created equal. In fact, the real issue isn&apos;t the primacy of content, since no user in their right mind will come to stare at a blank screen labeled Me.com; the real issue is what type of content you&apos;re offering.</description>
	</item>
	<item>
		<title>Dr. Strangemeeting (or: How I Learned to Stop Worrying and Enjoy the Donuts)</title>
		<link>http://tc.eserver.org/29437.html</link>
		<guid>http://tc.eserver.org/29437.html</guid>
		<description>Experts claim you&apos;ll spend 1500 hours in meetings during a typical 30-year career--that is, if you can duck some meetings by looking busy and if you can retire early. If you duck slowly or plan a long career, you could easily spend more time in meetings than you spend working. Fortunately, a little planning and some quick thinking should let you turn meetings into a blessing--or at least a tolerable evil.</description>
	</item>
	<item>
		<title>Hockey and the Art of Technical Communication</title>
		<link>http://tc.eserver.org/29438.html</link>
		<guid>http://tc.eserver.org/29438.html</guid>
		<description>If STC would fund an appropriately intensive study of the NHL, I have no doubt we could inspire dramatic changes in technical communication; the contrasts between the NFL and NHL approaches have profound consequences for our work.</description>
	</item>
	<item>
		<title>A Millennial Paradigm for Documentation: the Scroll!</title>
		<link>http://tc.eserver.org/29444.html</link>
		<guid>http://tc.eserver.org/29444.html</guid>
		<description>Although some zealots have proposed eliminating printed information entirely in favor of online help systems, Adobe Acrobat files, and even e-books, discarding printed books may prove less effective than simply modernizing them. Scrolls are the logical successors to books.</description>
	</item>
	<item>
		<title>The Physics of Reviewers</title>
		<link>http://tc.eserver.org/29436.html</link>
		<guid>http://tc.eserver.org/29436.html</guid>
		<description>Subject-matter experts, managers, and other reviewers tenaciously resist our nagging to review documents properly, often delaying reviews until it&apos;s too late to do a good job. It&apos;s not that they inherently oppose quality control; rather, the problem&apos;s in the amount of work required to review something thoroughly, and &apos;work&apos; is a physics concept. Conveniently, reviewers--like falling objects--follow the same laws of physics as the rest of the universe, and understanding those laws helps you predict reviewer behavior and take appropriate countermeasures.</description>
	</item>
	<item>
		<title>Policies, Procedures, and Paralysis</title>
		<link>http://tc.eserver.org/29439.html</link>
		<guid>http://tc.eserver.org/29439.html</guid>
		<description>We live in an uncertain world, and good intentions are no guarantee of success, so we develop policies and procedures to provide ourselves with a measure of security and provide the illusion of control.</description>
	</item>
	<item>
		<title>Privacy Means Never Having to Say You&apos;re Sorry</title>
		<link>http://tc.eserver.org/29442.html</link>
		<guid>http://tc.eserver.org/29442.html</guid>
		<description>For those of us who work with computers, the value of identifying ourselves to Web sites is increasingly obvious: no more retyping our name and address information, less need to memorize dozens of log-in passwords and paths to specific Web pages, less spam, and fewer irrelevant banner ads. But even those of us who appreciate the value of sharing some personal information with Web sites and those who run them are growing increasingly uncomfortable with the potential for abuse inherent in having information on our identities and preferences broadly available.</description>
	</item>
	<item>
		<title>Reach Out and Touch Someone</title>
		<link>http://tc.eserver.org/29441.html</link>
		<guid>http://tc.eserver.org/29441.html</guid>
		<description>The hardest part of communication lies in the many options we have available, and how tricky it can be to pick the right option for each individual member of our audience. When we write something, whether in print or online, we try to produce something that satisfies as many readers as possible because we require a &apos;one size fits all&apos; solution: we&apos;re not physically present to tailor our approach to meet each individual&apos;s needs, and so must meet a range of needs in a single document. With print, we&apos;re stuck with static text: the text can&apos;t change until we rewrite it and distribute a new version. Moving information online makes it easier to revise and distribute information, but actually updating the information still requires a writer. Are there alternatives that make it easier to reach customers with our messages?</description>
	</item>
	<item>
		<title>Taking Advantage of Reflexive Responses</title>
		<link>http://tc.eserver.org/29445.html</link>
		<guid>http://tc.eserver.org/29445.html</guid>
		<description>None of us likes to admit that we have conditioned reflexes that override our higher cognitive abilities, yet such denials notwithstanding, each of us does occasionally respond without thinking something through clearly. As technical communicators, it&apos;s important for us to accept this fact of human nature and plan for it in our documentation, and to work with the developers of the products that we document to both take advantage of the helpful reflexes and find ways to ward off the harmful ones.</description>
	</item>
	<item>
		<title>Wash Your Hands After Reading This Manual</title>
		<link>http://tc.eserver.org/29446.html</link>
		<guid>http://tc.eserver.org/29446.html</guid>
		<description>The next time you complain about the usability of your computer, think of this: despite patently suboptimal design, Windows computers are really no more difficult to use than your washroom, and the washrooms have been around for an awful lot longer. The bottom line--you should pardon my choice of words--is that despite manifest flaws in both technologies, each lets you accomplish surprising quantities of work. And technical writers take heed: this appalling gap in end-user documentation could just be the next million-selling &apos;for Dummies&apos; book.</description>
	</item>
	<item>
		<title>Defining Editing and the Top Five Rules</title>
		<link>http://tc.eserver.org/29428.html</link>
		<guid>http://tc.eserver.org/29428.html</guid>
		<description>Do no harm: this means no harm to the author&apos;s intended meaning, reputation, or legal liability; no harm to the reader, such as by omitting necessary safety information; and no ethical harm, such as by knowingly distorting the truth.</description>
	</item>
	<item>
		<title>Documentation is a Profit Center!</title>
		<link>http://tc.eserver.org/29435.html</link>
		<guid>http://tc.eserver.org/29435.html</guid>
		<description>Everyone knows that documentation is a cost center, and that downsizing writers and moving documentation online save money. Unfortunately for &apos;everyone&apos;, it&apos;s trivial to demonstrate that documentation is actually a profit center--and we don&apos;t even have to wrassle with messy stuff like customer satisfaction to prove it.</description>
	</item>
	<item>
		<title>The Domino Effect: Changes Have Unforeseen Consequences</title>
		<link>http://tc.eserver.org/29431.html</link>
		<guid>http://tc.eserver.org/29431.html</guid>
		<description>It&apos;s obvious that almost all the changes you make will affect your user community, but considerably less obvious how helpful that community can be about providing feedback before you make the changes.</description>
	</item>
	<item>
		<title>Don&apos;t be a Researcher: Be a Finder!</title>
		<link>http://tc.eserver.org/29418.html</link>
		<guid>http://tc.eserver.org/29418.html</guid>
		<description>One of the fascinating things about science is just how many breakthroughs have come from mixing the knowledge provided by entirely different disciplines, and I suspect that this lesson has yet to be learned in our own discipline of scientific communication. Technical writers have been grappling with the issues of rhetoric, audience analysis, and usability testing for years, and have developed effective solutions and techniques for addressing these issues. Scientific communicators have largely ignored these breakthroughs and clung to our familiar models of communication.</description>
	</item>
	<item>
		<title>Don&apos;t Wait to be Downsized!</title>
		<link>http://tc.eserver.org/29421.html</link>
		<guid>http://tc.eserver.org/29421.html</guid>
		<description>Sure, the economy&apos;s booming now, but as the Asian crisis becomes the North American crisis, it pays to remember Newton&apos;s famous law of gravity: what goes up must come down again. And, of course, when the economy comes down and pension fund managers start asking those awkward questions about why they should remain invested in your company&apos;s stock, managers have a lemming-like tendency to trim staff to make room for short-term profits and long-term plausible deniability. As a technical communicator, you&apos;re obviously well up on the hit list, which some might see as a bad thing--but there&apos;s a silver lining to every cloud (or, in our case, a copper lining; they don&apos;t pay us well enough for silver). In fact, the good news is that it&apos;s easy to ensure you&apos;re the first one fired, so you can leave before the job becomes mundane without looking like a quitter. Then there are all those perquisites (severance pay, a little downtime)...</description>
	</item>
	<item>
		<title>(e)Xpressive Markup Language?</title>
		<link>http://tc.eserver.org/29416.html</link>
		<guid>http://tc.eserver.org/29416.html</guid>
		<description>Conveying the emotional tone of a Web page has, up until now, been impossible with HTML, and the XML standard fails to address this issue. As an interim solution, developers have proposed several new tags to the World Wide Web Consortium (W3C).</description>
	</item>
	<item>
		<title>The Editor as Translator (or: How Do You Say That in Calculus?)</title>
		<link>http://tc.eserver.org/29425.html</link>
		<guid>http://tc.eserver.org/29425.html</guid>
		<description>Sometimes English just isn&apos;t the most elegant way to say something. It might be so much easier if we write for a math journal, because the correct language for the explanation can be, in fact, mathematics.</description>
	</item>
	<item>
		<title>Estimating Project Times and Costs Without Losing Your Shirt--Or Your Sanity</title>
		<link>http://tc.eserver.org/29410.html</link>
		<guid>http://tc.eserver.org/29410.html</guid>
		<description>Determining how long it takes to complete a job is essential for planning and for budgeting your time, whether you&apos;re a wage slave or a freelancer. In this article, I&apos;ll focus on the needs of the freelancer, but the same approach will work equally well for managers of teams of technical communicators and even for lone writers.</description>
	</item>
	<item>
		<title>Garbage In, Garbage Out: Using Affordances</title>
		<link>http://tc.eserver.org/29423.html</link>
		<guid>http://tc.eserver.org/29423.html</guid>
		<description>The trick is to make data-entry forms clear enough that workers understand what you require of them without having to ask. This understanding alone can drastically reduce the frequency of errors, but to turn that understanding into a payback, you&apos;ll have to design a label for each field that is truly obvious to the workers. Information designers call these clues &quot;affordances&quot;, and if you&apos;re lucky enough to have technical writers or editors in your organization, you can probably enlist their aid in designing these clues.</description>
	</item>
	<item>
		<title>Good Times, Bad Times</title>
		<link>http://tc.eserver.org/29424.html</link>
		<guid>http://tc.eserver.org/29424.html</guid>
		<description>The first &apos;macro viruses&apos; attached to Microsoft Word documents emerged within weeks after Office 97 was released, and sounded the warning that a new era was upon us.</description>
	</item>
	<item>
		<title>If You Build It, They&apos;ll Come</title>
		<link>http://tc.eserver.org/29433.html</link>
		<guid>http://tc.eserver.org/29433.html</guid>
		<description>If you create a community around your Web site, look beyond providing the outer semblances of community: design a site that can potentially work the way each of these very different members of the community wants it to work.</description>
	</item>
	<item>
		<title>Indexing Web Pages: Maybe Books Aren&apos;t Such a Bad Model After All!</title>
		<link>http://tc.eserver.org/29419.html</link>
		<guid>http://tc.eserver.org/29419.html</guid>
		<description>One of our favorite cliches is that you can&apos;t use the printed book as a model for online information. Web-based information, which is following the same evolutionary progress as online help systems, has inherited this &apos;books are bad&apos; philosophy. However, any statement we&apos;ve begun to take for granted bears some re-examination, because unquestioningly accepting dogma undermines our efforts to improve communication.</description>
	</item>
	<item>
		<title>The Information Revolution</title>
		<link>http://tc.eserver.org/29411.html</link>
		<guid>http://tc.eserver.org/29411.html</guid>
		<description>Nobody is offering courses in how to prepare hypermedia, nor are there a large number of jobs available for hypermedia authors. As we begin to come up against the limits imposed by the volume of existing knowledge, we will eventually be forced to place more importance on managing our information explosion.</description>
	</item>
	<item>
		<title>Mail Your Newsletter with Less Labor and Cost</title>
		<link>http://tc.eserver.org/29427.html</link>
		<guid>http://tc.eserver.org/29427.html</guid>
		<description>A lot of STC chapter and SIG mailings are done the old-fashioned way: envelopes stuffed by hand, and stamped manually or--occasionally--with a stamp machine. That&apos;s an awful lot of work, and expensive too. When I confronted this problem a few years back for my current employer, some research revealed a solution that eliminated the annual pressganging of volunteers to stuff envelopes and also saved us a fair bit of money.</description>
	</item>
	<item>
		<title>Measure Twice, Cut Once</title>
		<link>http://tc.eserver.org/29434.html</link>
		<guid>http://tc.eserver.org/29434.html</guid>
		<description>Acting without planning can be expensive, and because of the potential cost of poorly thought-out actions, we should not only plan, but plan twice.</description>
	</item>
	<item>
		<title>The Needs of the Many</title>
		<link>http://tc.eserver.org/29429.html</link>
		<guid>http://tc.eserver.org/29429.html</guid>
		<description>Installing major software patches or upgrades ranks right up there with paying your taxes in terms of stress. Why the stress? Well, first, there&apos;s the instinctive fear of screwing up something that&apos;s already working reasonably well, thank you very much, and spending the next 60-hour week trying to get back to where you were before you &apos;improved&apos; things.</description>
	</item>
	<item>
		<title>Notes on the Documentation Development Process</title>
		<link>http://tc.eserver.org/29414.html</link>
		<guid>http://tc.eserver.org/29414.html</guid>
		<description>Define your audience, and their needs, explicitly and carefully. The definition process may lead you to include additional material such as indexes, system requirements, and contextual notes (e.g., lists of exceptions), as well as the preplanned documentation.</description>
	</item>
	<item>
		<title>Nurturing a New Writer</title>
		<link>http://tc.eserver.org/29420.html</link>
		<guid>http://tc.eserver.org/29420.html</guid>
		<description>Technical communicators represent one of the most mobile groups of professionals I&apos;m aware of, with some sources claiming that the average time between changing jobs is as low as four years. This means that many of us will soon find ourselves in the position of working with newcomers, whether permant staff or &apos;temps,&apos; and this means we may face the problem of how to mentor or supervise someone new to our workplace. This article discusses how to work with someone who already has the basic training, but is nonetheless naive in the ways of your particular organization.</description>
	</item>
	<item>
		<title>Science and Fiction</title>
		<link>http://tc.eserver.org/29412.html</link>
		<guid>http://tc.eserver.org/29412.html</guid>
		<description>The purpose of this article is to clarify some common misperceptions as to what science is, what science does, how science relates to technology, and how the activities of science and technology differ from the areas of informed and uninformed speculation, and how the three areas complement each other.</description>
	</item>
	<item>
		<title>So You Want to be an Editor?</title>
		<link>http://tc.eserver.org/29417.html</link>
		<guid>http://tc.eserver.org/29417.html</guid>
		<description>Most technical communicators are hired primarily as writers and creators of information, but despite this, many of us must learn how to edit at some point. Whether the reasons are good (to prepare better first drafts for review) or bad (your employer won&apos;t pay for a full-time editorial position), the reality is inescapable: at some point you&apos;re going to have to edit your own writing or that of a colleague. The problem is that editing requires an entirely different mindset than writing, and it&apos;s difficult to make the mental shift from creating to revising.</description>
	</item>
	<item>
		<title>Sometimes Playing Dumb Makes Things Work Better</title>
		<link>http://tc.eserver.org/29430.html</link>
		<guid>http://tc.eserver.org/29430.html</guid>
		<description>I&apos;ve learned how to forget for a period of time that I know almost as much as my authors about their subject, and this lets me play dumb and trip over things that the author&apos;s peers and I could both figure out with a little work--or a lot of work, occasionally. Once I understand why I tripped over a particular wording, I can figure out how to fix it so that nobody else, even if they really were as idiotic as I sometimes pretend to be.</description>
	</item>
	<item>
		<title>Sometimes You Really Can be Too Helpful</title>
		<link>http://tc.eserver.org/29432.html</link>
		<guid>http://tc.eserver.org/29432.html</guid>
		<description>It&apos;s important to establish and maintain relationships with your audience: it gives you a handle on their changing needs so you can continue to meet those needs.</description>
	</item>
	<item>
		<title>Teamwork and the Product Documentation Process</title>
		<link>http://tc.eserver.org/29415.html</link>
		<guid>http://tc.eserver.org/29415.html</guid>
		<description>Get to know your new teammates. Get to know your audience. Define the product&apos;s features. Create a mockup of the user interface. Begin to document the features and interface.</description>
	</item>
	<item>
		<title>Using the Triage Method in Technical Writing</title>
		<link>http://tc.eserver.org/29426.html</link>
		<guid>http://tc.eserver.org/29426.html</guid>
		<description>Pragmatism is the necessary first step: do the best job you can do under the conditions. Nobody&apos;s going to benefit if you do a superb job on half the manual, then die of stress before you can document the important parts in the second half.</description>
	</item>
	<item>
		<title>Validity Checks</title>
		<link>http://tc.eserver.org/29422.html</link>
		<guid>http://tc.eserver.org/29422.html</guid>
		<description>Work with your fellow employees to understand how they enter data so you can determine the best way to present their choices; they won&apos;t forget who&apos;s responsible for their improved accuracy and speed, particularly around performance appraisal time. Of course, you&apos;ll also earn your own manager&apos;s gratitude once you&apos;re no longer wasting time fixing preventable errors.</description>
	</item>
	<item>
		<title>Writer-Editor Relationships in Revisions</title>
		<link>http://tc.eserver.org/29413.html</link>
		<guid>http://tc.eserver.org/29413.html</guid>
		<description>Editors, professional or otherwise, can be annoying individuals. The trick is to focus on the helpful parts of that annoyance and try to ignore the less-helpful parts.</description>
	</item>
	<item>
		<title>The Myth of &quot;The User&quot;</title>
		<link>http://tc.eserver.org/28812.html</link>
		<guid>http://tc.eserver.org/28812.html</guid>
		<description>Instead of becoming computer users, like the cheery protagonists of Star Trek, we&apos;ve become the computer used, like the gloomy inhabitants of Dilbert.</description>
	</item>
	<item>
		<title>Is &quot;Intercultural&quot; Communication a Moot Point?</title>
		<link>http://tc.eserver.org/28807.html</link>
		<guid>http://tc.eserver.org/28807.html</guid>
		<description>Good writing is good writing in any language, and focusing on the quality of the writing in your own language is a great start to any communication with people from other cultures.</description>
	</item>
	<item>
		<title>Personas and the Technical Communicator</title>
		<link>http://tc.eserver.org/28497.html</link>
		<guid>http://tc.eserver.org/28497.html</guid>
		<description>What&apos;s the problem with personas? They&apos;re a new concept to many communicators, and thus sufficiently unfamiliar to make them difficult to use. To help solve this problem, I developed a couple of personas to show you how it&apos;s done, and illustrate their implications for documentation.</description>
	</item>
	<item>
		<title>Finding Work in Tough Times</title>
		<link>http://tc.eserver.org/28369.html</link>
		<guid>http://tc.eserver.org/28369.html</guid>
		<description>It&apos;s not easy to find rewarding work. Hart describes three steps you can take to help the process go more smoothly when searching for that new job.</description>
	</item>
	<item>
		<title>Abstraction: Making the Complex Easier to Understand</title>
		<link>http://tc.eserver.org/28275.html</link>
		<guid>http://tc.eserver.org/28275.html</guid>
		<description>How can we make difficult concepts easier to grasp? Hart explores abstraction and how it can be used to clarify both simple and complex ideas.</description>
	</item>
	<item>
		<title>Effective Outlining: Designing Workable Blueprints for Writing</title>
		<link>http://tc.eserver.org/28084.html</link>
		<guid>http://tc.eserver.org/28084.html</guid>
		<description>Save time and increase your credibility by creating an effective outline. Hart&apos;s article discusses three important steps in designing an outline.</description>
	</item>
	<item>
		<title>Microwriting: Small Choices with Large Implications</title>
		<link>http://tc.eserver.org/28074.html</link>
		<guid>http://tc.eserver.org/28074.html</guid>
		<description>The little elements of writing can make a big difference. If you&apos;re looking for a way to refresh your writing, consider paying close attention to the aspects involved in microwriting.</description>
	</item>
	<item>
		<title>Designing an Effective Review Process</title>
		<link>http://tc.eserver.org/27985.html</link>
		<guid>http://tc.eserver.org/27985.html</guid>
		<description>Review processes can easily become frustrating and complicated. Hart shows how to create and revive a review process that can be tailored to the needs of your situation.</description>
	</item>
	<item>
		<title>Technology and Knowledge Transfer: Science and Industry Working Together</title>
		<link>http://tc.eserver.org/27886.html</link>
		<guid>http://tc.eserver.org/27886.html</guid>
		<description>Science and technology are intimately related. The technology sector that drives the modern economy would never have arisen without basic scientific research, and that research is now being funded by companies seeking to gain a technological edge over their competitors. Despite this mutual dependence, technical communication has taken different paths in science and industry. Technology and knowledge transfer, the communication of research results to an audience that can implement the results, bridges these two solitudes and strongly resembles much of the work done by other technical communicators.</description>
	</item>
	<item>
		<title>Recipe for Designing Usable Documentation</title>
		<link>http://tc.eserver.org/27807.html</link>
		<guid>http://tc.eserver.org/27807.html</guid>
		<description>What makes documentation usable? Usable documentation accommodates the way I think. Hart summarizes his principles for define &apos;user-friendly documentation.&apos;</description>
	</item>
	<item>
		<title>Sensitivity to Other Cultures</title>
		<link>http://tc.eserver.org/27269.html</link>
		<guid>http://tc.eserver.org/27269.html</guid>
		<description>Shares experiences and observations collected from working with colleagues in Asian cultures. Discusses the importance of actively working to accommodate the needs of communicators from other cultures by beginning the dialogue in their language.</description>
	</item>
	<item>
		<title>&quot;Backing Up&quot; Doesn&apos;t Mean Retreating</title>
		<link>http://tc.eserver.org/26745.html</link>
		<guid>http://tc.eserver.org/26745.html</guid>
		<description>Recently, several friends and colleagues have lost important files as a result of viruses, power failures, computer crashes, and miscellaneous other disasters that accompany working with computers. Each person could have minimized the consequences if they had developed and rigorously followed a simple backup strategy for their data. The fact that this happened to experienced computer users in each case leads me to believe that data loss is symptomatic of a broader problem: As technical communicators, our tight focus on documenting how to use a product sometimes makes us forget to document the consequences of using the product.</description>
	</item>
	<item>
		<title>Avoiding Repetitive-Stress Injuries: A Guide for the Technical Communicator</title>
		<link>http://tc.eserver.org/26124.html</link>
		<guid>http://tc.eserver.org/26124.html</guid>
		<description>Writers and editors in particular put in an awful lot of miles at the keyboard every day. For example, I commonly spend a solid 8 hours typing. Writers and editors in particular put in an awful lot of miles at the keyboard every day. For example, I commonly spend a solid 8 hours typing. Then there&apos;s that darned mouse. W. Wayt Gibbs, writing in the June 2002 Scientific American, used the Mouse Odometer software (www.modometer.com) to monitor his habits and found that in a single 5-day period, he&apos;d recorded 2440 feet of mouse movement and nearly 22 000 mouse clicks. It&apos;s no wonder computer users sometimes experience serious physical problems.It&apos;s no wonder computer users sometimes experience serious physical problems.</description>
	</item>
	<item>
		<title>Prescriptive Audience Analysis: Moving Beyond the Purely Descriptive</title>
		<link>http://tc.eserver.org/26125.html</link>
		<guid>http://tc.eserver.org/26125.html</guid>
		<description>Editing and writing both require an understanding of our audience, because without that knowledge, we can&apos;t shape our words to help them easily grasp difficult concepts. To understand our audience, we do what all writers and editors do, whether consciously or unconsciously: We create an image of our audience that guides our choice of words, images, and metaphors. This image is variously known as a &apos;stereotype&apos; (e.g., Schriver 1997) or a &apos;persona&apos; (e.g., Graham 2001). Keeping that image in mind as we work helps us satisfy the reader&apos;s needs, but if we&apos;re not careful, it can also cause us to waste valuable time collecting information that doesn&apos;t really help us communicate.</description>
	</item>
	<item>
		<title>Looking for Work as a Scientific Communicator?</title>
		<link>http://tc.eserver.org/26026.html</link>
		<guid>http://tc.eserver.org/26026.html</guid>
		<description>Many technical writers recently found themselves looking for work in the wake of September 11th and the dotcom meltdown.</description>
	</item>
	<item>
		<title>Streamlining an Interface Using Information Design Principles</title>
		<link>http://tc.eserver.org/24873.html</link>
		<guid>http://tc.eserver.org/24873.html</guid>
		<description>Describes a process for improving interface usability.</description>
	</item>
	<item>
		<title>Don&apos;t Feed the Subject Matter Experts</title>
		<link>http://tc.eserver.org/24739.html</link>
		<guid>http://tc.eserver.org/24739.html</guid>
		<description>I found myself wondering; was there any statistically  significant relationship between feeding and cooperation?</description>
	</item>
	<item>
		<title>Scientific Documentation: Learning from Journal Articles</title>
		<link>http://tc.eserver.org/24637.html</link>
		<guid>http://tc.eserver.org/24637.html</guid>
		<description>Suggests that writers of technical manuals could learn a thing or two about usability from the consistent form of scientific journal articles.</description>
	</item>
	<item>
		<title>Editing Web Pages: A Second Look</title>
		<link>http://tc.eserver.org/24202.html</link>
		<guid>http://tc.eserver.org/24202.html</guid>
		<description>How to edit Web pages--with revision tracking--using Microsoft Word.</description>
	</item>
	<item>
		<title>Taking Advantage of &quot;Automatic Text&quot; Features</title>
		<link>http://tc.eserver.org/24203.html</link>
		<guid>http://tc.eserver.org/24203.html</guid>
		<description>I recently began looking for a way to eliminate the need to manually perform small repetitive tasks. In Microsoft Word, that way is through the software’s &apos;automatic text&apos; features: Autoformat, Autocorrect, and Autotext. In this article, I’ll focus on these features in Word, but will also discuss how to lighten the work load in other software.</description>
	</item>
	<item>
		<title>PowerPoint Presentations: A Speaker&apos;s Guide</title>
		<link>http://tc.eserver.org/24192.html</link>
		<guid>http://tc.eserver.org/24192.html</guid>
		<description>Vinton Cerf, one of the founders of the Internet, reportedly parodied the well-known quote about the cost of attaining power, observing that if power corrupts, &apos;PowerPointcorrupts absolutely.&apos; Pointed though Cerf’s statement is, it places far too much blame on the software. After all, speakers must take some responsibility for their presentations. As in any other form of communication, you must decide what you’re going to say and how you plan to say it. But once that’s done, you need to use all the skills at your disposal to make the chosen medium work for you.</description>
	</item>
	<item>
		<title>Speaking in Tongues:  Dealing with Word&apos;s Dictionaries</title>
		<link>http://tc.eserver.org/24179.html</link>
		<guid>http://tc.eserver.org/24179.html</guid>
		<description>Word has powerful language tools, but if you don&apos;t understand how they work, even a simple spellcheck can pose problems. In this article, I&apos;ll discuss how to take full advantage of Word&apos;s language settings.</description>
	</item>
	<item>
		<title>Implementing On-Screen Editing</title>
		<link>http://tc.eserver.org/24172.html</link>
		<guid>http://tc.eserver.org/24172.html</guid>
		<description>On-screen editing offers obvious advantages over paper editing, including greater accuracy, shorter turnaround times, and improved consistency. Because authors don’t have to retype handwritten edits, there’s less risk of misreading  or  missing  corrections. Moreover, the edits have already been typed and spellchecked, so no new typos are introduced. Most editors can also enter corrections faster with a keyboard than with a pen, particularly when complex edits require restructuring of the document or extensive rewording, and eliminating the retyping phase further reduces turnaround times. Last but not least, using the search tools makes it easier to achieve consistency in long or complex documents.</description>
	</item>
	<item>
		<title>A Programming Primer</title>
		<link>http://tc.eserver.org/24164.html</link>
		<guid>http://tc.eserver.org/24164.html</guid>
		<description>The easiest way to gain the respect of programmers is to learn to speak their language. If you can do that, they’ll inevitably recognize the effort you&apos;ve invested in learning to appreciate their work and will treat you as an equal thereafter. With that goal in mind, I present this glossary of key programming terms you should master.</description>
	</item>
	<item>
		<title>Overcoming Objections to Onscreen Editing</title>
		<link>http://tc.eserver.org/23742.html</link>
		<guid>http://tc.eserver.org/23742.html</guid>
		<description>Although onscreen editing has been available for many years, it remains underused in many workplaces. Editors offer many reasons for their reluctance to embrace this technology, and by understanding these reasons, it becomes possible to mitigate the problems and help editors begin using the technology. By doing so, managers can implement a process that is more efficient for both the editor and the authors being edited.</description>
	</item>
	<item>
		<title>Streamlining an Interface Using Information Design Principles</title>
		<link>http://tc.eserver.org/23753.html</link>
		<guid>http://tc.eserver.org/23753.html</guid>
		<description>&apos;Information design&apos; is the art and science of understanding problems from the product user&apos;s standpoint, and using that understanding to select an appropriate mix of graphics&#xD;and text that supports the design and presents necessary&#xD;information appropriately. This progression topic&#xD;presents a simple, iterative way to examine a design&#xD;problem, and uses that approach to solve a common&#xD;design problem (using space more efficiently in a software&#xD;interface).</description>
	</item>
	<item>
		<title>Avoiding Repetitive-Stress Injuries: A Guide for the Technical Communicator</title>
		<link>http://tc.eserver.org/23278.html</link>
		<guid>http://tc.eserver.org/23278.html</guid>
		<description>Writers and editors in particular put in an awful lot of  miles at the keyboard every day. One serious problem is the risk of so-called  &apos;repetitive-stress injury&apos; (RSI)--simplistically,  any injury that results from overuse of a body part without  giving it time to recover. In fact, &apos;overuse  injury&apos; is probably a more immediately obvious term, and given how much time many of us spend using computers, overuse is indeed a risk.</description>
	</item>
	<item>
		<title>Just the FAQs</title>
		<link>http://tc.eserver.org/22792.html</link>
		<guid>http://tc.eserver.org/22792.html</guid>
		<description>Offers advice on creating effective FAQ documents.</description>
	</item>
	<item>
		<title>Getting Involved in Interface Design</title>
		<link>http://tc.eserver.org/22576.html</link>
		<guid>http://tc.eserver.org/22576.html</guid>
		<description>Describes a four-step process to help technical writers gain influence over product design.</description>
	</item>
	<item>
		<title>Designing a Telephone-Based User Interface</title>
		<link>http://tc.eserver.org/21648.html</link>
		<guid>http://tc.eserver.org/21648.html</guid>
		<description>Explains how technical communicators, drawing on their experience designing Web sites and software interfaces, can help design effective interfaces for telephone-answering and call-routing systems.</description>
	</item>
	<item>
		<title>Practical and Effective Metrics</title>
		<link>http://tc.eserver.org/21647.html</link>
		<guid>http://tc.eserver.org/21647.html</guid>
		<description>Discusses several issues involved in developing metrics that measure performance and identify specific problems affecting performance.</description>
	</item>
	<item>
		<title>Practical Tips for Improving Web Site and Intranet Usability</title>
		<link>http://tc.eserver.org/21033.html</link>
		<guid>http://tc.eserver.org/21033.html</guid>
		<description>There&apos;s a large body of theory available to guide Web and intranet&#xD;design, but concentrating too much on theory sometimes leads designers&#xD;to overlook basic things they can do to improve the usability of sites. This article&#xD;presents, in no particular order, seven simple ways to make your Web site or&#xD;intranet more usable.</description>
	</item>
	<item>
		<title>&quot;Prescriptive&quot; Audience Analysis: Moving Beyond the Purely Descriptive</title>
		<link>http://tc.eserver.org/20542.html</link>
		<guid>http://tc.eserver.org/20542.html</guid>
		<description>Editing and writing both require an understanding of our audience, because without that knowledge, we can&apos;t shape our words to help them easily grasp difficult concepts. To understand our audience, we do what all writers and editors do, whether consciously or unconsciously: We create an image of our audience that guides our choice of words, images, and metaphors. This image is variously known as a &apos;stereotype&apos; or a &apos;persona&apos;. Keeping that image in mind as we work helps us satisfy the reader&apos;s needs, but if we&apos;re not careful, it can also cause us to waste valuable time collecting information that doesn&apos;t really help us communicate.</description>
	</item>
	<item>
		<title>Audience Analysis: Looking Beyond the Superficial</title>
		<link>http://tc.eserver.org/19961.html</link>
		<guid>http://tc.eserver.org/19961.html</guid>
		<description>In performing an audience analysis, it’s easy to focus on simple, obvious issues such as the differences between men and women. In fact, men and women&#xD;have more similarities than differences when it comes&#xD;to most of the things that technical communicators&#xD;document. A discussion of some seemingly obvious&#xD;differences between men and women illustrates how&#xD;to look beyond superficial issues to find the truly&#xD;important differences.</description>
	</item>
	<item>
		<title>Technology Transfer: Science and Industry Working Together</title>
		<link>http://tc.eserver.org/19960.html</link>
		<guid>http://tc.eserver.org/19960.html</guid>
		<description>Science and technology are intimately related. The technology sector that drives the modern economy would never have arisen without basic scientific research, and that research is now being funded by&#xD;companies seeking to gain a technological edge over&#xD;their competitors. Despite this mutual dependence,&#xD;technical communication has taken different paths in&#xD;science and industry. Technology transfer, the&#xD;communication of research results to an audience&#xD;that can implement the results, bridges these two&#xD;solitudes and strongly resembles much of the work&#xD;done by other technical communicators.</description>
	</item>
	<item>
		<title>Structure Paves the Way Online</title>
		<link>http://tc.eserver.org/19910.html</link>
		<guid>http://tc.eserver.org/19910.html</guid>
		<description>What I&apos;ve called structure in this series actually has various other names, the most familiar of which are probably &apos;hierarchy&apos; or &apos;information architecture.&apos; Whichever word you use, structure encapsulates the relationships between the components of a site that visitors will use to navigate to the information they seek. Structure is simple enough to define, but can be devilishly tricky to create. A successful site structure must create what psychologists refer to as a schema: A mental model that visitors can use to understand where you&apos;ve hidden the content.</description>
	</item>
	<item>
		<title>Successful Online Presence: Relevance</title>
		<link>http://tc.eserver.org/19911.html</link>
		<guid>http://tc.eserver.org/19911.html</guid>
		<description>&apos;Relevance&apos; means the ability of a site to present information that satisfies the visitor&apos;s immediate needs; if it doesn&apos;t meet those needs, then it&apos;s (by definition) irrelevant to that visitor. Obviously, our goal in designing a site is to make its content as relevant as possible to visitors. The key to understanding what makes something relevant lies in recognizing that relevance is never a static, unchanging aspect of the content you provide: Some things must change regularly and some must stay the same, but some may fall into both categories at different times. Knowing which information falls into each category, and when, can be tricky, because it relies on sound knowledge of the people who will be using your information and whose needs you&apos;ll be satisfying. Unfortunately, those needs change.</description>
	</item>
	<item>
		<title>Editing Tests for Writers</title>
		<link>http://tc.eserver.org/19682.html</link>
		<guid>http://tc.eserver.org/19682.html</guid>
		<description>Times are hard, and many former writers are pounding the dirt looking for work. Some who have extensive experience with peer review or revising documents are&#xD;expanding their job searches to include careers as editors. However, new editors often face a barrier to entering the profession: the editing test. Rather than taking a chance on unproven candidates, publishers and other clients typically ask&#xD;would-be editors to review short documents that test three main aspects of an editor’s skills.</description>
	</item>
	<item>
		<title>Editing Web Pages</title>
		<link>http://tc.eserver.org/19708.html</link>
		<guid>http://tc.eserver.org/19708.html</guid>
		<description>Investigates some of the specific issues involved in editing Web sites, an increasingly common task for us wage slaves and an enormous opportunity for freelancers.</description>
	</item>
	<item>
		<title>Internet Resources for Editors</title>
		<link>http://tc.eserver.org/19692.html</link>
		<guid>http://tc.eserver.org/19692.html</guid>
		<description>This month, I’ll depart slightly from my usual topic and focus on onscreen practices that aren’t actual edits—but that support activities such as fact-checking that we must perform while editing. Specifically, I’ll describe how to use the Internet as a research tool to improve the quality of your editing.</description>
	</item>
	<item>
		<title>Keyboard Shortcuts and Other Tricks</title>
		<link>http://tc.eserver.org/19663.html</link>
		<guid>http://tc.eserver.org/19663.html</guid>
		<description>This column focuses on using a computer to increase the effectiveness (both the productivity and the quality) of editing manuscripts, with an emphasis on tools and techniques rather than issues of grammar and usage.</description>
	</item>
	<item>
		<title>Devil&apos;s Advocate</title>
		<link>http://tc.eserver.org/19590.html</link>
		<guid>http://tc.eserver.org/19590.html</guid>
		<description>The problem with wearing the technical support hat, I discovered, is that it tends to slip over your ears. Over time, you stop hearing the shrill cries of the users you&apos;re supporting, then you stop listening so carefully, then you stop speaking the same language as they do. And since you&apos;re busy putting out fires all over the building, who has time to start listening again? Problem is, once you no longer empathize with &apos;them,&apos; you forget that they&apos;ve got their own unending stream of crises to deal with. But if you want to tame those devils, you&apos;re going to need to take the time to understand their needs as well as you understand your own, and find a solution that meets both sets of needs. More often than you&apos;d suspect, the result is a win-win solution.</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>Automating Your Edits</title>
		<link>http://tc.eserver.org/15092.html</link>
		<guid>http://tc.eserver.org/15092.html</guid>
		<description>Suggests several uses of Microsoft Word&apos;s macro capabilities to help editors improve their speed and consistency. Macros, for example, are customized keystroke commands.</description>
	</item>
	<item>
		<title>Editing with Style (Sheets)</title>
		<link>http://tc.eserver.org/15126.html</link>
		<guid>http://tc.eserver.org/15126.html</guid>
		<description>Offers editors tips on creating and using style sheets.</description>
	</item>
	<item>
		<title>File-Exchange and Workflow Issues</title>
		<link>http://tc.eserver.org/15132.html</link>
		<guid>http://tc.eserver.org/15132.html</guid>
		<description>Suggests ways that editors can organize multiple versions of articles and avoid the pitfalls of transferring electronic files over the Internet.</description>
	</item>
	<item>
		<title>Getting Reviewers to Review</title>
		<link>http://tc.eserver.org/15139.html</link>
		<guid>http://tc.eserver.org/15139.html</guid>
		<description>Presents ten humorous suggestions for technical writers on how to persuade reviewers of documentation to do their jobs.</description>
	</item>
	<item>
		<title>Prove Your Worth!</title>
		<link>http://tc.eserver.org/15177.html</link>
		<guid>http://tc.eserver.org/15177.html</guid>
		<description>Describes ten arguments technical writers can use to demonstrate their importance to their employers.</description>
	</item>
	<item>
		<title>Seek and Ye Shall Find--And Replace</title>
		<link>http://tc.eserver.org/15188.html</link>
		<guid>http://tc.eserver.org/15188.html</guid>
		<description>Offers tips on using search and replace commands in word processors.</description>
	</item>
	<item>
		<title>Shakespearean Technical Writing</title>
		<link>http://tc.eserver.org/15193.html</link>
		<guid>http://tc.eserver.org/15193.html</guid>
		<description>Shows how technical writers can make better use of literary devices such as metaphor and foreshadowing to produce better, and more enjoyable, documentation.</description>
	</item>
	<item>
		<title>Spelling and Grammar Checkers</title>
		<link>http://tc.eserver.org/15198.html</link>
		<guid>http://tc.eserver.org/15198.html</guid>
		<description>Provides a few suggestions about how writers and editors can use spelling and grammar checkers more effectively.</description>
	</item>
	<item>
		<title>Why Edit On Screen?</title>
		<link>http://tc.eserver.org/15229.html</link>
		<guid>http://tc.eserver.org/15229.html</guid>
		<description>Provides a thorough introduction to the practices of on-screen editing, including how to make corrections, insert questions and suggestions, and communicate the results to the author.</description>
	</item>
	<item>
		<title>Nostradamus the Technical Writer</title>
		<link>http://tc.eserver.org/14938.html</link>
		<guid>http://tc.eserver.org/14938.html</guid>
		<description> Sue Gallagher, a longtime technical writer, once posed the following riddle: &apos;How are science fiction writers like technical writers?&apos; The answer, of course, is that both professions write about things we imagine will happen in the future, but that often don&apos;t--as anyone who&apos;s documented software or hardware for a startup company can confirm. With the new year arriving soon, I find my thoughts turning to a different form of science fiction: Eschatology, the art of predicting the future. It occurs to me that the role of technical writer as prognosticator has a proud history, and one that dates back to the days of Nostradamus the Prophet, one of the most famous eschatologists.</description>
	</item>
	<item>
		<title>Cheating the Quality Triangle</title>
		<link>http://tc.eserver.org/14695.html</link>
		<guid>http://tc.eserver.org/14695.html</guid>
		<description>Hart discusses ways that technical communicators can simultaneously improve the quality of their documentation, increase the speed with which it is produced, and lessen the costs of producing it.</description>
	</item>
	<item>
		<title>Effective Interviewing: Get the Story</title>
		<link>http://tc.eserver.org/14612.html</link>
		<guid>http://tc.eserver.org/14612.html</guid>
		<description>In this article, Geoffrey Hart offers the following tips on how to interview a subject matter expert (SME) for reliable, comprehensive, timely information:</description>
	</item>
	<item>
		<title>Identifying Additions and Deletions, Part I: Using Compatible Software</title>
		<link>http://tc.eserver.org/14722.html</link>
		<guid>http://tc.eserver.org/14722.html</guid>
		<description>Hart describes the problems and possibilities of Microsoft Word&apos;s Track Changes feature.</description>
	</item>
	<item>
		<title>Identifying Additions and Deletions, Part II: Incompatible Software</title>
		<link>http://tc.eserver.org/14736.html</link>
		<guid>http://tc.eserver.org/14736.html</guid>
		<description>Hart describes the difficulties of viewing electronic edits when the editor and the author are using incompatible software, and offers tips for working around these difficulties.</description>
	</item>
	<item>
		<title>Special Needs: Editing Tables and Graphics</title>
		<link>http://tc.eserver.org/14759.html</link>
		<guid>http://tc.eserver.org/14759.html</guid>
		<description>Hart explains the difficulties of editing tables and graphics on-screen.</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>Substantive Editing: Break It to Them Gently</title>
		<link>http://tc.eserver.org/14772.html</link>
		<guid>http://tc.eserver.org/14772.html</guid>
		<description>Emphasizing the need for clear, polite communication between editors and authors, Hart demonstrates how editors should address imprecise wording, ineffective organization, and other substantive issues.</description>
	</item>
	<item>
		<title>Conquering the Cubicle Syndrome</title>
		<link>http://tc.eserver.org/14498.html</link>
		<guid>http://tc.eserver.org/14498.html</guid>
		<description>Cubicles aren&apos;t really physical walls--they&apos;re a state of mind. In effect, it&apos;s the belief that you&apos;ve been compartmentalized and isolated that defines the cubicle. The four-sided, felt-lined livestock pens loved by evil office managers everywhere hides the truth: cubicles are all about being isolated and treated as part of the building infrastructure, whatever the physical location of your chair.</description>
	</item>
	<item>
		<title>Dealing with Difficult Employees in the Technical Communication Workplace</title>
		<link>http://tc.eserver.org/14497.html</link>
		<guid>http://tc.eserver.org/14497.html</guid>
		<description>Some of the more intractable problems we face on the job are the human ones. But cranky though Microsoft Word often seems, most of its blowups are at least predictable; humans are anything but. The worst problems can arise when you find yourself in a situation where power relationships come into play, which is often the case when you&apos;re managing another employee and responsible for their work and their on-the-job behavior. &#xD;&#xD;For a variety of reasons, technical communicators are often seen as &apos;difficult&apos; or &apos;problem&apos; employees--this means that co-workers tend to complain about us and insist that our managers correct our behavior. Unfortunately, we often work in high-stress environments that make it difficult for us to work calmly and difficult for colleagues to work with us peacefully. Many communicators complain that developers and other subject matter experts (SMEs) don&apos;t bother to understand what we do and thus, don&apos;t respect our work. As a result, they often consider meeting their own deadlines far more important than helping us do our work, and when we must ask them to provide the information we need to complete our documentation or to review draft documents, we don&apos;t get what we need. &#xD;&#xD;The result? We&apos;re forced to nag, and that can get us labeled as problems, not colleagues.</description>
	</item>
	<item>
		<title>The Five W&apos;s of Online Help</title>
		<link>http://tc.eserver.org/14256.html</link>
		<guid>http://tc.eserver.org/14256.html</guid>
		<description>For decades, journalists have used a proven approach called the &apos;Five W&apos;s&apos; to answer the questions that the readers of newspaper articles most commonly want writers to answer. The questions are sufficiently useful that they can easily be applied outside newspaper writing, and I&apos;ve already written about this in the context of audience analysis (Hart 1996). In this article, I&apos;ll show you how you can use these questions to develop more useful online help. &#xD;&#xD;Each of the five W&apos;s is a simple question that starts with the letter W: Why, Who, What, Where, and When. Some authorities add a sixth question, &apos;How,&apos; to this list, but &apos;how to&apos; information generally fits under what, where, or when, depending on the nature of the information. Users of online help can benefit greatly from the proven journalistic approach if we can answer these same five questions for each help topic that we create. In the remainder of this article, I&apos;ll provide an example of a failure to ask these questions, show how asking these five questions could have prevented this failure, and provide examples of typical questions we should be asking. Please note that, although I&apos;ve presented these five questions in an order that seems logical to me, in practice the approach becomes iterative: It doesn&apos;t much matter where you begin, since answering one question often reveals important aspects of the other questions that you&apos;d not yet considered.</description>
	</item>
	<item>
		<title>Top Five Tips for Starting a New Job</title>
		<link>http://tc.eserver.org/14145.html</link>
		<guid>http://tc.eserver.org/14145.html</guid>
		<description>This article offers five tips that can help you get off to a good start in your new job.</description>
	</item>
	<item>
		<title>A Day in the Life</title>
		<link>http://tc.eserver.org/13941.html</link>
		<guid>http://tc.eserver.org/13941.html</guid>
		<description>If it&apos;s a good day, you arrive at work around seven o&apos;clock, grateful for having missed the morning rush hour. Today&apos;s not a good day, so instead you crawl out from under the shakey shelf in your cubicle, glad that neither your cranky, obsolete computer nor the stale glass of Jolt cola fell on you during the night. Don&apos;t laugh; it&apos;s happened before, and putting yourself back together again cost you an hour of sleep you desperately needed. You smell the stench of cold pizza, and what&apos;s really appalling is that you&apos;re not sure whether it&apos;s coming from your shirt, your breath, or a hidden cache somewhere in the cubicle under piles of documentation someone left you to review. That&apos;s not your problem right now.</description>
	</item>
	<item>
		<title>Content, Structure, and Relevance: The Ploy&apos;s the Thing</title>
		<link>http://tc.eserver.org/13827.html</link>
		<guid>http://tc.eserver.org/13827.html</guid>
		<description>Attracting and retaining an audience on the Web requires the skills of a playwright, and like a good playwright, you have to be able to skillfully combine three inseparable elements: Content, structure, and relevance. &#xD;&#xD;Content is one of the hot buzzwords of the new millennium. Without content, your site can be aptly described by MacBeth&apos;s despairing lament: &apos;A tale told by an idiot, full of sound and fury, signifying nothing.&apos; (Substitute &apos;Flash and Shockwave&apos; for &apos;sound and fury&apos; and you&apos;ve got the picture.) Despair describes the second of these three components, because if you don&apos;t create a site structure that helps people find all that fine content you&apos;ve created, they&apos;ll give up and go elsewhere--or go mad with the effort of searching, with results every bit as tragic for your job prospects as &apos;the Scottish play&apos; is reputed to be for actors. And the part about &apos;signifying nothing&apos;? If the content that visitors do eventually find isn&apos;t relevant to their needs, they&apos;re not going to come back any more than Lady MacBeth will.</description>
	</item>
	<item>
		<title>Designing for the Other Half</title>
		<link>http://tc.eserver.org/13830.html</link>
		<guid>http://tc.eserver.org/13830.html</guid>
		<description>Whenever we design something, we confront the problem of how to account for differences in our audience&apos;s needs, skills, and background. We accept that audiences are diverse and include people with widely varying skill levels, physical abilities, background knowledge, and cultural differences. They range from power users--who could teach us something about the product--to the greenest of neophytes. Some have significant visual or other limitations. Some can understand the most abstract concepts, whereas others wouldn&apos;t recognize a metaphor if it bit them. And some come from very different cultures, such as the gap that divides Macintosh and Windows users. &#xD;&#xD;Unfortunately, our knowledge of the more obvious differences sometimes leads us to make ridiculous assumptions, such as considering women and men to be different audiences, or believing that it&apos;s impossible to produce something that works equally well for experienced and new users.</description>
	</item>
	<item>
		<title>Nothing but .Net? Nyet!</title>
		<link>http://tc.eserver.org/13829.html</link>
		<guid>http://tc.eserver.org/13829.html</guid>
		<description>Given Microsoft&apos;s track record, it would seem awfully foolish for me to bet against them and those who will follow their lead, and the idea does seem superficially reasonable. But despite this, I predict that the ASP aspects of .Net won&apos;t work nearly so well as Microsoft hopes and may even fail outright. The problem with Microsoft&apos;s ASP approach? The strategy is driven more strongly by economics and a fear of competition from smaller, more nimble ASPs than by customer needs and habits. </description>
	</item>
	<item>
		<title>Hart’s Law: The Magical Number Three, Plus or Minus Zero</title>
		<link>http://tc.eserver.org/13714.html</link>
		<guid>http://tc.eserver.org/13714.html</guid>
		<description>George Miller, infamous for his &apos;magical number seven, plus or minus two,&apos; somehow missed an even more important principle of how the world works: no matter how clever we think we are, it still takes us three tries to get anything approximately right. Although most of us have proven beyond a shadow of doubt our ability to blunder around and take many more than three tries, the overwhelming majority of us get it nearly right on the third try.</description>
	</item>
	<item>
		<title>Privacy Means Never Having to Say You&apos;re Sorry</title>
		<link>http://tc.eserver.org/13488.html</link>
		<guid>http://tc.eserver.org/13488.html</guid>
		<description>For those of us who regularly visit certain Web sites, the value of identifying ourselves to those sites grows quickly and painfully obvious: Accepting cookies from a Web site could potentially eliminate endlessly retyping our personal information, memorizing yet another login password, repeatedly re-customizing how a site responds to us, and enduring irrelevant information such as untargeted banner ads. But even those of us who appreciate the value of sharing personal information with Web sites and their designers have grown increasingly uncomfortable with the potential for abuse inherent in having confidential information about our identities and preferences broadly available. Even if a site isn&apos;t cracked and our private information stolen--always a risk on the Web--the site owner is bound to sell the information to commercial mailing lists, thereby guaranteeing us a lifetime supply of junk mail. Worst of all, we won&apos;t even be able to burn that junk on cold winter nights to stay warm.</description>
	</item>
	<item>
		<title>Reach Out and Touch Someone</title>
		<link>http://tc.eserver.org/13365.html</link>
		<guid>http://tc.eserver.org/13365.html</guid>
		<description>Providing the right combination of options for each individual member of our audience through a single online document (or online document set) would be tricky indeed, but consider the potential of being able to do so--the potential for providing flexible information. Users could quickly obtain the information needed, in the medium that suits them, with the appropriate level of detail right at their fingertips. An unobtainable utopia? Perhaps not.</description>
	</item>
	<item>
		<title>Nobody Reads Manuals, Do They?</title>
		<link>http://tc.eserver.org/12941.html</link>
		<guid>http://tc.eserver.org/12941.html</guid>
		<description>We technical writers have a mantra that we mutter quietly whenever someone asks an obvious question about how to use our software: &apos;RTFM.&apos; But though Reading The (ahem) &apos;Fine&apos; Manual would often solve the problem--assuming the purchaser actually received one of those increasingly rare printed manuals with the software--only technical writers seeking inspiration on how to do their own jobs better can be relied upon to read product documentation. To make matters worse, many of us admit that we&apos;d rather play with a product, hoping to figure out what to do, than use the documentation.</description>
	</item>
	<atom:link href="http://tc.eserver.org/authors/Hart,_Geoffrey_J.S.xml" rel="self" type="application/rss+xml"/>
</channel>
</rss>