System 'Design'
Designing and preparing document and clauses for efficient use is perhaps the most important part of the document assembly process. It likely will also be the most time-consuming and challenging part. With its variety of helpful tools, Pathagoras will work with you to make the job easier. But nothing beats a thoughtful approach to the process.
In creating a system, the user is quickly confronted with the question “What is the best way to develop the clauses for presentation to the end user? There is not a ‘best answer’ to this. It is a personal choice of the designer. It may be dictated by the office manager. It may ‘fall in your lap’ (but be a perfectly acceptable solution, or at least starting point) or it may be by meticulous preplanning. Regardless, the choices are essentially two (with a third choice being a combination of the two extremes). “Overbuild” and pare away, of build from the absolute bottom up. Or something in the middle.
(‘Neutering’ the document -- placing variables strategically throughout your document-- is another part of the system design process. However, unlike other program, creating variables in Pathagoras is a very simple matter. It does not add significant 'strain' to the development process. Neutering is discussed at this link.
Here are some questions to think about as you design your document assembly system.
a. Will the user be presented an entire standard document and just be required to replace variables with personal data? This is akin to a 'fill-in-the-blank' form. The form is set and all you do is replace variables.
b. Will the user be presented a more or less 'one-size-fits-all' document. It contains more than likely will be needed for the client or customer's need, and the user will be expected to pare away the unnecessary (actually we call it ‘optional’) parts? This kind of document is frequently called a 'template.'
c. Will the user be expected to build the document entirely from the ground up, selecting individual clauses from a collection of clauses stored in a glossary or a folder of clauses? (This is true document assembly (or perhaps more accurately, paragraph assembly.)
d. Will a middle ground between these concepts be used. The middle ground is huge, but typically the user is asked to call in individual clauses (i.e., build from scratch), but some of the individual clauses are ‘overbuild.’ The user selects, accepts or rejects the options as the clauses are called in during the document assembly process.
e. Still more middle ground: The document can be assembled from a ‘clause-set.’ A clause-set is a document or glossary term that is composed purely of references to other clauses. A clause-set typically reflects a frequently assembled (i.e., 'boilerplate') document. Clause-sets are frequently composed so that semi-boilerplate documents (similar, but not identical, documents) can be quickly generated without having to select each clause individually. E.g., a clause set might be created for each of the following circumstances:
Simple will, married man, no children, containing: wil100, wil103a,wil120, wil140m, wil145 and wil220m |
Simple will, married woman, no children, containing: wil100, wil102a,wil120, wil140f, wil145 and wil220f |
Simple will, married man, one child, containing: wil100, wil103b,wil120, wil140m, wil145 and wil220m |
Simple will, married woman, one child, containing: wil100, wil102b,wil120, wil140f, wil145 and wil220f. |
Simple will, married man, two or more children, containing: wil100, wil103c,wil120, wil140m, wil145 and wil220m |
Simple will, married woman, two or more children, containing: wil100, wil102c,wil120, wil140f, wil145 and wil220f |
Simple will, unmarried man, no children, containing: wil100, wil103d,wil120, wil140m, wil145 and wil220m |
Simple will, unmarried woman, no children, containing, wil100, wil102d,wil120, wil140f, wil145 and wil220f |
etc. You typically do not see the individual clause names when you are working with clause sets. You see only the one 'descriptive' name, e.g., "Simple Will, Married Woman, One Child." (Don't fret that the individual term names comprising the sets don't mean anything. Subjects are associated with each term's name to make clause selection for a clause set quite easy.)
When a document is built from a clause-set, it is indistinguishable from one built from a complete document. However, as the above examples illustrate, the source of a final document was separate clauses. The advantage of documents designed on clause-sets is that when a particular clause is changed, it automatically is reflected all document dependant on that clause. So, using above examples to illustrate the point, if 'wil145' is changed, its change will be automatically reflected in a future document built on any of the above clause-sets.
Special Situations-- Gender Differentialtion
Let’s assume your challenge is accounting for gender/sex differences within a clause or document. One alternative is for you to create separate clauses for each situation, naming the clauses similarly but with a last letter designator to indicate where it is for a male or a female. (Truly neutral clauses that appear in all documents won’t require the sex designator). So, like in the examples in the above table, a collection of will clauses might look like this: for ‘male’ wills: wil100, wil120m, wil140, wil150, wil170m, wil220m”; the clauses for an identical will for a female might be: “wil100, wil120f, wil140, wil150, wil170f, wil220f”. This is a perfectly acceptable solution.
Multiple Choice Text
On the other hand, wil120m and wil120f don’t have to separate clauses. Multiple choice variables e.g., [husband/wife] or [father/mother] or [he/she] (as appropriate), can be inserted into the various separate clauses. Doing so adds a slight amount of additional work. See this page for a full discussion on how to create and use multiple choice text (including grouping of multiple choice set so that the selection of wife in the above example automatically selects 'wife' and'she').
Optional Text
Sometimes the choices aren’t simple [husband/wife] or [chocolate/vanilla/ strawberry]. Rather, they may be much larger blocks of text. Pathagoras 'optional text functions' may come into play here. You can simple mark out the optional text in the master document or master clause. (For example, can create separate clauses to account for the gender differences and include those clauses within the master term. When Pathagoras encounters the optional text block during the document assembly process, it will stop and ask the user if he or she wants o keep or delete the “optional” text. Read more about “Options” and “Optional” text at this link: Optional Text.
Clause Sets
Yes. We return to the beginning. Instead of builing optional text into a clause, you can solve the challenge using clause-sets. Consider 'overbuilding' the set (i.e., build the set base on the maximum content of the final document, but expecting to pare away certain clauses before the final build. With Pathagoras, you can 'expand' the contents of a clause-set after you select it by name. (Here expand doesnt' mean assemble. It means display each component clause for acceptance or deletion. You can delete the clauses that are not needed for the particular client or customer before you decide to assemble the set.)
No other program offers so many options for moving clause text into final prpduct
-----------------
See Numbering for information about Pathagoras’ plain-vanilla numbering feature. See Professor Pathagoras for a step-by-step, interactive, hands-on exercise regarding the above.