Overview
Displaying items to users has a couple of
challanges. 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 additonal
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 heigth..).
- 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 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 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).
- ...
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 (aka 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
thatOpens 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 seperately: boolean. Shall each answer be
answered seperately, 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 seperatly
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