Workflow & Guide

Workflow & Guide

Summary

The Sakai 3.0 Workflow tool combines the functionality of the Sakai 2.x Matrix, Wizard and Evaluation tools, in addition to new functionality to meet current needs. Guidance, in the form of static content (e.g. instructions, rational, rubrics and examples) is available at the top-level of a workflow as well as on individual pages. Workflow progressions can be optional, involve choices, or enforce a required process.  A sortable, filtered "dashboard" view is available to enable evaluators and reviewers easy access to student's content, as well as a traditional "matrix" view that allows students to better visualize their progress. Workflows will be independent of any course or site boundaries.

User Stories

  • Teacher Education Program (IU): Students are asked to upload different types of evidence into separate pages of a workflow (with no progression). The evaluators don't evaluate the evidence in the individual pages, but instead evaluate the entire workflow collection using a rubric developed by the instructor.
  • Undergraduate Research Opportunity Program (UM): Students collect structured data in a workflow (with no progression) organized into Lectures, with each page associated with an enriching activity. No implicit page progression is needed or defined. Students view the workflow in a Matrix/Horizontal visualization. Some of the structured data collected will be re-used in a portfolio presentation.
  • Adverse Event Reflective Exercise (UM): Workflow (with open progression) for medical students, with each category representing an curriculum area and each page within the curriculum area representing a unit of time (year). Administrators need to select a subset (cohort) of students and batch update the status of their workflow pages (opening up the next year of pages for those students). Students fill out structured data within each page (collect), optionally solicit or receive feedback, create a structured reflection and submit the page for evaluation.
  • Expressive Portfolio (UM): Workflow (with no progression) with a single category with several pages create a guided portfolio creation experience. Pages collect structured data for re-use in a portfolio presentation (e.g. welcome page, goals page, philosophy statement, examples of work, resume page, ...). In-place feedback of artifacts is important, as well as re-use of artifacts from other workflow collections. Ideally, this would look like a content hosting system with sample/prototype data content in each page.
  • Dental Hygiene (UM): Open workflow with each category representing a competency domain and each page with the competency domain representing a unit of time (mini-mester). Feedback per artifact is important, as well as having different progressions for different categories. The last category leverages page status and submission for evaluation. The ability to define different evaluators for different pages is important.

Functional Details

Terminology

  • Artifact: single piece of content (e.g. form, assignment, uploaded-file) or a published portfolio presentation
  • Page: collection of content (e.g. matrix cell or wizard page) that will be stored or referenced in a common directory/folder
  • Category: collection of pages (e.g. matrix row or wizard category) that will be stored in a common directory/folder
  • Workflow Collection: collection of categories (e.g. wizarrd of matrix) that will be stored in a common directory/folder
  • Progression: the rules defining how a Page Status changes from LOCKED to READY

Workflow Definition

Workflow categories can be defined with one of four progression options:

  1. None: page status and evaluator attributes will not be used at all
  2. Open: page status will not automatically change based on a defined defined progression, and it's initial status may be READY or LOCKED
  3. Sequential: each individual page will be unlocked (set to READY) when the previous page in the category is set to PENDING
  4. Custom: each individual page can be defined as a trigger for another page, so a non-linear progression can be defined that unlocks a subsequent page when a given page's status becomes PENDING. This allows for choices, such as a user can set either Page-A or Page-B to pending, in order to unlock Page-X.

Defining a workflow involves the following actions:

  • Define a category (or sub-category) and category progression (none, open, sequential, custom)
  • Define page within a category
  • Optionally duplicate page
  • Optionally duplicate category
  • Optionally delete, modify, or move page
  • Optionally delete, modify, or move category
  • Optionally "bulk" modify the status of multiple pages in one operation
  • Import/Export/Duplicate workflow definition
  • Authorize workflow usage for specified users or user groups

Each Page of a workflow has the following attributes:

  • Name
  • Owner (e.g. student): permission to read/write artifacts and submit page for evaluation (page status to PENDING)
  • Guidance artifacts: such as instructions, rubrics, examples, attachments
  • Selected artifacts: such as specific forms, structured reflections, assignments, uploaded files, external URLs, or any artifact
  • Bound artifacts: required or automatically associated artifacts (e.g. specified assignment)
  • Reviewer(s): List of users from whom feedback/review is requested
    • Review (feedback) artifact (may be implemented as part of more global review anywhere functionality)
  • Evaluator: single user with permission to read artifacts, write evaluation/feedback, re-assign to another evaluator
    • Evaluation artifact (may be implemented as part of more global review anywhere functionality)
  • Status: READY, PENDING, COMPLETE, LOCKED
  • Tag(s): Pre-defined semantic tags associated with a page (e.g. defining a learning objective or outcome) that facilitates finding artifacts with the same tag
  • Change History: changes to status, add/delete/modify artifacts, changes to structured reflection/feedback/evaluation, evaluator changes, last-modified-date, etc.

Each Category has the following attributes:

  • Name
  • Progression (e.g.none, open, sequential, custom)

Each Workflow Collection has the following attributes:

  • Name
  • Owner (e.g. student): permission to add reflection, request reviewers and submit workflow for evaluation (page status to PENDING)
  • Guidance artifacts: such as instructions, rubrics, examples, attachments
  • Selected artifacts: such as specific forms, structured reflections, assignments, uploaded files, external URLs, or any artifact
  • Reviewer(s): List of users from whom feedback/review is requested
    • Review (feedback) artifact (may be implemented as part of more global review anywhere functionality)
  • Evaluator: single user with permission to read artifacts, write evaluation/feedback, re-assign to another evaluator
    • Evaluation artifact (may be implemented as part of more global review anywhere functionality)
  • Status: READY, PENDING, COMPLETE, LOCKED
  • Change History: changes to status, changes to pages, changes to structured reflection/feedback/evaluation, evaluator changes, last-modified-date, etc.

Workflow Visualization

Once a workflow has been defined, student and evaluator users are given a choice of visualization options that can be dynamically selected and changed. Student users can view their own workflows along with feedback requests from others within the dashboard visualizations. Evaluator and administrative users can view workflows from multiple students/users within the dashboard visualizations.

  • Matrix/Horizontal: Available only for workflows defined with a consistent number of categories and page (e.g. 3x4 or 1x5) and only available to students (not evaluators of  workflow collections). Categories are represented as horizontal rows. This view is best when the number of pages can be easily displayed across the top without requiring horizontal browser scrolling.
  • Matrix/Vertical: Available only for workflows defined with a consistent number of categories and page (e.g. 3x4 or 1x5) and only available to students (not evaluators of workflow collections). Categories are represented as vertical columns. This view is best when the number of categories can be easily displayed across the top without requiring horizontal browser scrolling.
  • Dashboard: Hierarchical listing of categories and pages that allows sorting and filtering by page attributes

The Dashboard Visualizations should leverage ideas originally defined in http://confluence.sakaiproject.org/confluence/display/OSP/UMichigan+-+OSP+Dashboard.

Workflow Usage

... tbd ... 

Diagrams & Mockups

Matrix/Horizontal Student Screenshot

Dashboard Student Screenshot


 

Dashboard Instructor Screenshot


 

Implementation Details

  • Workflow views of specific pages must provide contextual clues as to where the user is within the workflow (e.g. when looking at a page, we must display where they are in the workflow, either via "breadcrumbs", or perhaps a navigation frame with the entire workflow hierarchy available).
  • Should Sakai write it's own workflow engine or leverage an existing project such as Drools?
  • Workflow Rules (within a page and/or category) should be modular and extensible.
  • Workflow presentation should be skin-able with institution-specific stylesheets
  • Need some way to selectively show/hide workflow (by date or by choice); this will show/hide workflow but workflow collection content remains available
  • Should we automate moving students from one page to the next when submitted? For example, Upon submitting page one, page two is not only open, but it is (optionally) displayed?
  • How can we include attributes such as due-dates and grades? Are the due dates for content within the page (e.g. assignment), or for the page itself? If the content has an associated due date, there's the possibility of more than one due date, and also the need for a sakai-wide due-date attribute. If the page itself is considered a type of assignment, with due dates and grading associated with it, we would have to integrate with a broader sakai assignment services.