Skip to content

OAE D2L Integration: Proof of Concept

Stephen A Thomas edited this page Jan 13, 2014 · 21 revisions

Some quick notes on a proof-of-concept integration between the Open Academic Environment (OAE) and Desire2Learn (D2L). The focus of this effort is assessment of student assignments. This post considers the implications for OAE.

System Roles

  • Students use OAE to manage their activities related to assessment of their work.
  • Instructors use D2L to manage their activities relating to assessment of student work.

Typical Scenario

  1. (Optional) As OAE user, student receives a notification of impending assignment due date.
  2. Student designates any OAE content (owned by the student) as work to be submitted for assessment. Student identifies the specific class and assignment for the work.
  3. A copy of the content is transferred to D2L for assessment by the instructor.
  4. Student receives confirmation that content was successfully transmitted to D2L. The content's revision history includes an indication of the submission (along with date and time).
  5. (Optional) Student checks the "assessment status" of the content to see whether or not it has been evaluated.
  6. (Optional) Student and instructor engage in discussion related to content/assessment. Only student is able to view this discussion in OAE (regardless of the public/private profile of the content). Student receives notification of new discussion comments from instructor.
  7. Instructor provides evaluation (e.g. grade) for assignment, which student views on OAE (e.g. as part of content/assessment discussion). Student receives notification of evaluation.
  8. (Optional) Discussion may continue after evaluation.
  9. (Optional) Student may submit revised work.
  10. (Optional) Instructor may revise evaluation.

Potential Complications

  • Student may re-submit the same content for the same assignment. In this case the content's revision history should reflect multiple submissions.
  • Student may submit new content for the same assignment. In this case the assessment status for the original content should indicate that new content was submitted for the assignment.
  • Student may re-submit the same content for a different assignment. In this case the same content may have multiple evaluations.

Questions

  • How (if at all) will the system handle discussions related to an assignment before any content is submitted for assessment?
  • What (if any) are the policies on submission? (e.g. no re-submissions, no submissions past due date, ...) Are they fixed or do they vary by assignment? How are they enforced? (e.g. by the D2L API) Are those policies exposed prior to a submission attempt? (e.g. by the D2L API)
  • Does the D2L API provide a name (and thumbnail) for instructors?
  • Does D2L support the concept of revoking a submission?

Initial Design Mockups

Note: Alternative approaches can be see in earlier revisions of this document

The design approach below tries to leverage the existing OAE environment and components by integrating D2L seamlessly within the OAE experience. To submit content for assessment, the student uses the existing Share functionality and shares the content with an entity representing the D2L course. The D2L course could appear in as a suggested search item:

Alternatively, the interface could pre-populate the available choices with "ghost items" representing the courses relevant to the user (instead of or in addition to the current "My library").

If the student selects a D2L entity as the share target, she is given a choice of assignments. The student could leave this selection blank to submit the content outside of the context of any assignment.

Once content has been associated with a D2L assignment, the content's sub-title (normally its type) indicates the status of the assessment.

Expanding the main content clip exposes an additional "Discuss" option. Initially the option could be limited to content that has been submitted for assessment.

Clicking on the "Discuss" button could display a distinct modal dialog box for discussion related to the assignment. That dialog could incorporate interface elements of particular relevance to an assessment. (For example, it could show the status and, if available, result of the assessment in a prominent location.)

Alternatively, assessment-related discussions could be presented as normal OAE discussions. These discussions are private; only the student (via OAE) and instructor(s) (via D2L) participate and view.

Implementation Notes

This post outlines a potential strategy for integrating D2L reviews (aka assessments) in the OAE sharing feature as part of a proof of concept demonstration. The approach it suggests is not recommended for production implementation.

Loading the Content Page

As part of the content.js code setup, if the content is owned by the current user, issue an additional API request to get a list of classes/assignments for the user. Store the results as an option (potential review targets) of the content profile. (Defer setting up the clips until the results are available.)

Note that the current content profile does not indicate whether or not the content item is owned by the logged in user. An extension of the content profile or an additional API would be required.

Templates

Create or modify a template based on #autosuggest-suggested-template for rendering review target suggestions using a distinct icon instead of a thumbnail (in shared/oae/macros/autosuggest.html).

Create or modify a template based on #autosuggest-selected-template for review targets that are selected using a distinct icon instead of a thumbnail (in shared/oae/macros/autosuggest.html).

Create an additional template for selection of a specific assignment (in node_modules/oae-core/share/share.html).

Modify the #share-notification-title-template and the #share-notification-body-template as appropriate for review submission instead of normal sharing (in node_modules/oae-core/share/share.html).

Set Up

As part of the node_modules/oae-core/share/js/share.js code, check the content profile for potential review targets. If the list is not empty, modify the setup of the autosuggest plugin.

  • Selecting review targets via "ghost items"
    • Add review targets as ghost items to autosuggest
  • Selecting review targets via search
    • Instead of providing autosuggest a search URL, provide a local search function.
    • That function calls the standard /api/search/share endpoint and augments its results with any matching items from the potential review targets.
    • Results are only augmented if no review target is already selected (preventing the user from submitting the content for multiple reviews simultaneously).
    • Create an event handler for user selection of a specific assignment.
    • Create a formatList function to render suggested items based on either on the existing #autosuggest-suggested-template or the modified version, as appropriate. (Or use a modified version of the template in the existing logic.)
  • Create a selectionAdded function to adjust the rendering of selected items if they are review targets. (Existing code in shared/oae/api/oae.api.util.js hard-codes elements such as thumbnails that cannot be overridden by template changes, lines 832ff.)

Auto Suggest Changes

When the selected autosuggest items change (i.e. when autoSuggestChanged is called) perform several actions.

  • If the selected items don't include a review target, delete the template for assignments. Set the enable/disable state of the share button to its normal value.
  • If the selected items include a new review target, render the template for selecting a specific assignment using the list of assignments for that particular review target. Disable the share button until the user selects an assignment.

Assignment Selection Changes

When the new assignment change event handler is invoked:

  • If an assignment is selected, enable the share button.
  • If no assignment is selected, disable the share button.

Saving the Share

In the click handler for the #share-save button, add code to extract review targets in addition to principals from the getSelection() results.

For review targets, use a separate API modeled on the existing oae.api.content.shareContent to submit content for review.

In the shareFunction completion handler adjust the data parameters as appropriate for review templates.

In the shareFunction completion handler provide error handling for errors in addition to 401.

Modifications to the API Utility Code

For finding review targets via search: In the wrapper around the third-party autosuggest plugin (in shared/oae/api/oae.api.util.js) add support for functions as well as URLs. If the setup options include a non-null function property, then pass that function to the autosuggest plugin instead of the url property (line 921).

Initial API Thoughts

Some ideas on a proof-of-concept API (between the front-end and back-end):

Get content's review status

An API call to determine the review status (if any) of a given content item. Server should take into account content ownership (e.g. status should only be visible to content owner

Get eligible review targets

An API call to request an array (possibly empty) of eligible review targets for a given content item. Each element in the response array may be structured as:

{
    targetId:  '1',                                   // unique identifier for the review target
    shortName: 'CS6210',                              // brief name to use in buttons/labels
    longName:  'CS6210: Advanced Operating Systems',  // full name of target
    assignments: [                                    // array of potential assignments within target
      {
        assignmentId: '1',                            // unique identifier for the assignment
        name:         'Mirroring VMs"                 // name of assignment
      },
      // ...
    ]
}
```

When constructing the list of potential review targets, the server should take into account 

* ownership of the content item
* "courses" associated with the user (e.g. registered courses)
* assignments associated with each course
* validity of assignments (e.g. too early, too late, already submitted, ...)