Jumping to previous slide in the slide sequence

Choosing "Previous Slide" as an option in the "Jump to Slide" action takes you back to the slide that you viewed last and not to the slide previous to the current slide in the slide sequence.

I have created a menu of slides in my story which pops up in a lightbox and allows a user to jump to any slide in the course. Once a slide is chosen from this menu, I would like the Previous button to take us back to the slide which is just before the current slide in the slide sequence and not to the slide that we were viewing previously.

The "Jump to slide" - Previous slide takes us back to the slide that we came from which is not what I want.

Is there any generic way to go to the Previous slide the way I want it to be. I have custom Next and Previous buttons the Slide Master and would thus want to use some generic logic to go back to the Previous slide in the slide sequence.

Also, I also have a Replay button on my slide master which needs to be able to replay the current slide from the start. I am able to achieve the replaying by using a "Jump to Slide" and using the current slide as the target. The problem is that "current slide" is different for every slide so to be able to put the Replay button on a slide master, I need a generic way of replaying the "current" slide. As of now, I am copying the Replay button to every slide and then editing the trigger to set the slide to go to - to be the slide on which the button is.

So is there any generic way of replaying the "current slide"?

Thanks in advance for your help.

Paul

66 Replies
Peter Anderson

Hi Terry, 

You would do this in the trigger wizard. The "Previous Slide" option will indeed take you to the last slide visited rather than the slide that is before it in sequential order. To jump to the previous slide in sequential order, you'd need to select that specific slide in the trigger wizard. Something like in the image below:

Terry Bell

Thanks Peter,

I think I didn't see this issue because I had turned off the slide navigation controls.  I guess I'll have to either turn those on, or use a 'jump to' on each slide.  (I had some in my master slide, but it has the default "previous slide" behaviour.)

I'll get back at it, and thanks again for the response!

Mark Marino

I'm hitting the same issues.  I have custom Next/Back buttons on the slide master and the Back button just jumps back to the beginning of the current slide instead of jumping to the previous slide in the sequence.  I guess I could just put hard-coded "Back" buttons on each slide of the course, but that's less than optimal. 

I was also hit by the lack of a "Replay Slide" trigger action. I am eschewing the built-in seekbar and navigation buttons in lieu of my own custom buttons and I wanted to have a "Replay Slide" button, but no luck. 

My Spidey Senses say there's about to be a reply suggesting we visit the New Feature Request page.  

While we're there, would also suggest allowing "Play/Pause" and "Replay" buttons be allowed to be toggled on/off without having to show the "Seekbar" in the Player controls.

Pamela Dyckhoff

Urgent help needed please.

I am not as savvy as most of you when knowing what all of the non-intuitive triggers cana nd cannot do...yet!

However, I have a deadline (Monday by EOB) and I am completely stumped!  I have read through EVERY post about slide jumping, have tried various suggestions that were posted...and nothing is working.

I have a feeling it has something to do with the 2 arrows underneath of the Engage-like feature (slide 1.22). 

After the learner completes the knowledge check on slide 1.21 it jumps all the way to slide 1.36...instead of advancing to slide 1.22.

If anyone is on the forum today, could please offer your experienced advice?...and also help me understand what I did wrong so that I do not do it again?  )       Thank you so very much!!!  (In the meantime, I will be rearching for other answers within th forum discussions for trouble shooting.

Edie Egwuonwu

What if you want to renumber your scenes? I imported another Storyline into an existing one. Essentially I have an entry point where the learner selects a branch and then sequentially should go 1 to 2 to 3 and so on within their branch. By importing the new content my number is now all out of whack. I wouldn't care but it seems to affect the order the content appears in the left-hand nav and I can't have that.

There HAS to be a way but I'm stumped.

Rebecca Fleisch Cordeiro

Hi Edie,

Here are two things that might help:

Support article link: How to change the scene order

Regarding the left menu, you can reset it from the story by clicking the Player button (Home tab, Publish group)

When the Player Properties dialog box opens, click Menu (highlighted in yellow in screen shot)

Then click the Reset from Story button (see callout in screen shot)

Please shout out with any questions

Dirk Manuel

I'm sorry, but that's just stupid.  If you hit the 'Prev' button twice, you are now stuck in a loop, which makes NO SENSE on any level.  And having to hard-code the branching on every single slide is ridiculous (and will need re-adjusting every time you insert or delete a slide).

I (like one of the posters above) have suppressed the built-in buttons as I have custom buttons on the slides (not my choice, but that's our standard, as the PowerPoint is used elsewhere outside of Articulate). Most of these have hyperlinks of "Next slide" and "Prev slide", which works fine in PowerPoint, but now, once I Articulate it, Articulate screws that up as described above. So I have to go and set the branching on every slide, even though I have disabled the Articulate prev/next buttons, which is absurd! 

Please fix!

Ashley Terwilliger-Pollard

Hi Dirk,

This thread is a bit older, so I'm not sure I'm understanding the post here in the context of your situation. The Previous button on the player by default acts as a a browser back button would, so that it'll take the user back to the slide they saw last. It's hard coded that way, and you won't see the trigger embedded for it but you can always add your own triggers to each slide to change how that works.

In regards the previous/next buttons appearing they will appear on a revisit to a slide as described here. 

Dirk Manuel

Ashley (any relation to Bob?):

Thanks for the reply. I'm using Articulate PRESENTER 13 (maybe that's where I'm going wrong - I just googled my issue and it sent me to this page, which I now see is a discussion for STORYLINE. Either way, I see what I described above. Which certainly does not act like a Browser button because I get stuck in the 2-slide loop, like I mention...  Maybe I'll repost this to the Presenter forum....

Ashley Terwilliger-Pollard

Haha - ok, so now I know I need a break, as I reference that all the time, obviously in the family we just call him Sideshow. ;-)  It's always my interesting fact - as we do have semi similar hair and it was one of my many nicknames in college. ;-) One of the writers of that show is from near where I grew up and it's actually an oddly common last name around there. 

Dirk Manuel

Yeah, it is behaving 'as designed'.  My point is it is not behaving 'as desired'....  (or as logical). I understand the 'working like a Browser does' argument, but that's not really what one would expect (not me, and not the other posters on this thread) - and is actually inconsistent in itself.  For example, if I select the following slides from the Outline: 2, 4, 6, 8, and then press the PREV button 3 times (from Slide 8), I will go through: 6, 4, 2. Which is what you said would happen.  But if I then press NEXT 3 times (from slide 2), I go through 3, 4, 5.  So, in fact, nothing like how a browser works!

Now, I can see the argument that developers may choose to have their Slides in the presentation displayed in a different order in the actual Articulate Player, so having the PREV button go to the 'previous slide viewed' would make sense. But I would counter that this is probably by rare exception, and if a developer specifically wants to do that, they can go and proactively update the branching in Articulate (as you describe) to facilitate this.   But I would suggest that in the vast majority of cases (and certainly in the several hundred presentations I have worked on (and lord knows how I never noticed this until today...)), the average developer would prefer the PREV button to take them to the 'previous slide in the outline'. As logic suggests. 

And again, expecting 'most' developers to go in and change the branching just to make it work this way is prohibitively burdensome.  Your product is sold as a "rapid e-learning suite'. Given this, I would expect the whole process (of presentation creation) to be streamlined to the fullest extent possible (and as close to a single mouse-click as possible).

And even if we accept that Articulate is going to work the way you describe (which I don't like, but it's your product), for Articulate to basically override my custom on-slide buttons (which I have specifically created to send me back to the previous (physical) slide), to work the way your own buttons (which I have specifically disabled from my presentation) do, is flat out wrong.

Ashley Terwilliger-Pollard

Hi Dirk,

Sorry for the delay - but wanted to come back to this with fresh eyes and fully caffeinated. :-) 

I'm not a coder or programmer by nature or within my role here at Articulate - but I understand what you're describing in terms of how you'd like it to behave. Without seeing your file, or having our team take a look I wouldn't want to weigh in on the order you're seeing of jumping from 2 back to the 3, 4, 5. You also mentioned your on screen buttons being overriden - and if you've set those up as hyperlinks on the slide itself those buttons should work independent of the player buttons. 

Perhaps it's worth sharing your Presenter package with our Support engineers here so that we can take a better look and just confirm that we are on the same page? We can then also use that information as a part of the feature request to change the intended behavior based on what you've share here and how you've set it up. 

Steve Covello

I second Dirk's sentiment here, from a UX experience. The logic behind Prev = last slide viewed is misaligned to conventions. I'm in a situation where I can't enforce sequential navigation, so there is a potential for trainees to become terribly disoriented, which negatively impacts their affective experience in our training program. This is REALLY BAD since the problem is not caused by us (the developers).

If this behavior can be developer-defined, it would end this issue to both camps' satisfaction.

Leslie McKerchie

Thanks for sharing your thoughts as well here Steve. You are always welcome to share your thoughts with our product development team here.  

You can set hard triggers to control what the Prev and Next buttons will do if needed or even restrict navigation to prevent your users from getting disoriented as you mentioned. 

Steve Covello

Leslie - Thank you for the response. I have gone the manual trigger route with this situation, but it is not optimal. Restrict Navigation is only relevant here if the trainee goes through the process in order. Since this is a compliance "must do" activity, there is always the risk that they will want to skip some content, or skip to the end. This would impact the PREV behavior, as described.

Karen OBrien

Hi, I second the opinions of Dirk and Steve. I'm guessing that most people in the storyline development community would expect the 'jump to previous slide' trigger to go to the previous slide in the sequence (and not behave like the 'back' button on a browser).

It is definitely not optimal to have to use the hard-coded trigger - i.e. 'jump to slide xx' on my custom previous button. The reason being if slides are added/removed, this trigger has to be manually updated each time which is quite frustrating.

As an elearning developer who has been in the industry for over 10 years, I'm used to having the previous button in my elearning courses (whether they be built in flash/html) automatically jump to the previous page in the sequence. I'm really not a fan of hard-coding in this situation - it's quite clumsy to be honest. Is this something that could be a feature request?