I have just been notified by our LMS provider (Cornerstone) that changes will be made in Chrome 80, due for launch in Feb 2020, that will significantly affect the window close behavior and as a result course tracking.
Whilst Cornerstone are issuing an update for their SCORM player, do Articulate anticipate or have planned any updates that may be required for published Storlyline 360 and Rise courses?
Following this post. We too are interested in finding out what the impact will be to our Storyline courses and what Articulate will be doing to accommodate for it.
Thanks for reaching out! Google plans to end support for synchronous XHR in Chrome 80 when it's released in February 2020. You can learn more about this change here.
The good news is that SCORM and Tin Can API (xAPI) courses are unaffected by this browser change.
However, AICC courses could be impacted. Learner interactions that happen in the final few seconds before they close the browser tab might not get communicated to the LMS.
We're working on a solution for this issue now. I'll be sure to let you know as soon as we have steps for updating your AICC courses so they're fully compatible with Chrome 80.
I'd also recommend checking with your LMS admin or provider to see if your LMS uses synchronous XHR so they can update your system before Chrome 80 is released.
I'm in the same situation using Cornerstone, Storyline and Chrome. Looks like the beta release will be out starting Dec 18th.
I'll test and post if there are any issues. I don't see why it would have any impact since the course completion code is not sent when the user closes the browser. Maybe as Leslie mentioned the last few seconds of progress in a slide interaction might be lost.
Anyone else have information about this issue? Is there any cause for concern? Thank-you.
Just another +1. We are using Cornerstone for Salesforce (the one being deprecated next year) and SL3 (not 360 just yet unfortunately), and most of our end users are on Chrome.
Glad to hear that SCORM isn't anticipated to be affected from the SL side of things, but also I'm curious about if we'll still need to be worried about our LMS player being updated. We'll also be testing when the Chrome 80 Beta goes live to establish if we need to take more action.
Just curious, is there any documentation for specifically what Storyline SCORM packages are doing for reporting if not using synchronous XHR?
Thanks for the confirmation on that Leslie! Just curious, would you have any preferred resources as recommendations to learn more about SCORM packaging and reporting in general? We've been using a bit from https://support.scorm.com/hc/en-us.
This article explains how to record completion and success statuses in an LMS while covering LMS standards. Also, our team wrote all you need to know about SCORM in this blog post!
The community may have spotted other related content, so I'll hand the microphone over to them!
I'm excited to share that we just released Update 35 for Storyline 360. In it, we added support for Google Chrome 80, which no longer allows synchronous XHR when a web page is closed. This update ensures your AICC courses always communicate a final status to an LMS.
1. Will an updater be created to apply the fix to already published SL courses?
2. Will the update be applied to Rise as well as well. The AICC communication code appears to be similar in Rise to Storyline before the fix was applied?
For folks using Storyline 3: We just released Update 9 that offers support for the Google Chrome 80 and synchronous XHR scenario. This update ensures your AICC courses always communicate a final status to your LMS.
Here's how to update Storyline 3 to the latest version!
The fix in the latest Storyline updates support newly published courses, not previously published courses. We don't have a timeline for the next Articulate Updater yet, but I'll share your comment with the right team.
Also, my teammate, Vincent, replied to you in this discussion. We'll continue to update both conversations on any new developments regarding this context for Rise 360 and the Articulate Updater!
Thanks for the update regarding the Storyline 3 Update 9.
We have plenty of modules that was published using previous version of Storyline 3. Considering the timeline for Chrome 80 release. I would appreciate if you can provide an estimated timeline on when the Articulate Updater will be released for Storyline 3 to update the modules that are published using earlier version of Articulate Storyline 3.
Following! We have a many courses published in SCORM, but the reminder from Cornerstone said that SCORM could be impacted as well? We also have classes that were published in SCORM using Articulate Studio...Need to know if as long as it's SCORM, we're OK.
You're right to infer that this Chrome change is different from the Synchronous XHR problem discussed above!
The good news is that the most resource-intensive communication between an LMS and a course is suspend_data, which is already capped at a maximum of 64 KB by even the most generous LMS standards. We've never seen a course that approaches this level of runtime data, so we anticipate no impact as a result of this Chrome change.
Even with the XHR clarification (thank you so much again on that), just wanted to mention for any folks it might be relevant to, we tested a SCORM course with CFS on Chrome 80 (it's available through their beta) and everything reports as expected.
We have received a similar notice from cornerstone as follows:
The impact on you
Chrome version 80 will now limit the size of status and completion updates that your course can send upon Window Close. The new limit per message is 64KB. If the limit is exceeded, course status and completion will not be sent to Cornerstone and these statuses may not be accurate.
What we're doing to help We have audited all SCORM courses and have identified the below courses within your portal that exceed the new message size limit. These courses will need to be updated to correctly track user's status and completion
We have 4 courses that appear to exceed the 64KB cap. It appears these are older courses built in SL 2 most likely. All involve video snips with questions interspersed. If I repub in 360 will that resolve or is there some other way to limit the size of suspend_data? Any other suggestions?
A great way to inspect the communication between your LMS and your course is to enable LMS Debug Mode and check for messages that exceed 64 KB. I don't think you'll find any, but if you do, we'd love see a copy of the course for further troubleshooting!
Thanks for circling back. Does debug mode show the sizes of those messages? Guessing I can look for the "suspend_data" points in that log, but I don't remember seeing a file size...
Unfortunately, sharing our field-facing product training would likely get me in hot water, but will give it a whirl and see what I find.
LMS Debug Mode won't call out message sizes, but the chunks of suspend data will stick out like a sore thumb. It's extremely rare to see those exceed 10 KB, and we've never seen them exceed 64 KB.
Our LMS vendor, identified 5 courses they say exceed the 64KB message size. The courses they identified are also courses that were being "hit hard" by users because we were at the end of our yearly institutional compliance training, which I find interesting. Maybe these 5 courses were taken repeatedly using the Retake Quiz option before the window was closed and that's what increased the message size. See their note below.
From LMS vendor - "Please note that the message size is subject to specific input provided by the user interacting with the course. Potentially, one user communication with the courseware can send a request that will exceed the 64KB limit while other users’ requests won’t exceed this limit."
With this in mind, is there a way to ensure the message size doesn't exceed 64KB? if it's a variable that's increased by users, what can we do?
If the LMS Debug Mode indicates it's exceeded, how do you reduce the message size?
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. To reduce suspend data, you must reduce the complexity of the course.
I've never seen a course whose suspend data exceeds 64 KB. If you find that your course does, please feel free to send us a copy of the .story project file for further analysis.
38 Replies
Following this post. We too are interested in finding out what the impact will be to our Storyline courses and what Articulate will be doing to accommodate for it.
Hi Jeremy,
Thanks for reaching out! Google plans to end support for synchronous XHR in Chrome 80 when it's released in February 2020. You can learn more about this change here.
The good news is that SCORM and Tin Can API (xAPI) courses are unaffected by this browser change.
However, AICC courses could be impacted. Learner interactions that happen in the final few seconds before they close the browser tab might not get communicated to the LMS.
We're working on a solution for this issue now. I'll be sure to let you know as soon as we have steps for updating your AICC courses so they're fully compatible with Chrome 80.
I'd also recommend checking with your LMS admin or provider to see if your LMS uses synchronous XHR so they can update your system before Chrome 80 is released.
I'm in the same situation using Cornerstone, Storyline and Chrome. Looks like the beta release will be out starting Dec 18th.
I'll test and post if there are any issues. I don't see why it would have any impact since the course completion code is not sent when the user closes the browser. Maybe as Leslie mentioned the last few seconds of progress in a slide interaction might be lost.
Anyone else have information about this issue? Is there any cause for concern? Thank-you.
Just another +1. We are using Cornerstone for Salesforce (the one being deprecated next year) and SL3 (not 360 just yet unfortunately), and most of our end users are on Chrome.
Glad to hear that SCORM isn't anticipated to be affected from the SL side of things, but also I'm curious about if we'll still need to be worried about our LMS player being updated. We'll also be testing when the Chrome 80 Beta goes live to establish if we need to take more action.
Just curious, is there any documentation for specifically what Storyline SCORM packages are doing for reporting if not using synchronous XHR?
Hi Joseph,
SCORM courses are unaffected by the Chrome 80 update because SCORM packages use asynchronous XHR.
Thanks for the confirmation on that Leslie! Just curious, would you have any preferred resources as recommendations to learn more about SCORM packaging and reporting in general? We've been using a bit from https://support.scorm.com/hc/en-us.
Hi there, Joseph!
The resource you shared is a great one! I dug around, and here are a few others that may help on the topic:
The community may have spotted other related content, so I'll hand the microphone over to them!
Happy Tuesday, all!
I'm excited to share that we just released Update 35 for Storyline 360. In it, we added support for Google Chrome 80, which no longer allows synchronous XHR when a web page is closed. This update ensures your AICC courses always communicate a final status to an LMS.
To see all the enhancements this version has to offer, follow these steps to update your software! 🎁
Thanks for the update.
I have two follow up questions.
1. Will an updater be created to apply the fix to already published SL courses?
2. Will the update be applied to Rise as well as well. The AICC communication code appears to be similar in Rise to Storyline before the fix was applied?
Greetings on another happy Tuesday!
For folks using Storyline 3: We just released Update 9 that offers support for the Google Chrome 80 and synchronous XHR scenario. This update ensures your AICC courses always communicate a final status to your LMS.
Here's how to update Storyline 3 to the latest version!
Hey there, Sharon! Great questions.
The fix in the latest Storyline updates support newly published courses, not previously published courses. We don't have a timeline for the next Articulate Updater yet, but I'll share your comment with the right team.
Also, my teammate, Vincent, replied to you in this discussion. We'll continue to update both conversations on any new developments regarding this context for Rise 360 and the Articulate Updater!
Hi Katie,
Thanks for the update regarding the Storyline 3 Update 9.
We have plenty of modules that was published using previous version of Storyline 3. Considering the timeline for Chrome 80 release. I would appreciate if you can provide an estimated timeline on when the Articulate Updater will be released for Storyline 3 to update the modules that are published using earlier version of Articulate Storyline 3.
Thanks in advance.
Hi All.
We just received notice from TalentLMS that both SCORM and xAPI could be impacted. Are we sure it's just AICC?
Following! We have a many courses published in SCORM, but the reminder from Cornerstone said that SCORM could be impacted as well? We also have classes that were published in SCORM using Articulate Studio...Need to know if as long as it's SCORM, we're OK.
Following this as well. All of our courses are SCORM.
Hi Ginger, Catherine, and Amy!
Valid concerns and one that we've seen previously.
The difference being that SCORM courses are unaffected by the Chrome 80 update because SCORM packages use asynchronous XHR.
Google plans to end support for synchronous XHR in Chrome 80 when it's released in February 2020. You can learn more about this change here.
Hello, all:
We just received a notice from our LMS lead admin (for Cornerstone). In part, he wrote:
When Google releases Chrome version 80, they are limiting the data packet size that a SCORM course can send back to UPS University (Cornerstone).
· The data size limit being implemented in Chrome is 64KB.
· If your course attempts to send anything back to UPS U in Google Chrome that exceeds this 64KB limit, it will NOT work.
· This could mean an increase in users reporting course completion issues if they use Google Chrome to view your courses.
· Since we often recommend trying Google Chrome if IE11 or Edge browsers don’t work, THIS ISSUE CAN AFFECT YOU AND YOUR USERS.
Is this the same issue? It sounds different. Any suggestions?
Thanks.
Hi, Lerissa.
You're right to infer that this Chrome change is different from the Synchronous XHR problem discussed above!
The good news is that the most resource-intensive communication between an LMS and a course is
suspend_data, which is already capped at a maximum of 64 KB by even the most generous LMS standards. We've never seen a course that approaches this level of runtime data, so we anticipate no impact as a result of this Chrome change.Please let us know if you need anything else!
Even with the XHR clarification (thank you so much again on that), just wanted to mention for any folks it might be relevant to, we tested a SCORM course with CFS on Chrome 80 (it's available through their beta) and everything reports as expected.
We have received a similar notice from cornerstone as follows:
The impact on you
Chrome version 80 will now limit the size of status and completion updates that your course can send upon Window Close. The new limit per message is 64KB. If the limit is exceeded, course status and completion will not be sent to Cornerstone and these statuses may not be accurate.
What we're doing to help
We have audited all SCORM courses and have identified the below courses within your portal that exceed the new message size limit. These courses will need to be updated to correctly track user's status and completion
We have 4 courses that appear to exceed the 64KB cap. It appears these are older courses built in SL 2 most likely. All involve video snips with questions interspersed. If I repub in 360 will that resolve or is there some other way to limit the size of suspend_data? Any other suggestions?
Thanks for your reply, Matthew.
A great way to inspect the communication between your LMS and your course is to enable LMS Debug Mode and check for messages that exceed 64 KB. I don't think you'll find any, but if you do, we'd love see a copy of the course for further troubleshooting!
Thanks for circling back. Does debug mode show the sizes of those messages? Guessing I can look for the "suspend_data" points in that log, but I don't remember seeing a file size...
Unfortunately, sharing our field-facing product training would likely get me in hot water, but will give it a whirl and see what I find.
Happy Monday, Matthew.
LMS Debug Mode won't call out message sizes, but the chunks of suspend data will stick out like a sore thumb. It's extremely rare to see those exceed 10 KB, and we've never seen them exceed 64 KB.
Our LMS vendor, identified 5 courses they say exceed the 64KB message size. The courses they identified are also courses that were being "hit hard" by users because we were at the end of our yearly institutional compliance training, which I find interesting. Maybe these 5 courses were taken repeatedly using the Retake Quiz option before the window was closed and that's what increased the message size. See their note below.
From LMS vendor - "Please note that the message size is subject to specific input provided by the user interacting with the course. Potentially, one user communication with the courseware can send a request that will exceed the 64KB limit while other users’ requests won’t exceed this limit."
With this in mind, is there a way to ensure the message size doesn't exceed 64KB? if it's a variable that's increased by users, what can we do?
If the LMS Debug Mode indicates it's exceeded, how do you reduce the message size?
Hi, Jennifer.
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. To reduce suspend data, you must reduce the complexity of the course.
I've never seen a course whose suspend data exceeds 64 KB. If you find that your course does, please feel free to send us a copy of the .story project file for further analysis.
This discussion is closed. You can start a new discussion or contact Articulate Support.