<?xml version="1.0" encoding="utf-8" ?><rss version="2.0" xmlns:atom="http://www.w3.org/2005/Atom">
<channel>
	<title>TECHWR L</title>	<link>http://tc.eserver.org/publisher/TECHWR-L</link>
	<description>A listing of works published by TECHWR L 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>TECHWR L</title>
		<link>http://tc.eserver.org/dir/TECHWR-L</link>
	</image>
	<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>Making the Mentor Partnership Work: Part Two (For the Mentor)</title>
		<link>http://tc.eserver.org/32229.html</link>
		<guid>http://tc.eserver.org/32229.html</guid>
		<description>When you act as a mentor, you&apos;re agreeing to serve as an ad hoc advisor and sounding board to someone less experienced in the career world than you.</description>
	</item>
	<item>
		<title>Making the Mentor Partnership Work: Part One (for the Mentee)</title>
		<link>http://tc.eserver.org/32230.html</link>
		<guid>http://tc.eserver.org/32230.html</guid>
		<description>Few people enter the work world with a ready-made mentor. Instead, you need to actively pursue finding one--and take good care of her once you find her.</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>Tech Writers, Grammar, and the Prescriptive Attitude</title>
		<link>http://tc.eserver.org/32043.html</link>
		<guid>http://tc.eserver.org/32043.html</guid>
		<description>Prescriptive grammar is useful for teaching English as a second language, but it has little value for the practicing writer. Clinging to it may provide emotional security, but only at the expense of making writing harder than it needs to be. The culture-wide devotion to it will not be changed in a moment. But conscientious writers can at least change their own habits, and make life easier for themselves.</description>
	</item>
	<item>
		<title>Technical Writing: Look Before You Leap</title>
		<link>http://tc.eserver.org/32035.html</link>
		<guid>http://tc.eserver.org/32035.html</guid>
		<description>To many aspiring novelists, poets and journalists, working as a technical writer seems like the perfect stepping stone to their dreams. After all, you&apos;ll be paid to put pen to paper--something every wannabe writer dreams of. So what if it isn&apos;t the Great American Novel? You&apos;ll still have time for your own writing in your off hours. Or will you?&#xD;&#xD;If you are thinking about transitioning from your current non-writing position to technical writing because it&apos;s a hot market, you like technology, and/or you want to round out your freelance portfolio, you&apos;re on the right track. But if your main reason for considering the technical arena is that you enjoy writing, then re-evaluate your decision.</description>
	</item>
	<item>
		<title>Conducting Effective Team Technical Reviews</title>
		<link>http://tc.eserver.org/31975.html</link>
		<guid>http://tc.eserver.org/31975.html</guid>
		<description>Mention team technical reviews to a group of tech writers and chances are good that you will either get a loud, collective groan, or the group will vie to tell the best review horror story. On the one hand, technical reviews are a vital part of our jobs because they help us to produce high quality product documents. On the other hand, technical reviews gone wrong are the bane of our existence. The good news is that we have the power to conduct consistently effective technical reviews.&#xD;&#xD;This article summarizes why we do reviews and what often goes wrong in reviews, and then summarizes steps to take before, during, and after technical reviews that can help you conduct effective team technical reviews. Although your process and team may differ from what&apos;s described here, you can apply the information in part or in whole to improve your current review process.</description>
	</item>
	<item>
		<title>Networking Your Way to Success</title>
		<link>http://tc.eserver.org/31964.html</link>
		<guid>http://tc.eserver.org/31964.html</guid>
		<description> You don&apos;t have to spend hours making cold calls or squander money on invisible advertisements in order to find new clients. In fact, savvy businesspeople--technical writers included--know the best way to expand your client base is by leveraging the resources you already have.&#xD;&#xD;You might ask, &quot;What resources?&quot; Well, pull out your personal address book. This database of contacts--friends, relatives, and co-workers--is a gold mine when prospecting for business. By knowing how and who to ask, you can soon have as much business as you can handle!</description>
	</item>
	<item>
		<title>Take Control: What To Do When Your Job Interviewers Are Tongue-Tied</title>
		<link>http://tc.eserver.org/31966.html</link>
		<guid>http://tc.eserver.org/31966.html</guid>
		<description>When interviewing with a technical writing manager or with others who are familiar with the role of technical writers, the interview process can be a natural and productive information exchange. In such cases, interviewers can often readily define needs, assess a candidate&apos;s experience and qualifications, peruse a portfolio with their needs in mind, and initiate questions in the interview that are relevant to the position and candidate. But, what happens when interviewers are less familiar--or unfamiliar--with the role of technical writers or the technical writing position they seek to fill?</description>
	</item>
	<item>
		<title>Taking Your Show on the Road: Constructing and Using an Online Portfolio</title>
		<link>http://tc.eserver.org/31967.html</link>
		<guid>http://tc.eserver.org/31967.html</guid>
		<description>I had considered putting my makeshift portfolio on floppy disk. Lack of disk space and a widely-used viewing format made the idea impractical, but technology had moved on in six years, and neither problem existed now. Why not put my portfolio on CD?</description>
	</item>
	<item>
		<title>Word Master Documents</title>
		<link>http://tc.eserver.org/31968.html</link>
		<guid>http://tc.eserver.org/31968.html</guid>
		<description>This guide to dealing with the trials and tribulations of Master documents is virtually guaranteed to save whatever fragments of sanity you may have left as you deal with Master documents.</description>
	</item>
	<item>
		<title>Your Own Best Ad: Promoting Yourself as a Contractor</title>
		<link>http://tc.eserver.org/31965.html</link>
		<guid>http://tc.eserver.org/31965.html</guid>
		<description>Most contractors can&apos;t afford the time or money to advertise. If they can, there probably aren&apos;t many places where an ad would reach potential clients anyway. By default, then, your reputation as a contractor rests on your behavior at each job. Leave a happy client behind at the end of each job, and you&apos;ll soon start a word-of-mouth campaign that will keep you employed the rest of your working life.</description>
	</item>
	<item>
		<title>Screen Captures 102</title>
		<link>http://tc.eserver.org/29885.html</link>
		<guid>http://tc.eserver.org/29885.html</guid>
		<description>An introduction to generating screen captures from Microsoft Windows computers. Consider your deliverables; where is the screen capture going to be used and seen by the customer? This helps you determine how you need to create your screen capture.</description>
	</item>
	<item>
		<title>Surviving Life as a Contractor</title>
		<link>http://tc.eserver.org/28194.html</link>
		<guid>http://tc.eserver.org/28194.html</guid>
		<description>One of the biggest temptations as an independent is to watch the money roll in and just focus on the number in your bank account. If you are incorporated, then you know the importance of strict accounting; out of that number, you have to take into account corporate taxes as well as personal income tax. However, if you are a sole proprietor or undeclared, you only have to take into consideration personal tax withholdings and the other associated costs (insurance, retirement, etc.), right? Wrong. In both cases, it&apos;s important to set aside a portion of your earnings in a savings account for rainy days.</description>
	</item>
	<item>
		<title>Writing Software Requirements Specifications</title>
		<link>http://tc.eserver.org/27447.html</link>
		<guid>http://tc.eserver.org/27447.html</guid>
		<description> For technical writers who haven&apos;t had the experience of designing software requirements specifications (SRSs, also known as software functional specifications or system specifications) templates or even writing SRSs, they might assume that being given the opportunity to do so is either a reward or punishment for something they did (or failed to do) on a previous project. Actually, SRSs are ideal projects for technical writers to be involved with because they lay out the foundation for the development of a new product and for the types of user documentation and media that will be required later in the project development life cycle. It also doesn&apos;t hurt that you&apos;d be playing a visible role in contributing to the success of the project.</description>
	</item>
	<item>
		<title>Look Out Hollywood? Here Come the Technical Writers</title>
		<link>http://tc.eserver.org/26955.html</link>
		<guid>http://tc.eserver.org/26955.html</guid>
		<description>Have you heard it said that technical writing quashes your ability to be a creative writer? Do you ever think that you&apos;ve trained yourself to do your day job so well that you can no longer produce something in an artistic vein in your spare time? If so, you might want to consider trying your hand at screenwriting!&#xD;&#xD;There are many reasons why someone who excels at technical writing might find screenwriting to be a good creative outlet.</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>Social Rules for Creating a Style Guide</title>
		<link>http://tc.eserver.org/26744.html</link>
		<guid>http://tc.eserver.org/26744.html</guid>
		<description>Creating a style guide may initially seem like a terminology affair (&apos;option button&apos; or &apos;radio button&apos; - pick one), but the real challenge lies in persuading the department to adopt new style principles. Some writers will feel threatened by change, and respond in bizarre and unpredictable ways. Whisper campaigns and ambushes may lie in wait for you. Beware, innovative editor! Before you even think about the literary details of style, prepare to do battle with the true Goliaths and Grendyls: the department itself. By following these five rules below, you can avoid an unexpected apocalypse when you reveal the new guide.</description>
	</item>
	<item>
		<title>The Seven Deadly Sins of Tech Writing Burnout</title>
		<link>http://tc.eserver.org/26617.html</link>
		<guid>http://tc.eserver.org/26617.html</guid>
		<description>Beware the need for a vacation when the normally exciting and always rewarding nature of your technical writing job begins to lead you astray.</description>
	</item>
	<item>
		<title>Tech Writers in Startup Environments</title>
		<link>http://tc.eserver.org/26616.html</link>
		<guid>http://tc.eserver.org/26616.html</guid>
		<description>Responses from an inquiry about the type of writer most likely to do well in a start-up environment and what management needs to do to keep those people committed and dedicated for the long-term.</description>
	</item>
	<item>
		<title>Tech Writers, Grammar, and the Prescriptive Attitude</title>
		<link>http://tc.eserver.org/26615.html</link>
		<guid>http://tc.eserver.org/26615.html</guid>
		<description>Many tech writers do not see grammar as a set of conventions to help them write clearly. Instead, to judge by the wording of the questions and responses, they see grammar as a set of unchanging rules that can provide definitive answers in every situation.</description>
	</item>
	<item>
		<title>Corporate Communication Boring? Jazz It Up With Case Studies!</title>
		<link>http://tc.eserver.org/26599.html</link>
		<guid>http://tc.eserver.org/26599.html</guid>
		<description>Employer handbooks, product specifications, employer policies, administrative procedures, data base usage: are your eyes glazed over yet? Let’s face it. Few of us enjoy reading these bits of corporate communication and we all pity the poor souls who have to write them. What if you are one of those poor souls? Companies do have a responsibility to communicate effectively with their employees, managers, and customers. Readers need to get the message, because missing it can lead to falling profits, lower morale, or worse. So what do you do? One way to spice up corporate communication is by using case studies. While helping the reader understand and comply with company policy, practice, and product use, you get to have some fun, too.</description>
	</item>
	<item>
		<title>Local Input Critical for Global Web Content Success</title>
		<link>http://tc.eserver.org/26602.html</link>
		<guid>http://tc.eserver.org/26602.html</guid>
		<description>A successful web site puts its customers first. The first question your customers ask when they visit your web site is, &apos;So, what do you have for me today?&apos; Let’s face it. People on the web are only out for themselves. They come to your site, and you have a time window of less than 30 seconds to convince them to stay.</description>
	</item>
	<item>
		<title>A Technical Communicator&apos;s Pro Bono Guide to Attorneys</title>
		<link>http://tc.eserver.org/26598.html</link>
		<guid>http://tc.eserver.org/26598.html</guid>
		<description>While our job requirements and responsibilities are ever-changing, our allies remain the same. They include one crucial team member who will help you far more than you realize ∆ your attorney. If you don’t already have one, you may think that this is an additional expense that you cannot afford; after all, how often do you plan on being sued? However, good attorneys do more than represent you in court. Let’s take a look at what they can do for you.</description>
	</item>
	<item>
		<title>What Kind Of Writer Are You, Anyway?</title>
		<link>http://tc.eserver.org/26601.html</link>
		<guid>http://tc.eserver.org/26601.html</guid>
		<description>It never ceases to amaze me when clients and recruiters insist on absolute perfection in a technical writer, or, at the very least, a writer who is everything to everybody. So, at the risk of sounding flippant, what kind of writer are you anyway?</description>
	</item>
	<item>
		<title>The &quot;Write&quot; Hire</title>
		<link>http://tc.eserver.org/26600.html</link>
		<guid>http://tc.eserver.org/26600.html</guid>
		<description>If you are a newly-appointed documentation manager hiring your first technical writer, you are probably wondering what you have gotten yourself into. Do you know how to attract quality applicants, assess candidates’ qualifications, effectively interview , compare candidates, ensure a good fit, make an offer, negotiate compensation, and measure success? Where should you start? Hiring employees can be difficult whether adding one employee or staffing a full team from scratch.</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>Increasing Visibility: Building Demand for Technical Communication Services</title>
		<link>http://tc.eserver.org/26126.html</link>
		<guid>http://tc.eserver.org/26126.html</guid>
		<description>Good technical communication is critical to the success of products and ultimately to the success of companies. But even the most perfect manuals may go unread, and the most elegant help systems may go unnoticed unless you take the time to promote the quality and necessity of your work. You need to showcase your talents and to encourage people throughout your company--and the community--to value and understand the work that you do. This will ideally lead to more respect, better pay, and more interesting work.</description>
	</item>
	<item>
		<title>Opening Up to OpenOffice.org: Finding an Alternative to Microsoft Word</title>
		<link>http://tc.eserver.org/26101.html</link>
		<guid>http://tc.eserver.org/26101.html</guid>
		<description>When OpenOffice.org (www.openoffice.org) reached version 1.0 in May 2002, I did my journalistic duty and had a look. It wasn&apos;t what I expected. At times, the duplication of MS Word in OpenOffice.org seemed to extend to the faults, but the first impression is misleading. While MS Word users can be comfortable in OpenOffice.org within minutes, OpenOffice.org&apos;s interface is by far the tidier. More importantly, OpenOffice.org not only matches MS Word almost feature for feature, but often exceeds it, and provides working versions of features that have been broken or overdue for overhaul in MS Word for several releases.</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>They Boot Bosses, Don&apos;t They?</title>
		<link>http://tc.eserver.org/25923.html</link>
		<guid>http://tc.eserver.org/25923.html</guid>
		<description>I got a free pen, a free highlighter, a pad, and this story out of the Internet training course my company sent me to.</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>Hot Text: Web Writing That Works</title>
		<link>http://tc.eserver.org/22455.html</link>
		<guid>http://tc.eserver.org/22455.html</guid>
		<description>This book will help you improve any type of written communication, and it&apos;s a fun read to boot. The authors know what they&apos;re talking about and have the experience to back up their words. Both have spent many years writing for Web audiences. In addition to Web writing, their combined relevant experience includes journalism, technical communication, art, TV and radio, and teaching.</description>
	</item>
	<item>
		<title>Life in the New Work Order, or What Was I Doing Reading &lt;i&gt;Death March&lt;/i&gt;?</title>
		<link>http://tc.eserver.org/22456.html</link>
		<guid>http://tc.eserver.org/22456.html</guid>
		<description>So what is there in this book for the technical writer? There is some obvious advice, such as don&apos;t enforce a process that gets in the way of reaching goals; and don&apos;t try out radically new tools on this project. There is also good advice that most of us would take years to discover on our own, about the high-level politics that might help the project and some strategies to try during negotiation. If you are managing a group, it also gives some ideas on the different social roles that every team seems to need.</description>
	</item>
	<item>
		<title>Managing Enterprise Contact</title>
		<link>http://tc.eserver.org/22453.html</link>
		<guid>http://tc.eserver.org/22453.html</guid>
		<description>By the time I finished reading Managing Enterprise Content, I was excited! For me, the book answered questions about a unified content strategy on two levels: Not only did it address unified content strategy as a strategic business objective; it also unified the strategic directions that the umbrella of technical communication and training professions have been moving towards over the past decade: single-sourcing, corporate branding implementation, critical involvement in software or system development life cycle (SDLC) methodologies, and even implementation of ISO9000 compliance.</description>
	</item>
	<item>
		<title>Content Management for Dynamic Web Delivery</title>
		<link>http://tc.eserver.org/21692.html</link>
		<guid>http://tc.eserver.org/21692.html</guid>
		<description>&lt;i&gt;Content Management for Dynamic Web Delivery&lt;/i&gt; provides background and process for implementing content management in an organization. You don&apos;t have to spend a lot of time researching the topic on the Web, because all the necessary information you need, from introduction to the subject, to a blueprint to implement your solution is provided here. </description>
	</item>
	<item>
		<title>TECHWR-L Reviews</title>
		<link>http://tc.eserver.org/21691.html</link>
		<guid>http://tc.eserver.org/21691.html</guid>
		<description>Anyone may submit reviews for use on TECHWR-L.</description>
	</item>
	<item>
		<title>Boredom: The Secret of Tech Writing</title>
		<link>http://tc.eserver.org/21664.html</link>
		<guid>http://tc.eserver.org/21664.html</guid>
		<description>Of course, it&apos;s not 100% all of the time boring. Just some of it, on a fairly regular but not intolerable basis. But boring all the same.</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>Increasing Visibility: Building Demand for Technical Communication Services</title>
		<link>http://tc.eserver.org/19941.html</link>
		<guid>http://tc.eserver.org/19941.html</guid>
		<description>Good technical communication is critical to the success of products and ultimately to the success of companies. But even the most perfect manuals may go unread, and the most elegant help systems may go unnoticed unless you take the time to promote the quality and necessity of your work. You need to showcase your talents and to encourage people throughout your company--and the community--to value and understand the work that you do. This will ideally lead to more respect, better pay, and more interesting work.</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>E-Mail, Acronyms, and Alphabet Soup</title>
		<link>http://tc.eserver.org/19766.html</link>
		<guid>http://tc.eserver.org/19766.html</guid>
		<description>Emoticons have become pretty complex, now including ones like &lt;TT&gt;:-#&lt;/TT&gt; [lips are sealed], &lt;TT&gt;:-&amp;&lt;/TT&gt; [tongue tied], or &lt;TT&gt;:-&apos;&apos;&lt;/TT&gt; [pursing lips].</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 Benefits of a Job Well Done</title>
		<link>http://tc.eserver.org/19529.html</link>
		<guid>http://tc.eserver.org/19529.html</guid>
		<description>A parable about the lives of a high-tech technical writing team. Ken puts his twenty-five years as a technical writer to good use in this fictional work about four people hired to write manuals for Xoom-tek. In the chapter excerpted, Ken takes a humorous look at RIFs and downsizings.</description>
	</item>
	<item>
		<title>Opening Up to OpenOffice: Finding an Alternative to Microsoft Word</title>
		<link>http://tc.eserver.org/19528.html</link>
		<guid>http://tc.eserver.org/19528.html</guid>
		<description>When OpenOffice reached version 1.0 in May 2002, I did my journalistic duty and had a look. It wasn&apos;t what I expected. Aside from a few minor disappointments, I liked what I saw. I quickly became convinced that OpenOffice.org&apos;s Writer (OOo Writer) is a practical alternative to MS Word. Thirteen months of use has only cemented that impression. Four minor releases have been made since I started using OpenOffice.org, and, with each one, the program has become quicker and more stable. </description>
	</item>
	<item>
		<title>So You Want to Get Paid on Time? Here&apos;s How to Make It Happen</title>
		<link>http://tc.eserver.org/19527.html</link>
		<guid>http://tc.eserver.org/19527.html</guid>
		<description>&apos;I love everything about being self-employed--except for waiting to get paid! My paychecks never seem to arrive on time. Sometimes my clients forget to send my invoices to Accounts Payable or the invoices get misplaced; other times the process just bogs down and takes forever. Whatever the reason, I&apos;m stuck waiting for checks that don&apos;t come.&apos; This article addresses the question: How can I get my clients to pay on time?</description>
	</item>
	<item>
		<title>Increasing Visibility: Building Demand for Technical Communication Services</title>
		<link>http://tc.eserver.org/19515.html</link>
		<guid>http://tc.eserver.org/19515.html</guid>
		<description>Good technical communication is critical to the success of products and ultimately to the success of companies. But even the most perfect manuals may go unread, and the most elegant help systems may go unnoticed unless you take the time to promote the quality and necessity of your work. You need to showcase your talents and to encourage people throughout your company--and the community--to value and understand the work that you do. This will ideally lead to more respect, better pay, and more interesting work. </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>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>A Day in the Life of a Technical Writer</title>
		<link>http://tc.eserver.org/18692.html</link>
		<guid>http://tc.eserver.org/18692.html</guid>
		<description>This TECHWR-L Magazine section features a selection of quotations from active technical writers about what a day at work looks like.</description>
	</item>
	<item>
		<title>Understanding and Planning for Translation Services</title>
		<link>http://tc.eserver.org/18695.html</link>
		<guid>http://tc.eserver.org/18695.html</guid>
		<description>The past decade has seen significant advances in machine-translation (MT) technology. While MT is still a ways off its goal of replacing human translators, today it is used successfully in several industry sectors (incl. automotive, aerospace, defense) with lots of documentation to be translated. </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>Painless Linux (Part Two)</title>
		<link>http://tc.eserver.org/14808.html</link>
		<guid>http://tc.eserver.org/14808.html</guid>
		<description>If you&apos;re expecting to be lost in the interstellar darkness of the command line, you&apos;re in for a surprise. Although Linux includes some handy command line tools, today most of Linux&apos;s install programs, desktops, and programs now boast graphical windows. The desktops and the windows look a little different from the ones you see in other operating systems, but they&apos;re recognizable for what they are. &#xD;&#xD;As you&apos;ll see in this article, you have to look deeper to see the differences: They lie not only in the performance, but also in a design philosophy that favors small tools over monolithic ones, customization over standardization, and a hands-on approach over hidden complexity. Once you adjust to the novelties, even the command line is not the empty vacuum you expected, but a teeming ecology that in many ways is more powerful--and empowering--than the GUIs (Graphical User Interfaces). If Linux is somewhat rougher in patches than Windows, many people feel that this design philosophy more than compensates. After all, one day in the next few years, Linux is going to have the GUI sophistication, too. </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>Relieving Computer-Induced Headaches</title>
		<link>http://tc.eserver.org/14501.html</link>
		<guid>http://tc.eserver.org/14501.html</guid>
		<description>A thorough discussion of why some users get headaches when working at the computer.</description>
	</item>
	<item>
		<title>Repetitive Stress Injury Prevention</title>
		<link>http://tc.eserver.org/14502.html</link>
		<guid>http://tc.eserver.org/14502.html</guid>
		<description>I received a lot of email following my post asking about writing-specific ergonomics and wrist-strengthening exercises. A lot of people wanted to know what they can do to avoid several common work-related injuries, including: repetitive strain injuries; carpal tunnel syndrome; sore hands, arms, necks, backs; and mousing strain.</description>
	</item>
	<item>
		<title>TECHWR-L Daily Summary Mailing List</title>
		<link>http://tc.eserver.org/14496.html</link>
		<guid>http://tc.eserver.org/14496.html</guid>
		<description>The TECHWR-L Daily Summary Mailing list gives you a single, once-each-day message that lists the new jobs posted to TECHWR-L Employment Services that day, as well as the upcoming events listed on the Calendar. &#xD;&#xD;Anyone is welcome to subscribe to this Daily Summary mailing, and you&apos;re welcome to forward your complete copy to anyone. That said, we will be better able to gauge the popularity of this feature (and make decisions about continuing or discontinuing it) if interested individuals subscribe directly using this page.</description>
	</item>
	<item>
		<title>What Can We Learn from Other Functional Areas?</title>
		<link>http://tc.eserver.org/14500.html</link>
		<guid>http://tc.eserver.org/14500.html</guid>
		<description>Imagine the perfect technical writing experience. Engineers gladly line up at your door to explain how the product works. You enjoy ample time to finish the tasks on your documentation plan. Your manager gives you free rein to work at your own pace. Your customers rejoice at the usefulness of your document. &#xD;&#xD;A fairy tale? Perhaps. As a fledgling writer, though, that idyllic picture is my goal. To achieve even part of that goal, I&apos;ve discovered a need to develop new work habits, behaviors, and processes. In addition to seeking the help of mentors within the technical writing community, my strategy involves looking to other functional areas within my company and learning from the approaches they use on their own tasks. I believe people new to the technical communication industry, as well as those who have toiled in the field for decades, can benefit from the examples of other functional areas.</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>Annotated Cover Letter: Using Block Style Format</title>
		<link>http://tc.eserver.org/14143.html</link>
		<guid>http://tc.eserver.org/14143.html</guid>
		<description>An annotated sample cover letter for applying for a tech comm position.</description>
	</item>
	<item>
		<title>Client Questionnaire</title>
		<link>http://tc.eserver.org/14142.html</link>
		<guid>http://tc.eserver.org/14142.html</guid>
		<description>Following are questions and issues that should be covered during early meetings with a client, including general project questions, questions specific to documentation, and&#xD;questions regarding scheduling, reviews and administrative issues. Thanks to&#xD;TECHWR-Ler Judy Fraser for providing this awesome summary.</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>Establishing and Building Mutual Respect with Technical Team Members</title>
		<link>http://tc.eserver.org/14146.html</link>
		<guid>http://tc.eserver.org/14146.html</guid>
		<description>As a technical writer, are you finding yourself wishing for just a bit of respect from the engineers, SMEs (Subject Matter Experts), or other technical people you work with? Are you finding that these folks seem to stonewall you on every question you have or every goal you&apos;re trying to achieve? Are they obstreperous? Difficult? Or just plain unhelpful? &#xD;&#xD;When I hear technical writers complaining about--er, describing--such troubles when working in a team environment, my first reaction is to want to sit and observe how they actually interact with those seemingly impossible team members. In my experience, I&apos;ve found that the problem isn&apos;t always with a surly SME or with an engineer who lacks communication skills. Certainly, there are cases where other team members just don&apos;t value any contribution other than their own; however, most often, I have found the problem is with the technical writer&apos;s approach to the team environment--and have found that the problem began from the very start of that writer&apos;s involvement with the team.</description>
	</item>
	<item>
		<title>Estimating Worksheet</title>
		<link>http://tc.eserver.org/14141.html</link>
		<guid>http://tc.eserver.org/14141.html</guid>
		<description>An example worksheet for generating TC job estimates.</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>Getting Started in Technical Writing</title>
		<link>http://tc.eserver.org/14138.html</link>
		<guid>http://tc.eserver.org/14138.html</guid>
		<description>This summary provides a collection of tips and advice for getting started in the technical writing profession. The following categories are included in this summary:&#xD; Finding and Getting That First Job;&#xD; Types of Technical Writing;&#xD; Types of Technical Writers;&#xD; Degrees and Technical Writing;&#xD; Transferring to Technical Writing from Other Professions:&#xD; From Journalism;&#xD; From Teaching;&#xD; From Academia;&#xD; From Marketing;&#xD; From Law;&#xD; Essential Skills;&#xD; On Being a Technical Writer.</description>
	</item>
	<item>
		<title>Guidelines for Technical Edits</title>
		<link>http://tc.eserver.org/14134.html</link>
		<guid>http://tc.eserver.org/14134.html</guid>
		<description>The purpose of the technical edit is to ensure that all materials produced by the Documentation department are as complete and technically accurate as possible. Each document will also pass through a peer edit by a member of the Documentation department after the technical edit is complete, so as a technical editor you do not need to be concerned with issues of style and grammar.&#xD;Your main focus should be on the technical accuracy of the document.&#xD;The first step, of course, is simply to check the document for any errors. We need to make sure w&#xD;have correctly described each feature of the software, as well as the overall design and purpose of&#xD;the forms and systems we are discussing.&#xD;Beyond checking for errors, however, we want the documentation we produce to be as helpful to&#xD;the user as possible. For the purposes of the technical edit, this means not only checking for inaccuracies,&#xD;but asking whether the document has all the information that is necessary to use the&#xD;software successfully.</description>
	</item>
	<item>
		<title>Master Documents</title>
		<link>http://tc.eserver.org/28361.html</link>
		<guid>http://tc.eserver.org/28361.html</guid>
		<description>This chapter ventures deeply into Microsoft heresy. A heretic is someone who preaches heterodoxy, or mixed doctrines. Unlike a lot of official MS and MVP speak, this topic advocates the usage of a certain feature that can be said to be generally considered as broken - Master Documents, or Masters. As so little information is forthcoming on this&#xD;subject from other sources, yet many writers use them regularly because there is no&#xD;other choice, it is fully covered here.</description>
	</item>
	<item>
		<title>Programmers and Usability</title>
		<link>http://tc.eserver.org/14133.html</link>
		<guid>http://tc.eserver.org/14133.html</guid>
		<description>In tandem with the theme of usability is the one of how to get (or help) programmers to communicate (to&#xD;the user, to us...) – and the general tone is that, in effect, programmers really don&apos;t care about the end&#xD;user&apos;s &apos;experience&apos; of the software.&#xD;If this is true, it occurs to me to wonder, WHY are programmers disinterested in usability?</description>
	</item>
	<item>
		<title>Project Kickoff Form</title>
		<link>http://tc.eserver.org/14137.html</link>
		<guid>http://tc.eserver.org/14137.html</guid>
		<description>A sample project kickoff form, useful to clarify specific issues to particular jobs that might not otherwise become apparent until late in the job itself.</description>
	</item>
	<item>
		<title>Proofreading and Editing Tips</title>
		<link>http://tc.eserver.org/14135.html</link>
		<guid>http://tc.eserver.org/14135.html</guid>
		<description>General tips for proofing: Read it out loud and also silently. Read it backwards to focus on the spelling of words. Read it upside down to focus on typology.</description>
	</item>
	<item>
		<title>Screen Captures 102</title>
		<link>http://tc.eserver.org/14144.html</link>
		<guid>http://tc.eserver.org/14144.html</guid>
		<description>This document is about making screen captures for technical writers working primarily in a Microsoft Windows environment. The tools targeted include Adobe&#xD;FrameMaker, Microsoft Word, Adobe Acrobat, along with Techsmith’s SnagIt,&#xD;Adobe Photoshop, and Ulead’s PhotoImpact 4.2. Certainly, the thoughts and techniques mentioned herein can be applied to other&#xD;professions, other operating systems, and other tools.</description>
	</item>
	<item>
		<title>Tech Writing Folk Songs</title>
		<link>http://tc.eserver.org/14132.html</link>
		<guid>http://tc.eserver.org/14132.html</guid>
		<description>The long-awaited summary of Tech Writing Folklore and Minstrelsy!</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>Twenty Questions for Your First Day on the Job as a Contractor</title>
		<link>http://tc.eserver.org/14147.html</link>
		<guid>http://tc.eserver.org/14147.html</guid>
		<description>It&apos;s hard enough your first day at work as a permanent employee. There are forms to fill out, introductory meetings to attend, tools to learn. But people are likely to cut you a little slack at first, while you come up to speed. &#xD;&#xD;Then there&apos;s your first day as a contractor. You&apos;re expected to hit the ground running, ask what you need to know, and get productive as fast as possible. How can you minimize your initial minutes of floundering around, and get to work quickly? The sets of questions below, while by no means comprehensive, will help you figure out how your new environment works. They are grouped, but not prioritized.</description>
	</item>
	<item>
		<title>TECHWR-L Polls</title>
		<link>http://tc.eserver.org/13994.html</link>
		<guid>http://tc.eserver.org/13994.html</guid>
		<description>The TECHWR-L website periodically polls users&apos; opinions about the current state of the field. Review the recent findings.</description>
	</item>
	<item>
		<title>Painless Linux</title>
		<link>http://tc.eserver.org/13957.html</link>
		<guid>http://tc.eserver.org/13957.html</guid>
		<description>Is Linux in your technical writing future? The possibility is becoming too strong to ignore. Companies like Merrill Lynch and Credit Suisse First Boston are using Linux now, and countries ranging from Germany and France to Pakistan and Venezuela are adapting it and other open source software for government business. In high-tech, IBM reports that over one thousand of its business partners became Linux-certified in 2001, and the Linux applications listed in the IBM Global Solutions Directory rose from 2300 to 2800 in the six months between June 2001 and January 2002. In a little less than three years, Linux has captured over a third of the server market, and, while its share of the desktop market seems stalled at four percent, growing concerns about security, the cost of commercial software, and restrictive licensing practices are starting to change that.</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>The TECHWR-L Mentoring Program</title>
		<link>http://tc.eserver.org/13932.html</link>
		<guid>http://tc.eserver.org/13932.html</guid>
		<description>The TECHWR-L mentoring program is designed to match students or people starting out in the profession with those interested in being a mentor.</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>The Project Kickoff Form: Aid for Launching and Managing New Projects</title>
		<link>http://tc.eserver.org/13826.html</link>
		<guid>http://tc.eserver.org/13826.html</guid>
		<description>If you&apos;re a writer like me, news of a fresh assignment brings both excitement and anxiety. New assignments offer opportunities to further our knowledge and expand our portfolios, and they may result in a bonus or a more lucrative contract. But new projects can also inspire angst and dread if you have past experience with projects that involved false starts, unrestrained scope creep, misunderstandings between team members, uncommunicative teammates, or unfamiliar technologies.</description>
	</item>
	<item>
		<title>Single-Sourcing with FrameMaker</title>
		<link>http://tc.eserver.org/13588.html</link>
		<guid>http://tc.eserver.org/13588.html</guid>
		<description>As a technical writer, you may be exploring single-sourcing--producing multiple document outputs from a single information source--as a possible option for easing document development and production. Although solutions such as databases, SGML, and XML are available that can enable you to reuse information to produce multiple outputs, single-sourcing doesn&apos;t have to involve such complex solutions, expenses, and learning curves. Instead, if your single-sourcing needs are relatively simple, you can effectively single-source using a tool that technical writers commonly have available: FrameMaker.</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>Documentation Testing Checklist</title>
		<link>http://tc.eserver.org/13515.html</link>
		<guid>http://tc.eserver.org/13515.html</guid>
		<description>Check out this new Documentation Testing Checklist, which offers categories and suggestions to use when testing documentation.</description>
	</item>
	<item>
		<title>What Do Technical Writers Find Stressful?</title>
		<link>http://tc.eserver.org/13513.html</link>
		<guid>http://tc.eserver.org/13513.html</guid>
		<description>If you are new to the technical writing profession or are considering technical writing as a career, you may be wondering whether technical writing is a high-stress occupation. According to The Jobs Rated Almanac 2001 by Les Krantz, technical writers are rated as having a &apos;relatively moderate to medium level of stress&apos; when compared to other professions. The Almanac ranks 250 professions based on a range of job demands that are considered to cause stress; the stress ranking for &apos;technical writing&apos; is based on the large workloads, tight deadlines, stringent demands for quality, and the exposure to criticism characteristic of many technical and marketing writer jobs. </description>
	</item>
	<item>
		<title>What Strategies Can Technical Writers Use to Cope with Stress?</title>
		<link>http://tc.eserver.org/13514.html</link>
		<guid>http://tc.eserver.org/13514.html</guid>
		<description>This article offers some practical suggestions for increasing your ability to cope with stressors. Rather than attempting to cover solutions in depth, this article provides a range of ideas to explore in addressing the stressors discussed in Part One. The &apos;See Also&apos; section at the end of each topic provides links to additional resources related to the topic, which help clarify or expand on the strategies briefly described under each topic.</description>
	</item>
	<item>
		<title>Feng Shui for the Tech Writer&apos;s Workspace</title>
		<link>http://tc.eserver.org/13487.html</link>
		<guid>http://tc.eserver.org/13487.html</guid>
		<description>It sounds like something from a late-night infomercial: Enhance your productivity by cranking out online help files in half the time! Increase your prosperity by being promoted to head of the documentation department! Improve your interpersonal relations so that Subject Matter Experts (SMEs) are just waiting to review your documents. Ensure a long and healthy life, despite the stress of vaporware product launches! If an advertisement lurking in your emailbox claimed to have an ancient secret to give you all the above, you&apos;d likely press Delete faster than you can say &apos;looming deadlines.&apos; But what if millions of people--some as well-known and successful as Donald Trump--and major corporations, such as Virgin Airlines, The Wall Street Journal, and Citibank, attested to this &apos;magic&apos; secret&apos;s power? In that case, you just might sit back in your office chair and listen.</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>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>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>What&apos;s in a Name? Guidelines for Naming Files</title>
		<link>http://tc.eserver.org/13364.html</link>
		<guid>http://tc.eserver.org/13364.html</guid>
		<description>While file naming may seem like an insignificant detail, developing an intuitive, descriptive file naming system can help minimize file access and management challenges. What&apos;s more, developing such a file naming system--especially when a consistent system is not in place--can have added benefits, such as improving access through better searchability and browseability, and improving access for everyone who may, now or later, need to access project files. In this article, you&apos;ll find several tips and examples for naming files, which used individually or in combination, can help ease file access and management.</description>
	</item>
	<item>
		<title>Essential Resources for FrameMaker Users</title>
		<link>http://tc.eserver.org/13053.html</link>
		<guid>http://tc.eserver.org/13053.html</guid>
		<description>FrameMaker may be the current standard for technical publication, but that doesn&apos;t mean it&apos;s a perfect program. Many writers who&apos;ve used FrameMaker find that it&apos;s complex and quirky, with a lot functionality hidden in its now somewhat dated interface. So where do you go when you need help? This article will give you some suggestions.</description>
	</item>
	<item>
		<title>Adaptive Technologies for the Visually Impaired: The Role of Technical Communicators</title>
		<link>http://tc.eserver.org/12966.html</link>
		<guid>http://tc.eserver.org/12966.html</guid>
		<description>Try your ordinary web browsing and e-mail with an translucent piece of plastic draped over your monitor, with your monitor partially obstructed, or with your monitor turned off. With each of these changes, you’ll have a significantly different experience. For example, if you have plastic draped over your monitor, you’ll likely have a hard time reading words, interpreting graphics, or distinguishing colors. If your monitor is partially obstructed, you’ll likely have a difficult time navigating pages, reading columnar formats, or associating graphics with text. And, of course, if your monitor is off, you’ll have an entirely different set of challenges in accessing and using information. Each scenario offers a different view of the information onscreen, poses different challenges, and, most important, each is significantly different from unimpaired viewing.</description>
	</item>
	<item>
		<title>Context-Sensitive Disaster: Designing the Difference Between Help and Print</title>
		<link>http://tc.eserver.org/12948.html</link>
		<guid>http://tc.eserver.org/12948.html</guid>
		<description>My first epiphany about online help struck while I was browsing through the latest release of a popular Windows program. After exploring for a few minutes, I stumbled across an interesting option that hadn&apos;t appeared in the previous version (let&apos;s call this &apos;option X&apos;), and my curiosity was piqued. With the confidence of every naive Windows user, I hit the F1 key, certain that enlightenment was only a few words away. My optimism dwindled when I read the corresponding instructions in the online help.</description>
	</item>
	<item>
		<title>Converting HTML to PDF</title>
		<link>http://tc.eserver.org/12949.html</link>
		<guid>http://tc.eserver.org/12949.html</guid>
		<description>In December 1999, I asked: &apos;Is there any tool that currently exists to convert a bunch of html pages to pdf?&apos; Thanks to all for the replies I received. There are two main solutions. (1) Print directly from the browser, and choose either Distiller or PDFWriter as the printer to turn the file into a pdf. For those of you who warned me that I might have to edit out the footer and header (typically the address of the page, the time etc), these can be edited out, in IE 5 at least, by selecting Page Setup from the File menu, and editing the Headers and Footers section. (2) Use Acrobat&apos;s web capture feature (accessed for example, by selecting Open Web Page from the File menu). There is one major caution with this approach: it does not open local web pages using the formats &apos;file:///&apos; or &apos;c:\&apos; It turns out that the syntax is the all important thing; I&apos;ve used &apos;|&apos; (pipe) where &apos;:&apos; (colon) would normally be used after the C drive reference.</description>
	</item>
	<item>
		<title>Good, Fast, Cheap: Translation Memory Systems Offer the Potential for All Three</title>
		<link>http://tc.eserver.org/12964.html</link>
		<guid>http://tc.eserver.org/12964.html</guid>
		<description>For technical communicators exploring translation services, a relatively new technology can help provide consistency among translated documents, make the translation process more efficient, and make translation projects cost effective. Translation memory systems assist human translators by following along as a document is translated, creating a database of translated material and terminology, and allowing translators to access previously translated material easily. Using this technology, translators can translate, save, and reuse material, making the resulting translations highly consistent and the overall process more efficient and cost effective than working without this technology. In this exploratory article, we explain the evolution toward translation memory systems, discuss why and when they&apos;re particularly useful for helping translate technical documentation, and offer guidelines for determining whether translation memory systems are appropriate for your translation needs.</description>
	</item>
	<item>
		<title>Hitching with Clipboard and Pen Along the Open Road: A Tech Writer&apos;s Guide to the Open Source Movement</title>
		<link>http://tc.eserver.org/12963.html</link>
		<guid>http://tc.eserver.org/12963.html</guid>
		<description>The idea behind Open Source is simple: everyone should have the freedom to copy, distribute, and change source code. The implications, however, overturn the conventional high-tech business model. When software is no longer intellectual property, everything changes. Development is quicker because more people are involved. Bugs are caught more quickly. Instead of being passive consumers, customers can become partners in development. Instead of selling software, companies sell hardware, services, or added value. Internally, companies become more interactive and more loosely structured. If Open Source continues to gather speed, high-tech workers will discover that it is not just a development model, but also a new model for corporate life. For writers, the approach of Open Source could be especially important. How documentation is viewed and used, how writers interact with developers, and what tools are used--all of these and more could be affected by the Open Source movement.</description>
	</item>
	<item>
		<title>Knowing When to Upgrade Software</title>
		<link>http://tc.eserver.org/12954.html</link>
		<guid>http://tc.eserver.org/12954.html</guid>
		<description>Software upgrades generally do two things: Offer you new or improved features, and fix bugs present in existing versions. Whether you upgrade will depend on your need for the new or improved features, depend on whether you experience problems because of software bugs, and, of course, depend on your budget.</description>
	</item>
	<item>
		<title>Making FrameMaker Help Usable and Searchable</title>
		<link>http://tc.eserver.org/12951.html</link>
		<guid>http://tc.eserver.org/12951.html</guid>
		<description>You can convert FrameMaker&apos;s help files to a PDF file, thus making them fully searchable and far more usable than the originals. These instructions are Windows-centric, but can be adapted to work on all systems with Frame. (Directory/folder names are the only real difference.) </description>
	</item>
	<item>
		<title>A PageMaker to PDF: Converting Your PageMaker Files</title>
		<link>http://tc.eserver.org/12950.html</link>
		<guid>http://tc.eserver.org/12950.html</guid>
		<description>A three-page manual for creating Acrobat PDF files from page-layout files.</description>
	</item>
	<item>
		<title>PDF as an Online Document Format</title>
		<link>http://tc.eserver.org/12971.html</link>
		<guid>http://tc.eserver.org/12971.html</guid>
		<description>In January (2000), I asked about TechWhirlers&apos; experiences as users of PDF documents online. The specific questions were: Do you notice a difference between reading PDF online and reading HTML online? Do you have a preference either way? If so, which one? Here&apos;s the summary or responses and a synopsis of further information I&apos;ve been tracking down. I&apos;m sorry it&apos;s taken so long: like many an unplanned project it got way out of hand. I&apos;ve tried to restrict this message to issues of interest to the list; if I&apos;ve failed please accept my apologies.</description>
	</item>
	<item>
		<title>TECHWR-L Friendly Faces</title>
		<link>http://tc.eserver.org/12960.html</link>
		<guid>http://tc.eserver.org/12960.html</guid>
		<description>Welcome to the Friendly Faces of TECHWR-L, where you can put faces with the names of TECHWR-Lers. The friendly faces are listed in alphabetical order by last name.</description>
	</item>
	<item>
		<title>The TECHWR-L List Archive</title>
		<link>http://tc.eserver.org/12958.html</link>
		<guid>http://tc.eserver.org/12958.html</guid>
		<description>This new TECHWR-L archive format gives you complete access to TECHWR-L list messages--from the first messages posted in March 1993 to the current day&apos;s TECHWR-L postings. We&apos;ve added this new format in response to site visitor feedback, which indicated a need for a complete archive that: returns focused results (minimizing irrelevant results; returns results quickly; minimizes forms; minimizes reloading pages; offers flexibility to search by topic, author, thread, or date. This new archive format provides full-text search capabilities through all 120,000+ (and growing) messages, as well as allows you to browse by month/year, thread, and author. Experiment with the new archive format, or find out more about it. </description>
	</item>
	<item>
		<title>Thoughts About On-Line Help</title>
		<link>http://tc.eserver.org/12969.html</link>
		<guid>http://tc.eserver.org/12969.html</guid>
		<description>Shovelware is becoming the norm in computer software documentation.&#xD;Many companies no longer furnish printed books with their products, and it’s usually impossible to produce (from the on-line help files) a reasonable facsimile of a coherently organized, double-sided, printed book with page numbers, running headers and footers, table of contents, glossary, and&#xD;multilevel subject index.&#xD;The current sad state of affairs is epitomized by the FrameMaker user manual and on-line help. In the last release (V5.1) of&#xD;FrameMaker+SGML for which Frame Technology was responsible, the&#xD;printed user’s manual was quite comprehensive at 900+ pages, and the&#xD;on-line help was extensive, well-designed, and effective. But the Adobe-produced&#xD;V5.5 user’s manual (including the separate “Getting Started”&#xD;manual for FM+SGML) has 300 fewer pages, even though many new fea-tures (e.g., HTML and XML export) in V5.5 had to be covered in addition&#xD;to all those features common to both releases. Not only that, but the effectiveness of the on-li</description>
	</item>
	<item>
		<title>Understanding Graphic File Formats</title>
		<link>http://tc.eserver.org/12952.html</link>
		<guid>http://tc.eserver.org/12952.html</guid>
		<description>Identifying and fixing problems with graphics often comes down to a brief reminder of what the various kinds of graphic formats are and how to use each of them when they&apos;re the most appropriate--not merely most convenient--for the situation.</description>
	</item>
	<item>
		<title>User&apos;s Guide</title>
		<link>http://tc.eserver.org/12946.html</link>
		<guid>http://tc.eserver.org/12946.html</guid>
		<description>Did you know that some people think technical writers make too much money? Discuss it as much as you like, but one thing remains certain: Until engineers can figure out that &apos;I/O&apos; is &apos;on,&apos; we writers will continue to pull down the big bucks.</description>
	</item>
	<item>
		<title>WebHelp vs. HTML Help</title>
		<link>http://tc.eserver.org/12968.html</link>
		<guid>http://tc.eserver.org/12968.html</guid>
		<description>Thanks to all of you who responded to my recent questions about WebHelp and HTML Help. I&apos;ve put together an informal summary of my findings, but please feel free to make comments or add to it.</description>
	</item>
	<item>
		<title>Word vs. Frame</title>
		<link>http://tc.eserver.org/12967.html</link>
		<guid>http://tc.eserver.org/12967.html</guid>
		<description>This summary lists pros and cons for using FrameMaker or Word for creating large documents or books. The general consensus of techwhirlers is that FrameMaker is better-suited than Word for large documents and for creating a single-source documentation set.</description>
	</item>
	<item>
		<title>A Book of Your Own</title>
		<link>http://tc.eserver.org/12931.html</link>
		<guid>http://tc.eserver.org/12931.html</guid>
		<description>I was a tech writer long before I wrote my first book, although I had to jump through some difficult hoops to land my first tech writing job (a series of six tests on technology); however, a great deal of my work later, especially my consulting jobs, came about as a result of my books and the reputation they bestowed on me. Being published between covers brings you respect almost as quickly and surely as becoming known as a millionaire business owner does. Even now, it happens. A reader who owns a small business in Baltimore hired me recently to do some consulting with him, after reading one of my books published a few years ago. The gentleman had read several books on the subject of proposal writing and contracting, and he decided that my book reflected the kind of thinking he needed, although it was one of my most slender volumes.</description>
	</item>
	<item>
		<title>Creative Problem Solving: Getting the Best from Yourself</title>
		<link>http://tc.eserver.org/12935.html</link>
		<guid>http://tc.eserver.org/12935.html</guid>
		<description>You might think that as a technical writer, you don&apos;t have much room for creativity in your job. Not true. Although you may be writing about the intricacies of a network system rather than creating poetry about the summer sun, technical writers have as much room--and need--for creativity as any other kind of writer. Taking a creative approach to your work doesn&apos;t mean just thinking up fourteen synonyms for &apos;display.&apos; It means using different ways of thinking and interacting to solve on-the-job problems, from personnel concerns to how to fit all those graphics on the same page.</description>
	</item>
	<item>
		<title>Developing an Article from the Ground Up</title>
		<link>http://tc.eserver.org/12932.html</link>
		<guid>http://tc.eserver.org/12932.html</guid>
		<description>Whether it&apos;s at the request of your company&apos;s powers-that-be or out of your own personal desire to spread your wings, you may be thinking about writing an article. It&apos;ll be easy enough. You&apos;re a writer, after all. You already know how to research topics, develop information, and create a coherent document. You&apos;ve written tomes on the most arcane topics known to humankind. Surely one little 1000-word feature story is no big deal, right? That all depends. Article writing--for a specialized audience or for the general public--requires knowledge of a new process that many technical writers may not be familiar with. Fortunately, though, any professional writer can learn to transfer his or her existing skills to this new format, and you just might find the different method provides a mini vacation from your day-to-day work projects.</description>
	</item>
	<item>
		<title>Extending Your Tech Writing Skills: Pitching a Newspaper Column Idea</title>
		<link>http://tc.eserver.org/12934.html</link>
		<guid>http://tc.eserver.org/12934.html</guid>
		<description>Before pitching a column idea to your local newspaper editor, take time to examine whether becoming a columnist is right for you. In taking on a newspaper column, you not only take on a long-term commitment, but you also establish a responsibility to people in your own community. So, to begin, you might read Extending Your Tech Writing Skills: Becoming a Columnist, which identifies considerations for becoming a columnist.  If you decide that becoming a columnist does suit your interests and goals, then the following tips and ideas can help you land a column with your local newspaper. As you&apos;ll see, examining and refining the topic, overcoming the competition, using a creative approach, and following up appropriately can help.</description>
	</item>
	<item>
		<title>Freelance Article Writing: Tips for Establishing and Maintaining Good Relationships with Magazine Editors</title>
		<link>http://tc.eserver.org/12933.html</link>
		<guid>http://tc.eserver.org/12933.html</guid>
		<description>While writing attention-grabbing, informative queries--a much-covered topic in the freelance writing arena--is important in landing assignments, don&apos;t overlook one important aspect that can help you continue landing assignments time after time: Establishing and maintaining good relationships with the editors you work with. This article offers advice, how-to and why-to information, and techniques to apply throughout the publishing process that can help you build good relationships with magazine editors. Although the following sections provide specific details and steps, the message is simple: A little understanding, consideration, and effort go a long way.</description>
	</item>
	<item>
		<title>The Inappropriate Posting Scenario</title>
		<link>http://tc.eserver.org/12945.html</link>
		<guid>http://tc.eserver.org/12945.html</guid>
		<description>You are in a large lecture hall full of people in your profession. Included in the audience are students, educators, professionals. You cannot make out their faces, but they could reasonably include your employers or potential employers, your coworkers, and the ever-present violently obsessive technical writing groupies. Most of the audience members sit quietly as one member at a time gets up, walks to the podium, and shares information or advice or asks questions. Some of it is rich and detailed, some cursory but helpful, some trivial but relevant in a roundabout way. Somewhere in this stream of information, someone expresses an opinion or gives a piece of advice that you feel obligated to respond to.</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>
	<item>
		<title>Placing Copyright Notices In Documentation</title>
		<link>http://tc.eserver.org/12937.html</link>
		<guid>http://tc.eserver.org/12937.html</guid>
		<description>There&apos;s no legal reason not to include a copyright notice on every page of a printed manual, every slide of a PowerPoint presentation, or every page of a Web site. But, of course, too many copyright notices can become unruly and unattractive, so the practical question is whether there is a legal reason why copyright notices should be printed on every page of a document.</description>
	</item>
	<item>
		<title>TECHWR-L Employment Services</title>
		<link>http://tc.eserver.org/12943.html</link>
		<guid>http://tc.eserver.org/12943.html</guid>
		<description>The TECHWR-L Employment Central website lists positions available to technical communicators.</description>
	</item>
	<item>
		<title>TECHWR-L Events Calendar</title>
		<link>http://tc.eserver.org/12944.html</link>
		<guid>http://tc.eserver.org/12944.html</guid>
		<description>The TECHWR-L Events Calendar lists events of interest to people in the profession.</description>
	</item>
	<item>
		<title>Tips for Attending Conferences</title>
		<link>http://tc.eserver.org/12936.html</link>
		<guid>http://tc.eserver.org/12936.html</guid>
		<description>First, determine what you want to gain from the conference. Are you looking to gain new knowledge in specific topic areas? Are you looking to gain as much new information as possible? Are you primarily attending to network with new people? Are you looking to find a new job or investigate relevant services? Maybe some or all of these reasons? Determine what your goals are.</description>
	</item>
	<item>
		<title>Understanding Business Communication Copyright Laws</title>
		<link>http://tc.eserver.org/12939.html</link>
		<guid>http://tc.eserver.org/12939.html</guid>
		<description>For some reason, there is a common misconception that correspondence and other forms of communication are not subject to protection by U.S. copyright laws; however, generally, that is not true. The U.S. Copyright Act states that protection exists &apos;in original works of authorship fixed in any tangible medium of expression, now known or later developed, from which they can be perceived, reproduced, or otherwise communicated, either directly or with the aid of a machine or device.&apos; Therefore, letters typically are protected by copyright law.</description>
	</item>
	<item>
		<title>Using Client Logos</title>
		<link>http://tc.eserver.org/12940.html</link>
		<guid>http://tc.eserver.org/12940.html</guid>
		<description>According to the U.S. Lanham Act, a trademark is generally a &apos;word, name, symbol, or device, or combination thereof&apos; that is used to &apos;identify and distinguish...goods, including a unique product, from those manufactured or sold by others and to indicate the source of the goods, even if that source is unknown.&apos; Similarly, a service mark identifies and distinguishes services, rather than goods. Trademark infringement occurs when a person, without permission, uses another person&apos;s trademark or service mark in a commercial manner that is likely to cause confusion among the public. Trademark dilution, a less common legal violation, occurs when a person uses another person&apos;s famous trademark commercially without permission if doing so dilutes the distinctive quality of the trademark, even if there is no likelihood of confusion.</description>
	</item>
	<item>
		<title>Using Parts of Another Company&apos;s Documentation to Supplement Your Company&apos;s Documentation</title>
		<link>http://tc.eserver.org/12938.html</link>
		<guid>http://tc.eserver.org/12938.html</guid>
		<description>Although in some parts of life, as the saying goes, &apos;it&apos;s easier to ask forgiveness than to ask permission,&apos; that&apos;s certainly not true in copyright law. It&apos;s very important to ask permission, because if you don&apos;t, you could be committing copyright infringement. In some instances, you may be able to use small portions of the other company&apos;s documentation without asking permission, under the &apos;fair use&apos; doctrine of copyright law. However, this doctrine is highly fact-specific and often confusing; in other words, it&apos;s impossible to provide a blanket rule about how many paragraphs or words you can copy without violating the law.</description>
	</item>
	<item>
		<title>Developing an Annotated Portfolio</title>
		<link>http://tc.eserver.org/12929.html</link>
		<guid>http://tc.eserver.org/12929.html</guid>
		<description>Maybe you don&apos;t have a project that&apos;s all your own. Or, maybe you don&apos;t have many completed projects to show a prospective employer. But, you do have skills in planning documents, compiling and organizing information, writing, editing, and designing...right? Put those skills to use and create an annotated portfolio of your work that includes excerpts of what you have done, demonstrates your capabilities to develop documents, and makes potential employers look twice. But wait. How can you create a portfolio without actual portfolio pieces? You can, by examining what you have done, examining what skills you&apos;ve contributed, gathering reader/boss/coworker comments, and developing a cohesive document.</description>
	</item>
	<item>
		<title>How Come....</title>
		<link>http://tc.eserver.org/10794.html</link>
		<guid>http://tc.eserver.org/10794.html</guid>
		<description>How come...everyone still says there is &apos;an error in the docs!&apos;</description>
	</item>
	<atom:link href="http://tc.eserver.org/publisher/TECHWR-L.xml" rel="self" type="application/rss+xml"/>
</channel>
</rss>