Child pages
  • Matrix and Wizard Defaults and Cell-level Access Control
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.

Title:

Matrix and Wizard Defaults

Jira Number:

SAK-8418

Related Jira Numbers:

TBD

Component(s):

Matrix, Wizard

Author:

Lynn Ward and John Gosney, Indiana University

Date:

19 February 2008

Demo Status and Date(s):

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


----

Part 1: Functional Description


Matrix and Wizard Defaults (1)

Summary (1)

Give an overview of the envisioned enhancement, providing enough information for a non-technical user to understand what the feature is and what it would provide. Feel free to list specific features of the enhancement, but avoid implementation details and focus on functionality.

Currently, the evaluators and forms for each matrix cell and wizard page must be set manually, even when the intent is to use the same forms and evaluators for all cells/pages. This is a labor intensive process that could be addressed by establishing defaults in matrix/wizard properties.  Once defaults are established, the author can select an override option in specific cells/page where s/he does not wish to use the default selections.  The defaults/override process should also extend to reviewers to enable more granular control over access to student work.

Rationale (1)

Eliminating repetitive tasks in the authoring process, such as assigning forms, reviewers, and evaluators to multiple cells/pages will improve the overall usability of the authoring interface and significantly reduce the time involved in creating new matrices and wizards. 

Origin (1)

Describe how the need or desire for this enhancement arose, including background information about the problem it is meant to solve. Be specific about institution(s) and people who have played a role in planning the enhancement.

This (or a similar enhancement) has been discussed informally at Indiana University elsewhere and has recently been incorporated into IU's list of requirements for June 2008 in response to requests for improved usability and efficiency of the matrix authoring environment. A similar feature request was submitted to Jira by Bill Steele in February 2007.

User Stories (1)

The User Stories should paint a picture of what it is like for a user to make use of the enhancement. The actors should be based on real users with definable tasks and goals. Include as many stories as necessary to demonstrate how the enhancement would be used by different types of users.

Actors and Stakeholders

Actor: Program Administrator (also functions as site coordinator)
Stakeholders: anyone responsible for authoring a matrix or wizard (instructors, assessment coordinators, program administrators, instructional designers, instructional technologists, etc.)

User Story 1:  Program Admin Sets Default Forms, Reviewers, and Evaluators in New Matrix/Wizard

  1. Program Administrator logs into portfolio site and selects Matrices/Wizard tool
  2. Program Admin selects Add.
  3. On the Add Matrix page (or Step 1 in Add Wizard), the Program Admin selects the default forms, reviewers,  and evaluators (by username or role) for the matrix/wizard.
  4. When the Program Administrator saves her changes to the matrix/wizard, the forms, reviewers evaluators selected in step 3 above are set for every cell/page, the "use evaluator defaults"/"override evaluator defaults" toggle on each page is set to "use evaluator defaults", and the the "use form defaults"/"override form defaults" toggle on each page is set to "use form defaults",

User Story 2:  Program Admin Sets Default Forms and Evaluators in Existing Matrix/Wizard

  1. Program Administrator logs into portfolio site and selects Matrices/Wizard tool
  2. Program Admin clicks Edit to edit an existin matrix/wizard.
  3. On the Matrix Properties page (or Step 1 in Add Wizard), the Program Admin selects and/or modifies the default forms and evaluators (by username or role) for the matrix/wizard.
  4. When the Program Admin saves her changes to the matrix/wizard, the evaluators selected in step 3 above are set for all cells/pages in which the "use evaluator defaults"/"override evaluator defaults" toggle is set to "use evaluator defaults".  In addition, the forms selected in step 3 above are set for all cells/pages in which the "use form defaults"/"override evaluator defaults" toggle is set to "use form defaults", provided no data has been entered into the previously selected forms.  In cases where a data has been submitted to a previously selected form, the form selection is unchanged.

User Story 3:  Program Admin Overrides Default Forms and Evaluators in a Cell/Page

  1. Program Administrator logs into portfolio site and selects Matrices/Wizard tool
  2. Program Admin clicks Edit to edit an existin matrix/wizard.
  3. Program Admin selects cell/page X  where she will override the default forms and evaluators.
  4. Program Admin sets the "use evaluator defaults"/"override evaluator defaults" toggle to override evaluator defaults"
  5. Program Admin sets the "use form defaults"/"override form defaults" toggle to "override form defaults"
  6. Program Admin selects the desired evaluators and forms for cell/page X.
  7. Program Admin clicks Save Changes.
  8. At some later point, Program Admin edits matrix/wizard properties and revises default forms and/or evaluators.
  9. All cells/pages inherit new evaluator defaults except cell/page X.  All cells/pages inherit new form defaults except cell/page X, and cells/pages with submitted form data.

User Story 4:  Program Admin Reverts Back to Evaluator Defaults

  1. Program Administrator logs into portfolio site and selects Matrices/Wizard tool
  2. Program Admin clicks Edit to edit an existingmatrix/wizard.
  3. Program Admin selects cell/page X  where she previously overrode default evaluators.
  4. Program Admin sets the "use evaluator defaults"/"override evaluator defaults" toggle to "use evaluator defaults".
  5. Program Admin clicks Save Changes.
  6. The evaluators in cell X are set to the defaults defined in matrix properties (or page 1 of wizard).

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

Describe any functionality not fully captured in the User Stories.

  • Access to matrix cells are now controlled by evaluator/reviewer selections.  Evaluators/reviewers may only open those celle/pages in which they have been defined as an evaluator or reviewer.

Interaction and Implications (1)

Identify and describe potential interactions with existing and planned OSP/Sakai tools and enhancements from a functional perspective.

Diagrams and Mockups (3)

Include any ERDs, flowcharts, sketches, mockups, etc.

 

 

 

1. Set devault forms, reviewers,
and evaluators in matrix properties.

2. Cell set to use defaults.  Submitted
forms cannot be changed.

3.  Revise and defaults in matrix
properties.  If a form is changed, and
the original form has been submitted in
a cell linked to the defaults, the link is broken.

Design doc/screenshot not available.

4. Cell with submitted default form AFTER
form is revised in Matrix properties.  Form is
not and can no longer be linked to defaults.

5.  Matrix cell with all defaults overriden.

6. User attempts to access a matrix cell in
which s/he is not defined as a default or
override evaluator/reviewer.

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)

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.

1 Comment

  1. The approach we've been imagining at Serensoft is a bit different from Lynn's – smaller in scale, too – but after all our perspective is a bit different, too. Lynn is looking at this from the institutional perspective where setting 'defaults' would be a boon to program administrators. We look at it from the mechanical perspective where the matrix-mechanic can save a lot of time by being able to specify one set of forms, evaluators, descriptions, instructions, rationale, and examples and then replicating (some of?) those settings throughout the row, column or entire matrix – instead of repeating the drudgery over and over again, dozens of times.

    In our scenario the implementation wouldn't involve any policy changes, just a utility method to copy selected items from the 'current' cell to a chosen set of target cells...

    USE CASE: Often a matrix has many rows (or columns) that are similar, with a small handful of rows (or columns) that deviate from the normal ones. Imagine a program-level matrix that has many columns and many rows. Many of the columns represent a particular course in the program; these might have all the same forms, the same evaluators, even some of the same instructions. Then there might be an extra column or two that address various types of extracurricular activity – and the cells in these columns might all have a certain set of evaluators and a certain set of forms, but they won't have anything in common with the course-related columns...

    We envision something like a "Set as Defaults..." button in the edit-cell dialog area adjacent to the "Save Changes" button. This would allow the matrix-mechanic to then select which of this cell's settings will be applied to 1) all cells in 'this' ROW, 2) all cells in 'this' COLUMN, or 3) all cells in the MATRIX. In the use case described above, this would allow the matrix-builder to specify one set of defaults for the whole matrix, then override it in the deviant columns (or rows) easily.

    It doesn't have the institutionally-driven approach that Lynn is proposing, it's more of a simple let's-help-out-the-matrix-mechanic approach, by replicating settings along a row, or column, or throughout. And there'd be no 'revert' action available. If a mockup would help envision this I'd be glad to supply one.

    Just our perspective... thoughts?