Overview
Displaying items to users has a couple of challenges. First of all the
display of a single item can be different for each item_type (and even
within a type). Second of all, the display of items within a section
can be different from assessment to assessment. Last but not least, the
whole assessment might be displayed differently depending on attributes
and the type of assessment we are talking about.
Note: please refer to the discussion of Items here.
That discussion complements the discussion here, and the data model
graphic pertaining to the Item Display Types system is available there
also.
Item Display Types
Each item has an item_display_type object associated with it, that
defines how to display the item. Each item_display_type has a couple of
attributes, that can be passed to the formbuilder for the creation of
the widget. Each widget has at least one item_display_type associated
with it. In the long run I think this system has the potential to
become a part of OpenACS itself (storing additional display information
for each acs_object), but we are not there yet :). Obviouslly we are
talking cr_item_types here as well.
Each item_display_type has a couple of attributes in common.
- item_display_type_id
- item_type_name - name like "Select box, aligned right", stored in
the name field of CR.
- presentation_type - the type of "widget" displayed when the
Item is output in html. There are many types we should support beyond
the stock html types. We are talking ACS
Templating widgets here.
- item_answer_alignment - the orientation between the
"question part" of the Item (the item_text/item_subtext) and the
"answer part" -- the native Item widget (eg the textbox) or the 1..n
choices. Alternatives accommodate L->R and R->L alphabets (or is
this handled automagically be Internationalization?) and include:
- beside_left - the "answers" are left of the "question"
- beside_right - the "answers" are right of the "question"
- below - the "answers" are below the "question"
- above - the "answers" are above the "question"
- html_display_options - field to specify other stuff like
textarea dimensions ("rows=10 cols=50" eg)
- as_item_default -
optional field that sets what the as_item will
display when first output (eg text in a textbox; eg the defaults that
ad_dateentrywidget expects: "" for "no date", "0" for "today", or else
some specific date set by the author; see
this example)
Depending on the presentation_types additional
attributes (presentation_type attributes)
come into play (are added as attributes to the CR item type) (mark:
this is not feature complete. It really is up to the coder to decide
what attributes each widget should have, down here are only
*suggestions*). Additionally we're not mentioning all HTML
possibilities associated with each type (e.g. a textarea has width and
height..).
- textbox - single-line typed entry
- abs_size - An abstraction of the real size value in
"small","medium","large". Up to the developer how this translates.
- text area - multiple-line typed entry
- abs_size - An abstraction of the real size value in
"small","medium","large". Up to the developer how this translates.
- radiobutton - single-choice multiple-option
- choice_orientation - the pattern by which 2..n Item Choices
are
laid out when displayed. Note that this isn't a purely stylistic issue
better left to the .adp templates or css; the patterns have semantic
implications that the Assessment author appropriately should control
here. Note also that Items with no Choices (eg a simple textbox Item)
has no choice_orientation, but handles the location of that textbox
relative to the Item label by the item_alignment option (discussed
below).
- horizontal - all Choices are in one line
- vertical - all Choices are in one column
- matrix_col-row - Choices are laid out in matrix, filling
first col then row
- matrix_row-col -Choices are laid out in matrix, filling
first row then col
- Button type - type of button to use
- sort_order: Numerical, alphabetic, randomized or
by order of entry (sort_order field).
- checkbox - multiple-choice multiple-option
- choice_orientation (see above)
- allow_multiple_p - Is it allow one to select multiple values ?
- sort_order: Numerical, alphabetic, randomized or
by order of entry (sort_order field).
- select - multiple-option displayed in "popup menu"
- sort_order: Numerical, alphabetic, randomized or
by order of entry (sort_order field).
- allow_multiple_p - Is
it allow one to select multiple values ?
- multiple-choice-other: Consider, for instance, a combo box
that consists of a radiobutton plus a textbox -- used for instance when
you need a check "other" and then fill in what that "other" datum is.
In effect this is a single Item but it has two different forms: a
radiobutton and a textbox.
- other_size: size of the other text field.
- other_label: label (instead of "other").
- display_type: What display type should be used for the
multiple-choice-part ?
- pop-up_date - a widget with month-day-year select elements
that resets the day element based on year and month (ie include Feb 29
during leap years -- via Javascript) and tests for valid dates
- typed_date - similar to pop-up_date but month-day-year
elements are textboxes for all-keyboard entry; needs no resetting
scripts but does need date validity check
- image_map - requires a linked image; the image map coordinates
are handled as Item Choices
- file_upload - present a File box (browse button, file_name
textbox, and submit button together) so user can upload a file
- many more
In addition, there are some potential presentation_types that actually
seem to be better modeled as a Section of separate Items:
- ranking - a set of alternatives each need to be assigned an
exclusive rank ("Indicate the order of US Presidents from bad to
worse"). Is this one Item with multiple Item Choices? Actually, not,
since each alternative has a value that must be separately stored (the
tester would want to know that the testee ranked GWB last, for
instance).
- ...
Section display
A section can be seen as a form with all the
items within this section making up the form. Depending on the type of
assessment we are talking about, the section can be displayed in
various ways.
The section display page will be made up of the following attributes:
- Name: text. Name of the section like "test view sorted"
- Number of questions per page: integer. THIS HAS TO BE CHANGED IN
THE DATAMODELL FROM PAGINATION_STYLE. How many questions shall be
displayed per page in this section. Usually the answer would be "" for
all questions on one page (default), or "1" for one question per page
(a.k.a. one question at a time), but any number is imagineable.
- ADP style: ADP to choose
from that will control the makeup of the section along with the option
to create a new one and a link to edit existing ones that Opens a page with the current layout
of
the section in an textarea to be edited. Deferred., was item_orientation,
presentation_type, and item_alignment and item_labels_as_headers_p
- Sort questions: Select (random,
manual, alphabetic, numerical)<>
- <>Back button allowed: boolean (back_button_p). Is the use
of the
back button allowed? If not, the back button should be broken on
purpose and result in an error.
- Submit Answer separately: boolean. Shall each answer be answered
separately, even if we display multiple answers? If yes, display a
"save" button next to each answer along with green "V" if the answer
has been already submitted. To finish the section, you still have to
click on the OK button at the buttom. Once the section is finished all
answers that have not been separately submitted will be treated as not
being submitted at all.
Additionally each section has certain parameters that
determine the look and feel of the section itself. Luckily it is not
necessary to have differing attributes for the sections, therefore all
these display attributes can be found with the section
and assessment specification