Title:	Indiana University Matrices Enhancements
Jira Number:	http://bugs.sakaiproject.org/jira/browse/SAK-15710
Related Jira Numbers:	(JIRA numbers as links)
Component(s):	Matrices, Assignments, Evaluations, Wizards
Author:	Lynn Ward, Indiana University
Date:	April 3, 2009
Demo Status and Date(s):	Status: Pending Demo Dates: October 13, 2008 and March 23 and 30, 2009
Sakai 2.6 Test Instance with IU Enhancements	http://qa2-osp.sakaiproject.org:8085/portal Note: if you encounter bugs that are specific to this test instance,please add them as a subtask under SAK-15710 and set "Affects Version" to branch.

Part 1: Functional Description

Indiana University Matrices Enhancements (1)

Summary (1)

In Fall 2007, Indiana University forked the OSP code in order to rapidly develop additional capabilities needed for assessment activities on the IUPUI campus. These changes, which primarily affect the Matrices tool have been shared with the OSP community in a variety of ways, including presentations at Sakai conferences, as well as discussion and presentations during weekly calls. Most recently, the changes were summarized in the attached document for review by the community.

We are seeking community feedback and acceptance with the goal of merging these enhancements to trunk for use by the community in the Sakai 2.7 release. With a few exceptions (most notably, the new permissions structure), most of these changes can be toggled on and off via Sakai properties. The merged code would include all the functionality currently available in 2.6 plus the IU enhancements.

Rationale (2)

The following is a brief description of each enhancement, the rationale behind it, and page number references in the attached document. Some of these changes also affect the Wizards tool and the last column is used to indicate this.

Enhancement Description	Rationale	Page Numbers	Also Affects Wizards
Modified Matrices permissions and access control.	Original Sakai permissions did not provide sufficient flexibility or granularity for our users.	pp 5-9
Add two new guidance fields, Rubric and Expectations.	These terms are heavily used in the context of assessment portfolios on our campus. Like the other OSP guidance fields, they are optional and do not display if left empty.	pp 9-10
Added one-click show/hide behavior to matrix/wizard guidance.	The previous collapse/expand behavior for guidance required multiple clicks to hide the guidance. Our users either want to see it all, or get it out of the way when they are focused on completing forms or attaching artifacts	p 10
Added ability to link assignments, matrix cells, and/or wizard pages in any Sakai site to one or more cells in one or more matrices in the same or different sites. When student submits the assignment, the assignment is visible in the relevant cells of the student's matrix.	This functionality (which was inspired by Goal Management) was needed to lower the bar for faculty and student participation in program and institutional assessment efforts. Now faculty can help students add work to a matrix without leaving their course site.	pp 10-17
Changed three widget labels in evidence area of Matrix cell.	We eliminated the word "evidence" because it is both loaded and jargony. Also, changed the label for the submit button because the original label (Submit cell for evaluation confirmation) was too long and never made sense)	p 18
Made several changes to the handling of participant forms, but we are reverting back to the Sakai approach in the merged code.	n/a	p 19-20
Participant file attachments use the attachments helper instead of linking to files in Resources	The linking method resulted in locked files in Resources that could never be changed, preventing the user from organizing or reorganizing personal files.	p 21
Add a "request feedback button" to matrix cells and email notifications for reviewers and evaluators.	Reviewers had no way of knowing which users and cells were ready for feedback. Similarly, evaluators had to open the evaluations tool to learn about pending evaluations.		(for evaluator notifications only)
Added a flag to enable participants select their own reviewers.	Needed more flexible support for peer review.	p 3
New evaluation and feedback notifications for participants.	Previously, participants had to log in and heck matrix to find out whether feedback or evaluations had been added.	p 23
Added the ability to select default settings for forms, reviewers, and evaluators within Matrix Properties. Default settings can be overridden in cell.	Reduces labor required to set up new matrices.	p 25-27
Added a new workflow status (Returned) for Matrices and Wizards.	Users could not visually differentiate between cells that had been reviewed by evaluators and those that had never been submitted. Now, when an evaluator wants a participant to make changed to a cell, the status is set to Returned rather than Ready.	p 28
Removed the ability to edit a matrix from the Aggregated matrices tool.	Original version took too long to load for users who are members of multiple portfolio sites	p 29

Diagrams and Mockups (3)

The attached PDF highlights the differences between the IU Branch or the portfolio tools, currently running under Sakai 2.5x and generic Sakai 2.6.

Community Acceptance (4)

These changes were presented to the community during Monday calls on October 13, 2008 and March 23 and 30, 2009. In addition, IU delivered presentations about them at the Paris and Blacksburg Virginia Sakai conferences. Community response has been enthusiastic and several insititutions and organizations have inquired about the availability of the code.

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)

Behavior

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.

Conditions	Behavior
(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)
Behavior:	(Objective, verifiable behavior)
Post-step Conditions or Next Step:	(Conditions or Step name)

Interaction

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.

Assumptions

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.