Restricted Navigation
Oct 14, 2014
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
Jill,
Somehow, I missed your response when you posted it (I think you and Mike posted at the same time, so when I jumped directly to the bottom of the page, his was what I saw). I will take a look at your suggestion now and will let you know what I find.
Thanks!
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
Great workaround Jill...thanks for sharing it
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.
Thanks for the update Bobbi!
Glad you have fund a workaround for now.
Steve, I am linking your thread here for any updates you have to share from QA and support.
I agree. This change in logic from SL1 is a show stopper for us. I am relieved we waited to upgrade at this point from SL1. When Articulate fixes this in SL2, we will upgrade. Feature request sent.
Bobbi - it feels great to find a solution to a vexing problem!
One thing I love about Storyline is that Articulate had built in so much flexibility, which allows us to come up with these workarounds.
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
Hi Bobbi,
I'm glad that the workaround here worked for you - and if you'd like to see a different design or behavior within Storyline, it's also a good idea to share your thoughts directly with our product development team in the form of a feature request.
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
Thanks Bobbi for sending that in - and I'm hopeful as well that there will be additional options included for navigation based on users input.
I think I have come up with a very acceptable workaround/solution to this issue!!! To quickly re-cap the issue:
Here’s what I have come up with:
<option name="flow" value="free" />
with
<option name="flow" value="restricted" />
If uploading to an LMS, you have a couple more steps.
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
Thanks for sharing Bobbi!
this works great! cheers!!!
hopefully Articulate is considering a feature request in UI to provide option to manage logic behind the "restricted" for the non-techies in the audience.
this was a show stopper for us too w/ SLv2. thanks Bobbi for getting our show back on the road.
Make sure you share those thoughts here Melanie, so that our development team will know :)
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
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.
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
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
Thanks Bobbi for starting that one out! We'll be able to point directly to that one now. :-)
This post was removed by the author
This is especially a pain when you forget to "zero out" the timeline on slides that don't have any audio or include a seekbar. The user clicks Next and nothing happens without any explanation.
Will,
After quite a bit of hair-pulling and cussing, I finally came up with a solution that is actually quite simple and effective. I started a new thread on this, which can be found here.
Hope this helps you,
Bobbi
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...
Hi April,
Please also 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.
This discussion is closed. You can start a new discussion or contact Articulate Support.