Help with javascript to show layers - too much processing using built-in SL360 variables/triggers/layers

Jul 10, 2020

I wonder if any javascript wizards might be able to help me. I am building a "game" in Storyline 360. In the game, the learner is going shopping with a character, and makes decisions on what to buy. As the learner makes decisions, variables change from "false" to "true" and different images show on the screen. On the final slide in the game, a layer appears depending on what was purchased, with images showing depending on the value of the variables. This all works great using built-in variables, triggers, and layers. However, this final slide has about 30 layers, and within each trigger to show the correct layer, there are 6 "if" conditions to process. That's a lot of processing and I've noticed in Review that it takes many seconds for the processing to take place and for the layer to show. This is a game for learners with ID/DD and the delay may be very confusing. For this reason, I was wondering if the processing to show the correct layer could be done with javascript instead of built-in Storyline triggers to show layers.

The logic is like so:


if var1 is true AND var2 is false AND var3 is false AND var4 is false AND var5 is false AND var6 is false
show layer "var1"
else if
var1 is false AND var2 is true AND var3 is false AND var4 is false AND var5 is false AND var6 is false
show layer "var2"
else if
var1 is false AND var2 is false AND var3 is true AND var4 is false AND var5 is false AND var6 is false
show layer "var3"

... keeps going ...

else if
var1 is true AND var2 is true AND var3 is false AND var4 is false AND var5 is false AND var6 is false
show layer "var1and2"

... keeps going ...

show layer "var2andvar4andvar6"


As I mentioned, there are about 30 layers so there would be many "else if" conditions that would run.

I've looked at several posts here in the community, but I'm still not sure how I would do this. Any help with accomplishing this would be so appreciated! Thank you!

34 Replies
Walt Hamilton

I like Phil's idea of states. I envision a little work in the graphics program, but basically, Hat with visible/invisible state, Coat with visible/invisible state. etc. Can be done with one character, 6 objects with two states each, and 12 triggers (change state of hat to visible if Hat = True, and change state of hat to invisible if Hat = invisible. Each state can add to the total picture.
Of course, programming is much more glamorous, but stop and think a bit about what you have been through to learn the js. Unless you keep programming every day, in two months, if you have to do maintenance on this project, you'll have to learn the js all over again. And if you leave, and they need to make changes, will they have hired someone who can do js? Js is great for producing magic, but can be a nightmare for future maintenance.

And while Phil's usually (as in always) right, the way triggers are sequenced, and what they do, can slow processing. [Edit In retrospect, my slowing may have been caused by animations or motion paths, rather than triggers] Still in this case, my vote is the graphics.

Andrew Hanley
Walt Hamilton

Js is great for producing magic, but can be a nightmare for future maintenance.

Oh dear Walt! This is like the polar opposite to how I consider JS. :)

I will jump to the defence of JS here a bit, but only to try to encourage you that a small investment of time now - just simply to learn the very basics of JS (variables, operators, if/else statements) - will pay dividends time and again down the line as you start to adapt to a more dynamic and updatable way of working.

You are right, you can do some cool things with it, but for me the big advantage with JS is the ease of updating certain content and assets within courses. Maintenance becomes a breeze if, say, a client requires an additional button/state/layer to be shown and we dont need to worry about copy/pasting and editing all those triggers or states.

And no, Javascript has not paid me to say this ;)

Dave Cox

Looking back through this thread, I would also suggest that using boolean logic would make this much easier to figure out. Rather than use a true/false variable for each item, assign each item a binary value. Item 1 = 1, item 2 = 2, item 3 = 4, item 5 = 8, and etc. It's fairly easy to enable or disable each value using a bit of binary math, as well as to determine which state to display. This method can be used with or without JS.

The transparent objects method is also a really good way to build image layers, and PNG images still support transparency.

When I do need to add JS to a project, I find that a good practice for maintenance is to include a layer on the first slide with developer notes about how to republish the project. The layer is never shown when the project plays, and remains with the project for future developers to see. You can also add a note in the margin of you storyboard for developers to go look at that layer.

Walt Hamilton


I love programming, and I love the freedom and flexibility JS gives me.

But when I look at this original post, and look back over the opportunities I've had to help people on this forum with JS (some of it quite simple), it is obvious that a lot of us here lack programming skills. Then when I look at job descriptions, I find companies want to hire people with educational skills, or (even graphic) design skills. Sometimes they mention HTML5 or CSS, or even LMS, but I've never seen one ask for JS. So the bottom line for me is that any time I include JS, no matter how fun and easy, or even necessary it may be for me, I know that down the line I'm setting somebody up to fail. Either the owner will have lucked out and accidentally hired somebody like me with programming skills (if they hire according to their job descriptions, any degree of programming skill is a serendipitous accident), or some poor designer will have to learn JS, or they may even have to scrap it and start over entirely. Although if I were still teaching, I would definitely give Dave an A for his documentation!

Back in a previous century, when 4K was enough memory for anybody, there was usually one way to get something done. Now we have the luxury of making things work using any number of methods (witness this discussion). Given that, we owe it to those who follow us to think of them. Whether it is going to be I in two weeks, or an unknown person in an unknown amount of time, they will thank us if ease of maintenance was very high on our priority list when we created this project.

That is my point of view for calling JS in SL a maintenance nightmare, and something that ought to be used only as a last and only resort.

Dave Cox

Hi walt

Thanks for the call out. I try to be clear when I document how to do something. After all, that is big part of what I do for a living :-).

And yes, I remember back to those days when we had to program for limited memory space. Sometimes the techniques that we used back then still provide a good solution for solving a problem.

I love that i can use JS to enhance SL. But I agree with you, that we should only add JS when that is the only solution. If there is any way that I can accomplish a task in Storyline without resorting to JS, I will do that. And the way that SL supports triggers, layers, states, and variables,  there is a lot that you can do in storyline without having to resort to JS.  But I'm still glad we have JS for when we need it, and I know that those of us that are comfortable with it will continue to help those that are JS challanged.

Thanks for your observations,


This discussion is closed. You can start a new discussion or contact Articulate Support.