The object creation in JS works well and is a fundamental step, but in order to create dynamic question/answers there needs to be some sort of "branching". At the moment the object questions will just pile up and up and up. This is where I can help - the dynamic logic.
Jacob - some questions...
Have you thought the logic through yet? I am making a little video for you to help you do just that. It involves using/creating a DYNAMICALLY BUILT MS Office Organisation Chart in Excel (for starters) - it's not complicated it just sounds that way. To get started I want you to think of each question as a "room". Imagine the question is written on the wall of the room. Each possible answer is a "door" out of the room, leading to a new room with a new question. This sets up a branching effect that will allow each user to take a single route through the questionnaire, despite all the possibilities. The weights of each answer can be thought of as a score on each door. If a door requires the user to input data before proceeding, then that response can be stored alongside the route taken, in a separate 2D array object that holds the Answer ID and the input text.
What's important here (to my mind) is that you build an application that can be flexible in its questions through a front end "map". The map might look like an orgChart where each node is a room and each connecting line is an optional answer (a door out).
So in this first image you can see a new question is being asked depending on which answer is chosen.
Here, in this second image, you can hopefully see a model where not every question REQUIRES a separate new QUESTION.
But how will this translate in to data from (or to) a table?
Let's have a look at a sample database table of employees...
Each employee reports to another employee, except for Andrew the President. We can use programming code to extract the information directly from the table and build an MS OrgChart out of it - like this:
The code for this is VBA, and I won't talk about it here but basically what it does is look at the relationship between the employee and who they report to.
Pretty cool huh!? So building on this we can also do the same for a table of information containing questions...
....but instead of the employee reporting to someone, each question Follows From a previous one.
So it seems we can (yes we can) create the branching effect, without the nice graphics, as long as the relationships are set up correctly. In order to give each question a location ID we can also use a neat and simple ID, that tells us where it is in the tree, and who it is at a glance AND who its parent question is.
Have a look at this copy of the first image, with node names added in:
The length of the digits tells us what level we are on. So '010' would always be question 3 (3 digits long). We can also tell from this that its parent (the follow from question) is '01' or in code, its ID length - 1. :-D. This is very useful stuff indeed!!! How so?
1) We no longer even require a "reports to" or "follows from" field in the table - it's parent is known from it's ID length - 1.
2) In fact the whole Questionnaire Table can consist of just two fields, the Question_ID and the QuestionDesc. Anything extra is pudding.
3) Once we run out of digits (0-9), which would surely not happen in your case, we can use a-z, then A-Z and so on, to represent positions. That's a huge tree!
4) A Question's Score (or Weight) can be a third field, if necessary, which represents the value on the door on the way into that room. After all, each room only has one door in to it (at the moment).
5) If I say a question has an ID = 01110203120112321011, you'd know exactly where that question lives and who it's parent was right? Well there's more...
That number (or string) could also represent the entire route the user made in answering the questionnaire. If you wanted to get a 'total score', all you would have to do is look up the individual scores at each level in the table (each level being each new digit) and add them up.
It's so easy in fact, that we can look at any tree of complex nodes and easily count it's ID through the various levels, without even having to label them. So... once you get cracking with the logic through an Orgchart, you'll soon be building the table directly without having to use an orgchart at all!
Notice how I haven't mentioned answers? That is because only the QUESTIONS really matter. The Questionnaire table does not even need to know what the answers are. The table only needs the questions, their IDs, and from that, who they are related to (i.e. the parent question).
So it's vitally important to sort out the logic of your questionnaire. I suggest you play around with the Org Chart in MS Office (manually) to lay out a rough idea of the relationships, the number of Questions that follow on, and when indeed separate questions will be needed.
Using this system it should be entirely possible to make a dynamic orgChart that builds the table out of the orgchart. How do we make an online orgChart outside of MS Office? Well... here's one I prepared earlier (in Adobe Flash)....
This one has limited (but also extra) functionality. You can add a node by clicking on the little down arrow on the node box. You can drag the tree around by dragging a node, and you can also zoom in and out with a mouse wheel (if you have one of course). Because you can zoom in wouldn't it be cool to just create ANY questionnaire using a grpahic interface? I think so. Well that's a helluva lot to take in so far, so I'll leave it there for now. Let me know what you think if & when you get a chance.
ZOOM Edit: I've just noticed this bug - zooming won't work in Chrome without Pepper enabled. Instead the page will just scroll up and down when using the mouse wheel. If you are using Chrome, the Flash plugin is a special version called "Pepper", go to URL chrome://plugins to see it. If Pepper is disabled in Chrome, it will default to the system wide Flash plugin instead, and there are plenty of reasons why people disable it - having both plugins enabled can cause problems when trying to watch Youtube videos in full screen mode. Hence I usually switch off Pepper for Chrome for consistency in Youtube (eesh!). Flash is an evermore fiesty, slippery and troublesome plugin... sadly. Imagine for one second working for Adobe Flash... knowing that Apple and Google actively hate you.