Here is a graphical overview of the subsystem in the Assessment
+package that organizes Items into Sections and whole
+Assessments:
+
Review of Specific Entities
-
+
- Assessments (as_assessments) are the highest-level container in
+the hierarchical structure. They define the key by which all other
+entities are assembled into meaningful order during display,
+processing, retrieval and display of Assessment information.
+
The primary key assessment_id is a revision_id inherited from +cr_revisions. Note, the CR provides two main types of entities -- +cr_items and cr_revisions. The latter are where sequential versions +of the former go, while cr_items is where the "current" version of +an entity can be stored, where unchanging elements of an entity are +kept, or where data can be cached. This is particularly useful if +the system needs a single "live" version, but it isn't appropriate +in situations where all versions potentially are equally-important +siblings. In the case of the Assessment package, it seems likely +that in some applications, users would indeed want to designate a +single "live" version, while in many others, they +wouldn't.
Attributes of Assessments will include those previously included +in Surveys plus some others:
-
+
- assessment_id
- cr:name - a curt name appropriate for urls
+ - cr:title - a formal title to use in page layouts etc
- creator_id - Who is the "main" author and creator of this +assessment
- cr:description - text that can appear in introductory web +pages
- instructions - text that explains any specific steps the +subject needs to follow
- mode - whether this is a standalone assessment (like current +surveys), or if it provides an "assessment service" to another +OpenACS app, or a "web service" via SOAP etc
- editable_p - whether the response to the assessment is editable +once an item has been responded to by the user.
- anonymous_p - This +shows whether the creator of the accessment will have the +possibility to see the personal details of the respondee or not. In +particular this will exclude the user_id from the CSV files. It +shall still be possible to see the user that have not finished the +survey though.
- secure_access_p - The +assessment can only be taken if a secure connection (https) is +used.
- reuse_responses_p - If +yes, the system will look for previous responses to the the +questions and prefill the last answer the respondee has given in +the assessment form of the respondee
- show_item_name_p - If +yes, the respondee will see the name of the item in addition to the +item itself when taking the survey.
- entry_page - The customizable entry page that will be displayed +before the first response.
- exit_page - Customizable exit / thank you page that will be +displayed once the assessment has been responded.
- consent_page -
+ - return_url - URL the respondee will be redirected to after +finishing the assessment. Should be redirected directly if no Thank +you page is there. Otherwise the return_url should be set in the +thank you page context, so we can have a "continue" URL.
- start_time - At what time shall the assessment become available +to the users (remark: It will only become available to the users +who have at least the "respond" priviledge.
- end_time - At what time the assessment becomes unavailable. +This is a hard date, any response given after this time will be +discarded.
- number_tries - Number of times a respondee can answer the +assessment
- wait_between_tries - Number of minutes a respondee has to wait +before he can retake the assessment.
- time_for_response - How many minutes has the respondee to +finish the assessment (taken from the start_time in +as_sessions).
- show_feedback - Which feedback_text stored with the item_type +shall be displayed to the respondee (All, none, correct, +incorrect). Correct and Incorrect will only show the feedback_text +if the response was correct or incorrect.
- section_navigation - How shall the navigation
+happen
+ -
+
- default path - Order given by the relationship between
+assessment and section (the order value in cr_rels, if this is
+used).
+ - randomized - Sections will be displayed +randomly
- rule-based branching - Sections will be displayed according +to inter-item-checks. This should be +default. +
+- default path - Order given by the relationship between
+assessment and section (the order value in cr_rels, if this is
+used).
+ - Style Options (as_assessment_styles): Each assessment has a +special style associated with it. As styles can be reused (e.g. +within a department) they are covered in the +as_assessment_styles: +
-
+
-
+
-
+
- custom_header - Custom header (and footer) that will be
+displayed the the respondee when answering an assessment.
+Possibility to include system variables (e.g. first name).
+ - custom_footer
+ - form_template - Style (form_template) that will be used for
+this assesment. You can either select an existing one or upload a
+new style as well as edit the currently choosen one (no datamodell
+but UI thought).
+ - +progress_bar: What kind +of progress bar shall be displayed to the respondee while taking +the assessment(no progress bar, different styles). +
-
+presentation_style:
+These options allow the respondee to select between different
+presentation styles. At least one of the checkboxes mentioned below
+has to be selected.
-
+
- All questions at once
- One question per page. If you have +selected respondee may not edit their reponses, it will not be +possible for them to go back and choose another answer to that +question.
- Sectioned +
- <></> +
Permissions / Scope: Control of reuse previously was through a +shareable_p boolean. As with Items and Sections, we instead will +use the acs permission system:
-
+
- Read: An assessment author (who is granted this permission) can +reuse this assessment (NB: Usually the original author has admin +priviledges.)
- Write: Author can reuse and change this assessment.
- Admin: Author can reuse, change and give permission on this +assessment
- Respond: The user can respond to the survey.
+
+
- custom_header - Custom header (and footer) that will be
+displayed the the respondee when answering an assessment.
+Possibility to include system variables (e.g. first name).
- Sections (as_sections) represent logically-grouped set of Items +that always need to be present or absent together in the +Assessment. Sections thus divide at logical branch points. These +branch points are configured during Assessment creation to +determine movement among Sections based on one of various +mechanisms: pre-set criteria specified by the Assessment author, or +criteria based on user-submitted data up to the point of branching. +Note that Items within a single Section may be presented one-by-one +in different pages; pagination is thus related but not equivalent +to Section definitions and in fact is an attribute of a Section. +Well, more accurately, of a Section Display Type (see below). +Attributes of Sections themselves include
- e:
+
-
+
- section_id
- section_display_type_id - references +as_section_display_types
- name - used for page display
- definition - text used for identification and selection in +admin pages, not for end-user pages
- instructions - text displayed on user pages
- enabled_p - good to go?
- required_p - probably not as useful as per-Item required_p but +maybe worth having here; what should it mean, though? All Items in +a required section need to be required? At least one? Maybe this +isn't really useful.
- content_value - references cr_revisions: for an image, audio +file or video file
- numeric_value - optional "number of points" for section
- feedback_text - optional preset text to show user
- max_time_to_complete - optional max number of seconds to +perform Section +
Permissions / Scope: Control of reuse previously was through a +shareable_p boolean. As with Items and Assessments, we instead will +use the acs permission system:
-
+
- Read: A section author (who is granted this permission) can +reuse this section (NB: Usually the original author has admin +priviledges.)
- Write: Author can reuse and change this section.
- Admin: Author can reuse, change and give permission on this +section +
- Section Display Types (as_section_display_types) define types
+of display for an groups of Items. Examples are a "compound
+question" such as "What is your height" where the response needs to
+include a textbox for "feet" and one for "inches". Other examples
+are "grids" of radiobutton multiple-choice Items in which each row
+is another Item and each column is a shared radiobutton, with the
+labels for the radiobutton options only displayed at the top of the
+grid (see the SAQ for
+an illustration of this).
+
This entity is directly analogous in purpose and design to +as_item_display_types.
-
+
- section_display_type_id
- section_type_name - name like "Vertical Column" or "Depth-first +Grid" or "Combo Box"
- pagination_style - all-items; one-item-per-page; variable (get +item groups from mapping table)
- branched_p - whether this Section defines a branch point (so +that the navigation procs should look for the next step) or whether +this Section simply transitions to the next Section in the +sort_order (it may be better not to use this denormalization and +instead always look into the Sequencing mechanism for navigation -- +we're still fuzzy on this)
- item_orientation - the pattern by which 2..n Items 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.
+
-
+
- horizontal - all Items are in one line
- vertical - all Items are in one column
- matrix_col-row - Items are laid out in matrix, filling first +col then row
- matrix_row-col -Items are laid out in matrix, filling first row +then col +
- item_labels_as headers_p - whether to display labels of the +Items; if not, a "grid of radiobuttons" gets displayed. See +discussion of Items and Item Choices +here. There are contexts where a Section of Items all share the +same Choices and should be laid out with the Items' item_subtexts +as row headers and the radiobuttons (or checkboxes) only -- without +their labels -- displayed in a grid (see +this example).
- presentation_type - may actually be superfluous...gotta think
+more about this, but there's at least one example:
+
-
+
- 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).
- what others? +
- item_alignment - the orientation between the "section
+description part" of the Section (if any) and the group of Items.
+Alternatives accommodate L->R and R->L alphabets (or is this
+handled automagically be Internationalization?) and include:
+
-
+
- beside_left - the Items are left of the "heading"
- beside_right - the Items are right of the "heading"
- below - the Items are below the "heading"
- above - the Items are above the "heading" +
- display_options - field to specify other stuff like the grid +dimensions ("rows=10 cols=50" eg) +
- Item Section map (as_item_section_map) defines 1..n Items to a
+Section, caches display code, and contains optional overrides for
+Section and Item attributes:
+
-
+
- item_id
- section_id
- enabled_p
- required_p - whether Item must be answered
- item_default
- content_value - references CR
- numeric_value - where optionally the "points" for the Item can +be stored
- feedback_text
- max_time_to_complete
- adp_chunk - display code
- sort_order +
- Section Assessment Map (as_assessment_section_map) basically is
+a standard map, though we can override a few Section attributes
+here if desired:
+
-
+
- assessment_id
- section_id
- feedback_text
- max_time_to_complete
- sort_order +
+