-
-
-Introduction
The Assessment Package unites the work and needs of various
+
Introduction
+The Assessment Package unites the work and needs of various
members of the OpenACS community for data collection functionality
within the OpenACS framework. We're using the term "Assessment"
instead of "Survey" or "Questionnaire" (or "Case Report Form" aka
CRF, the term used in clinical trials) because it is a term used by
IMS and because it connotes the more generic nature of the data
-collection system we're focusing on.
There has been considerable recent interest in expanding the
+collection system we're focusing on.
+There has been considerable recent interest in expanding the
capabilities of generic data collection packages within OpenACS.
-Identified applications include:
+Identified applications include:
+
- Educational settings. The dotLRN project has updated the
Simple-Survey package to the Survey package now in the current
distribution. A number of groups in the OpenACS community are
@@ -49,8 +50,11 @@
key to creation of new vertical-application tools like dotWRK. Such
integration would also be immensely useful for a clinical trials
management toolkit.
-
Historical Considerations (Work Done So Far)
Several OpenACS efforts form the context for any future work.
-These include:
+Historical Considerations (Work Done So Far)
+Several OpenACS efforts form the context for any future work.
+These include:
+
- Survey. This package (largely written/revised by Dave Bauer) doesn't currently have any documentation
in the documentation section of the OpenACS.org site, but it
is in any current OpenACS installation at /doc/survey/. Dave has
@@ -94,46 +98,62 @@
will need a substantial rewrite to work within the new 5.x
infrastructure.
- Simple-survey. This package remains in the OpenACS distribution
but it is now obsolete, supplanted by Survey
-
Competitive Analysis
+
+Competitive Analysis
+
The number of competing products in this area is *huge*. Starting
with the usual suspects Blackboard and WebCT you can go on to
clinical trial software like Oracle Clinical or specialised survey
systems. When writing the specifications we tried to incorporate as
many ideas as possible from the various systems we had a look at
and use that experience. A detailed analysis would be too much for
-the moment.
Functional Requirements
-An overview of the functional requirements can be found here. It is highly encouraged to be read
+the moment.
+Functional Requirements
+
+An overview of the functional requirements can be found here
+. It is highly encouraged to be read
first, as it contains the use cases along with a global overview of
the functionality contained within assessment. Additional
requirements can be found in the specific pages for the user
-interface.
Design Tradeoffs
+interface.
+Design Tradeoffs
+
The assessment system has been designed with a large flexibility
and reuse of existing functionality in mind. This might result in
larger complexity for simple uses (e.g. a plain poll system on it's
own will be more performant than running a poll through
assessment), but provides the chance to maintain one code base for
-all these seperate modules.
API
-The API will be defined during the development phase.
Data model
-The data model is described in detail in the design descriptions.
+all these seperate modules.
+API
+
+The API will be defined during the development phase.
+Data model
+
+The data model is described in detail in the design descriptions
+.
+
+
The UI for Assessment divides into a number of primary functional
-areas, with the entry page located here. It is split up into multiple
-sections:
+areas, with the entry page located here
+. It is split up into multiple
+sections:
+
-
-Assessment
+Assessment
Authoring: all the pages involved in creating, editing, and
deleting the Assessments themselves
-
-Section
+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
+Item Authoring and
Catalogue: all the pages involing the item creation and the
item catalogue.
-
-Assessment
+Assessment
Delivery: all the pages involved in deploying a given
Assessment to users for completion, processing those results, etc;
these are user pages
-
-Section on Tests:
+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
@@ -148,13 +168,21 @@
be further thought through, depending on where the Site Management
mechanisms reside.
- Triggers and Action
Execution
-
-The Page Flow page is diagrammed
+
+
+
+The Page Flow
+ page is diagrammed
below and should give a very rough and outdated overview, but still
-good for getting an impression.
Authors
+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 outside the
-OpenACS community.
-
+Kaufman
+ and Malte
+Sussdorff
+ with help from numerous people within and outside the
+OpenACS community.
+