tdaxp

I'm working on another draft of my dissertation proposal presentation (I haven't given it yet, but I keep finding ways to make it better), and I found some scales I would like to use.

However, I realized that as the questions are pretty similar, I don't want to have to manually put it nearly identical material each time. I also want to format the displayed questions prettily, to present a proper likert scale...

Today (and last night, actually) the rough draft, I guess you could call it the first beta or so, of the system works. From beginning to end, from survey items, notes, and output, it's all there. A lot of things were changed in the final stretch. Below the fold are some of them.

The notes today are scattered, but so was the accomplishment: a functional system.

Saving survey data from the notesonrails application is not just a matter of adding something new -- it also involves destroying something old. Today's work doesn't get us a completely functional system, but it migrates the system from a "notes" to a "survey response" method of saving data, and lays the groundwork for more tomorrow...

Today we repair what we broke last time.

This entry is the most boring of all, as all it does is fix errors and "features" that were introduced (intentionally or no) in the prior work. At the end, the student experiment integrates quesiton lists and notes, but doesn't actually save the results.

Today experiments (or, rather, surveys) that incorporate multiple question sheets were implemented, and the groundwork was laid to making complex experiments that have both survey and matrix items. Work stopped once an unknown error was encountered -- trapping that will be the top priority for the next note on rails.

After my last note on rails I took a long break, in order to critique two texts (of which Cognitive Development is the first), attend the Boyd Conference, and generally relax. But a month is long enough to go without work on what will now be the technological basis for the next installment of the Wary Guerrilla / Wary Student research program.

Today's work focused laid the foundations for a completely revamped experiment feature. Before, the experiment feature only dropped the user straight into a note-taking interface. Now, question lists are being integrated so that an entire battery can be given through the interface. The task is not completed today -- indeed, all that was accomplished was presenting one question list instead of the notetaknig matrix -- but it's a start

After thanking the websites of continuous thinking, hokudai, rubyinside, and rubyonrails more practical help, read below the fold for implementation details...

Not going to change the experimental code yet -- that's too big for this day of vacation, whatever I said previously.

Today we'll improve the student interface to allow questions to be ordered, question lists to be ordered, and a new "question" type (instruction) to be added.

My props to Geek Skillz and Programming Ruby's "class Hash" for coming in useful today.

After creating the QuestionList and Question controllers, the next step is to update both of them so that defaults are returned when the user edits the extended fields (which conditions the QuqestionList belongs to, and what options a Question has). Because these are stored in other tables, this information is not presented as-saved to the user, but rather the "defaults" are blank.

With the help of wiki.rubyonrails.org, the process is pretty simple...

Having created a basic question-list interface (functionally the same as MediaLab's que file), today the admin interface is expanded to have a basic question interface.

The standard static scaffold is actually inappropriate for how we'll want questions to be generated (something like the experiment controller's ajax will be require), but for now let's just get it working.

The presentaiton was a hit. The next step is to make the "take the experiment" feature less fakey, by incorporating pretests and posttests. My inspiration for how to do this comes from MediaLab, which I worked with previously.

Every Question will belong to a QuestionList. Every QuestionList can belong to any number of conditions. There will also be a model that ties QuestionLists into Conditions and one that ties QuestionOptions into Questions. The table schemes are something like :