Jumping to previous slide in the slide sequence

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.

Good points, though I contend that PREV behavior should be author-defined, given that it is context dependent. 

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. 

Hi Terry!

You are welcome to share your thoughts with our product development team here.  

After 3 years, I would hope that they are aware of this issue already, but I will fill out the form and hope for the best.

I have tried to fill out that form multiple times yesterday and today, and keep getting "Whoops. We are having trouble processing your request. Please try again later."  (tried Chrome, Firefox, and IE)

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.

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.

I see what you're saying, but I think a flexible program should be able to handle both these scenarios without jumping through hoops. 

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.

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.

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.

Precisely for this reason. Just trying to learn everything I can about how things might be done better.

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. 

I'm late to the game here, but want to second Bob's frustrations as outlined above. Hard coding each individual slide in a branched course is absurd! Hoping this gets resolved within the product Articulate will be unveiling next week. 

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?

Any update on this this 4-year issue?

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.

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.

Hi Stian -  You are welcome to share your thoughts with our product development team here. I know users have expressed interest in having an 'option' to do what you are explaining.

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

Yes, this will need to be manually set if you wish for something outside of the default behavior. 

+1 for Dirk and Steve's opinion. Hard coding triggers right now on 100 slides and it's a big waste of time. 

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.