Next button is disabled when revisiting a slide which uses the state trigger

Sep 14, 2018

Before I submit this as a bug/feature request, I thought I'd seek feedback from the community.

I believe that all side triggers should be processed when the slide is loaded for the first or subsequent times. I consider the fact that some are processed each time the slide is loaded (and some aren't) to be a bug.

I've created and attached a demo .story file.

I look forward to hearing your thoughts on this.

Requirement

A slide has multiple layers. The learner is required to view all layers before proceeding to the next slide.
When revisiting the slide, they do not need to view all layers again; they should be able to click the next button.

How this is achieved

A trigger sets the state of the Next button to Disabled when the timeline of the slide start.
A second trigger sets the state of the next button to Normal when the state of the 3 buttons is Visited.
Each button that is used to show a layer has a Visited state.
The slide’s “When revisiting” property is set to “Automatically decide”.

Description of bug

When you move to the following slide, then click the back button to return to this slide:
The state of the 3 buttons remains visited.
The trigger which disables the Next button is processed, hiding the disabling the Next button.
The trigger which enables the Next button is not processed, despite the state of the 3 buttons being visited.

Expected behaviour

When revisiting a slide where the “When revisiting” property is set to “Automatically decide” or “Resume saved state” a trigger which assesses the state of multiple objects should be processed.

 

A workaround is suggested here:

https://community.articulate.com/discussions/articulate-storyline/disable-next-button-until-timeline-ends-and-layers-revealed

However, this would require the creation of one variable per slide. The variable would need to be set to true when the next button is clicked and processed before the next button is disabled. These 3 steps are not complex in themselves, but add complexity and potential for error.

14 Replies
Diarmaid Collins

Hi Chris. There are a few methods of achieving this and all are equally valid (one of the nice things of Storyline is the flexibility to achieve an outcome).

The simplest option here might be, instead of programming the slide to change the state of the next button to disabled when the timeline starts, simply choose the initial state of the button as 'disabled'.

And then have the base layer set to “Resume saved state” which should force it to remember that the states have been visited and therefore the next button has been made active.

What is currently happening is that the disabling trigger is being specified upon re-entering, yet your "enabling" is dependant on state changes which will not happen because they are already visited.

I believe the “Automatically decide” only really operates when there has been a user activated trigger performed within a slide or layer - such as button, text input, etc. Otherwise you are leaving it to the file to decide what to do.

Personally, I have found having any interactions/variables dependant on 'states' of objects to be very flaky - someone once pointed out here that sometimes one has to state "when state is NOT normal" to get the trigger happen instead of "if state IS XXXX", which is frustrating. So instead, I do create reusable "Item01_VIEWED" variables and have them monitored when slide timelines start/end. Less chance of buggy errors.

Diarmaid Collins

Hi Chris. If you have created a suite of states for your buttons, and have a style in mind for the disabled state, then from the states panel, select the Disabled State from the Initial State drop down panel.

I'm not sure about the attendant swipe gestures but I imagine they are attached to the buttons active/inactive states, so all you have to worry about is what triggers the 'activation' (non-disabled state) of the button.

Disabled state on button

Chris Reynolds

Thanks Dairmaid. It looks like you're creating your own buttons rather than using the built-in Next, Previous and Submit buttons.

Since the addition of the "Modern" HTML5 player, I've been using the built-in buttons as they respond to different screen sizes and allow swipe gestures for navigation.

Sorry if I'm sounding negative. I very much appreciate your responses. I will echo your earlier statement about states being flaky. I've found that they've improved to the point where I trust them enough to dispense with the mess of variables that I used to use, but these small gremlins do still rear their heads from time to time.

Chris Reynolds

On the contrary: you've been very helpful. Conversations like these are evidence for Articulate of the lengths we need to go to to get courses looking and working.

One of the things that kicked me back to using the built-in buttons was the introduction of text-to-speech and closed captions. All our courses feature this now, so we need a button to turn CC on and off as well as a volume slider. The UI buttons for these are positioned under the player and so my custom buttons looked odd, positioned vertically higher than the others.

The arrival of the Modern player brought minimalist, contemporary buttons for CC, volume and navigation. I've submitted a feature request asking that we are given the ability to change the built-in graphics with our own, in a similar way to how we can change the text labels today. I'd be very happy if I could change the Modern buttons for ones which match our brand!

Leslie McKerchie

Hi Chris,

Thanks for sharing such a great sample for us to take a look at.

You can still accomplish the design you're looking for by simply adding one more trigger to your slide:

So, no variables needed and it takes care of re-visits to the slide :)

Take a look at your updated file attached.

Patty Maher

Question related to this. I want users to view slides completely before moving to next slide. To do this, I added triggers on the master slides to set NEXT to disabled when the timeline starts and normal when it ends. This works, however, on revisiting slides I'd like them to be able to click NEXT immediately.  Based on this discussion, I was thinking I'd add a new trigger that sets NEXT to normal with the timeline starts on the condition that they have already clicked the NEXT button before. Is this reasonable or possible? I can't see a way to do it.

Alyssa Gomez

Hey, Patty!

It sounds like restricted navigation is the perfect menu setting for you. This setting disables the Next button until the timeline ends, but the Next button will remain enabled if you go back to a previous slide. 

You can turn on restricted navigation by clicking Player >> Menu >> Additional Options (the gear icon).

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