Forum OpenACS Development: Form builder matrix widget

Collapse
Posted by Malte Sussdorff on
For the assessment system we need to support a Matrix widget that supports
multi dimensional multiple choice questions. To illustrate, here is an
example:

Please rate the following with regards to quality and importance

                    Quality         Importance
                    1 2 3 4 5       1 2 3 4 5
Food                O O O O X       O O O X O
Security            O X O O O       O O O O X
Housing             O O O O O       O O O O O

Obviously these are 6 total questions (Food(Quality), Food(Importance)
....). Not sure if we should limit ourselves to just radio buttons or allow
(multiple select) checkboxes as well. I will for the moment assume we do.

Here is my thinking on the properties of the widget:

- dimensional_definition: This is a list of items that describe the Columns
of the above displayed form. It would look like:
{{key1 "label1" {{val1 "label_val1"} {val2 "label_val2"} ...}} {key2
"label2" ...}

Taking the example above this would translate into:

{{quality "Quality" {{1 "1"} {2 "2"} ..}} {importance "Importance" {{1 "1"}
{2 "2"}...}}

- row_items: List of the items describing the rows:
{{row1 "label_row1"} {row2 "label_row2"}...}

In the example above:

{{food "Food"} {security "Security"} {housing "Housing"}}

On submit arrays will be created with the selected values like this:

row1(key1) = user_value_1 ; row1(key2) = user_value

In the example above:

food(quality) = 5 ; food(importance) = 4; security(quality) = 2; security
(importance) = 5.

The label can be HTML, to include images. Furthermore it might be easily
internationalized.

Is this useful, would you like to see amendments to the way you define the
widget, any other comments you might have ?

One possible extension would be to give the type of a key as well like this

{{quality "Quality" radio {...}} {other "Further comments" text {...}}. This
would allow to mix and define widget types to be used in the matrix. It
would be nice e.g. For user profiling like this:

{{value "Your answer" text {...}} {visible "Visible to" checkbox -multiple
{admin "Admins"} {member "Members"} {registered "Registered Users"} {public
"Public"}}
Collapse
Posted by Joel Aufrecht on
The canonical name for a rated scale (ie, bad 1 2 3 4 5 6 7 good) is a Likert scale.  A default Likert scale would probably go -3 -2 -1 0 1 2 3.  You would typically want to define the number of values (usually odd), start and end point or default to 0 as the middle, and text labels for min, max, and middle.
Collapse
Posted by Caroline Meeks on
Take a look at orkut's profile page for another possible use case:

http://www.orkut.com/EditContact.aspx

They ask for profile information then on the same line a drop down for privacy control.

Collapse
Posted by Malte Sussdorff on
The orkut's profile page is *exactly* what I had in mind when writing the last 10 lines of my posting, but I prefer the checkboxes so you are more flexible in whom to give access :).
Collapse
Posted by Stan Kaufman on
Malthe, your schema for Likert scale questions correctly separates the text label attached to an option from the option's numerical value. This will support questions whose response options are something like "Strongly disagree...Disagree...Uncertain...Agree...Strongly Agree" while behind the scenes, the user's numerical response (chosen from 1,2,3,4, or 5 -- or -2,-1,0,1, or 2) can then be transformed to a 0-100 scale.

It is common for multiple questions to be used in the calculation of a single Likert scale -- for instance a "Food Preference Scale" that combines the "Quality" and "Importance" questions in your scenario. But also, the questions that map into a single scale aren't necessarily contiguous items in an assessment. So in addition to needing a mechanism to define the "grouping" widget for the form layout, there needs to be a mechanism to define the "scoring" grouping that defines what happens to user responses en route to the database.

Alternatively, the package could simply stuff raw responses into the database and *not* handle derived/calculated values like the actual Likert 0-100 scale results. Biostatisticians prefer to do their own calculations off-line, but a system that wants to provide immediate, scored feedback for a questionnaire (eg these demos) will need to have tools to let assessment authors define the calculations inclucing which items they operate on.

Collapse
Posted by Malte Sussdorff on
I tried to name this a formbuilder matrix and not a Likert widget due to the fact that it should not only support Likert scales. Ideally, the likert scale with the attributes stated by Joel would be a special case of the formbuilder matrix and make use of it in the assessment.

If you face an issue with multiple different user values depending on each question, I'd suggest to have multiple formbuilder matrix widgets, each grouping the questions and the values. Otherwise you might be better off writing the HTML code on your own (just kidding).

Alternatively (and especially true for assessment) we should handle the different scores of a value with the testing/scoring part of the assessment or the grading module, if you are keen on immediate scale results.

To be honest, I do not forsee someone using this widget in his/her package in the way you describe, except the assessment package. Therefore I'm reluctant to add scoring values to the widget itself.

Collapse
Posted by Stan Kaufman on
Malte, how did you access the orkut profile page? It appears that the only way is by being invited by someone there. If you're already in, can you invite me so I can see this?

As to handling scoring -- I agree with you. The widget you're designing only needs to set the value (either numerical or text) that the item author wants each choice to represent. How (or if) that value gets processed beyond simply getting stuffed in the db (graded, scored, whatever) after the form is returned involves other components that aren't related to your widget. And the UIs that assessment authors will use to define that processing (grading, scoring, whatever) also involve widgets/UIs other than what you're designing now. I didn't mean to conflate the steps and confuse the issue.

Collapse
Posted by Malte Sussdorff on
Taking this to the next level. If I want to create an cr_item that uses the form builder to display itself, how would you store the additional attributes that should be passed along to the formbuilder?

For sure, there is an attribute "formbuilder_widget" which defines which widget to use (e.g. textarea or matrix). But how do I store the additional attributes, as they are different for each type of widget. I thought of using an attribute "widget_attributes_xml" that stores the additional attributes in an XML scheme.

Alternatively, and now I'm blurting things out without really double checking it works, we could use xoTCL to handle the display of things using (multiple) inheritance. Here is how I envision it, not sure as mentioned before, if it would work at all.

We create a question "How old are you?". A new as_item_type object is created. We define it should be a text input box. Immediately the widget_type attribute would be set to "text input box" and the object would inherit more attributes from the "text input box" class, which we can set at a later stage (like "size" or "show while typing"). We then define that we also want to have a validity check of type "integer_range". The object would inherit attributes from this class like "low_end" and "high_end". We might want to have multiple types of checks associated, so we inherit more attributes from other types. To get this persistent, we would store it in XML format in the DB.

When displaying, we would call specific functions for each type (e.g. a display function for the "text input box" that returns the XHTML code, based on the attributes).

My question: Is it worthwhile to continue thinking down these lines or how would you solve the problem of dynamic attributes depending on some choices made in the creation of the question. Not to mention the possibility to change the display type or certain checks of a question at a later stage (which results in a different set of attributes associated with the question, e.g. if we decide to switch to multiple choice radio box with the age ranges instead).

Again, please accept my apologies if this is utter glibberish to you.

Collapse
Posted by Stan Kaufman on
Malte,

your speculations about handling CR attributes in assessment seem right in line with a lot of other discussion about acs_attributes metadata, auto-generation of forms, moving table creation from standard DDL to pl/sql (or tcl) APIs, and pushing various CR features up the hierarchy into acs_objects.

Here are some relevant threads I found:

autogenerating tables vs using the CR's pl/sql (or tcl) api
https://openacs.org/forums/message-view?message_id=112355

acs_attributes metadata - February thread
https://openacs.org/forums/message-view?message_id=162095

CMS
https://openacs.org/forums/message-view?message_id=79731

Tom Jackson's query-writer
https://openacs.org/forums/message-view?message_id=109730
https://openacs.org/forums/message-view?message_id=79731

Re automatic form generation:
https://openacs.org/forums/message-view?message_id=81377
https://openacs.org/forums/message-view?message_id=28086

a recent TIP (approved) related to this:
https://openacs.org/forums/message-view?message_id=163736

some other miscellaneous relevant threads:
https://openacs.org/forums/message-view?message_id=124744
https://openacs.org/forums/message-view?message_id=148989
https://openacs.org/forums/message-view?message_id=33756
https://openacs.org/forums/message-view?message_id=109708

I don't at this point have any clear ideas about the best way to proceed, particularly since there are lots of OpenACS core implications in all this. I do think that we want to implement assessment in ways that work with these core developments, not against them.

By the way, shouldn't Assessment be put in /contrib/packages in CVS, not /packages/ where it is now? We've barely begun the implementation, and potentially much of it will need to be revised/redone depending on how we decide to build it on the CR -- among other basic decisions.

Collapse
Posted by Malte Sussdorff on
By the way, shouldn't Assessment be put in /contrib/packages in cvs, not /packages/ where it is now?

There was a consensus reached in the OCT that we would try to avoid using the contrib directory in the future and put things into packages with a maturity level of 0, as the assessment package is at the moment. Maybe it was not communicated or maybe I got it wrong, but that was driving the decision to move it into packages.

Collapse
Posted by Gustaf Neumann on
Hi Malte,

actually, i thought, i sent a posting  earlier,
but it does not show up here, so i try again....

Malte, you might look into an approach for storing
meta-data via xotcl in:
https://openacs.org/forums/message-view?message_id=182169
certainly, this meta-data can made persistent as well..

As a oo proponent, i certainly think that for handling
complex object structures, a system can benefit from
oo functionality, eg for providing different viewers
for different situations for different classes.

To draw the line between
the tasks of a form builder and the complex object
is not a simple task, but certainly, some meta-data
about the object structure is the way to go.

I have a longer running plan to extend standard
meta-data-facilities of the parameter command
in xotcl; if you have challenging problems, let me know.

best regards
-gustaf