Forum OpenACS Q&A: Response to Survey Package Expansion Proposal

Dave, the hard part about using ad_page_contract and validation filters is that they need to be entirely dynamically generated for each survey, subsection and subsurvey and possibly dynamic given what Stan has suggested. I.e. if they answered yes to question 13 they need to also have answered question 15 with a value greater than "x"... - I agree that this will be tricky (though by all means possible). The trick will be in getting a data model that isn't completely bloated... I don't think that the unused code from simple-survey will be useful with the additions Stan has suggested... this goes way beyond simple-surveys grading... though you obviously didn't know any of this before Stan made his comments, so at the time you made the suggestion it was a good one. I'm glad to hear that you have already thought about templating, and what you intend to do seems good to me.

The rest is in response to Stan's concerns.

I am not certain if your third application is qualitatively different or not, and even if it is, I think this should be part of survey and not a separate package. At least in my view, it would nice to have a survey package that can be as simple or complex as you want it at the click of a button. I think the site owner  should be able to hide much of the complexity from survey admins (i.e. health administrators, teachers, etc) through simple parameters - that way, if all you want to do is ask "what time do you go to bed?" or "how many children do you have?" you can shield the plethora of options that could be available so as not to confuse people that only need a "simple" tool. But in the end it seems to me that the things you talk about could certainly have applications in education.

I am not certain about what you are asking in terms of "range checking" and "string matching" could you please elaborate on this (I could take a guess but don't want to thread this bboard with useless info). I would like to note that I am not saying that only one answer would have a certain value... if there are 5 possible responses you could assign 3 points to answer A, 5 points to answer B 1 point to answer C, etc. It isn't just going to be 1 point for the correct one and 0 for others.

as far as including separate CRF forms goes, based on defined responses I think that the data model I proposed could handle this with little modifications. All that would be needed is once a section is completed (and a section could in fact be just one question), we could route the survey through information contained in "survey_point_translation" and have a field in that table that if the boolean saying "include_subsurvey" is activated it would route them to that subservey - and then through once it is finished return them to the primary survey...  there would be a little bit of complexity here, in terms of routing, but I am certain it wouldn't be too hard. A bit more work would be needed if we wanted to relate many subsurveys (like your <i>Enter the following for all hospitalizations since some date: date of admission, primary diagnosis, discharge hematocrit, etc</i> example), to a special question - a more simple example if I understand you correctly would be if you asked "how many children do you have" and the user entered 3, then the system would automatically come back with 3 separate surveys with questions about those kids... skip logic could be done in javascript and would essentially be a different way of using sub-surveys - though I would prefer for it to be done in html. You wouldn't need a new page per question, just a new page per time you want to use skip logic... overall I think this would be cleaner. If we intend to use "skip logic" on a long survey, it would be better to have multiple pages anyways instead of an incredibly long form, that way each time they continue the information they have previously entered is stuffed in the database, and they don't submit 300 question form and accidentally press a wrong button and loose all the information they had painstakingly entered.

Annotating every response just means adding another field to survey_question_responses, that is text and titled user_comment - it could also be the same as grading_custom_comment, unless we want the admins to be able to annotate a response that would be hidden from the user on the same information as the user being able to annotate responses. UserID is already entered into that table, all we would need to do is add a timestamp - also just a simple column add. The audit record is already in place as has been mentioned (though it would be nice if editing a survey, to not re-enter all the info as a new response, but only enter those values that were changed - again, that isn't too hard to do).

Scheduling shouldn't be hard. The various thank you and reminder email messages are certainly useful for the scenarios I had talked about so I certainly think they should be added. I haven't worked with acs-mail or whatever other package does this, but I am under the impression that many of the mechanisms needed to do this are already in place. In terms of UI's I don't know how we could get a "telegraphic" keyboard entry UI other than the normal press tab to move forward and enter to go to the next page. We can start them out on the entry field, much like when you go to google.com it starts you out in the search box, and we should be able to eliminate useless links between entry fields (which would be hit by if you press tab), but I don't know how else to simplify this short of running a java application within the browser (which is a can of worms I don't want to open).

I will have to think about how scoring algorithms can be accommodated into the data model, and am certainly open to suggestions. Do you think this would be limited to addition, subtraction multiplication and division or would more complex forms of math be needed (okay, not complex, but I mean anything beyond 3rd grade math like derivatives, tangents, arcsine, etc.). Comparing to a scale table should be at least close to taken care of by my proposed survey_point_translation table... what we might want to do is abstract scoring into a separate entity and have a table choose to relate to another scoring table although it could have its own... i.e. these tables are not bound directly to a survey. The best way I can think of dealing with missing responses is to relate a percentage score to survey_point_translation - because it would allow certain questions to have been omitted...

That's it for tonight.