A directory of resources inthe field of technical communication.

TECHWR-L

54 found. Page 1 of 3.

About this Site | Advanced Search | Localization | Site Maps
 

1 2 3  NEXT PAGE »

 

1.
#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

2.
#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

3.
#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

4.
#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

5.
#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

6.
#13941

A Day in the Life

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.

Hart, Geoffrey J.S. TECHWR-L. Humor>Workplace

7.
#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

8.
#13830

Designing for the Other Half

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

9.
#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

10.
#19590

Devil's Advocate

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

11.
#19180

Escape From the Grammar Trap

Too many editors focus on the details and don't pay enough attention to the bigger picture. Editors can--and should--add even more value through substantive, technical, and usability editing. 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's needs. 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.

Weber, Jean Hollis. TECHWR-L (2002). Articles>Editing>Grammar

12.
#14141

Estimating Worksheet

An example worksheet for generating TC job estimates.

TECHWR-L. Resources>Workplace>Pricing>Estimating

13.
#14139

Example Style Guide   (PDF)

This document accompanies the TECHWR-L article 'Developing a Style Guide,' 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 'correct' choices, or the 'preferred' choices, or the 'best' 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.

Weber, Jean Hollis. TECHWR-L (1998). Reference>Style Guides

14.
#13487

Feng Shui for the Tech Writer's Workspace

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'd likely press Delete faster than you can say 'looming deadlines.' 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 'magic' secret's power? In that case, you just might sit back in your office chair and listen.

Chroust Ehmann, Lain. TECHWR-L (2002). Careers>Workplace>Ergonomics>SMEs

15.
#14256

The Five W's of Online Help

For decades, journalists have used a proven approach called the 'Five W's' 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've already written about this in the context of audience analysis (Hart 1996). In this article, I'll show you how you can use these questions to develop more useful online help. Each of the five W's is a simple question that starts with the letter W: Why, Who, What, Where, and When. Some authorities add a sixth question, 'How,' to this list, but 'how to' 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'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've presented these five questions in an order that seems logical to me, in practice the approach becomes iterative: It doesn't much matter where you begin, since answering one question often reveals important aspects of the other questions that you'd not yet considered.

Hart, Geoffrey J.S. TECHWR-L (2002). Articles>Documentation>Help

16.
#13363

Gender-Neutral Technical Writing

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's intention. In this article, you'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.

Weber, Jean Hollis. TECHWR-L (2002). Articles>Writing>Style Guides>Gender

17.
#22455

Review: Hot Text: Web Writing That Works

This book will help you improve any type of written communication, and it's a fun read to boot. The authors know what they'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.

Frick, Geri. TECHWR-L (2004). Articles>Reviews>Web Design>Writing

18.
#19515

Increasing Visibility: Building Demand for Technical Communication Services   (Word)

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.

Huettner, Brenda P. TECHWR-L (2003). Articles>TC>Workplace

19.
#26126

Increasing Visibility: Building Demand for Technical Communication Services

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.

Huettner, Brenda P. TECHWR-L (2005). Articles>TC>Marketing

20.
#32228

Inspiring Reviewers to Review Your Documents

To obtain good reviews, you must make the process as painless as possible for reviewers.

Hart, Geoffrey J.S. TECHWR-L (2008). Articles>Editing>Collaboration>SMEs

21.
#32230

Making the Mentor Partnership Work: Part One (for the Mentee)

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.

Chroust Ehmann, Lain. TECHWR-L (2008). Careers>Mentoring

22.
#32229

Making the Mentor Partnership Work: Part Two (For the Mentor)

When you act as a mentor, you're agreeing to serve as an ad hoc advisor and sounding board to someone less experienced in the career world than you.

Chroust Ehmann, Lain. TECHWR-L (2008). Careers>Mentoring

23.
#28361

Master Documents   (PDF)

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 subject from other sources, yet many writers use them regularly because there is no other choice, it is fully covered here.

Hudson, Steve. TECHWR-L. Articles>Software>Style Guides>Word Processing

24.
#31964

Networking Your Way to Success

You don'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. You might ask, "What resources?" 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!

Chroust Ehmann, Lain. TECHWR-L (2008). Articles>TC>Community Building>Collaboration

25.
#12941

Nobody Reads Manuals, Do They?

We technical writers have a mantra that we mutter quietly whenever someone asks an obvious question about how to use our software: 'RTFM.' But though Reading The (ahem) 'Fine' 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'd rather play with a product, hoping to figure out what to do, than use the documentation.

Hart, Geoffrey J.S. TECHWR-L (2000). Articles>Documentation>Usability

 
 NEXT PAGE »

 

Follow us on: TwitterFacebookRSSPost about us on: TwitterFacebookDeliciousRSSStumbleUpon