Including Javascript for repeating functionality
Jan 04, 2021
Up untill recently i always used Webobjects to add jQuery and GSAP because i use that for most of my work. Now Articulate included the latest version of GSAP in Storyline i notice i work without the Webobjects and use GSAP directly on elements in Storyline. One big disadvantage still though. By using a generic_functions.js script i added a lot of functionality to Storyline that aint available default. Eg. i can change color, shape, position of any shape and image with functions i predefined. Without the use of the Webobjects that add the external js file to the html-file i donot have global access to these functions and have to add the functions time after time on any trigger. That i donot like. I want to be able to call my setup functions at any time in a Storyline.
In the Gif below you can see what i mean. The card on the left has all code on it...quite some...the png on the left only calls the same function...but that fails due to scope.
The disadvantage of Webobjects is that if you change anything in your generic_functions.js you have to update your Webobject, change the unique number for the Webobject in your code...and publish again. Quite cumbersome.. so how to solve that...
At first i tried to find a way to include/import the javascript files into the existing Storyline code. That failed however. In the end the solution was simple. Just adding a reference to the javascript file in the index.html in both the classic and unified player folder in your Articulate folder as seen in the image below.
And from now on i have access to all my generic functions on any publish without any changes needed. Only when Articulate updates Storyline i have to change this again. And you need to remember that when you exchange projects with others, they dont have your updated files, so they need it too then.
As you can see here now my call to the functions work.
And by reusing code in functions it can be much simpler in the end.
6 Replies
Thanks for this FANTASTIC insight, Math.
I've got some Javascript that I'm experimenting with that I need to run before any screen triggers fire and this technique might give me an avenue to achieve that.
Glad you like it. Only mishap is that whenever Storyline updates, you need to update your setup too.
Just to followup, because my change to scormdriver.js was relatively small (about 20 lines) and because in my corporate environment I don't have easy access to change the Articulate 'master' files in down in Program Files, I decided to write a WORD macro (again, corporate environment means that macros are an easy way to get programming under the IT gatekeepers' radar ;-)) that:
An advantage of this approach is that even if an Articulate update overwrites the 'master' files, as long as they haven't changed too much (and hopefully scormdriver.js won't), then my process continues to work without having to remember to update the master.
Thanks again, Maths, for providing the inspiration.
That sounds great Pete. The scormdriver in fact is a one-on-one copied file from Rustici. So i don't expect that one to change much. So im wondering about your workflow... how you trigger your WORD macro ? On publish ? This really inspires me to try it too... i can imagine eg. the background-audio trick to set up automagically on publish if someone wants it... Seeing quite some possibilities...
Also the dreaded Big Black Play Button can be continuously removed this way...
Nothing so clever as auto-initiated. Developers in our team publish from Storyline as normal, WITHOUT zipping, then open the WORD.DOCM file that has the macro and run it with a keypress.
The first thing the macro does is display a dialogue prompting to navigate to the project Storyline Output folder and then it's all automatic from there, including Zipping ready for LMS import.
So, really, this replaces the Zipping stage of Storyline's usual publish process - with the added benefit of injecting the custom JS code.
Suspected something like that... and indeed when you do need to zip the published content why not indeed do it like this... good solution.
@Articulate... wouldnot it be nice for us developers if we could have a customized option in the publish menu...where we can control the publish process like Pete does here..
Something like this...
A watch folder might be good too. Setup some watch folder on your teams drives...when a new folder is published there some automatic scripts process files and zip them...
For sure gonna do some experiments with this.