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
Walt Hamilton

I'd like to open a discussion, not start an argument, but I think that a majority of designers probably have reasons for expecting PREV to jump to Previously viewed.

 

1. Thinking like a user: How is the user to know what is the previous slide in sequence if they didn't just come from there? If they don't know what it is, why would they want to jump to it? If they can see a menu, why can't they use the menu to go there? Aren't most of our users more practiced at internet use, thereby expecting internet-like activity, rather than a jump to  (what has to appear to them as) a non-visited location?


2. Thinking like a designer: If there is an educationally sound reason for Slide B to be previous to slide C, then the user comes to C from B, and B is the true previous location. In reality, I am enamored of SL's ability to permit me to create learner-centric sequencing, whether it be driven by deliberate choices, or the result of user actions. What that means to me is that I am not married to the idea of a certain sequence of slides, lacking a compelling pedagogical reason for a sequence. For example, if a user's learning experience is not damaged by them visiting slide C before slide B, then B need not be considered previous to C.
Example 1: User must visit A, then both B and C (in the order of their choice) before going on to D. On A, they are given the explicit choice for B or C, or their actions determine which is next. If C is visited first, they have a choice to go back to A, or forward to B; if B is first, the choice is back to A or forward to C. My point is that just because B is previous to C in my mind and/or naming convention, forcing (or expecting) them to click PREV to visit the location they haven't yet visited seems to have a pretty tenuous pedagogical foundation.
Example 2: The user can go from A to either B or C before advancing to D, or optionally maybe even advancing directly to D. In this cased B and C can be considered as equal options, rather than sequenced locations, with one prior to the other.
Example 3: The user has the option to advance from A to B for more information (which they may or may not already know) or advance directly to C where they need to use that information. On both A and C they can be given the option to visit B, but neither NEXT (on A) nor PREV (on C) is a good option for that choice; surely the choices would be More Information, or Continue Forward.


Just my .02, but whenever I think of PREV acting in a strictly linear fashion, I think I should probably put in a feature request for it to retain the flexibility we need for learner-centric sequencing.For me, it boils down to this: If it is a true previous, make them go there first; if they don't have to go there first, don't call it previous, either in on-screen text or triggers.

 

P.S. I understand that much mandated compliance training throws out all common sense and educationally sound principles. If it's mandated, you gotta do what you gotta do; I'm addressing developers who have choices.

Terry Bell

It seems to me that the function you are describing is a "back" button on a browser.  

Since the default target of the "Next" button is the "Next" slide in the sequence, then I believe the "Previous" button should, by default, go to the "Previous" button in a sequence.  These two buttons should counter/complement each other.

That's my 2 cents, but it also seems to be the preference of the overwhelming majority of people who have replied to this thread.  I wish the developers would see that.  I feel like they painted themselves into a corner by making a mistake early in the design, and can't admit that they were wrong. 

Leslie McKerchie

Hi Terry!

I just took a look and I seem to be having some difficulty as well when I tried in Chrome, but was able to successfully send via Edge.

I will share with our team and in the meantime, you can share your thoughts via support@articulate.com and put Feature Request in the title so that we can manually classify it for you. 

Sorry for any inconvenience.

Walt Hamilton

I guess my point is that it is not the physical next and previous slides in the sequence (which is what it seems like most of the people in this thread [admittedly a pretty small sample] seem to be asking for), but the logical next and previous. I think of it not as  "Which slides were created before and after this one?"  that the user is asking, but "Which slide did I just visit, and which one should I visit next?"

Of course, you have to understand that I think user-centric sequencing is a HUGE aid to actual learning, while program-centric (forced) sequencing can at times actually impede learning for certain learners in certain circumstances.

Karen OBrien

Yup - I second that. Obviously there's a case for both scenarios so there should be a trigger for both methods - something like 'jump to previous slide in sequence' and 'jump to previous slide visited' - this is what I submitted in my feature request so fingers crossed the powers that be will resolve it soon.

Walt Hamilton

Somebody please make the case to me  why a user would want to, or should want to go back to a 'previous' slide they have never visited.

I can see somehow sending them there as part of moving forward, but the term previous somehow seems to imply that they have or should have already been there.

Don't worry, I'm not not going to make a feature request to maintain the status quo; I never use the Previous or Next buttons. Instead, I am really sold on letting context determine the best methods for advance.

Terry Bell

In my case, we have to have numbered slides.  (fought that battle and lost)

So I look at slides 1-6, then realize I want to review something in slide 4, so I use the menu to get there.  Once on slide 4, I realize that I want to look at slide 3.  "Previous" should get me there, but the default behavior is that it will jump me back to slide 6.

It seems you have more control over the structure of your courses, but not everyone has that luxury.  If you don't have to use the next and previous buttons, then I'm not sure why you are concerned about what they do.

Ashley Terwilliger-Pollard

Thanks all for the continued lively discussion here around this set up - this is exactly the type of feedback and understanding our product team is looking for when we go through feature requests. This type of conversation is helping us understand the pain points vs. statements on what you'd like a feature to do - as the former helps our team to work through multiple scenarios and options for changing the behavior instead of modifying for a single outcome. Thanks again for continuing to share here and by submitting the feature requests. 

Ashley Terwilliger-Pollard

Hi Kathy,

Just to clarify - you'd need to hardcode it if you want the user to follow a particular path back, otherwise they'll be brought back to the last slide they saw. This is the behavior as designed in Storyline 2currently and operates similar to a browser back bar. Without seeing the branch set up you have, it sounds like the user could choose to go in a number of different directions, and if that's the case, allowing them to choose to just go back to what they saw before it would keep them within the branch that they choose?

Leslie McKerchie

Hi Ferdi and welcome to E-Learning Heroes :)

You can set the trigger to jump back to the slide you wish on any slide, but the built in functionality (just like a web browser) will take you back to the slide you previously viewed by default when set to previous slide. I do not have an update on that functionality if that's what you were asking.

Stian Larsen

I too have to agree here! Just noticed this today, and I have to redo all previously made content because I did not know that the prev-button worked this way!

A browser is not an e-learning tool! In a web-browser, you want to go back to the previous page when you hit back. But in an online course, you want to go "back one page/slide" when hitting back.

Take a normal physical book for example. If you sit down and open the book, you open the book on page 42. If you now go "back one page", you would expect to see page 41. Not the front cover again! :P

Are there really no other way to do this? I can't simply hardcode this for every single page! Not only is that a lot of extra work, but the whole idea of using a template/slide master for custom next/prev buttons will not work. So if I the wanted to change the position of the prev button, I would have to revisit ~100 slides and move it manually, instead of just once in the master... hmm, not good at all!

EDIT: My course is not forced. The user can jump in at any place. But once there, the user should be able to go to the previous slide in the chapter. I can't hardcode this, as it would not be a good way of making our courses.

It's not called a back button, it's called  a previous button. Back takes you back to where you where, previous goes one page/step/slide back in a hiearchy.

Stian Larsen

Thanks, I will :)

Does this mean there are no way for me to do this with a trigger? I Have to go over all my previously design courses and hard-code each and every back-button to point to the previous slide in the sequence? Not only that, but I will have to paste the back-buttons on every single slide, instead of in the master? And if I want to change the "previous page" button, I'll have to change it in about 128 different slides, just for this one project?

If so, autch...

Marc Lee

My experience with SL suggests looking at this issue in a different way:  it shouldn't be a matter of what one developer or another 'expects' to happen when a Prev or Next button is clicked.  To me, it's a matter of a) either keeping your project very simple and linear (so that the user is always or nearly always on the slide right after where the Prev button will take him or her -- that is straight linearity) or b) in projects with a lot of branching and complex structure - certainly part of the appeal of SL -- make sure you know to a certainty exactly where the user would expect to go from his or her position anywhere, -- quiz, background, different scene, etc. -- in the project.  So no matter what cul de sac the user found him- or herself in there would be a perfectly logical nav no matter which button is clicked.  This way the user would never find they are lost in hyperspace with no idea how they got there.  One solution would be to use a custom menu so that the user can always return to a known point from any location in the project.  This would require a custom menu button but this of course could go on the master so it doesn't require triggers on every slide.  In this type of project, the built-in Prev and Next buttons might not be appropriate at all.

Just my $0.02 worth.