Proposal 2007

What is Conditional Release?

Conditional Release (CR) is a subset of the larger concept of workflow. Workflow in broad-strokes can be defined within two contexts of use: 1) document control workflow, and 2) pedagogical model workflow. Document control workflow refers to defining and sequencing a process of creating, editing, review, approving, publishing, managing, archiving, and related document task workflow, incorporating subsequent concepts of sharing, version control, and access control. Related, but very different in goal, is the pedagogical model workflow, which refers to defining and sequencing a process of guiding a learner through learning objectives. In this model, an instructor defines a process where conditional release is a core part of the workflow: directing the learner through resources and activities based on demonstrated understanding.

The Problem

The current Resources tool applies a layer of access control to content based on date. In the interface this is termed "Availability," and it allows instructors to hide and reveal content at certain predetermined dates and times. This kind of access control allows very rudimentary CR, but is not sufficient to meet the goal of the pedagogical model. A learning resource that is released to a learner only on the basis of predetermined date might be able to tie release of subsequent curriculum to the date of an exam, for instance, but does not factor in the true pedagogical model (did the learner actually take the exam, if so, how did she score, what areas need prescriptive learning, etc.). The layer of access control must be expanded to allow for hiding and revealing of content, resources, and activities based on learning process; demonstrating understanding or completing an activity, for example. See #User Scenarios and Use Cases for more detail.

Motivations

The chief motivation behind CR is to provide the primary functionality to support pedagogical workflow in Sakai. This in turn will hopefully spark further thought, design, implementation, and improvement of pedagogical workflow and holistic CLE workflow in Sakai. The CR feature need is immediate for Georgia Tech, but it is still merely an early step toward a larger goal: more sophisticated flows between content, learning activities, etc. In a word, a CLE workflow engine. The CR work should pave the way toward this future.

User Scenarios and Use Cases

The primary persona is Sarah Windsor, faculty.

Sarah's Goals:

• Build on course materials from term to term
• Not to have to ask for help
• To spend as little time as possible doing administrative work; she'll delegate to her TA's when she has them
• To get tenure (get credit for tenure for everything she does)
• Use technology to help create an engaging and interactive environment for her on-line students where she can track their progress
• To be respected by students, colleagues and dean of school

If conditional release is to accomplish Sarah's goals, it will need to:

• Provide for re-use and expansion of pedagogical workflow from one semester to another, to ensure that Sarah will not have to re-do the workflow for each class every semester; ideally some form of "clone" is available to allow Sarah to easily replicate an existing conditional release flow or use it as a starting point for a new flow
• Ensure that the use and interface for conditional release is highly intuitive, matches her real-world expectations, and mirrors similar interaction she is used to in other Web/software contexts so that she can successfully use the functionality and does not have to phone IT support to ask for help
• Provide the ability for Sarah to grant her TA's access and permission to make changes to the conditional release flows for Sarah's courses
• Provide needed functionality for Sarah to implement pedagogical workflow such that her students learn better, her online students can participate; all ultimately contributing to Sarah's reputation as an instructor and tenure credit with the institution

Scenarios

Sarah wants to limit the availability of section two of her curriculum until students have demonstrated the desired level of understanding of section one.

Sarah has created review material for a section of her curriculum. Sarah wants to have the review material become available a week prior to the exam.

Sarah has created remedial material for a section one of her curriculum, and wants the remedial material made available to students who do not demonstrate the desired level of understanding of section one.

Sarah wants to create an online discussion session around one of her assignments, but she wants to limit access to the discussion to students who have completed the assignment.

Sarah wants to limit access to assignment two until students have completed assignment one and participated in a discussion of assignment one.

Design Ideas

The Conditional Release (CR) work comes out of a desire for a more general facility for triggering access to new content. "General" in two senses, then:

• That the conditions of release might be defined rather arbitrarily to facilitate desired workflow, and any Sakai tool could participate by registering itself appropriately
• That the release results might be defined rather arbitrarily to facilitate desired workflow, allowing individual Sakai tools to decide what available consequences might be, register those appropriately

The problem space is thus largely outside the scope of any particular tool, and calls for a shared service approach - a service which has the responsibility for moderating this communication across tools concerning rule application, etc.

A First Approach

One approach to the problem and its larger context would be to implement CR from the ground up as a first step toward a more robust Sakai-workflow architecture. Here is one such proposal: conditional-release-technical-proposal.pdf

The initial phase of this work would have essentially two deliverables:

1. A 'ConditionService' which will manage rules and their underlying registrations
2. Implementations for Gradebook and Resources which will allow Gradebook quantities (and by extension, Assignments and Tests&Quizzes results) to serve as conditions for content availability. (A corrollary deliverable will be found in UI additions to the "Revise Properties" screen of the Resources tool)

The 'Backwards' Approach

Another approach would be to start with a ready-made workflow engine, integrate it into Sakai, and implement CR as a very simple workflow case. Reasons for doing so include the wide availability of workflow engines, as well as providing a far more generalizable architecture for content management and cross-tool interactions.

A prime candidate for such a workflow engine would be Kuali Enterprise Workflow (KEW). It might be integrated as a Sakai service.

Suggested Interface

Conditional release is essentially a rules system, and thus might follow the interaction for setting up Email rules or filters. For example, Mozilla Thunderbird's email filter interface:

Design Issues

Logic Problems

Specifying Rules amounts to a form of declarative programming. While providing Sakai a measure of dynamism and power, it also enables site maintainers to introduce bugs into their resources, which poses complications for support.

Rules subject us to all the vagaries of boolean logic. For example, here is a rule that will always fail:

As a practical matter, it may prove very difficult to safeguard Conditional Release against logical errors, and impossible to prevent semantic errors, i.e., rules that fail to express the author's intent. Note that the Mozilla Thunderbird filter does nothing to prevent logical errors of this kind.

The support issue is especially thorny because the course instructor will never see the operation of the rule; they only apply for students, and then only when the special set of circumstances have been met.

We could imagine various implementations of testing strategies to help users validate their rules, but this is a hard problem and a large scope.