Learning More About Your LMS: Resume Behavior and Suspend Data

\n

Have you ever run into a situation where your course doesn’t pick up where you left off when you view it more than once on your LMS? Or maybe it does, but you’d prefer it start over from the beginning? The way your course responds when it’s relaunched is called the resume behavior.

\n

If your course isn’t resuming as desired, you’re probably wondering what’s going on and how to fix it. In this article, we’ll help you figure that out.

\n

How Do I Control the Resume Behavior?

\n

First, let’s examine our options. If you’re using Storyline 360, Presenter 360, Quizmaker 360, or Engage 360, you can choose from three resume options:

\n\n\n\n\n\n\n\n\n\n\n\n\n\n\n\n

\n Prompt to resume \n	\n If learners previously viewed part of the course, this option displays a prompt, asking learners if they want to pick up where they left off. \n
\n Always resume \n	\n This forces your course to open at the place where learners left off. They won’t see a prompt; it just happens automatically. \n
\n Never resume \n	\n This forces your course to always open at the beginning, even if learners completed part of the course previously. They won’t see a prompt. \n

\n

If you’re using Rise 360, the course will always resume from where the learner left off.

\n

How Does Resume Actually Work?

\n

As a learner makes his way through a course, a compressed chunk of information—called suspend data—is sent to the LMS after each slide. This suspend data describes everything about the current state of the course, including the learner’s responses, navigation history, object states, variable values, interaction results, and more.

\n

When the learner opens the course again, it asks the LMS where they previously left off. The LMS sends the suspend data back to the course, and the course uses it to resume at the same point and in the same state as before.

\n

Why Do Courses Fail to Resume?

\n

A few things could get in the way of the resume communication process:

\n\n\n\n\n\n\n\n\n\n\n\n\n\n\n\n

\n

You exceeded the suspend data limit.

\n

Your LMS might be imposing limits on suspend data. Older LMS specs, such as SCORM 1.2, have outdated restrictions on suspend data.

\n

We recommend publishing for the latest edition of SCORM 2004, xAPI (Tin Can API), or cmi5. See these articles for more information:

\n

You’re in a cross-domain environment.

\n

If you’re hosting AICC content on a different server than your LMS, you may experience a cross-domain conflict. See this article for solutions. (Note that this doesn’t apply to Rise 360 courses.)

\n

You already completed the course.

\n

The resume feature might not work as you’d expect after you meet the completion requirement. Most LMSs consider a course to be in review mode after the tracking requirement has been met.

\n

In review mode, resume data is no longer sent to the LMS, which prevents learners from accidentally changing their course status from Complete back to Incomplete. See this article for more information. (Note that this doesn’t apply to Rise 360 courses.)

\n

Can I Examine Suspend Data?

\n

Enable LMS debug mode to watch your suspend data flow back and forth between your content and your LMS. By doing so, you can verify that the data returned by your LMS upon resume is the same data that your content sent upon suspend—a common point of failure.

\n

To help you avoid exceeding suspend data limits (see above), we compress suspend data. As a result, the suspend_data string in an LMS debug log isn’t human-readable. You won’t be able to decipher what it means, but you can see if the data sent to the LMS matches the data that comes back from the LMS.

\n

Doesn’t My LMS Need to Read Suspend Data?

\n

No. Only the course itself needs to be able to decompress and read suspend data. The LMS just functions as a handy place to store suspend data between attempts.

\n

The Bottom Line

\n

Now that you have a better understanding of how resume behavior works, you should be able to troubleshoot these issues more easily if you run into them.

\n

Need more help troubleshooting? Check out these other resources:

\n

Good Morning, Stephan.

The decision to compress Suspend Data is less about protecting proprietary information and more about making sure we don't exceed the data limits that some Learning Management Systems impose.

Further still, we can't offer a web-based suspend data decoding tool right now since our compression/decompression routine is dependent on XML data that is unique to every project. It is not possible to decode the suspend data without first parsing the XML and then creating the correct object structure to read it. Again, we're not trying to hide anything. It's just that this model honestly isn't achievable at the moment.

If you have a set of LMS Debug Logs that we can help you diagnose, please feel free to send them over and we'll be happy to take a look:

https://www.articulate.com/support/contact/submit.php

Thanks for adding your voice to our community!

I Agree with Deborah! Perfect solution to save \"proprietary\" face while SERVING your customers.
PLEASE respond to this without any further delay.

Hey Justin -

This is a sore subject with a few of us LMS admins that double as developers:) It's less about troubleshooting and more about confirmation of progress when someone says \"I finished it.\" The typical flow is trust but verify and with the encrypted setup, the verify step is nearly impossible.

I've taken to completing a course (I have to do this anyway as an employee) to get an estimate of the suspend data volume, then comparing this with a learner's completion.

Additionally, in SCORM 1.2 when suspend data overflows the limit, Storyline restores behave in a consistently bad way.

I get that the restriction is based on the mechanics of how it's being saved. However, it's been pointed out in this thread that despite the compression, there are efficiencies that could be won by shifting the way questions are recorded to suspend data and shifting the progress to the front of the compressed string.

Shifting to SCORM 2004 is a decent suggestion to get the additional overhead beyond the 4K floor of 1.2. But not all LMS support this well.

Many LMS admins are used to uncompressed suspend data. Suspend data makes confirmations and \"under the hood\" review go very quickly. I suspect this is where a lot of the soreness is coming from. \"I've been able to do X for a decade, now I can't.\" Yes, folks really don't like having less access:) Go figure! :P

Justin if what you say were true then Articulate wouldn't be so shy about publishing the method. Most people will happily ignore the documentation but for those of us that want it (or feel we NEED it) we can have our developers go ahead and develop what we choose. If the routine is dependent on the XML data specific to each published lesson that's not the end of the world since we have access to that xml. Just publish the darned compression/decompression schema and let us do that which we want to do. Leaving the community guessing is problematic. You have people posting that they have figured things out or tell you to call this developer or that (who think they have solutions that will only cost $5K or what not).

I have had an unmitgated disaster going to Studio '13. I have had to create a spreadsheet of all my lessons suspend data on the last screen before the quiz to help deal with the lack of ability to go in and unlock progress up to a certain screen.

You really don't understand what its like supporting restricted navigation lessons without having any ability to confirm what's happening.

I am right now encountering multiple reports of students getting their progress wiped out. I want to be able to see what's happening. Interfacing with Articulate takes days and weeks. We need to see what's going on in real time.

Hi, Deborah.

I understand what you're asking for, and I'm sorry to say that I can't provide an ETA for such a tool at this time. I discussed this directly with engineering and we simply can't divert the resources needed to document (and maintain documentation on) this very complex algorithm. It is on the radar with the necessary people, but unfortunately there won't be anything more that I can say on this matter for the time being.

I suggest we shift the focus to the root of why your Learning Management System is so susceptible to losing learner progress in the first place. Based on the behavior that you've described both here and in your private Support Case with us, I expect that the data being returned by your LMS upon resume is different from the data that your content sent to the LMS upon suspend. This is a common point of failure, and sometimes it can be detected by viewing 2 sets of LMS Debug Logs (one during the initial suspend, and another during the resume attempt). Other times, the discrepancy is less visible (think extra whitespace at the beginning or end of the suspend data) and can only be detected using Fiddler logs (or similar). Of course, there's always the challenge of making sure you're running a logging tool at the time that a learner successfully reproduces the problem, which isn't always consistent.

We'd love it if you'd continue to work with us through your case to address this specific problem with your LMS. Thanks for your understanding.

Justin that pretty darned assumptive of you. Our LMS isnt losing data. It takes what it gets and it stores it. I have logs and logs to prove it. We encounter problems on the client side all the time and I have very little faith that Articulate will figure it out for me. I am trying to figure out ways to deal with the vagaries of different platforms. If a user a user opens a lesson one computer and gets 99 screens in and then opens on another computer (or tablet) or whatever and that device trashes the data our LMS will send them a big suspend data strings and they will ExitAu and send nothing. I have seen it happen. Thankfully it doesn't happen a lot.

The new '13 release is so much more susceptible to problems. And it give so much less feedback than it used to. And god forbid you try to update a unit and a user doesn't know how to clear their cache. In '09 the screens were consistently named and didn't seem to bomb out the way the current version does.

If you want to spend your times trying to troubleshoot the 1% with problems when I am willing to accept the vagaries of your software as long as I can support my users when we happen to encounter problems, well I can send you logs all day long. But the bottom line is, you could put a developer who knows what's going on a skype session for 10 minutes with my developer and we would be assuaged. It's being willing to do something about a situation that is not unique.

Justin I would like to submit a request for a new feature. To be able to do this correctly would require better knowledge of what's going on with the XML data that is unique. I am thinking that since the structure of the folders in a published presentation is known, and the files with the XML compression data are known, then a routine could be included in the published output that could be called that would \"know\" where the lesson specific xml is located.

We need two simple JavaScript functions – one will decode Articulate’s encoded data into human-readable form. The other function does the opposite. Our site supports Prototype – but we could support jQuery as well – and the best would be no JS library. We had already assumed the JS code is already in one of the .JS files that Articulate uses for the lessons.

Assume there are two fields on a page – each with a unique ID. The functions take two arbitrary field Ids. They expect content in the first ID and they deliver results into the second ID.

The first function should take the form articulate_decode(encodedFieldID, decodedFieldID)

The other JS function does the reverse: articulate_encode(decodedFieldID, encodedFieldID)

We just want to be able to add a little google translate like window to our system admin interface for viewing the data. This would enable any customer doing their own development to be able to address this really, really problematic situation.

Thank you, Deborah.

Your request is in the right hands, and we'll let you know if this is something we can tackle in the future.

Hi Justin, It's been a year. We back off HTML 5 because of all the problems with certain platforms completing wiping data and I am pleased that things are far better but... we still run into problems from time to time and this problem and related request hasn't been addressed. What's the story morning glory?

Blog Post

Learning More About Your LMS: Resume Behavior and Suspend Data

Learn

Connect

Discover

Community

Company

Trust Center