The suspend data problem

Resuming where you left off is the feature that quietly breaks first.

A learner who closes a long module halfway through expects to return to the same place. The mechanism is a small piece of storage that the content writes and the delivery system holds on its behalf. It works well until it does not, and when it fails the symptom is a learner losing progress, which is the failure users forgive least.

The classic cause is size. The storage field has a defined minimum capacity, and content that stores more than that is relying on a platform being generous. Rich modules with many interactions can exceed it without warning, and the failure is silent: the write is truncated, the read produces nonsense, and the learner is returned to the beginning.

A second cause is the session not being closed properly. If a learner closes the browser tab rather than exiting the module, some content never gets the chance to write its final state. Whether that matters depends on how frequently the content saves, which is an authoring decision that nobody outside the authoring team ever sees.

Both are worth testing before a course goes to a cohort rather than after. Open the module, move partway through, close it the way a real person would close it, and come back. If it resumes, the mechanism works for that content on that platform. If it does not, you have found it in testing rather than in a hundred support messages.

It is worth adding that resumption is the feature most affected by a change of platform or a change of hosting. The stored state belongs to the delivery system rather than to the package, so a migration that moves courses and learners without moving that state will return everybody partway through a module to the beginning. Whether that matters depends on how long the modules are and how many people are mid-way, and both are knowable before the move rather than after it.