Variable Playback Speed

+1 for this feature.

There are two clear use cases for students:

1. Those that like to run through things quickly (as mentioned in earlier comments)

2. People who are taking a course in a different language and may need the audio slower

I have regular requests from both of these audiences.

I would also support this feature being implemented 

We really need this feature.  +1

Adding my vote for this feature as well. We have non-interactive videos hosted on a platform that supports different playback speeds and as we add interactive content it's going to be a glaring difference between the content types.

I include my vote for video and audio speed playback variability.

Please implement this feature! We recently switched from BrainShark to Storyline, and we've gotten a number of complaints about the lack up ability to change playback speed. In general, Storyline offers far more features than BrainShark did, but from users' point of view, they lost a capability that they used to have.

We are continuously getting this request from our customers and students. So this is another vote for variable playback speed.

Hi Michelle,

I figured out a way to control video speed using JavaScript. Please look at the attachments to see how this can be done.

FYI: This controls the speed of the video, not the timeline of the slide, which means if you use this AND have the Seek bar in the player, these will get out of sync with one another. Maybe you could "bake in" the transport controls into the video itself, and NOT use the Storyline Seek bar, to get around this issue. Still, if Articulate could use this code somehow underneath and tie the Seek bar to report video progression, then we would have something!

Mark, That is a clever workaround for inserted video. But yes, to your point, it would be best if they could code it in and tie it to the actual speed of the timeline of the slide.

I think this should be viewed as two different tasks: enabling variable playback speed for audio (i.e. the whole Storyline e-learning) and enabling it for embedded video.

Variable playback speed is now standard for video. These days, it seems that almost nobody views a video at normal speed unless their viewing the video for entertainment. Rise has variable playback speed for embedded video, Articulate Review has it, why doesn't Storyline? It would seem that Articulate is behind the curve there.

Enabling variable playback speed for the audio, or for the whole e-learning itself, seems to be a much bigger ask. I haven't seen such capability in other eLearning tools.

If the embedded video has variable playback, then that could also be a valid option for those who want to speed up the whole eLearning. People could publish their Storyline content as video and then embed that video in the Storyline slide or slides, thereby providing a similar experience than if the audio could be sped up.

So I think the first priority, and probably the less difficult ask, is to provide variable playback speed for the embedded video in Storyline.

At least one  professor at my college has requested this on behalf of students.

+1

Dave, would you be able to show us how you would do this?  Or point me in the direction of a guide?

Thank you in advance!

I would also like to add my vote to add this functionality. Accessibility and learner preference are both key arguments presented that I agree with. Thank you.

Add my vote.

Our audience is very much in favor of this feature!

Hello, I'd also like to add my comment as my official vote to request that Articulate Storyline 360 include a feature of allowing the learner freedom to choose their own playback speed (increase or decrease) per their learning preferences or for their accessibility needs. 

It's absurd that Storyline doesn't have this. 

+1 on this

We get lots of comments from students that have good reasons for needing this feature.  It's so common across online multimedia that it's fully expected by people now - please get this done!

I've now gotten my first request for this. Please add this feature.

They're going to want you to request the feature this way --> https://articulate.com/support/contact/feature-request

Thank you for your advice. I submitted a request for the feature. I had to
hold back on using Articulate storyline solely because of this one issue. I
can't understand why Articulate is so behind on this issue, especially in
light of the data supporting the benefits of using variable speed.

As Mark states at some point in this discussion, there are 2 parts in Storyline that both would benefit from giving the user the possibility to setting the speed. Videos and the timeline.

For videos there are several options with other players or Javascript to get it done.
For the timeline there is at this moment no option. However as Articulate uses GSAP internally to do almost everything animationwise, i strongly believe they use it too for the timeline.
And especially i suspect they do use the timeline feature of GSAP to create and control the timeline in Storyline.
https://greensock.com/docs/v3/GSAP/Timeline

Especially when you check slides.min.js you find evidence of that...

timeline: this.props.model.timeline()

On several spots...

s.add(gsap.timeline().to(n, {
x: e * (2 === t ? -1 : 1),
ease: "power2.out",
duration: i

And when you check bootstrapper.min.js you find more evidence...

wrapGsap: function(t) {
t.pause(),
t.totalTime = function() {
return i.toMilliseconds(t.duration())
}
,
t.stepAnimation = function(e, n) {
var r = i.toSeconds(e);
t.seek(r, !0),
t.render(r, !!n, !0)
}
},

So im quite sure the Storyline timeline is in fact a GSAP timeline. And i do think with GSAP and javascript i can make the speed of the timeline controllable. So speed it up, slow it down at will. However this will be quite some research endeavour and will involve javascript. If enough people are interested in a workaround like this...im gladly spent time and get it working. Will take some time though...

Hi Leslie,

Are you able to find out if the developers have any plans to add this feature soon? A wonderful user just commented on this post that they would be willing to volunteer to code this functionality on their own time and share with the community. It's a shame it's come to this point, but just in case your team is actually working on this, I'd hate for this volunteer to waste their time. Thank you much!