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.
I'm sure there are good reasons for your approach,
but I wanted to understand whether you were
suggesting that it is, in some universal sense,
"unacceptable" for end-user assistance material
to contain categories of information that only some
end-users need.
and I reply:
Thanks for clarifying your question. No, I wasn't
making a universal suggestion that user documentation
should be limited to just what a specific user needs.
It's our approach for this project, and I think that
customized documentation of this sort may become more
common, but it's definitely not going to become "the
way" to write documentation.
and Mike wrote some more:
It is just possible that your users' problems with
previous documentation could have been reduced or
eliminated by proven traditional design techniques
rather than technological innovation.
and I reply some more:
Our users' problems were DEFINITELY caused by poor
document design. However, we inherited a suite of
documents and got stuck in a tragic cycle of endless
releases and no time to make any substantial usability
changes. C'est la vie.
You raise a good point about the balance between good
document design and technological innovation. We spent
a great deal of time discussing structure, types of
content, visual presentation, relationships between
topics, style, etc. We also had to cut the content
into chunks that could be used in both the user
documentation and training materials without
"tweaking". XML was simply the mechanism we chose to
use to label and manipulate that content.
I hope this clarifies things. Thanks for asking such
good questions, Mike.
Cheers,
Rowena
__________________________________
Do you Yahoo!?
Yahoo! SiteBuilder - Free, easy-to-use web site design software http://sitebuilder.yahoo.com
NEED TO PUBLISH FRAMEMAKER CONTENT ONLINE? "Mustang" is a NEW single
sourcing tool for FrameMaker that lets you easily publish your content
online. No macro language required! http://www.ehelp.com/techwr-l3
Mercer University's online MS Program in Technical Communication Management:
Preparing leaders of tomorrow's technical communication organizations today.
See www.mercer.edu/mstco or write George Hayhoe at hayhoe_g -at- mercer -dot- edu -dot-
---
You are currently subscribed to techwr-l as:
archive -at- raycomm -dot- com
To unsubscribe send a blank email to leave-techwr-l-obscured -at- lists -dot- raycomm -dot- com
Send administrative questions to ejray -at- raycomm -dot- com -dot- Visit http://www.raycomm.com/techwhirl/ for more resources and info.