Jumping to previous slide in the slide sequence

That does sound time consuming, Maggie, so I hope there is a better solution!  Have either of you had any response outside of this thread?

If I DO have to add a trigger defining the previous slide,  how do I do this?  I can't find any information, or I'm looking in the wrong place.

Thanks,

t

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:

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!

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.

same problem here....

Hi Mark,

For the "replay slide" trigger and including "play/pause" without the seekbar - you're right, that I'd send you here.   If you need anything else, please let us know! 

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.

Hi Pamela and welcome to Heroes! 

Are we able to take a look at your .story file to see the triggers you've set up? You can either share it here or send it directly to our Support engineers? 

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.

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

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!

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. 

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....

Hi Dirk,

The previous button in Presenter should behave the same way as detailed here. If you'd like us to take a look at your file we're happy to - you can share the presenter package here using the "Add Attachment" button or send along to our Support engineers. 

Oh, and I don't know Bob - but there are many more Terwilliger's in the world than one would imagine! Where's Bob located? 

Ha. Bob Terwilliger. That's Sideshow Bob's full name in The Simpsons. Just hadn't seen that name anywhere else - I thought they'd just made it up. You look nothing like him, if that helps ;-)

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. 

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.

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. 

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.

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. 

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.

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?

Absolutely Karen!

You are welcome to share your thoughts/ideas/suggestions with our product development team here on this subject and any others in the future as well.