Child pages
  • Form Data Extraction and Summary Data Presentation
Skip to end of metadata
Go to start of metadata
This page contains macros or features from a plugin which requires a valid license.

You will need to contact your administrator.


Form Data Extraction & Summary Data Presentation

Jira Number:

(TBD JIRA number as link)

Related Jira Numbers:

(TBD JIRA numbers as links)


OSP Matrix/Wizard/Common


Beth Kirschner, Noah Botimer (University of Michigan)


April 16, 2008

Demo Status and Date(s):

Status: Suggested
Date: (Date(s) enhancement demoed)

Part 1: Functional Description

Title of Enhancement (1)

Summary (1)

Viewing Summary Data

Traditionally, the Matrix provides an iconic overview of simply where items have been submitted. Hovering a mouse over an icon provides a tool-tip with the display name and the date submitted, but no further details. The view is also limited to a given user's Matrix. To provide a more practical interface across many cells, users, and submitted Forms, a summary view will need to be developed.

Exporting Data

To accommodate more complex statistics and analysis than are practical to implement within Sakai, the detail data presented on the summary view must be exportable. The data to be exported is the same as that of the summary view, except that any aggregate figures will be omitted, and the Faculty member providing Feedback or Evaluation will be included.

Rationale (1)

Any institutions interested in data mining and metrics could benefit from these features. The University of Michigan's requirements were defined by the Dental Hygiene use case described below.

Origin (1)

The University of Michigan's Dental Hygiene pilot's needs are largely compatible with the Matrix and Forms. Their core data collection and workflow are supported out of the box with very few customized forms.

However, there is a significant need for a practical summary view of Competency Reflections submitted across categories and mini-mesters. Currently, the Matrix requires a user to click into a specific cell to see the details of the submission, and on the submission to view any information captured there.

There is no summary view currently implemented, but it has many parallels with the general problem of reporting on Form data. For programmatic data and trend analysis, an export of the detail data presented in the summary view is also required. This export must be in a common format that is importable into statistical packages.

User Stories (1)

See Dental Hygiene User Stories

Functional Details (may be added after community demo) (1)

Summary Data Presentation

A Summary view must be developed to present summary data across students and matrix row/column cells. The following views are examples derived from the Dental Hygiene requirements:

  1. The view must present information from various sources:
    • Sakai's User Directory Service
    • Structural metadata of a Matrix
    • Structural metadata from the schema of a Form
    • Instance data from Forms collected in Matrix cells
    • Multiple users' Matrix submissions, simultaneously
  2. The view must support multiple grouping orders:
    • Student, Row, Column
    • Row, Student, Column
    • Column, Student, Row
    • Column, Row, Student
  3. The view must present aggregate computations

The following implementation options will be explored for feasibility

A. Implementation Option: XSLT or RSF
Rendering dynamic views based on files within Resources provides the ability to develop and evolve views without builds or restarts. The two leading candidate approaches are:

  • XSL Transformations based on an XML version of the detail data
  • RSF View Producers and Templates based on Object representation

The XSLT solution is attractive because there is already relatively extensive use of XSLT within Metaobj and the Portfolios Tool. It would require that the detail data be delivered as an XML document. There may be significant difficulty in providing the different grouping orders depending on the design of the XML.

The RSF solution is attractive because the HTML in the templates is not adorned with logic and remains previewable. The delivery of data to the templates and grouping logic is performed with native objects in a familiar programming language, Java or Python. Embedding BeanShell or Jython, respectively, would support the dynamic producers. The view would likely be developed as a helper to avoid introducing RSF dependencies into the Matrix Tool.

B. Implementation Option: Integration of a Reporting Tool
The most sophisticated strategy would be to outsource the reporting logic and presentation to an external reporting tool such as Eclipse BIRT or Pentaho Reports. There are significant advantages to this approach, including the availability of report designers that implement grouping and aggregates. The reporting engines also target multiple output formats (HTML, XML, XLS) from a single report design. However, the runtime engine would have to be integrated and deployed within the build. There may also be significant effort in passing parameters to a report.

Form Data Extraction

Data must be extracted from multiple types of forms and made available for presentation and export. Exported data format may be XLS (see Apache POI library) or XML (which can be transformed into MS Excel importable data).

  1. Submissions of Reflection, Feedback, and Evaluation Forms across students and cells must be accessible in a single dataset
  2. Performance of the data extraction must be adequate to provide the dataset for a complete cohort in less than 10 seconds. (e.g. 10 students X 11 columns X 5 rowss X 1 Reflection/cell avg X 2 to consider Reflection and Feedback = 1,100 forms per cohort)

Interaction and Implications (1)

  • It must be required that this additional functionality is an option and not required, to address ease of implementation issues for institutions who may not need.

Diagrams and Mockups (3)

(Select image to view)
This mockup displays a sample Dental Hygiene Matrix. Rows represent competencies and Columnis represent MiniMesters.

(Select image to view)
This mockup describes one possible summary screen leveraging data from:

  • User Information from Sakai
  • Configurable, localized text
  • Derived data from forms

(Select image to view)
This mockup shows a version of the above screen, using a sorting grid.

Community Acceptance (4)

Indicate how this feature has been discussed by the larger community (e.g., list discussion, specific meetings, etc.). Provide specific records of community acceptance (e.g., list institutions and contacts who also identify this feature as a requirement).

Part 2 of the Proposal for Enhancement Template: The Specification
The specification should be filled out once the feature is clearly defined.

Specification Template (5)


Describe each specific behavior of the feature in the present tense as if the feature were implemented perfectly. Use precise, objective language to describe ideal behaviors against which actual behaviors can be evaluated.

In the case of conditions and behaviors that must be evaluated independently, they should be presented in a two-column table as below.



(Short description of mutually exclusive condition #1)

(Objective, verifiable behavior in response to condition #1)

(Short description of mutually exclusive condition #2)

(Objective, verifiable behavior in response to condition #2)

When there are workflow behaviors (steps) that must be evaluated in sequence, they should be identified with prerequisite conditions, behavior, and post-behavior conditions as below.

Workflow Steps

(Unique, short, representative name of the step)

Prerequisite Conditions or Step:

(Conditions or Step name)


(Objective, verifiable behavior)

Post-step Conditions or Next Step:

(Conditions or Step name)


List any entities or actors that are used or affected by this feature. Each should link to an entry in the OSP Terminology page.

Quality Metrics

Describe any non-functional requirements of the feature, such as usability, performance, or design. Provide objective and, where possible, quantitative measures against which actual implementations can be evaluated.


Provide any assumptions about implementation path, availability of other required features, schedule concerns or otherwise.

Outstanding Issues

The Outstanding Issues section is a placeholder for the evolution of this specific feature. It should mention any explicit design or implementation decisions that are pending. There must be no outstanding decisions as of the confirmation of the feature as a requirement.

  • No labels