TechWhirl (TECHWR-L) is a resource for technical writing and technical communications professionals of all experience levels and in all industries to share their experiences and acquire information.
For two decades, technical communicators have turned to TechWhirl to ask and answer questions about the always-changing world of technical communications, such as tools, skills, career paths, methodologies, and emerging industries. The TechWhirl Archives and magazine, created for, by and about technical writers, offer a wealth of knowledge to everyone with an interest in any aspect of technical communications.
S>|} M>I have
S>|} M>heard that Microsoft charges the TW department for each call
S>|} M>Support takes. I don't know how well this works.
S>|} I hope they differentiate between software problems and document
S>|} problems. Overall, their documentation is good, except where they
S>|} happily tell you about features that don't work. Most of my calls
S>|} to software companies are because of program flaws, not because the
S>|} documentation didn't cover something.
S>Maybe I'm misunderstanding what you mean, Barb, but in my book, if I
S>happily tell your customer about a feature that doesn't work, that's
S>a document flaw. ``C'est plus qu'un crime, c'est une faute,'' as they
S>say, ``It's worse than a crime, it's a mistake!''
I understand what you're saying, and up to a point, you're right. I
should have clarified - the problems I've been seeing apparently occur
primarily with long, graphics-intensive documents. How much testing
should the technical writing folks have done to discover when the
product no longer worked? I think some problems do fall back into the
programmers' laps if it comes to blame-casting (and billing
departments).
