+far
@@ -138,13 +139,15 @@
+
-
@@ -38,73 +35,138 @@ 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. However, a given revision -can be chosen many easy ways other than looking at cr_items, while -being forced to create and maintain appropriate state in cr_items when -an application doesn't want it would be a major complication. Thus, -using the cr_revisions part of the CR alone seems to be the most useful -approach here. This decision pertains to all entities using the CR, but -it is particularly important with Assessments since they are the key to -all the rest of the entity hierarchies. - +version, while in many others, they wouldn't.
Attributes of Assessments will include those previously included -in Surveys plus some others: -
- +in Surveys plus some others:-
-
- assessment_id +
- assessment_id +
- cr:name - a curt name appropriate for urls
- - name - a formal title to use in page layouts etc - -
- short_name - a curt name appropriate for urls - -
- author - -
- definition - text that can appear in introductory web pages - +
- 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 - -
- scaled_p - whether some kind of scoring algorithm is defined -(ie "grading" or other schemes) - -
- mode - whether this is a standalone assessment (like current +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 +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 -
- - validated_p - whether this is a formal "instrument" like an -eponymous test (eg "Seattle Angina Questionnaire" or "MMPI" etc; this -means that alterations to this Assessment are not allowed since changes -would invalidate the Assessment - -
- enabled_p - released for actual use? - -
- editable_p - can anyone alter it further? - -
- template - references as_templates - ?not entirely clear -how/why we want to use this - +
- 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. +
-
+
-Permissions / Scope: Control of reuse previously was through a
+
+
-
+
- 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 +
+ <>
+ - Read: An assessment author (who is granted this permission)
+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 - -
-
-
+priviledges.)
-
+
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: -
--
-
+
-
-
- section_id - +
- section_id
- section_display_type_id - references -as_section_display_types - -
- name - used for page display - +as_section_display_types
-Permissions / Scope: Control of reuse previously was through a +
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: -
+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. - +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
-
+
This entity is directly analogous in purpose and design to -as_item_display_types. -
- +as_item_display_types.-
-
- section_display_type_id - +
- section_display_type_id
- section_type_name - name like "Vertical Column" or -"Depth-first Grid" or "Combo Box" - +"Depth-first Grid" or "Combo Box"
-
-
- horizontal - all Items are in one line - -
- vertical - all Items are in one column - +
- 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 - +first col then row
-
+
- 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? - +instance).
-
+
-
-
- 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" - +
- 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"
-
+
-
- +
-
-
- item_id - -
- section_id - -
- enabled_p - -
- required_p - whether Item must be answered - -
- item_default - -
- content_value - references CR - +
- 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 - +can be stored
-
+
-
-
- assessment_id - -
- section_id - -
- feedback_text - -
- max_time_to_complete - -
- sort_order - +
- assessment_id +
- section_id +
- feedback_text +
- max_time_to_complete +
- sort_order
- Conditional branching within a survey (though how well -worked out this is remains unclear) - -
- "Folder" based repositories of questions and sections - +worked out this is remains unclear) +
- "Folder" based repositories of questions and sections
-However, Surveys has some important limitations: -
+However, Surveys has some important limitations:
- Surveys are "published" as static HTML files which are -served out to users when they complete the survey - -
- The package doesn't use a templating system - -
- Oracle-only - +served out to users when they complete the survey +
- The package doesn't use a templating system +
- Oracle-only
Still, this package adopts some naming conventions consistent with the IMS spec and definitely represents the closest effort to a "complex -survey" done to date. -
+survey" done to date.-
+
Data modell
The data modell is described in detail in the design descriptions.-
User Interface
+User Interface
The UI for Assessment divides into a number of primary functional -areas, as diagrammed below. These include: +areas, with the entry page located here. +It is split up into multiple sections:-
-
- the "Home" area (for lack of a better term). These are the main -index pages for the user and admin sections -
- Assessment Authoring: all the pages involved in creating, -editing, and deleting the Assessments themselves; these are all admin -pages -
- Assessment Delivery: all the pages involved in +
- Assessment +Authoring: all the pages involved in creating, +editing, and deleting the Assessments themselves +
- Section Authoring: +all the pages involved in creating, +editing, and deleting the Sections themselves. Includes the page to +browse for items to include in sections +
- Item Authoring and +Catalogue: all the pages involing the item creation and the item +catalogue. +
- Assessment Delivery: +all the pages involved in deploying a given Assessment to users for completion, processing those results, etc; these are user pages -
- Assessment Review: all the pages involved in select +
- Section on Tests: +Currently still split away, some notes on additional user interface for +test. Shall be integrated with the rest of the pages. +
- Assessment Review: all the pages involved in select data extracts and displaying them in whatever formats indicated; this includes "grading" of an Assessment -- a special case of data review; these are admin pages, though there also needs to be some access to @@ -215,15 +215,13 @@ other "policies" of an Assessment. This area needs to interact with the next one in some fashion, though exactly how this occurs needs to be further thought through, depending on where the Site Management -mechanisms reside. -
- Site Management: pages involved in setting up who -does Assessments. These are admin pages and actually fall outside the -Assessment package per se. How dotLRN wants to interact with Assessment -is probably going to be different from how a Clinical Trials Management -CTM system would. But we include this in our diagram as a placeholder. +mechanisms reside.
+
+The Page Flow +page is diagrammed below and should give a very rough and outdated +overview, but still good for getting an impression.
+
Authors
The specifications for the assessment system have been written by Stan Kaufman and Malte Sussdorff with help from numerous people within and Index: openacs-4/packages/assessment/www/doc/page_flow.html =================================================================== RCS file: /usr/local/cvsroot/openacs-4/packages/assessment/www/doc/page_flow.html,v diff -u -N -r1.1 -r1.2 --- openacs-4/packages/assessment/www/doc/page_flow.html 13 Jun 2004 23:20:44 -0000 1.1 +++ openacs-4/packages/assessment/www/doc/page_flow.html 29 Jul 2004 09:35:11 -0000 1.2 @@ -14,15 +14,12 @@ package will use these OpenACS standards:-
-
- "trail of breadcrumb" navigational links - +
- "trail of breadcrumb" navigational links
- context-aware (via user identity => permissions) menu options (whether those "menus" are literally menus or some other -interface widget like toolbars) - +interface widget like toolbars)
- in-place, within-form user feedback (eg error messages about a -form field directly next to that field, not in an "error page") - +form field directly next to that field, not in an "error page")
Furthermore, the set of necessary pages for Assessment are not all that dissimilar to the set required by any other OpenACS package. We @@ -46,44 +43,59 @@
- the "Home" area (for lack of a better term). These are the main -index pages for the user and admin sections - -
- Assessment Authoring: all the pages involved in creating, +index pages for the user and admin sections +
- Assessment +Authoring: all the pages involved in creating, editing, and deleting the Assessments themselves; these are all admin -pages - +pages
- Assessment Delivery: all the pages involved in deploying a given Assessment to users for completion, processing those -results, etc; these are user pages - +results, etc; these are user pages
- Assessment Review: all the pages involved in select data extracts and displaying them in whatever formats indicated; this includes "grading" of an Assessment -- a special case of data review; these are admin pages, though there also needs to be some access to data displays for general users as well (eg for anonymous surveys etc). Also, this is where mechanisms that return information to "client" -packages that embed an Assessment would run. - +packages that embed an Assessment would run.
- Session Management: pages that set up the timing and other "policies" of an Assessment. This area needs to interact with the next one in some fashion, though exactly how this occurs needs to be further thought through, depending on where the Site Management -mechanisms reside. - +mechanisms reside.
- Site Management: pages involved in setting up who does Assessments. These are admin pages and actually fall outside the Assessment package per se. How dotLRN wants to interact with Assessment is probably going to be different from how a Clinical Trials Management -CTM system would. But we include this in our diagram as a placeholder. - +CTM system would. But we include this in our diagram as a placeholder.
-So this is how we currently anticipate this would all interrelate:
+In addition to the page flow we have two types of portlets for .LRN:+
-
+
- Portlet for the respondee with all assessments that have to be +answered and their deadlines. +
- Portlet for staff with all assessments that have to be reviewed +with review deadline and number of responses still to look at. +
+ +
-
+
- Possibility to browse assessments and +sections by category. +
+
+
+
+
+So this is how we currently anticipate this would all +interrelate:
-