Force Commit during Publish in Storyline (v1) and Presenter ('13)

Hi Terri,

We don't support modifying the published output, and I don't believe there is a place to change that within the publishing options. 

Storyline and Presenter communicate course completion to an LMS (LMSCommit) when the user meets the completion requirement, either when they reach the appropriate result slide or when they have viewed the required number of slides. BUT communication is continually going back and forth of course. Perhaps it would help if you could see the actual communication that is happening?  You could enable LMS debug mode.

Hi Ashley,

Thank you for the response. We have done the debug and found the culprit in the configuration.js and lms.js files built upon publish. Both files set the Force Commit to 60,000 by default when the code states to set to 0 for no force commit. Our LMS is reading this 60,000 and sending a complete statement back every 10 minutes - whether or not our learners have actually completed the content. Therefore, if we set an attempt limit in our LMS to three and the learning component takes more than 10 minutes, the LMS shows two attempts when the learner only launched it once.

We most certainly do not want designers touching published content. We are trying to find a way to change that setting prior to publish. The js files would indicate it is possible since the remarks within the files show an option for 0.

Thoughts on what we should try? Suggestions?

Thank you!

Hi Terri, 

It's not an option to change prior to publishing - which makes me think you'd need to change it in the js files - but that's the part that I'd recommend looking into further as it's something I don't know anything about. Here's one that discusses it with Javascript. 

Hello Ashley,

Yes, we have investigated the js files, but really want to avoid asking over 250 designers to modify the published files for every course they build. We were *really* hoping for a way to accomplish this through the Publish settings.

We fear if we instruct our designers to touch the js files after publish, there is a greater chance of something being broken and courses not working.

I appreciate your help and knowledge on this. Do you think this setting will be something looked at for an update or future enhancement?

Cheers!

Hi Terri, 

I don't have information toshare in regards to a timeline of updates or what enhancements may be included, but you're welcome to share your thoughts in the form of a feature request. 

I certainly understand not wanting that many designers changing things in the js files - but is there one main person or group that uploads them to the LMS who may have the skill set to make the changes in the js files? 

Ashley (or whomever) it took me some time to find this discussion. This problem with the timing of the lesson to server updates has plagued us since before Studio '09. I have submitted feature request changes in the past. With all the million and one things that you can set in the player, the inability to change the heartbeat interval through a player template (versus having to remember to do global replaces on the .js files) is maddening. I was actually looking to see if this was corrected in Presenter '13. I guess not. 

We are actually looking for updates every 1 minute so that we can see if a student is progressing through the course and stop accumulating time if they walk away from their lesson. 

With all the compliancy course applications the ability to provide a mechanism to deal with this issue is high. 

We can all submit feature requests until the cows come home but the product managers need input from the support reps covering these forums. This is a big issue. 

What I would like to have confirmed in this thread is exactly what is the purpose of the setting in the configuration.js versus the lms.js file and do both need to be changed or just one?

We use AICC. So as far as I know the only updates going to the server are PutParams with the suspend data. Pass/fail info only goes up with the ExitAu. 

Please confirm exactly what we need to change to get Presenter 13 to send up the PutParam updates with the screen suspend data every 60 seconds.

Hi Deborah, 

The support team does communicate with our product team and engineers regularly regarding bugs, feature requests, and forum threads with pertinent information, so I've definitely passed along your thoughts here to my team.

As for your specific request, in Storyline, you can use JavaScript to force an LMSCommit() whenever you want. You can see this described a bit further here. Since Studio '13 and '09 don't allow for Javascript triggers that method won't work. 

I'll have to defer to the community expertise in regards to any changes you'd like to make within the .js files, as we don't offer support for modifications of the published output or Javascript code. 

If there is anything else I can assist with, please feel free to let me know. 

As per my posting, I am only asking about Presenter '13. 

Okay community, since Articulate still isn't addressing this issue, how do you?

 

Hey Deborah, 

I know this post is a little old, but did you ever find a solution to your problem? 

For my purposes I just changed the time in the lms.js and Configuration.js files to a very large number and that made it do what I needed it t do.  This was in Presenter '13 and QM '13. 

However, now that we switched over to Studio 360, the problem is back.  Changing the time in the lms.js and Configuration.js files is not preventing commits from happening every 1 minute.  We tried altering some code in the html5/lib/scripts/app.min.js file that we thought might be causing the commits to take place, but it didn't help. 

Just curious if you ever figured out a solution.  My guess is that Articulate was not very helpful.  And something like this is generally beyond what the Articulate Community is capable of handling.  

Thanks, 

Steven 

Hi Steven,

I can see that you’re still struggling with this issue since you reached out here and in this other discussion. We’d love to help.  It looks like you already shared your debug log with Justin, so we can keep the conversation going over there!