Forum OpenACS Q&A: survey builder module

Collapse
Posted by David Kuczek on
I just read through an email from Michael Feldstein concerning ACES
and he mentioned the "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...

Collapse
Posted by Michael Feldstein on
I don't know what, if anything, happened with AD's efforts to port
Survey Builder to 4.x, but I do know that the module is under
active development on 3.4 at UCLA.

The code is available here:

http://neo.crump.ucla.edu:8007/download/

The person to contact at UCLA about it is Robert "Buddy" Dennis.
His email is mailto:RDennis@mednet.ucla.edu. I haven't had time to
reach out to him myself, so it would be great if somebody in the
community contacted him to find out what their progress has
been. At the very least we should be able to get up-to-date code
to port from 3.4, and at best perhaps UCLA would be interested
in participating in a port to .LRN.

Collapse
Posted by Michael Feldstein on
I just got an email from Buddy Dennis in response to David's
email to him. He is interested in participating in an OpenACS
port. (Welcome, Buddy et al!)

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.

Collapse
Posted by Malte Sussdorff on
Well, I checked out the survey builder module from AD CVS, played around with it, found it too difficult to use for our client and implemented branching for the simple survey 😉. Its not ready to be released [user dokumentation missing...] (and anyway only working within ACES aka. 3.4.5 and higher), but if someone is interested (e.g. because he wants to port survsimp to OACS4) I'll gladly share our code.
Collapse
Posted by Matthew Burke on
Basically the porting effort for the survey module got squashed when the powers that be decided on "no more Tcl development."  Sebastian Skracic (sp?) made a pretty good start on the port and I carried it forward some but after I was let go by aD, I'm sure nobody else picked it up.  There should be the code that Sebastian and I were working on available somewhere but I don't have a clue whom to ask about it.
Collapse
Posted by Michael Feldstein on
From what little I have seen of the survey builder module (which
was based on code that is months and months old by now), it
has the same basic problem as CMS, only not nearly as bad:
Great functionality in a confusing UI. It's possible that the folks at
UCLA have made changes since I last saw it; I don't know.
Regardless, it looks worth porting to me.
Collapse
Posted by Buddy Dennis on
Hello everyone, The primary authors of the Survey Builder module are Avni Khatri, Khy Huang , and myself. We have continued to build systems that rely on Survey Builder, but we haven't ported to OpenACS4.0, yet. We have recently developed a couple of sites (ACS3.4.10) that required new functionality from Survey Builder , and now that those development projects are pretty much under control, we will begin to port to OpenACS4.0.

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?
Here are some of the recent additions to the survey bulder:
  • 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.
Collapse
Posted by Don Baccus on
<blockquote><pre> 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.
</pre><blockquote>
Take a good look at the 4x templating and portal facilities before concluding that you need to provide something like this.
<p>When you're ready to start porting to OpenACS 4, let me know if you
want to use our CVS tree and SDM installation to maintain source and gather bugs.  I'd like to gather OACS 4 projects in one place as much as possible, I think all will benefit if users have a single place to go to report bugs and request features, etc.
Collapse
Posted by Michael Feldstein on

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.