Storyline Scenario Navigation with Previous button

Aug 18, 2020

We are building a series of scenarios for Paramedics.  The scenarios are basically linear with decision points that allow the learner to make decisions where we let them see the potential results and then redirect them to the correct decision.  Ultimately never changing the outcome of the scenario.

 

The issue we are running into is with the navigation using the Prev buttons.  The issue is with the Prev. button pointing to the "previously viewed slide" and not the previous slide in the sequence.  There are times when a learner may be trying to move backward in the scenario to review something by clicking on the "prev" button only to find that they are taken to the slide they just came from rather than the slide that was numerically/chronologically before the slide they are on. 

 

The only way we have found to work around this is to manually change the "prev" button triggers to point to a specific slide rather than the "previous" slide.  So we now have to change the default for every slide.  The issue with this is twofold: 

 

1.  The amount of time it takes to adjust the navigation on every slide (some have 100s)

 

2. If we do this and subsequently move this slide in the sequence, the navigation goes haywire.   

 

One of our developers (David) mentioned that it would be nice if there was another innate option/functionality for the "prev" button (or a stand-alone “back” button option) that would naturally take the learner "back" in the navigation rather than the "last viewed" or "previously viewed" slide.  This would allow an easy drag and drop adjustment of slides orientation without constantly changing the triggers.

 

Does anyone have any suggestions/pointers?

 

Example:

 

In the attached example, slides 1.1-1.6 are set using the innate “Prev” and “Next” buttons.  Slide 1.6 is a decision point that navigates to slides 1.7, 1.9, OR 1.11 with the “previous” trigger changed to “jump to slide 1.5” (this is what is causing the loop).  When the learner navigates to slide 1.6 and clicks the “prev” button it returns them to slide 1.5 by the design of “jump to slide 1.5”trigger.  Now, 1.5’s Prev. button returns the learner to slide 1.6 instead of 1.4 since 1.6 was the last slide viewed rather than moving back to slide 1.4 and so on.

 

NOTE:  The menu is not normally visible in the live scenario.  I made it available here for you to be able to see the navigation easier.

 

To create the loop, simply click the “>” next button until you get to slide 1.6 and then click the “<” previous button, and click the “<” previous button again on slide 1.5.

 

https://360.articulate.com/review/content/c51ddaea-a0e3-41ab-89dd-229d7592ed31/review

 

 

5 Replies
Walt Hamilton

Kelly,
You ask for suggestions, and I have some. I suspect you will not like all (or even some) of them, or you may like them and not be able to implement them. Nevertheless, I'm sending them, because they may help you, and I know you are not the only ones with this same problem. Also,I believe, and you may also, that what your developer asked for is not likely to happen soon enough to help you, if ever. So we are stuck with trying to find ways to create that functionality on our own.
Let me start by saying that using Prev and Next is a special soapbox issue to me, and only partially because of the problem you have mentioned. I mainly think that electronic authoring tools give us the ability to take the next step up from books. If we want to give our learners books, we should hand them a paper copy, and then Prev and Next work perfectly for them exactly the way they want and need them to act.
I realize that there are people here on the forum (and other places) that disagree with me. I realize that there are clients that disagree with me. I realize that there are people that agree with me that are doing work for government agencies that will never be allowed to use good design principles, but that is a rant for another day. Still I want to present at least the possibility that well designed projects can get along (maybe even better) without Next and Prev.
In particular, in scenario based training, I think it best that the learners be faced with a true life scenario. Take, for example, a paramedic on a crash scene. If he wants to know more about the scene, he can look around. If he want to know the pt's vitals, he can take them, and if he forgets them, he can take them again. If he missed something in the history, ask again. At any point, he can take an action, whether he has garnered all the info he should have or not. And all this without going forward (Next) or backward (Prev) in time. All options are instantly available.
In view of that, I modified scene 1. My guiding principle with these modifications was to avoid having to use Prev and Next, as they are what is causing the problems. At your discretion, on each slide the learner has the possibility of taking any possible action. (Practically, this will represent a lot of work for you, and may not be possible. On the other hand, not to be nasty, but I don't think Prev and Next are working for you, FWIW.) I put the icons and their triggers on the master, and they can be added to any slide by changing the layout. Each scene would need its own version of the master slide.
I modified the feedback process, putting feedback and the option to try again on the same slide. If there is a need for a multi-step scenario to play out the results of the chosen course of action, I would use layers on the feedback slide (e.g. This happens to your pt. Click (which shows new layer) to see final results (death, lawsuit, etc.)
As an even better option, I invite your attention to scene 2. You would want to change the text inputs for multiple choice alternatives, and add a couple of layers for correct and incorrect feedback. I believe realistically, this slide replaces slides 2 - 12 of scene 1. Your live scenario may contain much more information, even to the extent that this option is not possible, but I will point out that there is no way of falling into an endless loop with this slide, apart from constantly choosing the wrong option.
I don't offer these ideas as a condemnation of you or your design choices, or of anybody else. You may be constrained by circumstances beyond your control, but you described what sounds to me like an untenable situation, and I offer these suggestions as possible alternatives. I also offer them in the interests of furthering conversation on best practices, should anybody else read this discussion.

Kelly Kirk

I just spoke with the developer and he reminded me that we originally had the buttons on the slide and that we chose the next/prev buttons for our mobile users.  The next/prev buttons allow the learners to "swipe" to change slides. 

I can't find a way to set a "swipe" trigger otherwise.  Am I overlooking something?

This discussion is closed. You can start a new discussion or contact Articulate Support.