Prologue

There is no individual part of document assembly that is rocket science. It is simply a case of making a list of everything your system will need, coming up with a naming schema for it, applying the naming schema and programming your documents. It is akin to being beaten to death with feathers - it takes a long time and its a lot of soft punches, but its doable. Unlike being beaten to death, there are large profits to be realised, so long as the planning and targeting of your development was done well.

I am aware that there are quite a few holes in this process, for which I am totally unashamed - really! To explain every painstaking detail of this process would not only be counter-productive (from my point of view), it would be far too verbose to be readable (I'm walking that line already...), and the explanation of every nuance would take years. What I sincerely hope is that this will help some budding document assembly developers build better systems, and start realising the true power of document assembly.

The real key is just planning.

• Have a system or approach that tracks everything you do
• Collect your template list
• Collect as many variations of each template as possible so you can program optional content for each template
• Open up each template, and then open up each document variation for that template and mark the variations - each template becomes a mini-master
• Rinse and repeat until the entire library is represented by a series of your master templates
• Design variables and dialogs to handle all the information required and ask all the questions necessary; this is your blueprint
• Review your blueprint and ensure you've been consistent and thorough
• Program your system, test and deliver
• Always take feedback. Its their system, not yours.

It doesn't matter how you achieve these steps. What matters is that you have a systematic approach to document assembly development.

Good luck and happy developing.