Gary:
Don't like to make your task seem a bit harder, but have you ALSO
considered that you might need to have Nested includes in many such cases
if you really want single-source maintenance?
That is not always obvious initially, but may quickly become evident in
practice. In other words, you can use an include perhaps at one level,
but then you realise various components of your documents overlap to the
point where a second level (nested) include is needed within the first
level include -- and either have to redesign components and/or have a
mixture of some single-source maintenance with some multiple sources
(urk!)
A few years ago, I started using Confluence as a means of trying to
maximise single source maintenance. At first, I had major difficulties
using page includes but then Atlassian added nested includes, and it was
suddenly a good deal easier. There's probably a deal of water gone under
the bridges since then, but I'd mention that using nested includes could
allow for export to Word documents, last time I looked. Latter seems
long way around, however, if I had my druthers, with 150+ readers etc I
think I'd plump for Confluence as the tool and forget trying to get Word to
work.
Then of course, you could go the DITA XML route using map files that can
handle nested includes.....
-Peter M
On 23 April 2018 at 19:52, Garry <suss@xxxxxxxxxxx> wrote:
Hi All Again:
My shiny new employer, an org of 150+ staff, uses perhaps 50-60 scripts in
its call centre. These are Word docs. To my irkment, they are written with
tables (left col = heading, centre col = script, right col = notes).
Portions of common text/boilerplate are used in many docs.
The current solution is exactly what you would expect of an org in which
even Word 2016 styles are regarded as a dark art. Whenever a piece of
boilerplate is changed, it is manually changed in all the docs in which it
appears. Then a reviewer checks all the relevant docs to ensure the
boilerplate has been updated correctly.
This is driving me nuts.
What I am thinking of: Use Word INCLUDETEXT fields. Pro: Everything you'd
expect. Cons: Lots.
* I could never let the docs out of my sight again. The dears would be
befuddled by fields and field codes. I can see them deleting an entire
field while they write in their own text manually.
* They rely heavily on Track Changes to ensure I really have deleted that
comma**. AFAIK, changing the source of an INCLUDETEXT field would present
itself in Track Changes as though the entire boilerplate had changed.
Confusion would reign.
* INCLUDETEXT does not deal with table rows seemlessly. An INCLUDETEXT
table row leaves a para gap above and below.
* And, of course, there is no structure and security.
It has been a long time since I used anything but Word. Does anyone have
ideas for either (a) a robust way to use INCLUDETEXT fields, or (b) a
better solution in Word (Building Blocks don't seem to fit) or (c) a
replacement tool for Word?
Thanks for your time,
Garry
** As an example. Say I have to change the par "Go to Read Disclosures" to
"Go to Read Disclosures and Conditions". The sane way to do this would be
to make that change in one doc, zipply select the par in other docs, then
paste the new par "Go to Read Disclosures and Conditions" to all other
docs. Nup. Not allowed. I have to paste the specific fragment " and
Conditions" at the corrct insertion point to all docs, so it shows up in
Track Changes. If I pasted in the entire par over the old, the reviewer
would get confused. Sigh.
**************************************************
To view the austechwriter archives, go to www.freelists.org/archives/aus
techwriter
To unsubscribe, send a message to austechwriter-request@xxxxxxxxxxxxx
with "unsubscribe" in the Subject field (without quotes).
To manage your subscription (e.g., set and unset DIGEST and VACATION
modes) go to www.freelists.org/list/austechwriter
To contact the list administrator, send a message to
austechwriter-admins@xxxxxxxxxxxxx
**************************************************
