Title:	Formative Feedback Enhancements
Jira Number:	TBD
Related Jira Numbers:	BD
Component(s):	Matrix, Wizard, Portfolio
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

Formative Feedback Enhancements (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.

At Indiana University, we have found the current solution for providing formative feedback in the matrix and wizard to be of minimal value. In this proposal, we suggest increasing the utility of the feedback functionality in the matrix and wizard (and adding similar capabilities to the portfolio tool) by:
-           Adding workflow support, including notifications
-           Allowing students to initiate feedback requests to members and non-members of the portfolio site
-           Limiting cell/page access to only those individuals who have been invited (or designated by the coordinator) as authorized to provide feedback for a given student.

Rationale (1)

Explain why this feature would be valuable, and to whom. Include background information about the problem the solution is meant to solve.

Currently, the feedback function in the matrices and wizards is an all or nothing proposition. Any user with the "review" permission can view and comment on any cell/page for any participant. The only means of restricting reviewer access is via groups, but control is not sufficiently granular to support one-to-one peer/mentor/advisor feedback arrangements. Moreover, the portfolio owner may wish to solicit feedback on specific cells/pages (or an entire matrix/wizard) from an advisor, mentor, or peer who is not a member of the portfolio site. The current feedback function offers the owner no options for sharing his/her guided portfolio work with other users.

A second shortcoming of the current feedback function is the absence of workflow support and visual cues. Users with the "review" permission have no way of knowing whether and when a specific cell or page is ready for formative review. Nor is the owner alerted when new feedback is available for a cell/page.
The enhancement of the feedback function with workflow support, student-initiated invitations, and more granular access controls will be useful to:

Faculty who want to initiate peer feedback processes, but are loathe to give students unlimited access to the portfolio work of their peers
Students who want to solicit feedback on specific cells/pages from a fellow student, mentor, advisor, instructor, regardless of whether they are members of the portfolio site
Anyone engaged in facilitating, requesting, or providing feedback to students prior to formal evaluation

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.

Very few of Indiana University's portfolio users currently take advantage of OSP's feedback functionality due to the limitations described above. Yet, the ability to enable peers/instructors/mentors/advisors/etc to provide formative feedback has been identified as a high priority by our current users. The enhancements described here were first proposed by the ePort Functional Requirements Committee (FRC) at IU.

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: Student 1
Actor: Student 2 (member of the student 1's portfolio site)
Actor: Student 3 (not member of portfolio site)
Actor: Instructor 1
Actor: Advisor 1 (not member of portfolio site)
Stakeholders: students who want feedback on their work before they submit it for formal evaluation; advisors who want the ability to provide guidance to students as they pursue their academic and career goals.

User Story 1: Student Invites Feedback

Student 1 opens matrix/wizard/portfolio page one which s/he would like to receive feedback.
Student 1 clicks invite feedback
Student 1 is prompted to indicate whether feedback is for entire matrix/wizard/portfolio or just the current cell/page.
Student 1 selects Students 2 (from a list of site members) as well as Student 3 and Advisor 1 (by entering their user IDs) as invitees.
Student 1 writes an optional message to invitees to provide some context for the invitation and clicks send.
Students 2 and 3 and Advisor 1 each receive an email notification containing Student 1's custom message, and instructions with a link that takes the user directly to Student 1's cell/page/matrix/wizard/portfolio within their My Feedback Invitations (aggregated view of feedback invitations) dashboard.
Students 2 logs in, reviews Student 1's cell/page/matrix/wizard/portfolio X and fills out a feedback form, and clicks submit.
A "new feedback" icon (or other visual cue) appears in the cell/page/matrix/wizard/portfolio X.
Cell/page/matrix/wizard/portfolio X is added to Student 1's Unread Feedback dashboard.
Student 1 receives an email notification indicating that new feedback on cell/page/matrix/wizard/portfolio X is available. The message contains a direct link to cell/page/matrix/wizard/portfolio X in his Unread Feedback dashboard.
Student 1 logs in and reads the feedback from Student 2. There is an option to reply to Student 1, but he chooses not to use it. After Student 1 is finished reading, he clicks Return to Dashboard.
The feedback entry from Student 2 is marked as read and the "new feedback" icon in cell/page/matrix/wizard/portfolio X changes to a "read feedback" icon.
The process is similar for Student 3 and Advisor 1.

User Story 2: Instructor Initiates Feedback Process and Assigns Feedback Providers

Instructor 1 logs in to the portfolio site and edits the matrix/wizard in which she wishes to facilitate peer feedback.
Instructor 1 clicks on the cell/page where she wants feedback to occur.
Instructor 1 clicks Assign Feedback Providers
Instructor 1 assigns one or more individuals (who may or may not be members of the site) as feedback providers for each participant. Assignments are made on a per participant basis.
Instructor 1 writes an optional message to invitees to provide some context for the invitation and clicks send.
Each assignee receives an email notification containing Instructor 1's custom message, and instructions with a link that takes the user directly to their My Feedback Invitations (aggregated view of feedback invitations) dashboard.
Remaining steps are similar to User Story 1, steps 6-13.

Note: The instructor could also initiate this process by distributing a sheet with the feedback assignments and instructing students to invite their assigned partner(s) as described in User Story 1

User Story 3: Instructor Initiates Feedback Process - Random Assignment

Instructor 1 logs in to the portfolio site and edits the matrix/wizard in which she wishes to facilitate peer feedback.
Instructor 1 clicks on the cell/page where she wants feedback to occur.
Instructor 1 clicks Assign Feedback Providers
Instructor 1 selects Randomly Assign Participants.
Instructor 1 writes an optional message to invitees to provide some context for the invitation and clicks send.
Instructor 1 receives an email notification containing the random feedback assignments
Each assignee receives an email notification containing Instructor 1's custom message, and instructions with a link that takes the user directly to Student 1's cell/page/matrix/wizard/portfolio within their My Feedback Invitations (aggregated view of feedback invitations) dashboard.
Remaining steps are similar to User Story 1, steps 7-13.

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

Describe any functionality not fully captured in the User Stories.

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.

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.

Browser not supported