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.
>How fields and pages are named, basic business rule, field behaviour, etc.
will be
>configured by editing a handful of XML files. Some basic workflows will
remain constant,
>regardless of configuration, but it is possible that every procedure will
need to look
>different from one customer to the next.
Been there, done that, have the flashbacks.
>Seems regular ole' FrameMaker to WebWorks files just won't cut it, since we
are not going to
>be touching up these user docs for each and every customer.
Depends on the scope you take. If you actually try to meet everyone's need,
then you're correct. You have no idea of predicting what you need to
document. However, if you document only what the application supports out
the door and make the help system extensible, you can give them a procedure
for dropping in their own help files. Another option is to use modules in
your Frame files (embedded Word docs using the same style names), give them
the Frame files and WWP templates to produce their own customized content,
and let them keep their own content up to date. There are a number of
approaches you can take.
Of course, I'm addressing only the technical issues here, and not whether or
not you should even turn over source files to a client. <shudder/>
>Has anyone dealt with this problem?
Yup. I documented only what happened on our end. That's all I could count
on. I gave very general instructions on what users needed to do in the UI.
Could'nt predict what those wacky software engineers were going to do, after
all.
>I was thinking it might be possible to make the procedure for a particular
page just another
>element of one of the GUI XML files that the admin would configure.
You're on an interesting track. You could use an external entity reference,
which would contain a fragment of XML (with multiple elements).
>We can put basic text in there, then highlight the information that will
most likely change >(though it would be nice for this stuff to get pulled
from the XML configuration, but that
>would require serious programming, something we don't have the resources
for..)
And that's the rub. A single-source XML production environment requires
programming resources, unless we as technical communicators make XSL part of
our toolset. I'm in the process of learning it, and it's no small feat
(well, not if you want to include XSL-FO). And I LIKE the stuff. However, if
we all had a base understanding of XSL, we could promote it and get more
programmers to take it seriously for things other than Web sites.
>Any thoughts??
Yup. Run. Or hire a consultant. A good one could help you determine the full
range of your options before you sink a lot of time into pursuing the wrong
solution.
ROBOHELP X5: Featuring Word 2003 support, Content Management, Multi-Author
support, PDF and XML support and much more!
TRY IT TODAY at http://www.macromedia.com/go/techwrl
WEBWORKS FINALDRAFT: New! Document review system for Word and FrameMaker
authors. Automatic browser-based drafts with unlimited reviewers. Full
online discussions -- no Web server needed! http://www.webworks.com/techwr-l
---
You are currently subscribed to techwr-l as:
archiver -at- techwr-l -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.
