Method and apparatus for preparation of a database document in a local processing apparatus and loading of the database document with data from remote sources5842195Abstract A system for obtaining information from a plurality of computer users (7 to 12), comprising a processing apparatus (2) including an input mechanism (3 and 4) via which a survey author may input data, and a survey authoring mechanism (FIG. 2) enabling construction of a survey questionnaire document including at least one question formulated from data input by the survey author, transmission mechanism (6) for transmitting the survey questionnaire document to a plurality of respondent users (7 to 12); and a processing apparatus (2) including a collating mechanism arranged to receive transmissions from the transmission mechanism, to identify response documents which include responses to the at least one question from the plurality of respondent users and to load a database in accordance with the responses. Claims We claim: Description The present invention relates to a system and method for obtaining and collating information from a plurality of computer users. More particularly, but not exclusively, the invention relates to a method and system for asking questions of computer users having access to electronic mail, and to a method and system for collating their responses and presenting them in a database.
______________________________________
On Selection
Database Field
Option Button Text
Entry Branching to
______________________________________
Yes I will be taking leave
Y {NEXT}
during this period.
No I will not be taking
N {FINISH}
leave during this period.
I am not sure at this
M {FINISH}
time.
______________________________________
See FIG. 8 for a screen display of the question text and allowable answers. The author (local user) then saves the work he has done so far by selecting the FILE/SAVE menu option. The survey document may be given a unique and descriptive name. Such as HOLIDAY.SVM. The author (local user) can now go ahead and create the final question in the survey document. To start a new question the author (local user) must select the QUESTION/NEW QUESTION menu option. This will present the author (local user) with a new question box containing, as before, the "NEXT" and PREVIOUS buttons as well as the Question Text area. The author (local user) can now proceed as per the first question but using the new set of variables. Lets assume that the final question is an option-type question and the parameters are as follows:
______________________________________
Field Variable
______________________________________
Question Text Where will you be
holidaying
Question Title Destination
Database Column Heading
Destination
Never Seen Database Field Value
BY PASSED
Option One: Option Text
New South Wales
Option One: Branching To:
{FINISH}
Option One: On Selection
NSW
Database Field Value
Option Two: Option Text
Australia, but not
NSW
Option Two: Branching To:
{FINISH}
Option Two: On Selection
AUST
Database Field Value
Option Three: Option Text
Overseas
Option Three: Branching To:
{FINISH}
Option Three: On Selection
OS
Database Field Value
______________________________________
Now that the second and final question of this brief survey document has been completed the author (local user) can take a look at the linking of options from question one (LEAVE) to question two (DESTINATION) or FINISH (end of survey document). Earlier the Branched-To Question field was mentioned and the author (local user) used the {NEXT} and {FINISH} options because he could not nominate the "Question Title" of the next question at that point. Now that the next question has a title, "Destination", the "Branching To" field in the previous question that contained the {NEXT} option will automatically change to read (DESTINATION). So in summary, the author (local user) has asked a question relating to leave being taken and another relating to where the respondent (remote user) will be taking this leave. Now clearly if the respondent (remote user) has answered either option two or three (No and Not sure) to the first question (LEAVE) there is no need for them to answer the second question (DESTINATION) and therefore they should go straight on to (FINISH). Option one (Yes I will be taking leave during this period) of question one (LEAVE) should lead to question two (DESTINATION). As the second question is also the last the author (local user) may choose settings of {FINISH} as all options will need to lead to the end of the survey document. Although in this example the author (local user) has chosen the {NEXT} option to automatically handle his linking it can be done manually using the following process. The first thing to do is to get the first question (Leave) back on the screen. This is done by selecting the QUESTION/GOTO QUESTION menu, and the choosing of "LEAVE" of the list (FIG. 9). Question one (LEAVE) is now displayed on the screen. Double clicking on the first option (Yes I will . . . ) will display the option button properties dialogue box. From the list displayed in the Branched-To Question section select the second questions title "DESTINATION" and press Enter or click OK. The final step before testing is to nominate which question is the first question to be presented to the respondent (remote user). This is done by selecting the QUESTION/SET FIRST QUESTION menu and nominating the Question Title of the appropriate question. The first test that the author (local user) should perform is the SCAN TEST. This is accessed through the TOOLS/SCAN menu option (FIG. 15). On selecting SCAN TEST the arrangement scans through the survey document and searches for any errors in the question structure. This is particularly important for complex survey documents which incorporate a number of branched-to questions. SCAN TEST generates a report of "orphans" and "cul-de-sac" ie., questions which no other questions lead to and questions which do not lead to anything. The arrangement is aware that there is a single question which will not have a preceding question (the question selected as the first question in the survey document) and a single question which will not have a succeeding question (the last question in the survey document). It may test all the other questions simply to determine for orphans or cul-de-sacs. Once any existing orphans or cul-de-sacs have been identified the author (local user) can access them to correct them. In addition to orphans or cul-de-sacs SCAN TEST also identifies any Cross Linked Questions (A child question that branches to any preceding question) and Duplicate Database Field Names. It will also test for illegal names (e.g. over eight characters for DOS based database) and missing names. In one embodiment, an entire list of the items appears on the authors (local users) screen. Clicking on one item immediately takes the author (local user) to that item. By "item" is meant any item which may be determined by the local user in preparing the Survey Document, e.g., Goto's, not accessed, branching-to questions, DatabaseFieldName, etc. The listing will not include information such as question text (although the question title is listed) and the like which do not effect the mechanical structure of the Survey Document (e.g., the pathway through the Survey Document). It is a mandatory requirement, however, that the author enter Question Text. While this will not affect the mechanical operation of the document (the way it runs on the respondents processor), if no Question Text is provided, the respondent user will view a blank question (i.e., no question). A test for question text is therefore important and is included. There may be other mandatory items such as question labels. The listing enables the author to briefly check that the document structure reads as desired. Any items identified by the scan test as being in error are preferably highlighted in the listing so that the user can click on them and take the appropriate action to correct the error. An embodiment is envisaged where all variables in the Survey Document which could be effected by the author or system configuration are listed. Once the SCAN TEST has been completed without error the author (local user) can be confident that the mechanics of their survey document are in order. The Respondent Test is accessed either via the TOOLS/TEST FROM TOP (FIG. 15) or by a simple click on a "Test" icon on the tool bar. Activating Respondent Test will take the author (local user) through the survey document as if he where a respondent (remote user). A further test is TOOLS/TEST FROM CURRENT (FIG. 16) this allows the local user the option of testing the Survey Document from any particular question he is currently displaying. Prior to sending the survey document the author (local user) determines the electronic mail address the response documents are sent to. FILE/SET REPLY ADDR (FIG. 15) and then nominates the return address. Once the author (local user) is satisfied that the survey document works and that the response will be going to the correct mail address he may send it to his target audience. To do this he selects the FILE/SEND SURVEY (FIG. 16) menu option (FIG. 10). The Survey Author Module assumes that the author (local user) will be sending the survey document that is currently loaded. It will present a dialogue box listing of all the respondents (remote users) and groups of respondents (remote users) that the author (local user) could mail to. The survey author may also mail to the respondents of previous surveys. A listing of the respondents of previous surveys is kept. The dialogue and box will also list all the previous surveys so that the author may click on a selected previous survey to send to remote users who filed responses for that survey. Methods may also be used to select sub groups within the targeted database. The author (local user) will make his selection and press Enter or click OK. Another dialogue box will appear enabling the author (local user) to attach a message to the survey document. For example the author (local user) could use this to introduce the survey document to the respondents (remote users) and explain the benefits to them or the organisation of responding to it quickly. Once the author (local user) is satisfied that everything is OK he can press Enter or click OK. The small survey document will then be on its way to its target audience. At the same time (in the preferred embodiment, just prior to transmission) the apparatus will automatically create the database in preparation for the responses. Also, at the point that the local user selects the FILE/SEND survey menu from the File menu they are offered a dialogue box requesting them to name the SVQ (survey document to be sent out) file that is about to be sent out. The default name is that of the SVM (the survey document master--see later). Once the local user has either selected a new name for the SVQ or accepted the default name the local user will be offered another dialogue box asking for them to select the database type that they would like to create for this survey to be collated into. At this point the local user will ask for either a database name and/or table name. The default will be the SVQ name. However, the local user can change it. The database can be fully populated if the author is mailing the survey to a list of known users. However, there is the option for the database not to be populated if their survey is sent to a group, for example, or put on a bulletin board. In the present example, the database is fully populated. See FIG. 14 for a diagrammatic representation of the database. The database is comprised of three columns and N+1 respondent (remote user) rows, where N is the number of respondents (remote users) (+1 is the row containing the column headings). The three columns include two columns for the two respective questions, and a column which contains respondent (remote user) ID. Note that a number of fields may be necessary for a users mail address. The columns and rows intersect in matrix form to provide database answer fields in the form of cells, for the entry of the appropriate field value as answer documents are processed. Each remote processing apparatus may be configured with a "Survey User Module" or recipient module (response module) to enable preparation of an answer document in answer to the survey document. The Survey User Module will be installed either on the server that the respondent (remote user or recipient) is attached to in the network, or on the respondents (remote users) machine. Alternatively, the recipient module may be transmitted with the survey document, so that a respondents users computer need not even be configured to be able to process the survey document. Instead, the recipient module transmitted with the survey document will configure the respondent users computer. The respondent (remote user) will generally access the survey document through their normal electronic mail procedure. Where the respondent (remote user) is not connected to electronic mail, he may receive the survey document by another communications medium, eg. by normal mail, or by any other means. They will read the mail that has accompanied the survey document and then use their mouse to select and launch the survey document. On their screen will appear the question one (LEAVE) dialogue. They will use their mouse to select the option that applies to them. They will then click on next. Depending on their selection either the (FINISH) or the (DESTINATION) dialogue box will appear. Once they have answered all the questions the (FINISH) screen (FIG. 11) will appear thanking them for the involvement in the survey. Once they press Enter or click Finish all of their answers will be transmitted back to the Survey Collator Module automatically. The local processing apparatus, in particular the Survey Collator Module is arranged to monitor incoming transmissions via electronic mail other means, even manual entry) to identify answer documents for the particular survey. The "Survey Collator Module" is applied to gather all the incoming responses and load them in the database. In the preferred embodiment, as described below with reference to FIG. 12, the Survey Collator Module has a number of functions, operation of which may be dictated by the collator (local user). Note that the Survey Collator Module may be entered on a different processing apparatus to the processing apparatus which the author (local user) used to prepare the survey document. This arrangement will be particularly useful where the author (local user) makes heavy use of a particular computer and, although he may wish to prepare the survey document using that computer, he does not wish machine time to be taken up with collation of answer documents. He can therefore designate another machine to receive and collate the answer documents. Survey Collator Module--As previously explained this module of the application gathers all the incoming responses and puts them in a database ready for analysis. When this module is first launched the collator (local user) must select the SURVEY/PROCESS menu. The collation process is automatic. An options menu is provided which enables the local user to select whether a particular survey should be "activated", "suspended" or "terminated". When a survey is "activated" the collator will automatically collate all response documents relating to that survey. When a survey is "suspended" (dl in FIG. 12), the collator will receive an identify response documents relating to the survey but will not process them. It will merely store them. When a survey is "terminated" the collator will identify all response documents relating to that survey and delete them upon arrival. The Survey/Process menu will now attempt to logon and start the collation process. On loading the collator module it will not start the collation process until the Survey/Process menu has been selected. The way that the collator gets to know about the surveys is when the first response document comes in. When this happens the collator puts its name up on the screen along with information relating to the last date and time it received an entry and the total number of entries it has received for that survey to date. The collator will continue to collate the "activated" survey entries until the local user "suspends" the process. The local user can also decide to "terminate" the survey, in which case all incoming responses will be deleted upon arrival (see later for description of "activated, suspended, and terminated"). All surveys will list on the screen regardless of which of the three states they are in. The local user could decide to delete a survey from the list. However, if an answer document comes in it will attempt to restart the collation process. FIG. 12(a) illustrates the main Survey Collator Module screen of this embodiment. The Survey Collator Module can handle a plurality of different surveys, exemplified in FIG. 12(a) by "survey 1" and "survey 2" under "survey name". Once the collator (local user) has done this the Survey Collator Module will automatically start the electronic mail if it is not already running and then start to scan for incoming responses. On the screen the collator (local user) will notice that the Survey Collator Module tells him how many responses it has received and what percentage that amount represents of the total the survey document was sent to ("Total #", "# Read", "% Process"). The "total" and "percentage process" will only appear when the survey has been sent to a known list of respondents and a pre-populated database option has been chosen. Where the database is unpopulated, obviously the collator will not know how many respondents will be required to fill the database. If after a few days the collator (local user) notices that the responses have slowed down to a trickle he may like to send all those who have not yet responded a quick reminder. This can be done automatically by selecting the SURVEY/REMIND menu option (FIG. 12(b)). Having done this the collator (local user) will be asked to type a brief reminder message. Once the collator (local user) presses Enter or Clicks OK the Survey Collator Module will interrogate the nominated survey database and send the mail to all the non-respondents. This should prompt a few more to respond to the survey. However, if in a few more days the collator (local user) still has not received all the responses he may select SURVEY/RE-SEND menu (FIG. 12(c)). This works the same way as REMIND but along with a message from the collator (local user) it will retransmit the survey document. Once the collator (local user) is happy with the number or percentage of the responses received he can de-activate the survey document by selecting the SURVEY/TERMINATE menu option (FIG. 12(d) and 12(e)). This means that Survey Collator Module will discard all responses for this survey from now on. The database will contain audience responses for each user. If the respondent (remote user) does not respond this may be indicated in an extra database column (the "respond column"). There is also the option of gathering various information available automatically on the E-Mail system. For example, postcodes, telephone numbers, etc. Various database columns would be prepared to receive this automatically gathered information, which would not be part of the survey document received by the remote user. Further options include date/time stamping depending on the time the answer document was received and/or the ability to log whether this is a reply to an original survey or a reply to a reminder or a reply to a re-sent survey. Appropriate database columns would be required. FIG. 12(g) illustrates "Options" available with the survey collator. FIG. 13 shows a functional diagram of the survey system. The functional diagram shows in brief the steps discussed above of operation of the apparatus and method in accordance with the embodiment discussed above. At 100 the author creates a survey with a survey name 101 and mails it out to a remote user 105. Further, just prior to mailing of the survey, the database is created at 102, the questionnaire is prepared at 103, and the questionnaire is mailed to the Collator at 104. At the remote user end of the system, at 106 the user reads and processes the survey and creates an answer document at 107 and sends 108 by mail back to the collator. At the local user end, at 109 the collator reads the questionnaire and notes the existence of the survey in its register. Later at 110 the collator reads the answer document and updates the database at 111 with the answer. In operation, when the survey document has been completed prior to transmission it is a master. The document sent out is a subset of the survey master, known as the SVQ. The SVQ is saved for subsequent re-transmission, e.g., if reminders are required. At the point that the local user selects the FILE/SEND survey MENU OPTION from the file menu they are offered a dialogue box requesting them to name the SVQ file that is about to be sent out. The default name is that of the SVM. Once the local user has either selected a new name for the SVQ or accepted the default name the local user will be offered another dialogue box asking for them select the database type that they would like to create for this survey to be collated into (see above). As discussed above, at this point the local user will be asked for either a database name and/or table name. The default will be whatever the SVQ was named, although the local user can change it. The safeguard here is that the local user will not be able to select an existing database name or table name within an existing database. Note that the SVQ is also preferably saved in collator, as reminders will most probably be sent from them. One advantageous feature of a preferred embodiment of the invention, as briefly discussed above relates to the naming of the database column headings when a question and allowable answer utilise a numeric field grid or check box grid. For example, referring to FIG. 6, which illustrates a check box grid, it will be appreciated that there are 16 possible answers (check box cells) to this question. If the remote user has more than one car, he may check more than one cell. Sixteen database columns are therefore required. Manually choosing a name for each of these database columns would be laborious. To overcome this problem, the apparatus and method of a preferred embodiment of the present invention automatically designate database column headings which are formed from components of the column and row grid headings. For example, the name for the database column heading corresponding to the top left hand corner check box cell may automatically be set at "sedan 4". Similarly with the rest of the check box cells. This naming technique can also be applied for a numeric field grid. The column heading may be formed from combining the entire column and row headings of the grid, as above, by combining components of both of them, or by using the column or row heading only or a component thereof. For option button grids, where only one option is allowed to be chosen, in a preferred embodiment of the invention, as discussed briefly above, it is only necessary for the database to contain one database column, no matter the number of possible answers. In this case, the database field value to be entered in the database column in dependence on the remote users answer is chosen from components of the column and row headings of the grid. With the option buttons grid therefore, the actual field value to be entered is named from the headings of the rows and columns of the grid box cell selected. As discussed previously, option button girds may include a series of sub-groups requiring the remote user to select a single option item in each of the sub-groups. In this case, as many columns in the database will be required as their are sub-groups. An advantageous feature of a preferred embodiment of the invention allows the database to be fully loaded prior to the survey document being sent out, in order to test whether the apparatus can accommodate the fully loaded database. In the embodiment described above, when the remote user receives the survey document (SVQ) and processes it on his apparatus to produce an answer document (SVR), the SVR is sent back and the original mail message and the SVQ are deleted or the remote user is told to delete, so that they cannot be used again by the remote user. A further option exists for the Survey Author (local user) however, to provide an instruction that tells the remote users not to delete the SVQ when the answer document is sent back. This enables a requirement for regular information (weekly, monthly, quarterly) to be met by the remote user by simply re-running the SVQ on a regular basis. If such an option is utilised, the databases prepared to include a "time received" database column to indicate a time at which the particular answer document is received from the particular user. The following is a description of the structure of a software implementation of the preferred embodiment of the present invention, a working example of which has been explained above generally from the point of view of user operation of the embodiment. Software code has not been listed. The following description of the software modules and the various "features" they are required to execute will be sufficient, together with the following descriptions of the various documents (survey master document, survey question document and survey response document), and the previous description of the functions of the system, to enable a person skilled in the art to construct software. This description does not describe the specifics of the user interface, as, except where certain operational rules are enforced, the specifics are fundamentally irrelevant to the description of the current embodiment. The operational rules will be covered at the end of this description. The computer language used within this description when detailing structures is generic, but a person skilled in the art will easily be able to convert these details to an appropriate computer language. Overview The preferred embodiment is composed of three separate but related software modules: Survey Authoring Module--herein known as the Author (local user) Survey Recipient Module--herein known as the Recipient (remote user) Survey Collating Module--herein known as the Collator (local user) In the current embodiment all three modules are designed as Microsoft Windows applications, having been written and complied in Microsoft Visual C++ using Microsoft's MFC Class Library. All three modules interface to Microsoft E-Mail through the MAPI interface. Both the Author and the Collator modules access databases through Microsoft ODBC interface, allowing the system to work with almost all available databases. Standard programming techniques have been used as much as possible to allow portability to other systems that support MFC. There are three areas where slightly non-standard techniques have been used: 1. The presentation of the dialogue boxes in the Respondent module (and equally their presentation in test mode within the Author module) utilises a Windows feature of being able to present a dialogue box from a template in memory instead of the usual method of presentation from a static resource. This allows dynamic control of the appearance and content of the dialogue boxes from information stored in the questionnaire (SVQ). 2. At the point when the survey questionnaire is to be mailed to the remote users the Respondent module (Response Exe) is pre-pended to the actual questionnaire document (SVQ), given the `file-name` of the survey master document (SVM) and the extension `Exe`. It should be noted that the SVQ is a C++ `object`, and to achieve data persistence its MFC archiving methods are used both to write it at the Author, and to reload it at Respondent. When the remote user runs the composite file, the Respondent module start-up-code offsets the file pointer in the MFC standard archive read method to point to the SVQ section of itself. It then loads the data to `re-instantiate` itself, processes the data through the normal SVQ methods and presents the questions to the user. The composite file transmitted to the Respondents operates as a true `object` with encapsulated SVQ data. (Note that an `object`, as will be understood by a skilled person, is a collection of executable methods that are specific to the encapsulated data types and structure (an `instance` of which is held within the object), and (generally) those methods are the only way for external agents (people or processes) to operate on that data). 3. Following on from (2) above, the final size of the composite file is largely determined by the number of executable SVQ methods which are mailed with the SVQ data. To increase efficiency through the E-Mail system the size of the composite file should be as small as possible. By using conditional compiles on the SVQ object, a common minimal `set` is used by the Respondent module, while the full `set` is available to the Author module. The common minimal set will be a matter of choice of the skilled person, who will be able to establish the minimal set of methods required to run the SVQ by the respondent module. The Author Module The main functions of the Author module are the design of the questionnaire, preparation of an appropriate database, and the transmission of the questionnaire to the remote users. All Author functionality is derived from the Survey Master Document (SVM) methods. Note: the SVM contains the Survey Questionnaire Document (SVQ) inside itself so that all SVQ methods are available to the Author. Further the SVQ contains an array of `Question-Box objects` inside itself so that all Question-Box methods are available to the Author. The data members for the SVM/SVQ/Question-Box `objects` and the functionality of the more relevant methods are detailed below. The Menu structure, as will be realised form the preceding description, is based as closely as possible on Microsoft `Office` products to achieve the highest degree of user interface compatibility with Microsoft standards and therefore facilitating ease of use. The user interface for the dialogue box editing used in the creation of the question boxes is preferably based on several Microsoft and Borland `dialogue editors`. Other techniques could be used. One of the underpinning interface design criteria has been to shield the Author user from the need to have any knowledge about databases. The Author module generates default database field names based on the Question names, e.g., user question name as the field name. Users can change the database field names if they wish but there is no need to do so. The database field types required are, in this preferred embodiment, deliberately limited to Boolean (Logical), Text and Numeric. Except for `Numeric` fields, the other types are automatically deduced by the Author module, and the user is shielded from the need to set the database field types. For `Numeric` fields the database field types default to `Integer` but the user may change them to `Decimal` (assumed 2 places) if they wish. The database field length is automatically deduced for Boolean and Numeric fields, and a default calculation is performed for the length of Text fields based on the length of the field on the users's screen (which may be set by the survey author, as discussed previously). In the interests of making life easier for the user various `features` are designed into the system for the preferred embodiment. For the Quenstion's goto directives the Author defaults to a system specific value of `{Next}`. When a new Question is added, the Author module automatically retro-fits the new Question's name into the previous Question's goto directives if they were set to `{Next}`. Equally if the user changes the names of a Question all other questions are scanned to see if any of the other Quenstion's goto directives point to the current Question, and if so, their goto directives are changed to reflect the new names. The scan test (part of the author module) tests for as wide a range of errors possible: 1. `Orphan` or `Cul-de-sac` questions. 2. Question Box text which has not been changed from the system default `Question Text for Question No. 001`. 3. Item (Option Buttons, Check Boxes, and Labels) text which has not changed from the system defaults (`Option Button Text 01`, `Check Box Text 01`, and `Label 01` respectively). 4. Duplicate database field names. 5. Any missing fields. The author module automatically checks for missing, or duplicate or illegal database table names at the point of creation of the survey database. A wide range of system defaults exist for the user to set the default size and position of the Question Box, default values for all the items, default values for the `Never Seen Value` and the default goto directive. The author automatically generates the last Question (`{FINISH}`) when a new survey document is created. When the user decides to mail out the survey to the remote users the following sequence occurs: 1. The user is presented with a list of E-Mail users (via the MAPI mail interface) for the remote users (or groups of remote users) to be selected. 2. The user is presented with a suitable `Subject and Note` dialogue box to advise the remote users about the survey. 3. The user is presented with a list of E-Mail users (via the MAPI mail interface) for the Collator E-Mail address to be selected. 4. The user is presented with standard ODBC dialogues for the selection (or creation) of the Data Set Name (DSN) for the required database. 5. This is followed by a dialogue box where the user is asked to enter the `table name` for the survey (defaults to the name of the survey). 6. The table is created in the ODBC database. 7. The SVQ section of the SVM is written to disk. 8. Respondent module (Response Exe) is pre-pended to the SVQ, given the `file-name` of the Survey Master Document (SVM) and the extension `Exe`. 9. The `composite object` of Response Exe and the SVQ is mailed to the selected respondents (and to the Collator E-Mail address) via the E-Mail system. The Respondent Module The composite file, containing both the Response Exe (the executable methods for the SVQ) and the SVQ `persistent data`, appear as an executable file attached to the E-Mail message containing the `Subject and Note` texts (mentioned in the Author module above). When the user launches the attached executable its start-up-code offsets the file pointer in the MFC standard archive read method to point to the SVQ data section of itself. It then loads the data to `re-instantiate` itself, processes the data through the `common minimal set` of SVQ methods and presents the questions to the user. The answers are stored in the SVQ as the user works through the questionnaire. When the user finally exits the `{Finish}` terminating question, the answers are copied to the Survey Response Document (SVR). As there may be hundreds (or thousands) of SVR documents arriving at the Collator's E-Mail address, the size of the SVR is extremely important. For this reason the SVR has been created separately from the SVQ. While the SVR's data members are exact copies of the associated data members in the SVQ the number of members is reduced to the bare essentials--see below for a description of the SVR structure. Collator The Collator works with 3 document types: 1. Its own `survey register` document, which is a list of current surveys including relevant associated information--see below. 2. The Survey Questionnaire document (SVQ). 3. The Survey Response Document (SVR). The Collator's main function is to read incoming survey response documents (SVR) and update (or add) the respondents answer information to the appropriate ODBC database. The Collators other functions are: 1. To read incoming survey questionnaire documents (SVQ) and register the new survey in the Collator's `register`. 2. To send reminders to entries in a pre-populated database that have not yet responded (i.e., the Mail Received Date field is still set to the default). 3. To re-send the Survey Questionnaire Document (SVQ) to E-Mail users that request a resend, or to entries in a pre-populated database that have not yet responded (i.e., the Mail Received Date field is still set to default). Outside of the methods available to Collator through the document `objects` that it is `aware` of, the Collator is a straight forward and simple program. Upon starting the Collator reads the E-Mail message queue to ascertain if there are any relevant messages of it. If there are no relevant messages it goes to `sleep` for a period of time controlled through its user definable options (see FIG. 12). If there are messages to process then it sits in a loop reading and processing messages up to a number specified again in its user definable options (see FIG. 12), or until there are no more messages to process, where upon it will put itself to `sleep` again. If it has been `asleep`, it will re-enter the loop as if it had just started. When it processes an SVR (assuming the associated survey has been registered) it will update the appropriate database and delete the E-Mail message containing the processed SVR. When it processes an SVQ it will register the new survey in its `register` and copy the SVQ to a user definable directory for safe keeping. The surveys are registered with a default status of `Active` but the user may choose to set that initial status to `Suspended` to have manual control over when surveys are processed. Collator E-Mail Messages The Collator monitors the E-Mail in-tray. It searches for 2 types of E-Mail messages. 1. The copy of the Survey Questionnaire Document (SVQ) sent by the Authoring module at questionnaire transmission time, and 2. The Survey Response Documents (SVR) returned by the respondents (remote users). Both these messages are coded with a signature so that they can be picked out from the normal E-Mail that may arrive. The signature indicates what types of message they are, but not which particular survey or database they belong to. Collator has to open the messages and read them to ascertain that specific information. Collator Survey Status Collator maintains a `register` where all the current and recent surveys that it is `aware` of are listed. Each survey has an associated status as discussed previously: 1. Active--the survey is being processed normally. The responses are being read, the database is being updated or added to and the read messages are being deleted once they have been successfully processed. 2. Suspended--the survey responses are ignored. Collator reads the message, ascertains that the survey is in a suspended state and advances to read the next E-Mail message. This state is set to temporarily isolate the database from the incoming E-Mail. This is useful for accessing the database before the survey is terminated, for staged analysis or repair. A suspended survey can either be re-activated or terminated. A survey may optionally be set to suspended the instant that it is registered. 3. Terminated--the survey is concluded. Any E-Mail associated with this particular survey will be read to ascertain its identity and then deleted without any processing. Collator Survey Registration Collator registration occurs as a result of receiving either the SVQ or an SVR E-Mail message for a survey that has not yet been `registered`. The survey is immediately stored in Collator's internal register, and the status is either set to `Active` or `Suspended` depending on the user options that have been set. A user may choose to set the `Suspended-on-registration` option if the user wishes to set the survey `cut-off` values before any of the responses are processed. The associated database and the number of responses received is also stored in the register on a survey by survey basis. If the default status for a newly registered survey is `Active` but a problem occurs when the associated database is being accessed, the survey will be automatically placed in a suspended state with a message indicating that an error occurred linking to the database when the survey was being registered. The E-Mail message will remain in the in-tray in this case until it is able to be processed correctly, or unless its status is changed to `Terminated`. A survey entry in the Collator's register can be deleted if it is old and has been previously terminated. If an old response arrives after an entry has been deleted the Collator acts as if it is a new survey and will attempt to re-register the survey and to link to the database and process the response, unless the default registration option is to set a suspended state. Collator Survey `Cut-Off` Levels If the survey is using a pre-populated database then the exact number of responses is known and a `cut-off` level can be set in terms of either a `percentage complete` or a specific number of responses. If the survey is not using a pre-populated database then the `cut-off` level can only be set as a specified number of responses. Once the `cut-off` level is reached the survey status is immediately set to `suspended`. The `cut-off` level can be left empty and the Collator will continue to process until the survey is manually `suspended` or terminated. Collator Database Creation An additional feature of the Collator and the format of the Survey Response Document (SVR) is that the database can be re-created from the information in the SVR. If the original database was pre-populated the fully populated database cannot be re-created, but the correct database structure can be reproduced and Collator, being aware of the `re-creation`, can change the database `updates` to `additions`. This has two main advantages: If for any reason the original database has been corrupted, destroyed or lost, and a sufficient number of responses has not yet been processed, the Collator can re-create the database, and the Author does not have to burden the remote users to re-respond to a previous survey. If the survey instigator is in a location physically removed from the original database, but wishes to run Collator and process the responses, a new database can be created. Collator Options The Collator can be set to process continually or to sleep for a range of minutes and then awaken to process a specified number of responses only. The Collator `register` document structure
______________________________________
WORD wNumOFSurveys Number of Surveys
WORD wSleepMinutes num of minutes to sleep
WORD wMaximumGrab max num SVRs to process
WORD wDBNumOfRetries
max ODBC retries
WORD wDBRetryWait 100th secs between retries
STRING strSVQPathName SVQ directory name
BOOLEAN bSortByName sort by name or date
BOOLEAN bAscending sort ascending or descending
BOOLEAN bHideTerminated
hide terminated from display
BOOLEAN bSuspendOnRegister
suspend on registration
DATETIME LastScan timestamp of last scan
ARRAY SurveyRegister array of Survey info
______________________________________
The Survey Register Structure
______________________________________
WORD wSurveyStatus Status of the survey
WORD wtotalResponses
total SVRs received
WORD wProcessedResponses
number SVRs processed
WORD wDeletedResponses
number SVRs deleted
WORD wTotalRows pre-populated total
WORD wCutOffCount holds cut off level
BOOLEAN bRecreatedDatabase
indicates DB recreation
BOOLEAN bPrePopulated indicates pre-populated DB
BOOLEAN bRetainAfterReply
indicates SVQ is kept
DATETIME tmRegistered timestamp when registered
DATETIME tmCurrentStatus
timestamp of current status
DATETIME tmLastRead timestamp of last SVR read
DATETIME tmRemind timestamp of last Reminder
DATETIME tmResend timestamp of last Resend
STRING strSVQFileName name of SVQ file
STRING strSurveyName full SVM pathfilename
STRING strTableName Name of the Table
STRING strDataSetName Data Set Name (DSN)
STRING strDataSetConnection
Full DSN Connect string
ARRAY DataSetDataTypeArray
Available Data Types Array
______________________________________
The above-described modules access 3 document file formats collectively known as the Survey Documents: 1. the Survey Master Document (SVM), 2. the Survey Questionnaire Document (SVQ), and 3. the Survey Response Document (SVR). The design of these Survey Documents underpins the preferred embodiment. Whilst the preferred embodiment is implemented for MS Windows the design of the Survey Documents could easily be transferred to any computer system. The Survey Master Document (SVM) contains the Survey Questionnaire Document (SVQ), and also contains additional survey `author` information not required in the questionnaire (SVQ) section. The Survey Response Document (SVR), contains the answers and sufficient information to link to the database and sufficient information to re-create the database in the case of a catastrophic error. The Survey Master Document (SVM) The SVM is composed of four main sections: 1. The Survey Questionnaire Document (SVQ); 2. Subject and Note Texts; 3. Array of Recipients; and 4. Document defaults and options. 1) Survey Questionnaire Document (SVQ) The following lists the document variables in order.
______________________________________
String strSurveyMasterPathName
PathName of this survey -
long name for document
BOOLEAN bFlagPrePopulate Pre-populate Database
BOOLEAN bFlagRetainAfterReply
Retain SVQ after Reply
BOOLEAN bFlagFollowUp Indicates secondary Survey
String FirstQuestionName
The first one to start with
String SelectedQuestionName
Currently selected Question
Name
String NextQuestionName Next Question Name to be
selected
WORD NumOfQuestions Number of Questions in the
survey
Strut ReplyToInfo The Collator's mail address
String strTableName Name of the Table
String strDataSetName Data Set Name (DSN)
String strDataSetConnection
Full DSN Connection string
Array DatasetDataTypeArray
Array of Data Types
available
Array QuestionsArray Each element is a
"QuestionBox`
______________________________________
The following is a description of the document variables. The strSurveyMasterPathName is the full pathname of the survey master document itself. The bFlagPrePopulate indicates that a pre-populated database is being used. The default value of this flag is False. If True this flag has several implications; 1. the Survey Authoring Module will create and pre-populate the database with the E-Mail name and address, default mail received date and each question's `bypass` values; 2. the Respondent Module will set the Survey Response Document (SVR) to `update` and not `insert` records to the database; 3. the Collating Module responds to received SVR with this flag set to true by displaying percentage received figures as well as numbers of responses received. Also the Collating module allows the use of `reminds` and `re-sends` if this flag is set to true; and 4. all three modules are aware that if this flag is set then the index on the database is unique only on the name and address, and does not include the mail received date. Equally, if this flag is false it indicates to all three modules that the database is indexed on name, address and mail date received, so as to allow multiple responses from each respondent. The bFlagRetainAfterReply indicates to the Respondent Module that it should indicate to the remote user to keep the current Survey Questionnaire Document (SVQ) rather than delete it on completion. The default state of this flag is false. The bFlagFollowUp indicates to the all modules that some of the mail addresses being used are from previous surveys and may no longer be valid on completion. The default state of this flag is false. The FirstQuestionName stores the name of the question to be first selected from the QuestionsArray. The SelectedQuestionName is simply a current storage place for the name of the current Question. The NextQuestionName is loaded by the control logic with the name of the next Question to select. The NumOfQuestions is simply a storage area to record the number of Questions in the survey. The ReplyToInfo structure contains the E-Mail name and address to reply to the Collator via the E-Mail system. The structure contains:
______________________________________
String MailName
String MailAddress
LONG MailEntryIDSize
Array MailEntryIDData
______________________________________
The fields are specific to MS Mail, but can be extended for any electronic mail or electronic bulletin board systems. The purpose of these fields is to store the Collator's mail address in the message that is sent to the Respondents. Note the Collator's mail address may not be the same as the Author's mail address (see previous description). The Author selects the Collator's mail address just prior to the Survey Document being sent to the Respondents. The strTableName contains the name of the table to use within the specified database. The strDataSetName contains the DSN that specifies on the local user's computer which database to use. The DatabaseSystem is specific to MS ODBC, but can be extended for any database system. The strDataSetConnection contains the full ODBC connection string that is the complete identification string required to access the ODBC database. The DataSetDataTypeArray is a list of the data types available for the chosen database. This information is used in the creation of the database. The QuestionsArray is an Array of Question Box structures which contain all necessary information to present a question to the remote user. The `QuestionBox` structure is explained after the description of the Survey Document's main sections (see `The Question Box Structure` below). Note: the Question Box array is accessed by use of the desired Question Box's `RefName`; equally when a Question Box is placed in the array the `RefName` is extracted from the Question Box structure and used as the index associated with the array. Note that the bFlagPrePopulate flag is set to false where, for example, the Author is sending a survey to an electronic bulletin system. As has previously been mentioned, application of the invention to a "bulletin system" would involve posting a Survey Questionnaire Document (SVQ) on a "bulletin board" for selection and answer by any user having access to the bulletin board. That is, the users would not be preselected for the Survey Document to be sent to. In such a case, the database size would depend upon the number of answers received to the Survey Document. As discussed above bFlagRetainAfterReply flag when false indicates to the Recipient that it should erase the copy of the composite file when the Recipient has successfully sent back an answer (SVR). However if this flag is false then the SVQ may be preserved and used again. The bFlagRetainAfterReply flag when true also tells the Author and the Collator that each recipient may send more than one answer (SVR), and therefore an extra `DateReceived` field is generated in the database. This extra field is used to make the answer rows in the database unique for indexing purposes, and also to track the arrival of each of the multiple answers. This facility is useful where the local user may require periodic update of the same survey, eg. political poling. Out of date information would be overwritten by the new information coming in from the remote users, and the database "date received" field would indicate the latest date which an answer has been received from the remote. 2. Subject and Note Texts
______________________________________
String MailSubjectText
E-Mail Subject Text
String MailNoteText E-Mail Note Text
______________________________________
The MailToSelection stores the operator's selection of who the mail recipients are. The MailsubjectText is a simple one line description of the mail being sent to the Recipient. The MailNoteText is used for a description of the survey, read by the Recipient before they begin the survey. 3) Array of Recipients The recipients data is exactly the same as reply to info accept that it is an array of them.
______________________________________
Array RecipientsArray
Each element is a
"RecipientDate`
______________________________________
Again the actual `RecipientDate` structure implemented in the current embodiment is specific to MS mail, but can be extended for any electronic mail system. Note this is not a fully expanded list--just simply what the operator chose. It may be any combination of individuals or E-Mail groups, or the E-Mail names and addresses of Respondents from previous surveys. 4) Document defaults and options
______________________________________
WORD wQuestionBoxLeftMargin
WORD wQuestionBoxTopMargin
WORD wQuestionBoxWidth
WORD wQuestionBoxHeight
WORD wQuestionTextWidth
WORD wQuestionTextHeight
WORD wQuestionTextLeftMargin
WORD wQuestionTextTopMargin
WORD wControlsLeftMargin
WORD wItemsLeftMargin
WORD wCentreQuestionText
String strNeverSeenValue
String strNeverSeenSelection
String strOptionChosenValue
String strOptionChosenSelection
String strCheckBoxTrueValue
String strCheckBoxTrueSelection
String strCheckBoxFalseValue
String strCheckBoxFalseSelection
String strNumericFieldType
String StrNumericTypeSelection
String strGotoDlgName
String strGotoDlgSelection
______________________________________
These fields are used as a place to store Author defaults for the creation of each of the Question Boxes by the Author. They are a convenience for the operator of the system, but not relevant to this description. The Question Box Structure Overview From the Recipient's perspective a Question Box is simply a standard graphical user interface `dialogue box` with: 1. The question text in an area at the top of the Question Box; 2. some user controls; either option buttons, check boxes, numeric data entry fields, or text data entry fields; and 3. two push buttons at the bottom of the Question Box, marked `Previous` and `Next`. The Question Box structure must contain and/or achieve the following: 1. Sufficient information to display the Question Box via the graphical user interface; 2. define the Question Box's database field's name, type and size in the Author or Collator created database; 3. store the Recipient's answers in all the Question Box's database fields; 4. store the `Never-Seen` values as the Recipient's answers in all the Question Box's database fields if the particular question is never asked due to Question Box `branching`; 5. store the `Branch Control Language` script for this particular question if required (see later); and 6. define the name of the next Question Box to `goto` depending on the user's current or previous answers. To achieve this there is a three tiered structure: 1. The Question Box or header containing several `GroupData` structures; 2. the `GroupData` structures which in turn contains several `ControlData` structures; and 3. the `ControlData` structure. These three structures are detailed after the next section. Constants/definitions used by all three structures Each control is assigned a `TYPE` indicator. This is used to ensure consistency between the control and its Group. The controls are grouped by `TYPE`.
______________________________________
define CTL-TYPE-NULL 0x00000000L
define CTL-TYPE-QUESTIONTEXT
0x10000000L
define CTL-TYPE-NEXTPREVBUTTONS
0x20000000L
define CTL-TYPE-OPTIONBUTTONS
0x00000001L
define CTL-TYPE-CHECKBOX 0x00000002L
define CTL-TYPE-NUMERIC 0x00000004L
define CTL-TYPE-TEXT 0x00000008L
______________________________________
These defines indicate the `TYPE' of each Group.
______________________________________
define GRP-TYPE-NULL 0x00000000L
define GRP-TYPE-QUESTIONTEXT
0x10000000L
define GRP-TYPE-NEXTPREVBUTTONS
0x2000D000L
define GRP-TYPE-OPTIONSBUTTONS
0x00000001L
define GRP-TYPE-CHECKBOX 0x00000002L
define GRP-TYPE-NUMERIC 0x00000004L
define GRP-TYPE-TEXT 0x00000008L
define GRP-TYPE-GRID 0x00000100L
______________________________________
The Question Box needs to indicate what `TYPEs` of group/controls it contains. Note; 1. The first 4 are simple types. 2. The `GRID` is used in conjunction with the first 4 TYPEs to indicate which TYPE of `grid` it is.
______________________________________
define DLG-TYPE-NULL 0x00000000L
define DLG-TYPE-BASE 0x30000000L
only PUSHBUTTONS & STATICTEXT
define DLG-TYPE-FINISH 0x30000000L
only PUSHBUTTONS & STATICTEXT
define DLG-TYPE-OPTIONBUTTONS
0x00000001L
define DLG-TYPE-CHECKBOX 0x00000002L
define DLG-TYPE-NUMERIC 0x00000004L
define DLG-TYFE-TEXT 0x00000008L
define DLG-TYPE-GRID 0x00000100L
______________________________________
Following defines are for masking out the 3 sets of TYPEs:
______________________________________
define STANDARD-TYPES-MASK
0xF0000000L
Standard (StaticText & PushButtons)
define ACTIVE-TYPES-MASK
0x000000FFL
Active (Option, Check, Numeric, Text)
define COMPLEX-TYPES-MASK
0x0000FF00L
Complex (Grid and Combo indicators)
______________________________________
The ControlData Structure The ControlData structure is mainly concerned with displaying the controls within the Question Box's dialogue; therefore they are based on MS Windows ControlData structure. However it is the additional fields that are important, as each graphical user interface will store its control's data slightly differently. Also please note the standard MS Windows IDOK define is allocated to the `Next` button, and the IDCANCEL to the `Previous` button. This is pure convenience--any define will do. Attributes as per MS Windows structure
______________________________________
WORD wX X pos in dlg units
WORD wY Y pos in dlg units
WORD wWidth Width in dlg units
WORD wHeight Height in dlg units
WORD wControlID ID for messages from the
control
DWORD lControlStyle Window Style -
Option/Check, Default,
Group etc
BYTE bClassID Class ID - Button, Edit,
Static, etc
String ControlText Control Text
BYTE bBytesToNextControl
Always null
______________________________________
Attributes additional to MS Windows structure
______________________________________
DWORD lControlType Type of Control (Option
Button, Check Box, etc)
String FieldValueSelected
Value of database-field if
this Control is selected
String ItemLabel Name used to reference the
control through the BCL
String GotoQuestionName
See explanation below
______________________________________
The lControlType is used to cross check the control within the parent group structure. The Fiel | ||||||