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.
Re: Doc Design and Convention ( was TECHWR-L Digest, Vol 48, Issue 27)
Subject:Re: Doc Design and Convention ( was TECHWR-L Digest, Vol 48, Issue 27) From:Chris Despopoulos <despopoulos_chriss -at- yahoo -dot- com> To:techwr-l -at- lists -dot- techwr-l -dot- com Date:Tue, 3 Nov 2009 09:32:22 -0800 (PST)
This is exactly what I'm talking about. I'm not saying it's the design of the product that's at fault. I'm saying that the task-oriented mantra has been abused. I'm not convinced that it's because non-writers have jobs. Haven't you seen examples of that stuff from people who made it through tech writing courses? Somehow they were *taught* to do that.
I'm also saying it's a result of old-think in modern times. There was a time when you had to explain how a mouse works. This thread started with the question, how much detail to use when describing a click? So we're still worried about whether people can figure out a statement like, "Click OK"?!?! Not really, but we're worried that we need to pay homage to that concern in our style guides. Bah!
If we have to formally work through this type of issue, why not go all the way and formally reevaluate the task-oriented mantra? Why not look at modern design methodologies and map them to new documentation designs?
(PS -- sorry about screwing up the subject line so often...)
# More to the point, I've thrown out and rewritten from scratch lots of
# docs that were nothing but a narrative, illustrated walkthrough of the
# UI. They didn't tell anyone anything beyond what they could see on
# screen.
#
# The problem was with the writers, not the design of the products. That
# was partly the result of the dot-com boom, when just about anybody who
# wanted to be a tech writer could find a job, even if they weren't
# capable of understanding the technology.
#
Are you looking for one documentation tool that does it all? Author,
build, test, and publish your Help files with just one easy-to-use tool.
Try the latest Doc-To-Help 2009 v3 risk-free for 30-days at: http://www.doctohelp.com/
Help & Manual 5: The complete help authoring tool for individual
authors and teams. Professional power, intuitive interface. Write
once, publish to 8 formats. Multi-user authoring and version control! http://www.helpandmanual.com/
---
You are currently subscribed to TECHWR-L as archive -at- web -dot- techwr-l -dot- com -dot-