Adapt_framework: Should completion settings move to config.json?

Created on 7 Aug 2017  路  13Comments  路  Source: adaptlearning/adapt_framework

Currently there are course completion attributes which live inside the Spoor extension. For v3 should these be attributes of the course rather than a specific plugin?

question

Most helpful comment

maybe _submitScore (or whatever the property is, am on holiday so not really able to check). or maybe that should be moved to assessment config? can you hold this until next week when i'm back and can comment more fully?

All 13 comments

The rationale for this is that with the xAPI support there are multiple extensions which would be interested in what constitutes a course completion. Right now that information is held in _spoor, and should possibly move to config.json.

course.json or config.json?

I was thinking config.json. I think the completion settings should only ever be defined in one place and since there's only one config.json file, even with multiple language versions, it's a good option.

As long as there's a documented decision i'm happy.

From in the _tracking section of Spoor the following should probably move:

  • _requireCourseCompleted
  • _requireAssessmentPassed

Are there any others, or anything else which should be added?

maybe _submitScore (or whatever the property is, am on holiday so not really able to check). or maybe that should be moved to assessment config? can you hold this until next week when i'm back and can comment more fully?

Of course, we can discuss when you're back.

Enjoy your holiday!

@brian-learningpool Ok sorry for delay

Having had a chance to look I think you're right, _requireCourseCompleted and _requireAssessmentPassed are the only two settings that seem to be high-level enough to justify moving. Things like _shouldSubmitScore and _shouldRecordInteractions seem quite extension specific.

How about this as a top-level item in config.json?

"_completionCriteria": {
    "_requireContentCompleted": true,
    "_requireAssessmentPassed:" true
}

?

No worries, @moloko. That's exactly what I was thinking too. Thanks!

@moloko, something that @oliverfoster and I were discussing: should _requireAssessmentPassed become _requireAssessmentCompleted instead?

In theory shouldn't it be at least possible to fail the course by failing the assessment?

@brian-learningpool my definition of 'assessment completed' here was 'assessment has either been passed or all attempts have been used up'... didn't make that clear though, sorry.

| Course Complete | Assessment Finished (finished = completed, passed or all attempts finished) | Statuses Possible |
|-----------------|---------------------|----------------------------|
| y (satisfy me) | n | incomplete, completed |
| y (satisfy me) | y (then me) | incomplete, failed, passed |
| n | y (satisfy me) | incomplete, failed, passed |
| n | n | complete |

leads to:


checkCompletion: function() {

  var completionData = this.getCompletionData();

  if (completionData.status === COMPLETION_STATE.INCOMPLETE) {
    return;
  }

  Adapt.trigger('tracking:complete', completionData);
  Adapt.log.debug('tracking:complete', completionData);

},

getCompletionData: function() {

  var completionData = {
    status: COMPLETION_STATE.INCOMPLETE,
    assessment: null
  };

  // Course complete is required
  if (this._config._requireCourseComplete && !Adapt.course.get("_isComplete")) {
    // INCOMPLETE: course not complete
    return completionData;
  }

  // Assessment completed required
  if (this._config._requireAssessmentFinished) {

    if (!this._assessmentState) {
      // INCOMPLETE: assessment is not complete
      return completionData;
    }

    if (!this._assessmentState.isPass && this._assessmentState.attempts) {
      // INCOMPLETE: assessment has more attempts
      return completionData;
    }

    if (!this._assessmentState.isPass) {
      // FAILED: assessment is failed and has no more attempts
      completionData.status = COMPLETION_STATE.FAILED;
      completionData.assessment = this._assessmentState;
      return completionData;
    }

    // PASSED: assessment completed passed
    completionData.status = COMPLETION_STATE.PASSED;
    completionData.assessment = this._assessmentState;
    return completionData;

  }

  // COMPLETED: criteria met, no assessment requirements
  completionData.status = COMPLETION_STATE.COMPLETED;
  return completionData;

},

matt just pointed out to me that with spoor:

        "_reporting": {
            "_comment": "Your options here are 'completed', 'passed', 'failed', and 'incomplete'",
            "_onTrackingCriteriaMet": "completed",
            "_onAssessmentFailure": "incomplete",
            "_resetStatusOnLanguageChange": false
        }

In SCORM 1.2 these properties send their single value to the LMS when our states are:

_onAssessmentFailure : FAILED
_onTrackingCriteriaMet : PASSED/COMPLETE

In SCORM 1.2 the LMS ends up with a single text status representing whatever came out of Adapt (as above either "completed" or "incomplete).

In SCORM 2004 you have TWO completion data elements: completion_status and success_status.

completion_status : INCOMPLETE/COMPLETE
success_status: UNKNOWN/PASS/FAIL

In SCORM 2004 our states of INCOMPLETE/COMPLETE/PASS/FAIL become split into COMPLETE+PASS/FAIL or INCOMPLETE+UNKNOWN

brian said:

xapi results objects have:
INCOMPLETE/COMPLETED/PASSED/FAILED

Was this page helpful?
0 / 5 - 0 ratings