You can easily relocate references to your Options and Optional text blocks to the top of the document.  From this position, Pathagoras can process all of the questions at one time and create a form (i.e., an 'interview') of those questions so all (or most . . . see below) can be answered at on sitting.

   Not only can Pathagoras present the Interview, but it can automatically create the 'form' for you out of the  <<*Optional*>> or <<*Options*>> text blocks found in the document body. The button triggering this is called "Create <<*Ask Table.*>>" and it is  found under the 'Pathagoras Features | Authoring Tools' in the Pathagoras toolbar. But before going there, let talk about a few other things first.

  informationThe Interview and the AskTable are used somewhat interchangeably, but they really are not the same thing. The Ask Table is a group of 'AskOptions, Ask Optional and Ask Repeats sentences. This Ask table is what is processed to create the Interview. The Interview is presented


1.The document must contain at least one <<*Optional*>> or <<*Options*>> text block. (As a practical matter, your document would likely have many such text blocks. If it has only a few, there would not be much of a benefit to the table.) AND

2.Each <<*Optional*>> or <<*Options*>> text block that you want to be part of the Interview must be augmented by a !GroupName! It is the !GroupName! that links the Ask prompt to the associated Options/Optionals/Repeat blocks in the document.

(<<*Optional*>> and <<*Options*>> text blocks can still reside in a document without a group designator, but they will not be brought up into the Ask Table.)

   Creating the <<*Ask. . .*>> Table:

   Display the document for which you wish to create the Ask Table.

   Click "Pathagoras Features List". Select "Authoring Tools" and then "Create <<*Ask Table*>>".

   Follow the prompts.

   Using the <<*Ask. . .*>> Table

    The Ask Table typically sits at the top of a source document. When the end user assembles a document from either the Clause Selection Screen or a DropDown list, document processing immediately begins. Pathagoras will read each element of the table from top to bottom and present the appropriate question for a response onto an 'Interview' form. The user checks (or leaves unchecked if the option is not desired). Once all choices are made, the end user clicks the Next button. The various responses are recorded and processed throughout the document. If there were more questions in the Table then there was room in the Interview, Pathagoras will present the remaining questions onto a new (continuation) Interview.

   Once you have created your Ask Table, you can expand and refine its functionality by adding Logic Prompts. Pathagoras provides 3, and they are discussed, and examples are provided in the subsequent pages. But to summarize, here they are:

The <<*If*. . . >> prompt allows you to direct Pathagoras to present certain additional elements, or set certain values based on the values of predecessor elements. The logic is simply "If This Answer, then, This response". You can cascade down an answer tree, refining and defining values simply by asking and answering questions.

The <<*Case* . . .>> prompt is an expansion of If logic, for when you want to test a series of values in a particular order.

The <<*Set*>> prompt lets you simply assign a value. Used when you know a value is static for a particular document. (Set is most useful when you have several similar documents, and want to preset a value of each in the Menu so that value in turn selects certain text in the document body.

   These 'equations' bring incredible flexibility to your documents. For example, certain decisions can be made for the end user automatically, based on answers and values provided or set in previous answers. (The application of further 'logic' to the Table is entirely optional. If you want to stop right here and take a 'breath,' please do.)

"<<*Ask*>> Table" (and the Interview Wizard):

   You can manually type or cut and paste the individual prompts from the document body to the document top, but here you should use the 'Interview Wizard'. It will search for each of the  <<*Options/Optional*>> text blocks to which ! a !GroupName! has been assigned and place them into a single location at the top of the document. (Note: The 'standard' assembly routine as described in the previous page 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.

'If/Then' and 'Case'

  Please read the important information in the box below before embarking on this adventure.

  Applying logic to your documents is not really hard once you know how to read and write the logic statements. Of course, the more levels you stack and nest, the harder the table is to read, but it is in figuring out how to 'program' to get the document to do its own thinking that can make the process really fun.

   The examples and illustrations which follow should make the process a bit more understandable.

  informationWhile this process resembles the 'Interview' features found in other programs, it really is not.

  Interview forms used in competitive programs require quite intricate and oftentimes complex setups:

First of all, on top of the time you spend with document and template design, you must create a separate interview form for your project. You must connect the individual controls within the form to the 'results' you desire. The 'results' are typically a document or clause or file, but the results can also be branches or loops. Those branches or loops will lead to other forms, branches or loops.

In most programs, the 'results' connections is accomplished via exercises that result in complex commands that are inserted as fields either behind the base document or most likely in a separate file.  Then you have to lock in the form as save it out to a special location under a special name with a special suffix.

The Interviews in other programs are quite impressive when demonstrated by the salespeople offering their product. That is because they are prepared long before the demonstration is conducted. It should be apparent that the same will not occur in your office on your form without a substantial amount of effort. (Okay, this last paragraph is pure sales pitch, but it is accurate nevertheless.)

   Pathagoras does not require that kind of programming. Pathagoras Interviews are created directly from a Pathagorized document. The interviews are "dynamic" and created "fresh" each time you process the source document. That mean that if you change the <<*Option/Optional*>> text block in a source document and then assemble a new document, the change in the source will reflect the next time the Interview Wizard is run. This makes testing the document exceptionally easy, and fully understandable.

   Of course, when you are inserting and editing <<*Options*>> and <<*Optional*>> blocks, and creating your If/Then and and Case equations, you are 'programming' in a fashion . But it is quite different from what you have ever done before. Pathagoras 'programming' is 'facial' to the document, not independent from it. By facial, we mean that just by looking at the document's face, you can see what is happening.  When something doesn't happen as expected, the face of the document 'tells' you why.

   If you encounter errors in the processing, or just want to make changes to rewrite a question or correct a logic issue, simply work on the source document and then save it. The next time you process the document, it will show a new Interview reflecting your changes. (If the document has  <<*Options*>> and <<*Optional*>> blocks that are (or may be) improperly formed, run the "Structure Checker." Pathagoras will typically detect and fix any formation or structure errors, or at a minimum will point out the section of the document that contains the likely source of the error.)

Click the button_next_h button in the menu bar to read more about Interviews.