Why did it take me so long to learn...

• Never write an email response when I'm angry. Waiting 24 hours can mean the difference between a relationship-straining diatribe (and looking whiny) and a rational appraisal of a situation with reasonable recommendations.
• Don't use "Reply All" to show others how smart I am by taking on [whatever, whoever]. I now limit my distribution of "I think you did something wrong" e-mails to the individual. The serendipity is that half the time I'm wrong, and I'm saved the public embarrassment of their "Reply All" that makes that obvious to the world. I took a course in grad school that helped me analyze my interaction style. I titled the summary paper that described my newly found insight "You're Wrong and I Must Warn the Others." If that describes how you interact in groups, you might want to put it on your list of "things to work on." (BTW--I'm still working on it.)
• When having to choose between the best solution (as defined by, uh, me) and a consensus, go for the consensus. The theme of me being wrong half the time applies here as well--the compromise is not such a compromise since half the time (at least) my best solution would have been wrong.
• Don't squander the opportunity to lose an argument.
  

Layoffs

The news this week was that IBM laid off 5000 workers in the US. Some take-aways for me:

• No matter how strong you are, you can't be stronger than your customers. IBM looked at the numbers and said we need to be leaner in the coming year. Anyone watching the news could have seen that coming.
• When you work for a good company, good people get laid off. Why? Because there aren't any bad people to lay off. Those of us who kept our jobs need to reflect on that with a bit of humility.
  
• In a bad economy, avoid specialist roles like "special adviser" or "ombudsman." If you're out there all alone on an org chart, well, it's as good as wearing a target. Avoid being an infrastructure person; try to be writing words someone is ultimately paying for (i.e., user-facing doc).

I got some insight from our director about how this sort of thing works. I'd seen it from the inside before, but his clarity gave me fresh insight.

It starts at high-level management as a dollar amount. "Our income and our burn rate are misaligned by this much, therefore we need to cut x dollars." Payroll is the deepest pocket, so that's where you have to go if x is a big number. Then middle managers do some calculations and x dollars is translated into y headcount. From then on, y becomes "the number." Lower level managers divvy up y among even lower level managers until some sub-component of y is communicated to a line manager who must convert that number into names, that is, actual people who have to figure out how to make mortgages and buy food.

It's a cold calculus and a heartbreaking one that gets more so as the process trickles lower and lower. It probably works because the ones at the top who have to start the ball rolling are insulated from the humanity where the ball lands.

So if you lose your job, take some solace in the coldness; it was never about you and it wasn't because of anything you did. If you keep your job, it doesn't mean you are better than those who didn't, just luckier, perhaps.

May we all be lucky.

Because I said so

A colleague sent me a link to a blog by someone leaving Google. The person joined Google seven years after it had been founded as its "first visual designer." He refers to himself as a "classically trained designer" and contrasts that to the other designers at Google, who had backgrounds in CS and HCI.

It reminded me why I have trouble working with visual designers. I deconstruct his blog to be saying, "It got frustrating not getting my way on the merits of my stated, expert opinion, but having to actually justify and convince non-classically trained people--often being asked to justify my decisions with USER DATA (how pedestrian!)."

I think technical communicators are grounded more in the social sciences and rely less on the kind of connoisseurship I find with visual designers. For example, I'm involved in fewer and fewer discussion where someone says "It just doesn't sound right to my ear." In most discussions I have with technical communicators, they have reasons and research to back up why this combination of words is more suitable than another combination.

Not that I don't work with visual designers who do the same. It's just that with visual designers I'm more likely to encounter the "because I have taste and you don't" rebuttal. (I have yet to get a good explanation for why Comic Sans is a bad font.)

Imagine going into engineering meetings and justifying my suggested changes to the UI labels by saying, "Because I am a classically trained technical communicator." Like THAT'S going to work.

My point is that I'm glad it doesn't work. I don't mind basing my decisions on principles and research that can be empirically validated. It's part of what makes me a professional.

Miscellany

A day in the life

Tom Johnson has an interesting post on Quick Reference cards that has double value. For one, it gives good advice on what to do and what to avoid. More importantly, though, it is a great snapshot of what a technical communicator's life is like. I highly recommend it to my academic friends to share with your students, especially those who have not yet started working in the profession. It's not a depressing snapshot, but it does provide a splash of reality in the face.

Shhhhh

In the never-ending cube versus office and office versus home discussions, I often hear the argument for the need for a quiet place in which to concentrate. For a lot of my career, the people who invented the stuff I documented have worked in the chaos of common work areas with couches and foosball tables. But to document their output seems to require quiet and to edit that documentation requires greater quiet.

I have no beef with any of that, but it reminds me of an observation I have made about sports, namely that we are wildly inconsistent with our expectations of crowd noise. For example, in baseball the pitcher throws the ball ninety miles an hour at the batter and puts all kinds of curves on it, but the crowd is hysterical "Batta, batta, batta, suhwiiiing batta." In tennis, the server throws the ball to himself and we are all "Quiet, quiet, quiet, everyone, he's SERVING."

In golf the ball isn't even moving and the player is trying to put it into a hole in the ground (not very likely to be dodging around) and again, "Quiet, quiet, quiet, everyone, he's PUTTING." But a quarterback has to hit a moving target while monster-size opponents try to give him a concussion and again, the crowd is screaming.

No point here, just a pithy, Friday morning observation. Life is good these days.

Bless their hearts award #09-3

Scenario
This award goes to my ubiquitous user, me, who demonstrates that sometimes the user really is stupid, no really!

I signed up for Skype, the VoIP application, so Tom Johnson could do an interview with me. I had heard about it but had never used it, so I was sort of insufferably pleased with myself over being with it. I told my wife that she was "like so yesterday" and that I had grown. She told me to pick my socks up off the bathroom floor. (Thirty-six years of marriage fosters this kind of crystal clarity in a couple's communications.)

At any rate, this week I started noticing that lots of Web sites had Skype-friendly phone numbers. Example:


As the week went on, I found I was noticing these more and more. I thought, "Funny, once you become aware of something, it seems like you start noticing it everywhere." After several days it dawned on me: I was noticing it everywhere. Part of installing Skype means that it causes your browser to display phone numbers this way. Can I say business model?

Lesson learned
Sometimes the user makes stupid mistakes or stupid assumptions, and there is nothing in your design or your user assistance that can stop that. It's OK. Your application doesn't have to be fool proof, just try to make it so fools don't hurt themselves. Keep the error messages friendly and maybe take a lesson from my wife:

Bring It On!

I spent a lot of my holiday working on my January column for UXmatters, which I just sent to my editor this morning. I spent a lot of time on it because it is really my strategy statement for my own professional survival and our collective professional survival as user assistance writers in the upcoming new economy. Some highlights:

User assistance groups that survive will do so by doing the following:

• reducing documentation costs
• improving the relevance of the content
• integrating documentation more closely with the product’s user interface
  

Recommitting to user centered design will be evidenced by the survivors in the following ways:

• Starting their research by talking to the product manager and not the developers. The question of the new economy is not “How does the product work,” but “What do the users hope to accomplish with this product and how does that support our business model?” Other questions will be “How do the users measure their own success and how will they evaluate us?”

• Building use cases that focus more on when and why users interact with the system—and less about how. Emphasis needs to be on context, “Why/when would the users go here, what are they trying to achieve, and how will they know if they achieve it?”
  

• Writing documentation primarily for users who are in the middle of something. Users go to the documentation when they are stuck in their own tasks and get out of the documentation as soon as they feel unstuck. Survivors will analyze user tasks for information requirements and decision points that might stop the user’s task flow. Solutions in the new economy will be minimalist and designed to get the user going again as soon as possible. Writers who succeed in the new economy will know that ultimately the user’s solution is in the user interface, not in the Help.

• Integrating user assistance into the user interface. Because the solution to the user’s problem is in the user interface, that’s where the user assistance belongs. User assistance will not be apparent to the user in many cases; it will be just another aspect of the user interface.

• Basing their information design decisions on real user data, such as usability testing and contextual inquiries. We have ignored the data in front of us for two decades—users don’t read the documentation—but this new economy has rung the bell and we must now pay better attention.

The column will give some practical advice on gathering user data that informs user assistance design to deliver useful user assistance. It also will present my effort to redefine myself as cute (assuming the editor does not cut my MOOPOP mascot). I'll post a link to the column when UXmatters publishes it.



MOOPOP = Moments of Opportunity, Points of Pain.

Meanwhile, happy new year to all. Fasten your seat belts and hunker down for interesting times. If we are here a year from now, it will be because we changed and adapted to deliver greater value at a lower cost.

What's in your backpack?

My buddy Miranda Bennett apparently shares my life philosophy of "Anything worth doing is worth overdoing." She wanted to get more exercise so she took up backpacking on the Appalachian Trail. You go, girl.

Someone in the group she joined was helping her sort through her backpack and gave her the following observation, "Your gear is your fear." Apparently, it's an esoteric principle known to backpackers and essentially means that whatever you're afraid of will be reflected in what you overpack. So if you're afraid of getting lost, you might have four maps, two compasses, and a GPS. Afraid of being wet? Two ponchos, galoshes, and five changes of clothing.

Every now and then I get that old "fight or flight" reflex at work. I doubt if I'm unique in that. But I'm a technical writer, and no one is chasing me with a hatchet and there are no lions hungrily walking our halls. So I have to ask, "What am I afraid of?"

If that happens to you, look at your gear. Not now, it won't work. Wait until you have that adrenaline rush that says get the hell out or stand your ground swinging. When that happens, take a serious look at your gear, that is, the artifacts, books, tools, and other stuff you have surrounded yourself with. You could also check out the emotional baggage you like to haul around as well.

Keep what you need, put some of it away, and then walk your trail.

Thanks, Miranda!

For a few moments I was special

Those not following national news, Georgia had the last contested seat in the Senate up for a run-off election. Well, to make a long story short, I GOT A CALL FROM BARAK OBAMA! That's right, the president-elect called me. The only problem was that I couldn't get a word in edgewise, he just talked and talked as if he wasn't listening to me.

Well, at least he called. I wonder if I need to put him on my holiday card list now.

Will Write for Metamucil

I almost started today's blog with "I'm getting old" and then decided that's not true. I am old. I tried my best not to get old. Physically I tried to avoid it by drinking and smoking and not exercising, but that didn't work (at least not yet). Professionally I have dutifully tried to keep up with the trends: I DITA, I Wiki, I blog, I tweet, I have a translator on my blog, and I have a page on FaceBook. I also have a pair of bell-bottoms but that doesn't make it 1970 again. (I don't really have a pair of bell-bottoms, that was just a literary device.)

About nine years ago, I was giving a talk on Web page usability at a CDC conference and a gentleman in the audience asked a question about how to make his health Web site for young African American males more engaging. I thought about it for a minute and then gave him my best counsel: "Don't take the advice of a fifty year old white man."

I am feeling the same way about technical communication in general these days. I am steeped in a literary world view that is grounded in the static page. I grew up reading books, papers, and magazines. I did not work with text on a computer screen until I was in my forties--and then it was green screen command-line word processing where you had to actually print the document to see what it looked like.

Keith Lang dedicated an entire blog post to a rather blistering critique of my latest column in UXmatters. My biggest "ouch" response came to this paragraph.

The article is like bad help. It’s too long. It’s too dry. It has no narrative, and it’s written for the kind of people that like to read manuals. I’ll admit it, I’m one of them, but I’m aware I’m the small minority. The pictures are boring. It has no characters, story, or SEX to it. And it’s text, text text.

Not surprisingly, Keith is quite a bit younger than I am, but it reinforces a truth I have come to accept: I am ill equipped to write for an emerging segment of the marketplace.

But that doesn't mean I'm used up like a worn-out number two pencil stub (my favorite simile these days). But it does mean that I need to reevaluate where and how I add value.

For example, Keith included what he called a"nice example" of a built in help video:
It is very nice. A couple of questions: What does this video do to your translation costs, assuming it has a sound track? And how well will the image of a young woman with exposed bra straps play in conservative cultures such as with Muslims? (See my earlier blog about the BBC article in English and Arabic.) Maybe Keith isn't thinking about global markets. After all, his blog does say about comments: "here's how to have your comment approved and published: - Make it in English (my only language)." Sort of says, "If you don't speak English your voice is not welcome here." So maybe part of my emerging role as an elder is to remind the Keiths of our profession that cartoons and cool need to translate across wide cultural boundaries, and input needs to be open to diverse cultures, some of whom might not write your language well.

I'm not picking on Keith, I have have encountered similar gaps before with designers I know well and I respect a lot. People like me, that is, ones with an ingrained world view of communication-as-words, need to bring in designers who have grown up with a more interactive experience with communication channels. If nothing else, they are more like the market place than I am.
But this does bring up the core question of this blog: What is the role of older technical communication professionals like me?

Well, I don't think I should just shut up altogether (although I should shut up a lot and listen more--but that's been true for forty years). But what value do I bring to the party that could help my younger colleagues be even more successful with their innovations? Some suggestions:

• I think I understand the business model better at times than they do. I can help them focus on how their ideas add value not only to the user experience but to the success of the enterprise that pays their salaries.
• I value sustainable processes more than they do. I can help move their innovative ideas into the factory and make those nifty things they do scalable.
• And my somewhat conservative technical communication style probably still plays better in highly technical, complex problem spaces like configuring firewalls than a video or a cartoon would. And that style translates efficiently across cultures and languages.
  

I should probably try to get a job with a high-tech global company.

Time change

I hate it when the time changes from daylight saving time. It's such a pain to get up at 2:00 am to reset my clock. They should make it occur at a more convenient time.



What!?!?

Step away from the keyboard!

You know what never works out well? Letting technical communicators get involved in legal documents. When I do it I end up in tears; when I watch others do it I find myself shaking my head and saying "Bless their hearts."

We want it to be clear; lawyers want it to stand up in court. I've come to accept that there just is not much overlap in that Venn diagram.

Solution? Let them have their way.

My Recession Strategy

Yikes, the economic news is certainly scary these days. So what do you do if you think layoffs are coming?

Get into the top third

Every boss right now is making a list, real or mental, that focuses on which employees are in the top third and which are in the bottom third. Get into the top third of that list by doing the following:

• Add value in the areas that your boss will be evaluated on.
• Make your boss's job easier/more pleasant.
  

Some examples for adding value:

• Is your boss tasked with off-shoring certain aspects of the work and you've been the lone voice of reason in the wilderness pointing out the foolishness of such an endeavor? (Substitute the appropriate goal: implementing DITA, going to a new CMS, etc.) Step one: Shut up! Step two: Find ways to make it work.
• Yeah, yeah, we're all about the user, yay user, but take a look at ways to cut development time, production costs, etc., and let your boss know what you're doing there as well.

Some examples for making your boss's job easier or more pleasant:

• Be happy. Seriously, people would rather work with happy people than with chronic whiners.
• Having personality conflicts with someone? Get over it or at least appear to. If someone is habitually whining about you and you have nothing bad to say in return, you make the top third, he makes the bottom third.
• Having legitimate work conflicts? Stay positive and work through the solution.
• When discussing issues with your boss, have a success path defined--don't tell them how the project will fail.
  

Remember, in a layoff, the decision as to who goes and who stays will be made for some rational reasons and some emotional reasons. Cover down on both.

One more thing...

Oh yeah, start going to your local STC chapter meetings. Never hurts to fire up the network before you need it.

Good news, bad news

Language! What a tricky thing--and once again I am in awe of the ability of technology to make me smarter. I used the word "bellweather" in an email to someone today and my spell checker informed me that it should be "bellwether." I had always assumed that a "bellweather" referred somehow to a bell that rang in strong wind and therefore was an indicator of impending weather, and hence its more metaphorical use as a trend indicator. The corrected spelling made me doubt whether (no pun intended) or not I understood the word so I cut and immediately pasted it in my Wiki search widget on my default browser page. Oh my:

A bellwether is any entity in a given arena that serves to create or influence trends or to presage future happenings.

The term is derived from the Middle English bellewether and refers to the practice of placing a bell around the neck of a castrated ram (a wether) leading its flock of sheep. The movements of the flock could be perceived by hearing the bell before the flock was in sight.

Well, the next time you're thinking about whether to be a leader or a follower, you might want to keep that castrated ram thing in mind.

I should have paid more attention in geography class

Well, I finally ran out of bottled water and canned beans, so I emerged from my duct-taped basement ready to fight for my life and country against the Russian invaders. Well, am I embarrassed! It seems there's a whole country somewhere also named Georgia, and it was invaded, not my state. I need to become more global.

Congrats to Jimmy Wales

Fresh from STC News and Notes: "Jimmy Wales, the founder and creator of Wikipedia, has been selected as STC’s 2009 Honorary Fellow."

I expect this announcement to create its own share of controversy. STC's top honor going to someone who cuts technical communicators out of the loop?

Well, we're out of the loop only if we choose to be out of the loop. One way to define Wikipedia is as a technology intervention to connect people with answers to people with questions. Sounds like technical communication to me. I think Wikipedia is an icon to where we are going as a profession: less about grammar and style guides and more about presenting information as performance support; less about creating content and more about orchestrating the distribution of that content.

It doesn't mean we will quit writing, quit editing, or quit publishing. It's just that like the passing of the literary clergy of days gone by, we are no longer the exclusive keepers of the book.

But just in case Wales' honor adds to your angst already brought on by offshore non-native writers, machine translators, mechanical spelling and grammar checkers, and you're wondering about the need for technical communicators--there are a few areas we can focus on that will let us add value above and beyond our commodities that are getting eroded:

• User analysis as problem analysis and information as performance/decision support, i.e., what does the user need to know in order to make an informed decision at this point in her work flow
  
• Dynamically generated user assistance (If Amazon.com can figure out my reading preferences and Google can guess what ads I'm most likely to respond to, why can't my Help track where my user has been, what system configurations she has set and give her tailored Help. Why does my Help say "If you are in Routing mode do this; if you are in Transparent mode do that." Why doesn't the application tell the Help what mode the user has configured and deliver a dynamic Help page that gives only the appropriate information?)
• Integrating our communication skills to improve the design and development process, as in use case development

At any rate, job well done, Jimmy, and thanks to a forward-looking selection committee for making Mr. Wales an Honorary Fellow.

Errors and Humanity

A recent article by Scott Abel on Content Wrangler about TEAL, a group whose quest is to correct the typographic errors of others, got me thinking about errors. That vector is intersecting with some reading I've been doing lately in "Orality and Literacy" by Walter Ong (at the suggestion of someone to one of my earlier blogs).

First of all, we sometimes misuse the word "typo" as in typographical error. According to Wikipedia, "A typographical error or typo is a mistake made during, originally, the manual type-setting (typography) of printed material, or more recently, the typing process. The term includes errors due to mechanical failure or slips of the hand or finger, but excludes errors of ignorance." Checking other dictionaries supports that definition.

The mistake discussed in the Content Wrangler article failed to meet these criteria on two counts: (1) The mistake occurred in a hand-written sign, which would make it a chirographic error and (2) It was not a mechanical slip; it was a mistake in applying the apostrophe rule.

Scott and I had a fun discussion and I'm not blogging to belabor my point; it's just that I have a genuine interest in the different ways we make mistakes and would like to explore it a bit--not sure this will go anywhere useful. Here's my starting taxonomy:

• Typographical--More or less mechanical slips such as wrong letters or metatheses, such as my habitual typing of "form" when I mean "from."
• Oral--Where we use homonyms inadvertently, such as "there" for "their" or "too" for "two." Almost a mechanical slip, but not really, and one not caused by ignorance but rather by the hasty grabbing by our mind of a spelling from the wrong box but one located near the correct box. I also include subject/verb disagreements caused by singular words that sound plural, such as "My interest in this area are clear."
• Drops--Where a word that was in the writer's head just never makes it to the page, e.g., "I've been meaning write you..." I think this is caused by the writer's thoughts getting ahead of his fingers. It's often missed in rereading because of the Gestalt of filling in blanks based on knowing the broader context.
  
• Spelling--No accident, the writer didn't know the correct spelling.
• Punctuation--No accident, the writer thought there should be a comma and there really should not have been.
• Grammar--Breaking the rules that define conjugation and inflection.
• Usage--Wrong word for the context, such as , uh, typo to describe a punctuation mistake on a hand-written sign (OK, I am belaboring the point).
• Factual--What the writer said can be refuted by evidence or authoritative sources, e.g., "There are 51 states in the US."
• Logical--The structure of the discourse and the premises do not support a conclusion.
  

The last three--usage, factual, and logical--are major errors because they lead to miscommunication. When the others do not miscommunicate (and sometimes they do), they are minor infractions that might reflect badly on the writer but do not mislead the reader.

I think people worry too much about the minor infractions in instant messages and blogs. How often do we get an IM with a typo or oral only to get an immediate follow up like "oops, I meant two not too :-0 " Personally I think the error is part of the oral nature of IMs and the correction does more harm by interrupting the flow of the otherwise spontaneous conversation. In my comment to Scott's article I wrote "technical communicators at their worse." Oops , I know it should have been "worst" but that's the nature of a free and spontaneous engagement using language.

I'm not advocating that we get lax in our own standards, particularly as they apply to our professional, written communications. But let's be more forgiving of these patterns (yes, that's what they are, more so than mistakes) when they occur with others. Just because a restaurant can't get the menu right, doesn't mean they can't cook. Put the red pen away and enjoy your meal.

Why I Hate PDFs

Not all PDFs; that would be over the top. I just hate user manuals that are distributed as PDFs.

1. They are mainly used online so why the artificial page constraints? I'm in the middle of a topic and all of a sudden there is a page break--not because of a topical shift but because had it been printed on 8.5 x 11 we would have run out of paper. News flash: I didn't print it and I was not running out of paper.
2. Don't hand me that "search online and then print what you want to read malarkey." If that was the plan, there would be only one set of page numbers, not a "paper" page number and an "electronic" page number that make me guess which one the printer dialog box is asking for. I know you can match them up, but most writers don't; it violates "good book design" to start counting at the beginning. That's why we all know that if the page number is a Roman numeral, there is no useful content on that page.
3. They are laid out as if they were going to be printed--and printed in duplex at that! If the company is too cheap to print, then at least make it easy for Joe Schmoe to print and stop with the recto/verso page layouts.
4. They carry so much book overhead: book front cover pages, book back cover pages, inside cover pages, chapter cover pages. It takes me three clicks to get to a topic that actually says something.
5. There are too many of them and they are named after obscure roles--none of which describe me. I've never met a system administrator, never saw the job title anywhere I worked, yet there are a bazzilion guides out there written for that person. I always suspect that what I need is scattered across three different guides. Give me a single source where I can ask my question once and get all my possible results.
6. They just scream, "Books are what I know how to write; books are what you get."

User books died; if they had value in that form, companies would still print them and users would buy them. Yet PDFs still hang around like pathetic home town sports fans after the team has moved to the West Coast. Quintus in The Gladiator says "A people ought to know when they've been defeated." PDFs should get the wake-up call.

[Yes, I quoted The Gladiator. It's one of my favorite movies; you might want to take that into consideration when deciding how much credibility to give my opinions.]

Guess who's talking

A little side trip again away from reuse. I was visiting with my sibs in Florida and was picking up a bar tab (since I am typically the major contributor to the total). The waitress delivered me two credit card tickets, one labeled "Mine" and the other labeled "Yours."

So which one do I keep and which one do I give back to her?

Had she handed them to me and said "This one is mine and this one is yours," I would have given her the one about which she had said "This one is mine." But because it was in writing, I was inclined to keep the one that said "Mine." I guess because as I read it, the voice in my head was my voice and I identified "Mine" with me. But the "Yours" didn't work in that scenario since I wasn't talking to anyone other than myself. I think I kept "Yours" and gave her "Mine" not feeling any too comfortable that I had gotten it right.

But boy, what a lot of thinking just to figure out which to give back of two documents that would have been the same except for the label that tried to differentiate them.


Why not "Customer" and "Merchant"? like most do? That is not ambiguous.

Or even "Give us one and keep the other."

Or don't label either. Then if I asked which one she wanted she could say, "The one with the big tip on it."

Side Track

I just generated a PDF of a draft of a user guide I am working on. I've included the obligatory front matter and Chapter 1 starts on the 23rd page.

And we ask why users don't read our stuff.

:-(

A techwriter dies and goes to heaven...

and she finds herself at the pearly gates before St. Peter. He looks over her record and decides she is worthy to enter heaven.

"We've upgraded our services recently," he tells her, "so that you now have access to a more personalized heaven experience. Since you are a technical writer, I'll show you several versions of heaven behind some of those doors over there that have been expressly designed to enhance the technical communicator's heaven experience."

"Wow," the techwriter replies with excitement.

"The only problem," St. Peter tells her, "is I just got a text message from the boss and I have to handle it. I'll be back in a few minutes and then I'll give you a tour of your heavenly options."

With that, St. Peter steps away, leaving the techwriter standing in front of three doors. Her curiosity gets the better of her and she opens the first door. There she sees a work station with a bazillion-pixel, high def screen, screaming CPU with graphical coprocessors, loaded with all of the latest authoring tools and a high-speed connection to the UWW (Universal Wide Web). She tries a Google search and instead of getting two-million hits she gets just five, and they are the perfect five.

"This is way cool," she thinks to herself.

She decides to see what's behind the second door. There she finds a cosmic Starbucks. Instead of walls and windows, the table are open to the entire universe and you can almost touch the planets and the stars. Instead of paper cups, the coffee is served in deep blue china mugs. She sees a person putting sugar into her latte (in heaven sugar has no calories) when a tiny paper clip walks across the table and knocks on the mug with a sound of tiny knuckles on glass--tink tink tink!

The paper clip speaks, "I see you're trying to sweeten your coffee, can I ..."

At that point the person fixing her coffee picks up the paper clip, takes a rubber band, and shoots the paper clip out into the vast emptiness of space.

"How cool is that," says the techwriter.

St. Peter hasn't returned yet, so she looks behind the third door. There she sees a technical communicator in a meeting room with developers and she is discussing a user interface being projected onto a screen at the front of the room.

"For one thing," she says to the developers, "you've used 'data base' as two words in the title but as one word in the actual screen. Our style guide says database should be one word."

There is a general round of approvals and one of the developers says, "That's why we need technical communicators on the team."

The technical communicator at the front of the room continues, "And if the user doesn't put the right date format in the date field, you pop up a rather cryptic error message. I think you should just put in some client-side scripting that accepts the user's format and converts it to the format the database requires."

Once again, a general round of approvals and someones says, "Of course, it takes a technical communicator to see it from the user's side. We were too focused on the back-end requirements."

And then the technical communicator says, "I have a report from a usability test we did with real users doing authentic tasks with this UI. I can make the results available to you."

Once again, enthusiasm abounds around the table and someone says, "This is why we need technical communicators on the dev team, they keep us focused on the user, and they have real data to back it up."

At this point, the techwriter hears St. Peter returning and she hurries back to the gate.

"Well," St. Peter says, "let's show you some options for your personalized heaven experience."

"Oh, St. Peter," she says, "I can save you some time. I found my technical communicator heaven; it's behind the third door."

St. Peter looks disappointed. "Oh no," he says, "there's been a misunderstanding. That's not technical communicator heaven; that's the door to developer's hell.