Forum Discussion
Dealing with the naming of variables
Hello Storyline developers, I wonder how you deal with the following situation: I have made an e-learning with +/- 80 slides and to prevent errors I have created new variables for every slide (b...
If you change the variable names by editing them in the Variables window, Storyline will automatically adjust the names in the triggers.
Of course, you still have to rename all the variables if you include scene & slide numbers and then insert an extra slide. But at least you only have to do it once in the window, instead of locating all of the uses in the slide triggers.
BTW, I also recommend keeping the names as short as possible, so you can ID a variable by the first part of the name. For example, instead of "Slide11" for scene1, slide 1, I suggest "1_01."
Rather than solutions, I'd like to recommend rethinking the problem.
If you are coding there are real reasons for local and global variables. But the way SL is set up, the only real use for variables is that one part of the program is aware of what happened in another part. The need for local variables can (and probably should) be met in less complicated ways.
Local (limited in use to only this slide) variables can be changed only in two ways. The most useful way is in response to an action on a different slide. But the only way to pass that action is through a variable that is used by both slides, and you wouldn't want to name that variable with a slide name. The other way to change a variable is in response to an action on its own slide (a user action, or a time action). This would involve changing the variable (an unnecessary step probably), then taking the desired action. A simpler method is to take the action. If later there is a need to know if the action was taken, check the state of the object.
Take, for example, the variable slide414_moveSidebarUp. If the learner chooses at some point to move the Sidebar up on all or various slides, that variable can be used when each slide starts to move it up (same variable and trigger on each slide). If the choice is made on each individual slide, let the learner's action move it, and if it is necessary to know later in the slide if it has been moved, check its state.
I can see a scenario in which occasionally it is necessary to know many how times a learner takes a certain action. The intuitive way to track that is to add to a counter (variable) each time an object is clicked. That is a method that is dangerous and vulnerable. For example, an action occurs when all five objects are clicked. If you add one to a counter with each click, what happens if the learner clicks one object five times? The action is taken, even if the conditions have not been met. Far better to do something like: "when object is clicked, take action if all five objects are in visited state". Visited state is a built-in state, so referring to it in a trigger creates the state and the necessary trigger to change it when clicked. Side benefit: no variable is created, changed, or checked.
(Private rant - This does not work on built-in buttons; they come with a ton of unneeded baggage.)
If all else fails, and there is no way around single-slide variables, name them using the slide name, which seldom changes, even when the number does.
I would be interested in seeing a couple of slides from this course, to see if there isn't a simpler method of creating the interactions than to use all those single-use variables.
So, if I understand you well, I should make more user of the states of an objects, instead of creating new variables? That seems indeed a good idea, and will think about when I will create a new e-learning.
I've added a slide with a multiple choice questions. How would you make this one simpler?Hi, Jeroen,
The attached file shows one way to simply the slide. Here are a few of the changes:
- I deleted triggers that showed a Hover state on mouseover. Hover is a built-in state, so it will automatically show. (Here's more info about built-in states and their automatic functions: PRIMER: Take advantage of built-in states | Articulate - Community.)
- I redid the "sidebar" so it is just one object: a shape with text. The "i" icon was inserted while editing the states. That makes it part of the object. (Note: I deleted the extra state and triggers before pasting it into the Normal state. Then I adjusted its color in the shapes Hover state.)
- There's now a T/F variable that toggles when the user clicks the sidebar. That helps control whether the motion path goes up or down.
- For pulsing the "i" icon, I put a copy of it on a layer, so the pulsing happens there. That means the choice buttons only need 1 trigger to make the icon pulse: a trigger that shows the pulsing layer. (This was done to replicate what your original slide does. Personally, I wouldn't pulse that icon every time the user selects a choice.)
I didn't change what happens with the Feedback button. It still shakes if they user hasn't selected their choice. I suggest you consider this alternative: have that button Hidden or Disabled, and then change it to Normal when the user makes their selection. That would make it more obvious that they need to make a selection before clicking that button.
Hello Judy,
Thanks for your feedback! You have some good points!
Will think of them if I need to make some new slides in the future!
Best wishes,
Jeroen
