Clauses are snippets of text designed to be called into a document under construction 'one at a time.'  Assembly is typically accomplished via the Clause Selection Screen.

Templates are 'complete' documents. They typically contain automated <<*Optional*>> text blocks that allow the user to choose whether that block of text should be kept or deleted.


  A major decision that you, as the systems designer, will have to make in creating your first document assembly system is whether to build the system based on a 'clause assembly' model or a 'template' model. The text in the below section will help guide you in making that decision.
   But as you read the below text, keep in mind that it is really not an 'all-or-nothing' decision.  Our approach in designing Pathagoras was to provide you as much flexibility in system design as possible. You can mix the two approaches and easily go back and forth as you need to and learn more about how your end users will be using the source document.  And if you commit to one approach and decide to adopt the other, not to worry.  Pathagoras provides the tools needed to make the switch.
   To the extent that we can recommend something to you, we encourage, and have built our demo systems around, the 'clause assembly' method, with judicious use of Options and Optional blocks (a 'templates' feature) within many of the clauses.


  Pathagoras offers two distinct approaches to document assembly. Despite the title to this section Clauses VS Templates, the approaches are not opposites. Rather, they can complement each other quite nicely when you fully understand the strengths and weaknesses of both.

   At the outset, you will make some decisions as to the basic approach you want to take. However, those decisions are never etched in stone. Pathagoras makes it easy for you to change your mind.

   Let's discuss the two basic approaches.

Document Assembly by Clauses: This connotes 'paragraph assembly.' You would maintain a collection of text snippets, each saved as individual documents in a designated folder. Each snippet would typically represent a 'stand-alone' section of a larger whole.

Sometimes the snippet is a mandatory part of the document;

Sometimes the snippet is an optional clause. It will be called into some documents, but not others.

Sometimes the snippet is one of several alternative clause. One of them will always be called in, but not necessarily all of them. These snippets might be labeled "ChoiceA", ChoiceB, ChoiceC.

   Collectively, the snippets represent all of the possible text choices regarding a particular type of document.

   In a typical document assembly session, a user would select the book that contains all of the clauses. (A book is  simply a pointer to a folder that you have designated.) Pathagoras reads the contents of the folder and displays all of the available snippets (i.e., documents in the folder) onto the 'Clause Selection Screen' (in the left panel). The user would select the clauses needed for the specific client/customer, moving the clauses from the left panel to the right. When the proper clauses are at the right, and in the proper order, the user clicks Next>> and the selected clauses are instantly assembled into a new, unique document.

   Keep in mind that what is being displayed in the Clause Selection Screen are the documents in a folder. (Pathagoras doesn't know that they are just 'snippets' of text.) The beauty (and elegance) of such a system is that if you add more snippets to the folder, more snippets will display on the Clause Selection Screen.

   Advantages of the 'clause based' approach:

it is easier to effect a change that affects multiple documents. Let's say that you moved your office. Let's further say that your office's address appears in the signature block of every single document that you create. If you assemble documents, calling in the signature block as a snippet at the end of each new document, you only have to change the one snippet and it permeates all future documents built with that term. (The alternative, of course, is to open each 'complete' document/template and make the address change in each.)

when you need just a single clause, it is easy to point and click it in. Of course, if you don't have a DropDown List of the clauses, you really should.

you can call in a single clause simply by typing its name to the editing screen and pressing <Alt-G>. Depending upon how the clause is named and where it is stored, Pathagoras can typically find the clause almost immediately and insert it into your document with your having to navigate to find it.

oIf the clauses are named following the prefix/suffix naming style, and the clause will be called directly from the folder or glossary which has been associated with the prefix. Response time is practically immediate.

oif the clause has been saved in one of your SuperBooks, Pathagoras will hunt it down there, again practically immediately.

Click here to be taken to the section of this Manual that discusses how to 'dis-assemble' a currently 'complete' document into its component parts. This will serve as the starting point for a 'clause assembly' system.

Click here to be taken to the section of this Manual that discusses how to create Clause Sets. (Clause Sets allow the end user to create a complete document by selecting a single 'set' of pre-designated clause snippets. Clause Sets allow you to truly have the best of both worlds.)

Document Assembly by Templates: A template contemplates a complete (actually, overbuilt) document. It typically had all, or at least most of the text that a standard (and perhaps super-standard) document of its type would contain. Variables (placeholders for personal information, addresses, dates, etc.) are strategically placed throughout the document. During the document assembly session, the end user will provide the personal information. Frequently a template will be overbuild. It will contain text sometimes stays in, or sometimes is deleted, depending upon the specific client/customer circumstances or desires. Those text blocks can be marked as <<*Optional*>>. Sometimes the text block should reflect choices. Those can be marked as <<*Options*>> blocks.

Advantages of the 'template' approach:

It is conceptually easier. There is only one new concept being introduced to the document assembly beginner -- the concept of variables that need to be completed to end up with a final product. It simply is easier to learn one new thing at a time. (So the suggestion to the system administrator is this. 'Pathagorize' a template and use it to introduce the users to the concept of document assembly as variable completion. Later, dis-assemble the template into its component parts and see if 'clause assembly' might work better for your office.)

For the document assembly administrator, template assembly is likewise quite a bit easier to implement. You don't have to 'disassemble' a document into its component parts. (While we recommend that you eventually adopt the paragraph assembly approach, it is not necessary at the outset. Document 'dis-assembly' can be postponed until a time when you and the office is 'ready' for that new dimension.)

Formatting and style management can be more easily controlled within a single document. If your office uses (either intentionally or inadvertently) mixed styles, you may get unexpected results when you assembly clauses by snippets. The proper 'solution' is to make the styles uniform across all snippets and templates, but the 'advantage' of templates is that you don't have to mess with this right now. You just need to make the template internally consistent.

Since templates are complete documents, the end user initially sees a result that is more complete and perhaps more intellectually satisfying.

Other document assembly systems tend to favor this approach. Therefore, it is perceived to be an industry 'standard'. And it you have tried another system, that will be your default 'assumption' and bias. That is perfectly okay, but to the extent we can begin moving you over to the concept of 'snippets,' you can dramatically improve document assembly efficiency.

Pathagoras and the 'Industry Standard'

   The industry standard for document assembly source document is 'template based.' Pathagoras allows, but does not promote, that standard. The reason why Pathagoras does not embrace the industry standard is that the standard has not worked. Document assembly as an office 'product' has been around for more than 15 years. Very few people and offices use it, even though 10s of thousands of copies of Pathagoras' competitor's program have been sold.

   In the long run it is tougher and more confusing to try to push an entire document, which run the gamut from simple to complex, into a template. Templates can become exceedingly long, complex and time consuming to write. That is why so much document assembly 'software' has become document assembly 'shelf-ware.'  Administrators were finding that they couldn't write the logic blocks accurately. End users were overwhelmed by having to learn a new program. The program was shelved until more time could be found to implement it.

   With paragraph assembly, the clauses are still selected by the end user, but the administrator does not have to be a programmer. Each separate clause is self-contained. No options text to type, not programming-like code to create. Just simple plain text clauses that assemble quickly and accurately.

Notes:  Except for the fact that a 'paragraph' is typically smaller than a 'template,' there is no technical difference between the two concepts. They are both 'documents' as far as Pathagoras or any user can tell. Each can contain [bracketed variables]. Each can contain <<Options>> and <Optional>> text blocks. Each can contain references to other clauses (set out between "<<" and ">>" markers.)

   The main difference between a 'clause snippet' source file and a 'template' source file is the average size of the file. Snippets are intentionally short. They are designed with sequentially pasting of one clause after another one in mind. Templates are intentionally long. They are designed with presenting the whole, and 'keeping' or 'deleting' optional text in mind.

   So, keep this in mind. No matter how complete the template might be, it likely won't contain every possible option within its four corners. So you will likely have a need for at least a small library of clause snippets that you can quickly reference for that additional text needed to put on the final touches. And not every clause snippet should be free from options and optional text blocks which are typically associated with templates. Use them when you need them.

Created with Help & Manual 7 and styled with Premium Pack Version 2.70 © by EC Software