53 Replies
Tim Neill

This is a serious deficiency. 'Feature request' just submitted.

It is really tedious to have to split content onto separate layers and then display each layer (using a trigger and a condition) when a 'Next' button is clicked. Building up a screen of bullet text/images, etc. is something even PowerPoint can do!

And it gets worse - if there is an audio on each of these layers, when I click 'Next' to display another layer, the currently playing audio continues together with the new layer's audio. And no, I don't want to have to play/pause named audio files with a trigger. When you display a new layer, an audio that is playing on the layer you are leaving should stop. 

A lot of people have been asking for this 'jump to a cue point' for many months. Where is it?

Rachel Barnum

Hey Tim,

I'm curious about how you're setting up the course. It sounds like to me that you can use the timeline to do exactly what you're trying to do. You can adjust the length of time that bullets or images stay on the screen, and match it up with the audio. This may just be a misunderstanding on my part about what you're trying to do exactly.

If you're trying to make sure they hit next, you can always just make them go to the next slide. If you're trying to have them click buttons (like a click and reveal), you can use layer settings to "pause" the base layer, which should also "pause" the audio. You can also make it "hide other layers". 

You can access the layer settings using the gear icon next to the layer on the right.

And this will appear:

Ashley Terwilliger

Hi Susan,

Thanks for reaching out here and I'm sorry to say that we're unable to share information in regards to timelines of new features or updates to fix issues. We don't share our product road map in general, but once we're able to share any updates we'll be certain to do so here. Please feel free to let me know if you have any other questions or there is anything I can assist with. 

Michael Anderson

For some projects where I have needed this kind of control over the timeline, I have created my own timeline clock counter using Matthew Bibby's javascript code, and then time my course events off of that counter. I can change my timeline time at any time by changing the value of the counter. This is good for projects where you don't need to reverse the timeline at all.

Tim Neill

Alex - 'Created a feature request - I note this has been requested over 5+ years ago.'

Don't hold your breath - I gave up submitting 'feature' requests like this (for facilities which I felt should have been included as standard) a few years ago. Not one has ever been implemented. 

eg: Why does SL allow a playing audio on one layer to keep playing even after a second audio is started on a another layer? Daft.

Tim Neill

So a voiceover narration is still playing on layer 1, when the user clicks a button to go to layer 2 to play a different v/o but keep the layer 1 graphics visible. Both v/o tracks are then playing together. When would you ever want this? And before you suggest it, I don't see why I should have to stop the first file playing explicitly by specifying its file name. It should just stop. I have been using authoring systems for almost 30 years (Authorware didn't allow this 23 years ago) and I think there is no excuse.

Brian Allen
Tim Neill

Authorware didn't allow this 23 years ago

Thank goodness for progress!

I'm not going to put all the possible, potential uses of this tool into a box and allow myself to believe that the way I want it to work is what will also work best for everyone else.

I've seen enough interactive games and courses where the ability to build upon audio sounds with the introductions of additional layers would absolutely be seen as a "plus", and that's just the first application for this that comes to mind.

Your example is a very specific application where you want to display two layers at the same time, and you feel that Storyline should automatically know which parts of those layers should still be visible/functional and which shouldn't be. I personally don't find it overly unreasonable that in this scenario I may need to give Storyline explicit instructions for which components on those slide layers should continue and which shouldn't, in fact it seems very reasonable.

Brian Allen
Tim Neill

give us the choice - 'do you want to kill the running audio when you start a new one?'

You're right, this would be a great feature suggestion... and I'm just an author, a customer, like you, I have no say in feature development. Which might be a good thing, otherwise there might be a random "order Starbucks" button hidden in there somewhere.

Back to your original comment, on feature suggestions, I've also submitted my share. Some I have seen make it into the product, others have not. In retrospect, the feature requests that I've seen productized are most likely features that appealed to (and were asked for) by a wide range of customers. The feature requests that haven't are probably specific to a much smaller group of users.

Given that, for what it's worth, I do believe that it is always valuable to add our voices to the others and still submit those feature requests, in the hopes that there are enough others who would like to see the same functionality I'm asking for.

Michael Anderson

Brian, you sound like a very rational fellow. :)  I agree with you, but I do share Tim's frustration that many feature requests are not judged worthy of implementation. But I think that we need to realize that there are probably a huge number of man (and woman) hours involved in adding and testing a new feature.

Brian Allen

Ha! I have my days :) Let me say that this specific feature request, to jump to a point on the timeline, I know I've probably submitted a half dozen times, which explains why I've been following this thread.

Given the length of time we've been waiting on it: 1) Not many people have asked for it, 2) There are other requests in front of it that make more sense to productize, OR, 3) As you said, it's a monumental task effort-wise to add it to the product.

Leslie McKerchie

We are watching and we are working to better our feature request process. 

That being said, Brian almost nailed it with his explanation and I thought it may be helpful to share how we manage feature requests.

I'm going to connect some dots on our end and get this prioritized so that we can take another look.