SL2 & SL360 "Restricted" Menu Navigation and Next Button - Solution / Workaround

Many developers are having an issue with the new "restricted" menu navigation logic in SL2.  I have come up with, what I think is a very quick, simple and viable solution.  To re-cap the issue:

  •  In SL1 the Menu Navigation options include “restricted” which allows learners to view the current slide and any slide they've previously viewed, but not use the menu to jump ahead or skip over slides.  This only restricts the learners' ability to click on menu items to navigate. If the slides included a Previous or Next button, users can still be click those to freely move forward and backward in the course at will.  Content developers could add triggers/variables to control the previous/next buttons, as they saw fit.
  • In SL2 the Menu Navigation “Restricted” logic was changed.  The restricted option still allows learners to view the current slide and any slide they've previously viewed, but not use the menu to jump ahead or skip over slides.  However, this now also disables the Next button and does not allow users to advance forward until the timeline ends.  Triggers/variables do not work to over-ride this logic change.

Here’s what I have come up with:

  1. Create your .story project and set the navigation menu options to “Free”.  This will ensure that the next and previous buttons are not restricted.  (Don't worry, we will adjust the menu navigation itself in a bit).  If needed, go ahead and create triggers/variables to control the previous/next button navigation as desired.
  2. Publish your .story project.  Go ahead and “zip” if the course will be uploaded to an LMS.
  3. In the “publish successful” pop-up window, click “OPEN” to open the Storyline output directory.
  4. Double-click and open the story_content folder.
  5. Open the frame.xml file (this can be opened with Notepad)
  6. Find and replace the following:
    <option name="flow" value="free" />
    with
    <option name="flow" value="restricted" />
  7. Save and close the frame.xml file.
  8. Launch and play your course.  The navigation menu is now restricted, but the previous/next buttons can be used at will.  (Any triggers/variables that were added to control the previous/next button navigation should work as developed.)

If uploading to an LMS, you have a couple more steps.

  1. In the file directory, right-click and "copy" the modified frame.xml file.
  2. Navigate to the story_content folder in the ZIPPED file.
  3. Right-click and "paste" (replace) the modified file here.  You can now upload to your LMS.


This seems kind of tricky, but it is actually very easy!  And once you’ve done it a couple of times, you will see that it literally only takes a few seconds to do!

Hope this helps,

Bobbi

Addendum for HTML 5 (added 10/11/2016)

If publishing to HTML 5, the frame.js file must also be changed.  This can be done by following the below steps.  (NOTE: These steps must be done prior to uploading to LMS, if launching through an LMS.)

  1. Open the frame.js file (recommend opening with Notepad)
  2. Find and replace the following:
    |free|
    with
    |restricted|
  3. Save and close the frame.js file.
192 Replies
Kevin Thorn

Hi Angelia,

First, to understand your setup, are you using the default sidebar menu or custom menu with your own buttons?

If using the default sidebar menu you could set up a couple variables to determine "QuizAttempt1" and "QuizAttempt2" as True/False variables. 

When the user accesses the quiz the first time, QuizAttempt1 is equal to True. If in your scenario the learner misses 4 questions, add an additional trigger to change QuizAttempt2 now to True when they start the course over. Then, if the learner clicks the menu to go to the quiz immediately add one more trigger on the opening slide of the quiz (perhaps showing a lightbox or popup layer) that says (on the condition QuizAttempt2 is True), "You cannot access the quiz directly. Please go..." or something. 

It's harder to do this with the sidebar menu because we don't have access to those triggers (or states). If it's custom menu, you'd have complete control and it would be easier to setup.

Hope that helps a little.

Vickie Burnett

I am just getting started with SL2, but have worked a lot in Captivate 8. This issue of the Next button advancement being tied to the restriction of the menu has messed me up. In Captivate 8, those functions were handled separately.

I played with a few slides to see if I could keep the restricted menu functionality while allowing the Next button to be tied to the user's click instead of the slide duration. To do this, I deselected the Next button from the slide properties for the play bar. Then, I created my own Next button and put it on the slides. This seemed to work just fine.

Christie Pollick

Many thanks for touching base and sharing what worked for you, Vickie! I'm sure that information will he really helpful to others who come across this thread seeking assistance.

And if you'd like to share you thoughts or ideas for functionality you'd like to see if the future, you are welcome to share with our Product team via this form. :)

Tina Arcamo

Hi,

I followed Bobbi's hack and it worked. However, when the learner revisits the entire course, it remained in 'restricted navigation'. Is there a quick way we can revert the navigation to 'free' when the course has been revisited? I do not want to create customized Next button from the Slide Master  because I have triggers that makes some slides jump to other slides or scenes when the Next button is clicked.

Thanks.

Chris Barnett

Thanks for this work around!

For those of us less comfortable getting into the programming files, wouldn't it also work to go through and simply shorten the timeline of slides to, say, 0.5 seconds?  This would allow the learner to click "Next" whenever s/he is ready to move on.  For slides where viewing animations, layers, etc. are crucial, the timeline can be extended.  

Am I missing anything here, or might this also work (especially for smaller projects)?

Alternatively, would this be a potential "fix" to this "problem?"  If the change was made with SL2 to accommodate some requests (but at the frustration of others), perhaps SL3 could include a default minimum-timeline of 0.5 seconds instead of 5 seconds (or, better yet, the ability for a designer to define and apply the minimum-timeline of his/her choice).

Christie Pollick

Hi, Chris -- Thanks for reaching out, and I will defer to your fellow community members to share more specific recommendations. 

Also, I wanted to note in case you weren't aware, if there are any features or functionality you would like to see made available in a future release, here is the form you would need to connect with our Product Development team. :)

Bobbi Bailey

Chris,

Unless you have a perfectly flat project (no audio, no animations, no transition timing, etc), then unfortunately, your suggestion will not work.  Storyline automatically sets your timeline to the length of the object (if you have a 20 second audio file, then by default, that slide would have a 20 second timeline), and this cannot be overridden.  So therefore, the user is forced to sit through that entire 20 seconds.... which is what we don't want them to have to do.

The logic was correct in SL1 and the Next button operated independently of the timeline.  But (for some reason that none of us can seem to figure out!), in SL2 the Storyline software engineers changed the logic and are now forcing the Next button to be dependent on the timeline.  The "fix" should be for the SL engineers to return the logic back to the way it was in SL1, where the Next button and Timeline worked independently of each other.  With this, the course designer has the flexibility to control whether they want to the user to sit through the entire slide, halfway through, or only 0.0001 seconds worth of it.  How the timeline operates should be at the discretion of the course designer.

Ashley Terwilliger

Hi Bobbi,

I know that this has been a topic of discussion since Storyline 2 came out - but I wanted to reiterate here that the change in the behavior was based on users feedback that setting the menu had no effect on the next button and users could still skip through the course fairly quickly. And it was extra work to add in the conditions to the triggers and prevent them from doing so. It seems from this thread and others there is still a group that would prefer the old set up so although we continue to share that sentiment with our teams, the best course of action is to also submit it as a feature (which I suspect you've done, so sharing as a reminder for others). 

Bobbi Bailey

Ashley,

Yes, I have certainly submitted a feature request.  :-)  My response was geared toward Chris' suggestion that we set the timelines to 0.05 seconds.  While it is possible to do that if you have static/flat slides, but it is not feasible to do if you have any audio or animations on your slides.

Vickie Burnett

My problem is that in our courses, we want to force the students to listen
to the entire side, yet have the ability to review previous slides without
being allowed to jump ahead. Combining the functionality of the system Next
button with Menu restriction makes that impossible...either the student
cannot review previous slides using the menu or he has complete access to
the menu and the ability to jump to the next slide without completing the
content on that slide. I didn't want to have to alter the SCORM coding, so
that is why I created the workaround for this type of situation.

Ashley Terwilliger

Certainly Bobbi - and I appreciate the workaround you shared here. I was mostly responding to this portion: 

The logic was correct in SL1 and the Next button operated independently of the timeline.  But (for some reason that none of us can seem to figure out!), in SL2 the Storyline software engineers changed the logic and are now forcing the Next button to be dependent on the timeline.  

To clarify that there was a reason and rationale, as it was previously explained (and now buried a bit) earlier in this thread. 

JTS Admin

Ashley,

Clearly you had a rationale, but the engineers made a wrong decision.  Nothing should be forced, you could easily have given designers the option to tie the next button to the timeline.  A variable could then be used to determine when the next button should be tied to the timeline and when to bypass.

Ashley Terwilliger

Hi Malissa, 

If you're referring to Bobbi's initial work around, I can't offer support for any changes to the published output - but you may want to confirm that you're also testing the content within an intended publish environment so as to not encounter security restrictions as detailed here. Also, please make sure you're testing the content in an HTML5 supported browser.

You may also want to look at posting your work here so that folks in the community can take a look and weigh in on your set up. 

Ashley Terwilliger

Hi Rabbil,

I'm glad to hear that Bobbi's workaround assisted you - and as you can see from this forum discussion that multiple users would prefer it didn't work as it does now in Storyline 2. It's worth noting that this change was the result of user feedback as they wanted to be able to restrict or lock down the course as a whole, not just the menu as it was previously. You're encourage to also share your thoughts and feedback here. 

Chris Barnett

I'm so glad I subscribed to this thread, as it is one of the few with three pages (!!) of continued comments, spanning more than a year.  What I'm hearing is that the changes were made to SL2 to accommodate one set of comments, but that other users don't appreciate the new functionality.  Perhaps if we all use Ashley's link to share THOSE comments, too, the next iteration will provide the OPTION for DESIGNER'S to decide what is locked independently of one another.