Pathagoras Help System

Document Logic

Hide Navigation Pane

Document Logic

Previous topic Next topic No directory for this topic No expanding text in this topic  

Document Logic

Previous topic Next topic Topic directory requires JavaScript JavaScript is required for expanding text JavaScript is required for the print function Mail us feedback on this topic!  

   How do some programs 'know' that if Condition A exists, then clauses 1, 2 and 3 should be inserted into the document, but if Condition B exists, only clause 2 and 4 should be inserted?  Do these programs somehow possess an intuition quality? Well . . . .  no!

   They 'know' what to do because somebody sat down and programmed the document logic needed o make those 'decisions.' And, because some programs required this kind of programming in order to even begin using their systems, that drove many people to forgo implementing document assembly from the 'get go.'

   This kind of document assembly program fits into the category of 'menu driven.'  A menu is presented to the end user. The end user then makes certain selections from the menu, and from those selections a proper document is assembled.

   So what's the downside to such a system? None, really, for the end-user. But for the document author, designing and programming those menus can be complex, difficult, time consuming and frustrating. Writing instructions for transmitting of instructions from human to machine is called programming and programming is what most end users of document assembly programs want to avoid. Indeed, 'no-programming' is a lode-star goal and advertising cornerstone of most document assembly program, including Pathagoras.

   Most of the 'big guys' have offered document logic in their programs for many years. Since, as stated. implementing the logic necessary for such systems was cumbersome and complex. Programming the menus involves use of ancillary, non-Word screens and documents that must be opened and edited and saved in pre-defined locations that may not mirror current office operations. Only on computers that contained the program that drives document assembly could be used for editing. Unless there was an IT person on staff, many of those programs became 'shelf-ware' (software that simply sits on the shelf.)

   Pathagoras waited until it could be done the right way. With the advent of Pathagoras v. 2011, Pathagoras offers a simple, user-friendly way to offer logic for those brave souls who desire it. (Despite our claims of simplicity, many of our customers will find taking advantage of our logical document cumbersome and complex, too. While we honestly think it is just about as as easy as it can get (and different levels are offered so that you can implement only as much as you desire), it is still may not be for everyone.

   Plain text, facial and 'all Word, all the time. These are the primary ways that we differ from the 'big guys.'  When you are editing, testing re-editing and retesting documents to confirm the instructions you have created, when you are creating automated forms using Pathagoras, you are always in Word. All the instructions are on the face of the document. You can read and see what is supposed to happen. When things go awry, you can see the 'error of your ways' and more easily make corrections (since you do not have to change programs to make the corrections. You can re-test your updated work immediately.

   Because Pathagoras is 'plain text' and the Word -- Pathagoras relationship is '24/7', you can even edit your documents on a machine on which Pathagoras has not been installed! (Of course, to test your work, you will need a Pathagoras computer.)

   Let's examine several approaches offered by Pathagoras that involve 'document logic,' from the simplest to the more complex.

Simple:

Optional Text:

"If A, then B" If Condition A (let's say, 'minor children'), insert 'this' text (let's say 'Uniform Gifts To Minors' language)Trust, otherwise delete the text."  This is probably best handled by Pathagoras' <<*Optional*>> text blocks.

<<*Optional*Are there Minor Children?*I direct that any funds otherwise due to my minor children be placed in an account established under UGMA.>>

When an <<*Optional*>> text block is encountered, Pathagoras will stop, highlight the text and ask you if you want to keep or  delete that text (or if, as above, a question is posed, it will ask the question.) The positive or negative response to the question controls what happens next. Language is retained or language is deleted.

Click here for information, instructions and illustrated examples on the use of  <<*Optional*>> text blocks.

   Options Text:

"Choose A, B, C, D or E." Instead of the on/off logic of Optional text, Pathagoras allows you to choose among a  collection of choices. When the end user selects one of the available choices,  that choice remains in the document and the others are excises.

Click here for information, instructions and illustrated examples on the use of <<*Options*>> text block.

Medium:

"If A, then B, but not just for the immediate question and resulting text, but in multiple locations throughout the document." If a choice for Condition A is made at the top of the document, i.e., "Are there minor children?", it surely would be nice for that choice to be 'stored' by the program so that clauses in the middle and the bottom of the document that depend upon the same answer can be similarly processed. Pathagoras handles this by augmenting the  <<*Options*>> and <<*Optional*>> text blocks with !Groups!. So, if the answer to the question posed by the first instance of a particular group is "Yes" or "Keep" for <<*Optional*>> text, or "1 thru 6" (or any combination of selections involving the 6 choices) for <<*Options*>> text, all other instances of <<*Optional*>> or <<*Options*>> text bearing the same !GroupName! will be processed identically.

Click here for instructions and illustrated examples on the use of !Groups! and <<*Options*>> text.

  Understanding the 'standard' document assembly sequence of events is important at this stage. After a  document is created via the Clause Selection Screen or inserted onto the screen via a DropDown List,  Pathagoras will automatically search for each <<*Options/Optional*>> block in the document, starting from the top and working down to the bottom. Once the end user makes a decision regarding each block, Pathagoras processes the choice. If !Groups! are used, the decision regarding that particular text block is applied against each member of the !Group! wherever located in the document. Then, Pathagoras returns to the top of the document and searches for another <<*Options/Optional*>> blocks. It processes it, returns to the top, etc. When there are no more <<*Options/Optional*>> blocks to process, Pathagoras 'stops', presenting to you what is hopefully a perfectly tailored initial draft of your document.

Advanced:

The Interview Wizard ("Ask Table"):

Once you have implemented !Groups!, the Interview Wizard allows you to gather all of the  <<*Options/Optional*>> text blocks to which !GroupNames! have been assigned into a single location at the top of the document. That way, the end user can answer all (or at least some -- you many not have given every Options/Optional block a !GroupName!) of the questions needed to produce the final product as soon as the document is displayed. (Note: The 'standard' assembly routine as described in the box above is top to bottom, with each <<*Options/Optional*>> block presented individually. The Interview Wizard doesn't really change the top to bottom flow, but it does compress the information gathering process.

Click here for instructions and illustrated examples on the use of Menus.

'If/Then' and 'Case'

   Once you have created an "Ask Table" you can manually modify that table to implement an even higher level of document logic. You can direct Pathagoras to present certain element of the table only if certain predecessor tables were answered in a certain way. It can be simply If This Answer, then, This response. or more along.d Interview Wizard, the ultimate in document logic can be implemented.

   The rest of this section of the Manual is devoted to implementing Document Logic with 'If/Then' and 'Case' equations. Please read the important information in the box below before embarking on this adventure.

   It really is not hard once you know how to 'read' the logic statements, but I would rather call it hard, and let you be pleasantly surprised when you find that it is not so bad. Keep reading. The following examples and illustrations should make the process a bit more understandable.

  Please note the following. This page presents logic 'stuff' from the simplest to the most advanced possible implementations. Use what you want. If you are satisfied with the simplest iterations, stop there. If you want to move to !Groups! do so. If you want to implement the Interview Wizard and Ask Tables, and maybe even add some If/Then and Case statements, do so. But keep these things firmly in mind.

Implementing document logic all optional. Of course, the more you implement, the more automated you can make your document for yourself and for others. But nothing is required. Take 'Pathagorizing' and automating your documents and clauses it at your own pace, and don't feel that you have to implement anything else.
The Ask tables and the Interview Wizard draw their information from existing <<*Options and Optional*>> text blocks. Not all questions need be in the Ask Table for the system to work well.
Everything builds on top of everything else. An Optional text block is augmented by the insertion of a "!GroupName!", not replaced by it.
All features described above work whether you are adding simple logic to an entire document (typically called a 'template') or to individual clauses that you intend to cobble together from scratch using the Document Assembly/Clause Selection Screen routines.