Restricted Navigation

I have a course that has multiple (7) scenes.  We want to use the default player menu pane to allow users to do 2 things: 1) have a visual representation to see where they currently are at in the course progression, and 2) be able to freely jump back to a prior (already viewed) scene/slide for review, if so desired, and then forward again up to the furthest slide viewed.  However, we do not want the user to be able to randomly jump forward to a scene without going through a linear progression.  Because of this, I have chosen "restricted" for my menu navigation option.

Ok, so all that works just fine.  But then, here's my dilima.

With "Restricted" it seems to not only restrict the menu navigation, but it also seems to disable the default "next" button until the timeline ends.  Although we want the user to go in a linear progression, we want the user to be able to advance forward with the next button at any point of the timeline when they click the next button.  

Reason for this: We have audio voice-overs that present audible information for users who prefer to listen to the information being presented.  We also use the notes panel, which contains the written text of the script for those who would prefer to read the information instead of listening to the voice-over.

For those who choose to turn the volume (audio) off and read the script themselves, they often read the text in its entirety before the audio on the timeline has completed. But then, they are forced to sit and wait until the timeline ends before they can proceed.

We could potentially use the seek bar, which would allow the user to click and jump to end of the time line and then click next... but we really do not want the seekbar (for aesthetic purposes) on our player, nor do we want to create extra "clicks" for the user.

I know I can use variables to add a condition to the next button to prevent it from moving forward until that condition is met. So, I thought maybe I could do the reverse.  Maybe I could create a true/false variable "Proceed" and set the default to True.  Then on the "next" trigger, set the condition to allow the user to jump to the next slide when they click the next button if "Proceed" equals "True". 

Unfortanetly, this didn't work for me.

Then I thought, ok, i'll set a slide trigger to adjust the variable to true at timeline start and then add the condition to the next button to allow the user to jump to next slide if the varible equals true.

Again, this didn't work for me.

I really need to figure out how to achieve a hybrid of using the restricted menu, yet allowing the user to advance to next slide when clicking the next button (even if prior to timeline end).

I know we could set up our own navigation buttons instead of using the default. However, because we want to maintain consistency with our course design/layout/navigation; and because we don't want to give up an of the stage "real-estate" in order to build our own navigation, this is not an option for us.  Default player "next" button it is.

Any suggestions would be greatly appreciated.

Thanks in advance!!

78 Replies
Leslie McKerchie

Hi Linda!

The navigation settings in Articulate Storyline 2 affect both the menu and the player buttons, making it much easier to control the overall navigation for your course. To learn how to restrict or lock navigation in Storyline 2, see this article.

If you would like to see this handled differently, please share your thoughts in the form of a feature request, as our team is checking and tracking those to review for future updates/versions. 

Also, did you take a look at the information Bobbi shared in the workaround in this thread. 

Linda Tromanhauser

Hi,

I just submitted a feature request. I had not seen Bobbi's workaround, and that may work for me.

This is a particular problem for me because I have one slide where the Next button doesn't work at all when the menu is Restricted. I think it's because there are multiple layers on the slide, but haven't been able to figure out the problem. But it stops the learner right there and it's impossible to continue. Definitely a dealbreaker.

Thanks for responding so quickly to my request,

Linda

Adrian Donoso

Hi everyone,

I think I might have found an alternative workaround for this limitation. The Restricted menu option seems to only affect the Next button. So instead use the Submit button to go the next slide.

Here are the Steps:

1. Restrict the Menu in the Player Properties under Menu

2. Hide the Next button in the slide properties and include the Submit button instead

3. Create a trigger that when the user clicks the Submit button it jumps to the next slide

Optional (but recommended)

4. Rename the submit button to something else by changing the Text Label for "Submit button" (number 95 for me)  in the Player Properties

I renamed mine to SKIP but you could rename it to the normal NEXT to avoid confusion.

Hope this works for everyone else!

 

 

 

Adrian Donoso
Adrian Donoso

Hi everyone,

I think I might have found an alternative workaround for this limitation. The Restricted menu option seems to only affect the Next button. So instead use the Submit button to go the next slide.

Here are the Steps:

1. Restrict the Menu in the Player Properties under Menu

2. Hide the Next button in the slide properties and include the Submit button instead

3. Create a trigger that when the user clicks the Submit button it jumps to the next slide

Optional (but recommended)

4. Rename the submit button to something else by changing the Text Label for "Submit button" (number 95 for me)  in the Player Properties

I renamed mine to SKIP but you could rename it to the normal NEXT to avoid confusion.

Hope this works for everyone else!

 

 

 

I tried to attach two images but it wouldn't let me. Here is a screenshot on how to rename the button.

Adrian Donoso

Hi Ashley,

Yes this is true that you will lose the submit button for interactions/quizzes etc. However maybe you can switch the buttons around. Rename the Next button to Submit and vice versa. You can then use the previously named Next button to submit the interaction via a trigger.

I haven't tested this out but in theory it sounds like it should work. If anyone tries it out please let me know!

Thanks!

 

Adrian Donoso

Ashley it worked for me. I have attached a sample storyline file. I renamed the text of the buttons so that they are switched. So Submit became Next and vice versa. I used a multiple choice interaction to check if the button would submit the interaction and it worked. The trigger Submit an Interaction is not restricted by the menu and the multiple choice interaction allows you to go to the next slide.

The only thing that didn't work out was that now the new Next buttom has no arrow ">" and the Submit button does. I tried to set the icon color to be transparent to mitigate this but then it affects the play button too. I decided to simply add "NEXT >" for the text label. Doesn't quite look the same but this is just for aesthetic purposes anyways. If anyone knows how to go around this please let me know.

Thanks!

Adrian Donoso

Oh I forgot to mention that in the Multiple Choice the Submit button is restricted to wait for the timeline to finish. So I would just make the timeline be .1 seconds long unless audio or some other animation is needed in the slide.

I left the timeline run in the Multiple Choice slide run to highlight this point.

Glen Murdock

Have enough feature requests been submitted to get this fixed in future releases?

By 'fixed' I mean something along the lines of "back to the way it was in SL1" or "adding a fourth navigation restriction option that enables the 'next' button but disables the menu until the user has visited the slide." This timeline-based restriction stuff is irritating!

CHRISTINE OMALLEY

Thanks to Emily! 

Thought I was going crazy - having to click multiple times to get the Next button to advance the slide. I'm using Storyline 2 on a new course. Hope they will issue an update to resolve this issue. I used your suggestion to shorten the timeline (on non-audio pages) to by-pass the delay. 

I think this is important for Articulate to fix. Developers can spin their circles trying to figure this out - and time is money :-) 

Yasmine Benamrane

Bobbi, this is amazing! Thank you soooo much for sharing. I have exactly the same issue and didn't know what to do about it. And this really is a big issue when using SL2 as it stops the potential purchasing process of the software until I find a way to solve it. So thanks to you, I applied this solution and it seems to work amazingly! I will also report to the development team to add my stone so they might come back to the SL1 functioning system regarding this topic.

Yasmine