#12966
Adaptive Technologies for the Visually Impaired: The Role of Technical Communicators
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.
Ray, Deborah S. and Eric J. Ray. TECHWR-L (1998). Design>Accessibility
#14143
Annotated Cover Letter: Using Block Style Format 
An annotated sample cover letter for applying for a tech comm position.
Ray, Deborah S. TECHWR-L (2000). Careers>Resumes>Cover Letters
#26124
Avoiding Repetitive-Stress Injuries: A Guide for the Technical Communicator
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'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'd recorded 2440 feet of mouse movement and nearly 22 000 mouse clicks. It's no wonder computer users sometimes experience serious physical problems.It's no wonder computer users sometimes experience serious physical problems.
Hart, Geoffrey J.S. TECHWR-L (2005). Articles>Human Computer Interaction>Ergonomics>RSI
#23278
Avoiding Repetitive-Stress Injuries: A Guide for the Technical Communicator
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 'repetitive-stress injury' (RSI)--simplistically, any injury that results from overuse of a body part without giving it time to recover. In fact, 'overuse injury' is probably a more immediately obvious term, and given how much time many of us spend using computers, overuse is indeed a risk.
Hart, Geoffrey J.S. TECHWR-L (2004). Articles>Human Computer Interaction>Ergonomics>RSI
#26745
"Backing Up" Doesn't Mean Retreating
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.
Hart, Geoffrey J.S. TECHWR-L (2006). Articles>Technology>Security
#19529
The Benefits of a Job Well Done 
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.
Wisman, Ken. TECHWR-L (2003). Humor>Documentation>Software
#12931
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.
Holtz, Herman. TECHWR-L (2001). Articles>Writing>Publishing
#21664
Boredom: The Secret of Tech Writing
Of course, it'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.
Higgins, Lisa. TECHWR-L (2000). Humor>Writing>Technical Writing
#14142
Following are questions and issues that should be covered during early meetings with a client, including general project questions, questions specific to documentation, and questions regarding scheduling, reviews and administrative issues. Thanks to TECHWR-Ler Judy Fraser for providing this awesome summary.
#31975
Conducting Effective Team Technical Reviews
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. 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's described here, you can apply the information in part or in whole to improve your current review process.
Brown, M. Katherine 'Kit'. TECHWR-L (2008). Articles>Project Management>Collaboration>Assessment
#14498
Conquering the Cubicle Syndrome
Cubicles aren't really physical walls--they're a state of mind. In effect, it's the belief that you'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.
Hart, Geoffrey J.S. TECHWR-L (1999). Careers>Workplace>Collaboration
#21692
Review: Content Management for Dynamic Web Delivery
Content Management for Dynamic Web Delivery provides background and process for implementing content management in an organization. You don'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.
Frick, Geri. TECHWR-L (2004). Articles>Reviews>Content Management
#13827
Content, Structure, and Relevance: The Ploy's the Thing
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. Content is one of the hot buzzwords of the new millennium. Without content, your site can be aptly described by MacBeth's despairing lament: 'A tale told by an idiot, full of sound and fury, signifying nothing.' (Substitute 'Flash and Shockwave' for 'sound and fury' and you've got the picture.) Despair describes the second of these three components, because if you don't create a site structure that helps people find all that fine content you've created, they'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 'the Scottish play' is reputed to be for actors. And the part about 'signifying nothing'? If the content that visitors do eventually find isn't relevant to their needs, they're not going to come back any more than Lady MacBeth will.
Hart, Geoffrey J.S. TECHWR-L (2001). Design>Information Design
#12948
Context-Sensitive Disaster: Designing the Difference Between Help and Print
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't appeared in the previous version (let's call this 'option X'), 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.
#12949
In December 1999, I asked: 'Is there any tool that currently exists to convert a bunch of html pages to pdf?' 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'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 'file:///' or 'c:\' It turns out that the syntax is the all important thing; I've used '|' (pipe) where ':' (colon) would normally be used after the C drive reference.
McCarthy, Christopher. TECHWR-L. Design>Web Design>HTML>Adobe Acrobat
#26599
Corporate Communication Boring? Jazz It Up With Case Studies!
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.
McMorrow, Virginia G. TECHWR-L (2005). Articles>Business Communication>Case Studies
#12935
Creative Problem Solving: Getting the Best from Yourself
You might think that as a technical writer, you don'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't mean just thinking up fourteen synonyms for 'display.' 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.
Chroust Ehmann, Lain. TECHWR-L (2000). Articles>Writing
#13941
If it's a good day, you arrive at work around seven o'clock, grateful for having missed the morning rush hour. Today'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't laugh; it'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's really appalling is that you're not sure whether it'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's not your problem right now.
#18692
A Day in the Life of a Technical Writer
This TECHWR-L Magazine section features a selection of quotations from active technical writers about what a day at work looks like.
#14497
Dealing with Difficult Employees in the Technical Communication Workplace
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're managing another employee and responsible for their work and their on-the-job behavior. For a variety of reasons, technical communicators are often seen as 'difficult' or 'problem' 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't bother to understand what we do and thus, don'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't get what we need. The result? We're forced to nag, and that can get us labeled as problems, not colleagues.
Hart, Geoffrey J.S. TECHWR-L (2002). Careers>Management>Collaboration>SMEs
#13830
Whenever we design something, we confront the problem of how to account for differences in our audience'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'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. 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's impossible to produce something that works equally well for experienced and new users.
Hart, Geoffrey J.S. TECHWR-L (2000). Design>User Interface>User Centered Design
#14140
Developing a Departmental Style Guide
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's more, you many find that style guides don't seem to have consistencies among them that can help guide you in developing one.
Weber, Jean Hollis. TECHWR-L (1998). Articles>Style Guides>Workflow
#12929
Developing an Annotated Portfolio
Maybe you don't have a project that's all your own. Or, maybe you don'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've contributed, gathering reader/boss/coworker comments, and developing a cohesive document.
Ray, Deborah S. TECHWR-L (2001). Careers>Portfolios
#12932
Developing an Article from the Ground Up
Whether it's at the request of your company's powers-that-be or out of your own personal desire to spread your wings, you may be thinking about writing an article. It'll be easy enough. You're a writer, after all. You already know how to research topics, develop information, and create a coherent document. You'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.
Chroust Ehmann, Lain. TECHWR-L (2001). Articles>Writing>Planning
#19590
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're supporting, then you stop listening so carefully, then you stop speaking the same language as they do. And since you're busy putting out fires all over the building, who has time to start listening again? Problem is, once you no longer empathize with 'them,' you forget that they've got their own unending stream of crises to deal with. But if you want to tame those devils, you'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'd suspect, the result is a win-win solution.
Hart, Geoffrey J.S. TECHWR-L (1999). Articles>Usability>User Centered Design
