Dragan,

Thanks for your detailed reply. At this point, my biggest problem is building an easy to use, systematic interface for BUILDING the questionnaire, administration is more straightforward. But I am really set on the 'tree' vs. network idea, ie. that each branch is unique. Although it may introduce a lot of redundant questions. I need a systematic way to add a question, define possible answers, define a branch to question for EACH possible answer, then, systematically, create the next question (or select it from an existing bank of questions ?), then, go back to the previous question, and repeat the process until all branch possibilities are covered, then, move on to the first of the most recently defined new branches, and define branches for it.

Does this sound feasible ? Does it make sense ? How to implement ???


>Here are the basics of my database design (there's more but..)
>>For the survey 'definition' - a table called surhdr - with a survey id
>>For the questions 'surques' - 1 Row per question
>>For now I only support text/numeric answers and multiple choice/pick one only
>>types. Ultimately, I need to support 'pick more than 1', and need to support
>>questions that represent a score, scale or rating, eg. add up a score for
>>level of agreement - 5 - agree strongly 4 - agree 3 - disagree 2 - strongly disagree - get an agreement rating.
>
>I've done something more limited - which means without branching - so my experience may be only of limited value. One thing here is that you have to cover two issues: when do you create the records for the answers, and where do you create them from. For the first one here, I've done it two ways: one way is to create all answer records in a batch at the same time as when the questionnaire is created; the other way is to check with the form's template whether we got the answer records, and if there's something wrong (wrong number of records, wrong question IDs etc, none found at all), (re)create them. As to "where from", I have a table with questionnaire definition - row per question, with the visible ordinal number (like "B.4" and such), actual ordinal number and question ID, and that's the template to create answer records from. Now in your case you may want to avoid creating records for skipped questions, right? It'll make your life somewhat more interesting :)
>
>>So I have a table - surans - one row per possible answer with the answer
>>text. If it is a text or numeric answer, there is only 1 row in surans
>>and the answer text is blank
>
>For multiple choice answers you may use an integer field, and store the ordinal numbers of checked answers as bits in it, which would give you some symmetry (one question - one answer record) at the price of having to do some coding to store and retrieve answers (for j=1 to 32... bitset(answer, j-1) or bittest() for reading). The limitation is that you can't have more than 32 choices or else you'd need a second (third etc) integer field.
>
>>Coding a 'network model' questionnaire that allows branching from anywhere
>>to anywhere seems VERY HARD. How would I check for circular references ?
>
>You should build a string or array of questions visited while following a branch. If you visit any one of them twice, it's circular. I've done this for an production assembly sheet, where anything could be an element or composition thereof, or combined in several levels, and the rule was that nothing could be an element of itself, no matter how many levels apart.
>
>>Coding a 'tree' doesn't seem as hard. In other words, only allow branching
>>to a new unique question # that no other branch has branched to. A lot of
>>duplication possibly - if there is overlap. But easier to handle
>
>I'm not sure this limitation would hold in real life. Imagine you get to something like "if your answer to 5 is 1, answer 6 to 9 then skip to 20, if it's 2 answer 10 to 14 then skip to 20 else go directly to 15". This way you have three ways to come to 20 - once from 9, once from 14 and the regular fall through from 19. By your rule, branch from 14 to 20 is not allowed. I think checking for circular references should be sufficient.
>
>>in section 1- if results are 'pet lover' go to pet lover section, if results
>>neutral - go to pet neutral section, if hate pets go to pet haters section
>
>This seems better (i.e. more stable and easier to implement), but then several sections would have the next question the same (i.e. once done with pet related stuff, you end up with several things pointing to the introductory part of the car-van-truck section), one more reason to give up the unique branching rule.
>
>>Question: showing one question at a time is easy, attempting to show
>>more than one at a time, especially if you are handling complicated
>>branching logic, seems, well, very very difficult.
>
>I've displayed the questions in containers three levels deep: outer is the visibility frame; middle is there to scroll within the outer one (and is higher than it, so it's "behind" the outer one), and then each question-answer set of controls is in its own container, one below another in the inner container. In this case, I'd simply hide all the containers between the current question and the question to jump to, so it would appear to be the next question.
>
>>Question: Showing question numbers on the screen - Each question has an
>>'absolute' number' Also, I have 'sections' and each question has a number within the section. The unique numbers are added, on the fly as I add content,
>>and have very little correspondence with the actual order of the questionnaire.
>>It seems to make more sense to just autoincrement a number based on the
>>order in which they answer, which might vary depending on the branching. But how do I print output ? what number to print - 'relative' number or absolute number'
>
>The questionnaires usually have their own numbering scheme from the original printed version, and the author would probably like to keep it. That's why I mentioned the "printable ordinal number" which is entered manually during the composition of the questionnaire.
>
>>Another problem - building the interface for asking and answering hasn't been
>>that hard. But I am hand keying via browse, my questions and answers, I need
>>a 'build questionnaire interface' - to automate the handling of question #
>>sequencing - and 'branch as I build'
>
>I've built two forms for this, one to get the questionnaire's global stuff, and the other with just a grid with a toolbar to handle the questions for one form.
>
>>BTW - I am building a set of radio buttons, and /or text boxs for the answers,
>>on the fly with 'addobject() in a container.
>
>I've had radio buttons for answer entry - and once it was finally done (took quite a while and lots of coding around its shortcomings, because we needed hot keys), gave it up in favor of combos.