I have a JS trigger in a Storyline 360 project that contains 2 large arrays. I placed the code in a trigger instead of an external file because I hate having to add the external files into the published output each time I publish and am not actually sure how to add external files when publishing to Review.
Aside from it being a pain to work with the code in the tiny trigger window, is there any other reason why I should consider placing the code in an external file?
My #1 reason for placing the code in an external file is that I can make changes to the code without re-publishing the .story file. I recently had a project with about fifteen functions, and if I had been forced to re-publish every time I corrected my stupid programming mistakes I never would have finished the project. (Soooo not a programmer!)
Hey Sharon, that is a good point. If I did that it would really change the way I work right now. I am such a visual person that every time I make a change, I publish which is insane when you thing about it.
I wonder if there is any difference in the performance of the output if you use an external file?
Storyline takes the code you place on triggers and places it in a file called user.js, which is stored in the story_content folder. If you open it you'll see Storyline has made your triggers into a bunch of functions.
It's obviously redundant when you think about it, because when you write external code you're probably calling functions via a trigger, like this:
myFunction();
and then the bulk of the code is in the external file.
Storyline wraps your function call in yet another function, so you get
function Script2() { myFunction(); }
There is also a switch statement that determines when to run the user.js functions.
Even if you pasted a bunch of code into the triggers, Storyline would still have to generate the user.js functions. In my eyes, this means you wouldn't experience much (if any) difference. If you're really curious you could always publish an identical project with internal and external code, then zip each and compare the total size.
Oh, one more good reason to use external files -- I can (for example) write a function to generate a random number, then call it on five different slides without rewriting the code.
As Matthew and Sharon point out...biggest plus of code in an external file versus in triggers is reusability over slides. So you create a function once and can use it in any slide anytime.
Depending on how you add that external file ( i use a Webobject to add JQuery, Gsap and my generic_functions.js ) you have to change the url pointing at the Weboject each time you publish.
Small correction: if you update or add a new file into your folder containing your Webobject you have to import the Webobject again and change the url. Else it keeps the older files and not updates anything.
So my workflow is now like this.. i create my scripts...either in triggers, fix things in the console or directly in the user.js. Whenever i think a function i created is solid enough to add to my generic_function.js file i add it inthere and recreate the Webobject so i can use it anytime by calling it. In fact i reuse and add that generic_functions.js in all my projects so i can reuse it always.
Quickly out-of-my-head several of the functions i have inthere...
docLoaded( ) Gets triggered when a Storyline is loaded and checks the URL its loaded from to see whether its on a LMS or testing locally. If on a LMS it gets the username..if not i sets a Storyline variable to a dummy name
sendEmail( ) This function directly sends email to a specified adress with quite some available parameters. So not using the users mail, but using SMTP.
getElementsFromStoryline( ) This function gets ALL elements on your timeline in Arrays to loopover. I have setup 2 arrays: textsArray and imagesArray. The script checks all elements on a page and adds them to the array, so i can animate all texts and / or images at will. Makes it also easy to create custom state-like animations with javascript.
getTranslateX( ) getTranslateY( ) Two functions i use a lot when animating with GSAP. These get the x and y position of any given SVG element ( all Storyline elements are ) in screen and thus gives me the possibility to animate precise and perfectly.
changeText( ) A function that has parameters to change any onscreen text in Storyline to whatever text, colour and or size. FontFamily now is not changeable...would be great to figure out too.
For a multigame-setup im working on i do have a lot more..but have to test and doublecheck them before i add them to my generic_functions.js
In fact here you can see the status as is now for this multiuser game..
You can login simultenauously with 2 browser-instances ( only tested in Chrome sofar )… changing ( dragging/dropping ) tiles (octagons) in one instance…you will see direct update in the other.
9 Replies
My #1 reason for placing the code in an external file is that I can make changes to the code without re-publishing the .story file. I recently had a project with about fifteen functions, and if I had been forced to re-publish every time I corrected my stupid programming mistakes I never would have finished the project. (Soooo not a programmer!)
Hey Sharon, that is a good point. If I did that it would really change the way I work right now. I am such a visual person that every time I make a change, I publish which is insane when you thing about it.
I wonder if there is any difference in the performance of the output if you use an external file?
Good question!
Storyline takes the code you place on triggers and places it in a file called user.js, which is stored in the story_content folder. If you open it you'll see Storyline has made your triggers into a bunch of functions.
It's obviously redundant when you think about it, because when you write external code you're probably calling functions via a trigger, like this:
myFunction();
and then the bulk of the code is in the external file.
Storyline wraps your function call in yet another function, so you get
function Script2()
{
myFunction();
}
There is also a switch statement that determines when to run the user.js functions.
Even if you pasted a bunch of code into the triggers, Storyline would still have to generate the user.js functions. In my eyes, this means you wouldn't experience much (if any) difference. If you're really curious you could always publish an identical project with internal and external code, then zip each and compare the total size.
Oh, one more good reason to use external files -- I can (for example) write a function to generate a random number, then call it on five different slides without rewriting the code.
Ok I'm sold. I need to repeat the code across several slides so external it is.
As Matthew and Sharon point out...biggest plus of code in an external file versus in triggers is reusability over slides. So you create a function once and can use it in any slide anytime.
Depending on how you add that external file ( i use a Webobject to add JQuery, Gsap and my generic_functions.js ) you have to change the url pointing at the Weboject each time you publish.
Small correction: if you update or add a new file into your folder containing your Webobject you have to import the Webobject again and change the url. Else it keeps the older files and not updates anything.
So my workflow is now like this.. i create my scripts...either in triggers, fix things in the console or directly in the user.js. Whenever i think a function i created is solid enough to add to my generic_function.js file i add it inthere and recreate the Webobject so i can use it anytime by calling it. In fact i reuse and add that generic_functions.js in all my projects so i can reuse it always.
Quickly out-of-my-head several of the functions i have inthere...
docLoaded( )Gets triggered when a Storyline is loaded and checks the URL its loaded from to see whether its on a LMS or testing locally. If on a LMS it gets the username..if not i sets a Storyline variable to a dummy name
sendEmail( )This function directly sends email to a specified adress with quite some available parameters.
So not using the users mail, but using SMTP.
getElementsFromStoryline( )This function gets ALL elements on your timeline in Arrays to loopover.
I have setup 2 arrays: textsArray and imagesArray. The script checks all elements on a page and adds them to the array, so i can animate all texts and / or images at will. Makes it also easy to create custom state-like animations with javascript.
getTranslateX( )getTranslateY( )Two functions i use a lot when animating with GSAP. These get the x and y position of any given SVG element ( all Storyline elements are ) in screen and thus gives me the possibility to animate precise and perfectly.
changeText( )A function that has parameters to change any onscreen text in Storyline to whatever text, colour and or size. FontFamily now is not changeable...would be great to figure out too.
For a multigame-setup im working on i do have a lot more..but have to test and doublecheck them before i add them to my generic_functions.js
In fact here you can see the status as is now for this multiuser game..
login to:
https://fontys.talentlms.com/
Username 1: JaapAap
Password: Welkom123!
Username 2: UserDemo
Password: Welkom123!
You can login simultenauously with 2 browser-instances ( only tested in Chrome sofar )… changing ( dragging/dropping ) tiles (octagons) in one instance…you will see direct update in the other.
Kind regards,
Math
See reply below :-)...euhhh above ;-)
For sure...will be breaking this up in several smaller stories/workflow tutorials on how to create a multiplayer game with Storyline...
This discussion is closed. You can start a new discussion or contact Articulate Support.