Forum OpenACS Q&A: survey builder module

"If somebody finishes and ports aD's survey builder module, ACES
would go from having the weakest testing tool to having the strongest
one."

Then I found a thread on the web/db bboard at aD and Mathew Burke
mentioned:

"Yes, we are working on the "complex" version. The ASJ article uses
the term "survey builder" and since that seems to be accurate and
descriptive, that is the term we are using.

We are tentatively planning on an alpha release for March 16th.

-- Matthew Burke, February 27, 2001"

Does anyone have up-to-date information about this module? It neither
appears on the OpenACS 4.x porting schedule nor in the download area
of aD...

This is important, though:

Please do NOT use the URL I posted above. It is apparently their
development server. In fact, if the moderators of this forum could
edit or remove that information for me, I'd be grateful and I'm
sure the folks at UCLA will be grateful as well.

If you want the survey builder code, please use the following
URL:

http://surveys.crump.ucla.edu

It's my bad for not checking with the folks at UCLA for not
checking with them before posting the information.

We will take this opportunity to redo some things in Survey Builder that have bothered us for some time. We would like to understand what other people are interested in seeing in the next version.

So far, it looks like a cleaner, more intuitive UI and user documentation are desired.
What else?

• Cloneable items - for situations where you have a question like "How many siblings are in your family?" And you then want to provide first_names, last_name age, gender fields for each member.
• Item grouping - for the purpose of tracking information across pages that relates to cloned items. For example, perhaps a survey continues to ask information about each sibling's hobbies. For reporting purposes, we need to preserve which items across pages related to which sibling.
• xml export/import - We needed a cleaner way to do development on a survey on one system and then move that work over to a production server-- Pretty straightforward.
• Growing items - this one allows the response range of an item to grow with an "other" option. For example, for a radio button question "What is you favorite color" with the response range of (red, blue, green) there will be an additional option "other" with an associated text box. The survey author can decide if admin approval is required before any user-submitted other colors are presented to subsequent users. Otherwise it becomes immediately available.
• Template system - this allows developers to place procedure calls at the beginning and end of surveys. The procedures configure the properties of the page and item before the page displays.
• Expanded policies - we needed to allow any member of a group to be able to come into a half-finished survey and complete it even though it was started by a different user. This capability was required in patient data management situations, for example, where a research assistant is collecting information from a patient who is participating in a clinical trial. We have several RAs working on a project, and a survey is capturing data related to a patient, but the data entry is being done by 1 or more RAs.

For me, I'm not going to have a good sense of what else I'd want in survey builder until I get a chance to play with it a bit more. UI is definitely going to be an important place to start, though.

In general, I'd like to see it usable for the following types of applications in addition to the creation of surveys:

• Testing: This will be crucial for .LRN. We'll need anti-cheating mechanisms, the ability to create a test question bank (both of which may already be in the current system), and a decent reporting system (though some of this last piece may be customized specifically for .LRN).
• Diagnostic or decision support tools: With branching, you can set up a system to help users identify problems, make difficult choices, and so on. Nothing other than the branching capability itself is necessary here, although some kind of tree visualization tool would be very helpful. Another nice-to-have for this purpose would be the ability to capture the decision paths of individual users.
• eLearning simulations: You could use the same branching tool to create adventure-game-like simulations. This would be particularly useful in corporate eLearning, but it could have lots of academic applications as well.
• Polling: I see no reason not to replace polling with code from survey builder. In the long-run, this would enable more sophisticated data analysis and graphing tools that may get built into one to be usable by the other.

That's about all I can think of without spending more time playing with the module itself.