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
Bobbi Bailey

Jill,

You have hit the nail on the head!!!!! I am a happy happy person at this moment  

I am attaching another example that I created (based on your work around), using a couple more slides, so that others can truly see the effect of the restricted menu and the (now) non-restricted next button.  You can rapidly click through the slides using the next button, but until you get to a future slide using the next button, you can not jump ahead using the menu.

I still think the logic change by Articulate is nuts, but at least i have a relatively simple solution to work with now!!! Thank you!!

I am going to post your work-around idea over on this thread, as there were others looking for the same thing.

Thank you, again!

Bobbi

Steve Lyne

It looks as though we're not alone in this.  It seems a bad error in logic for this change to have been made in SL2 (but more than made up for by having the autosave function - Yes!!!).  It is self-contradictory to have the NEXT button rely on the base layer timeline completing but also have the layer function option of pausing the base layer timeline!

I also think there is a bug that sometimes prevents the base timeline from ever completing - Support are looking at that  - maybe the bug is picked up when translating an SL1 project into SL2.

Thanks heaps for letting me know I'm not the only one having this issue.

Bobbi Bailey

Jill,

Storyline is rich with a lot of features, and the ability to come up with multiple ways to accomplish something really is great... it definitely makes the logical brain think and gets the creative mind flowing!  Unfortunately, however, in this case, (IMO) they have taken away our flexibility and are forcing us to come up with work-arounds that are sub-par from a design/development perspective and ultimately reduce the overall effectiveness and value of Storyline itself.

Your work-around worked great, in the fact that it was easy to do and accomplished my immediate goal, but it did not come without a cost.  My course consists of over 100 slides, each now with a blank base layer.  I cannot look at the story view for a quick glance at my slides.  My base slides are 0.25 seconds long, so now the feature within Storyline that auto determines the approx length of the course is returning invalid results, because the actual course timeline now resides in a layer. Just to quickly name a couple things.

These may seem minor, but they are a cost that I have to now pay in order to accomplish something that was a standard feature in a previous version.  Yes, we have the work-around, which I am obviously thankful for, but realistically, it is not ideal and not something we should even have had to come up with.

All in all, Storyline is a very valuable tool in my eDevelopment toolkit... one with a ton of potential to be absolutely great!  I sincerely hope that Articulate evaluates this change (and others, if needed) and corrects what many of us think is a ill-logical change.  I want to see this product move forward, not take step backwards.

Just a few of my thoughts,

Bobbi

Bobbi Bailey

Bobbi Bailey said:

Thanks Rebecca! At least we tried!

I also have submitted a feature request.  Hopefully this will be addressed very soon!


Ashley,

Thank you for the suggestion!  I have actually already done this.  I certainly hope (and encourage!) others who run across this same issue to submit a feature request, as well. 

I am hopeful that the software engineers will take this feedback to heart and change the logic back to the way it was in SL1.  

Bobbi

Bobbi Bailey

I think I have come up with a very acceptable workaround/solution to this issue!!! To quickly 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!

I am now ready to do the "happy dance"!!!

Hope this helps someone else,

Bobbi

jeff jone

Hi Bobbi,

Sorry for the trouble your having, I am experiencing the exact same issue and feel just as strongly about it, programmers seem to be assuming to much with this function hopefully they patch to fix this issue or someone comes up with a easy work around asap. I'll continue to try alternatives and let you know if I find a suitable fix. I opened a post detailing the same issue before I found yours you might check it from time to time to see if someone response with something new. https://community.articulate.com/discussions/articulate-storyline/restricted-navigation-issue-articulate-2

Regards,

Jeff 

Leslie McKerchie

In Articulate Storyline 1, restricted and locked navigation settings only affected the menu. In contrast, 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.

Bobbi Bailey

HI Jeff,

I'm not sure if you saw it or not, but I actually have found a very viable (and actually simple) solution to this issue, which I detail on page 4 of this thread.  Hopefully this will help you.  I am going to post this over on your thread as well, just in case you aren't subscribed to this one.

Best of luck!

Bobbi

Bobbi Bailey

Melanie, Glad this worked for you!

Leslie / Ashley and other staff -- because the solution I came up with is getting "buried in the weeds" of this thread, I have started a brand new thread with this information as the initial post.  Hopefully this will make it easier for users to find when searching and it will be easier for you to link to, if needed.

Cheers to all!

Bobbi

April Hilbert

Since this thread has been inactive for 2 months my response may be coming too late but hopefully it will help for future projects if so. I am dealing with the same thing. I am making edits to several courses that were initially authored in SL1. We started making many edits in SL2 before we recognized this problem (which, I agree, is a terrible logic change. It makes no sense). We had gone to far in our edits to revert back to SL1 for these courses. So I've been having to shorten the timeline down to 1 second on every.single.slide. Very annoying.

We also have several slides with the option of listening to narration or just reading the text. My workaround is this... I place the audio on a slide layer. The audio is the ONLY thing on that layer. If there are other layers, I generally have them set to not hide other layers so that it won't cut off the audio if the others are clicked. That can be case by case depending on what all is on the slide. On the base layer I set a trigger to show the audio layer when the timeline begins. The base layer timeline is set to 1 second. That way, after 1 second, the user can freely click next and the audio is able to fully play. The end user can't tell the difference. Time consuming and a pain in the butt but the end result is the same for me so far.

Hope that helps and I really hope they change this in a future update! I'm kind of regretting upgrading to SL2...