31 Replies
Christine Hendrickson

Hi Peg!

I'm sorry, but currently it is not possible to disable the volume button for specific slides. Right now, if you disable the button, it will be disabled for all slides. The same goes for enabling the button in the player, it will show across all slides.

I'm guessing you have media on different portions of the course, but not all, is that right? Do you want the volume button available for muting the audio entirely? If so, maybe you could have a custom button that would mute the audio?

If that's an option for you, take a look here at Steve's custom mute toggle. 

If you'd like to see more options for the volume control button, please submit a feature request with us. 

Thanks Peg,


Peg Simmons

Thanks Christine! I will enter a feature request.

The scene I'm referring to is the final quiz which has no audio; The rest of the course does have audio so it makes sense to have the volume button. It looks pretty silly to have the control button when there is no audio. I have a note in the Help about no audio but one never knows if that comes to mind at the end of a course. I'm concerned that the student being confused. 

Christine Hendrickson

Good morning Peg!

Thanks for sending in that information! We always take feature requests seriously and I can definitely see how that option would be handy, especially for courses designed like yours. I agree it can be a bit odd to see the option to adjust the volume, if there isn't anything to adjust :)

I hope you have a great day!


Alexandros Anoyatis

Hi Peg and Christine,

Actually there is a way - albeit a little 'crazy'.

You can place a web object containing a webpage that matches your player's background just under the slide's viewable area.

You will find that the web object is still displayed on top of every other element - even the player itself. You can view the demo or grab the attached story.

Hope this helps,

P.S.: The reason the webobject contains scrollbars is because there is actually some (black) text in that specific URL - sorry I couldn't find a better one. Using a URL which is totally empty of content will take care of the scrollbars issue.

Christine Hendrickson

Hi Alex,

Haha, true! I could see that resulting in some additional time for work.

I'm wondering if that would work with some type of embedded media, too.. the type that displays in a frame? 

Only problem I see is making sure that it's lined up properly over the actual button. Again, though, something I may definitely try out. You could probably do this *lightbulb* .. you could definitely take advantage of this with other player elements too.. :D

New thing every day. This is my favorite, right now :)


Alexandros Anoyatis

If by embedded media you mean the "Insert Video-->From Website" embed method, then the answer is yes. I've tried that with an external video player - it actually overlaps the SL Players Shell.

So both the embed and the web object overlap. I just happen to like the web object method a bit more because it looks a little more foul proof (always on top, no exceptions*).

The problem I see is not the positioning per se - by trial and error you should be able to cover the spots after a couple of previews. It's that the coverup most likely won't look very nice on AMP (since the background color usually differs from the one in the SL Player).


* Actually there was one. The URL I initially inserted as the web object was Google.com. Funny enough, some antiDoS/anti-flood mechanism must have kicked in, since it only appeared once, then it magically disappeared.

Christine Hendrickson

Oh no, I totally understand that the web object would be the best method - I was just curious if you had tried both.

That's pretty awesome! :D

I don't create a lot of courses for AMP, really, unless I'm testing. I like being on a real "machine" :) So I don't see that as an issue. 

This is definitely something I think I'll end up referring do with a lot of cases, so thanks again for sharing this :)

Have a great one, Alex!~


Imran khan

Hi Peg,

you can also do this by editting generated frame.xml :

  1.  Make sure that the seekbar option is checked for all the slide's except to the slide you dont want audio icon.It will make easy for you to search the relevant slide's control Node. Publish the course.
  2. Open frame.xml find this node  "" 
  3. just make the volume enabled="false" and its done........
Ashley Terwilliger-Pollard

Hi Thomas and welcome to Heroes! 

Once a Storyline file has been published, there isn't a way to edit it. You'd have to return to your source file to disable the volume button and then republish. To disable the volume button, go to the Player button -> Features, look for "Controls" at the bottom and uncheck the "Volume" box. Here are some additional directions for how to customize the player and remove the Volume button.


Alexandros Anoyatis

I can confirm that, unfortunately, the workaround no longer works. It used to in certain versions of Storyline 1, and maybe early versions of SL 2 as well, but the player now has a greater z-index than an in-built iframe (which is what I was using for the "hack" above), therefore rendering this solution obsolete.

Robert Fuller

"Thanks for sending in that information! We always take feature requests seriously"

Three years, and one huge software roll-out later, and apparently it's not taken seriously enough :P

You've got a multi-scene course, a little video content here and there, and only need a volume control and seekbar in some spots -- not others? Sure, turn off the seekbar, but that darn volume button's with you for life!


Someone tell the Emperor he's bare-@ss nekkid, please?

Ashley Terwilliger-Pollard

Hi Robert,

I know there have been a number of forum discussions about this, and likely the same number of feature requests. We use all that feedback in combination with the ease of workarounds, other solutions, etc. when our team looks at features and updates to the product. Since volume can also be controlled by an end user on their individual device, the ability to modify the volume within the player hasn't bubbled up to the top of our priority list as you could choose to remove it from the player as a whole. 

I hope that adds a bit more insight into our process for features and updates in general. Please let me know if you have any other questions. 

Lisa Jones

Hi Ashley, Leslie, and all other staff,

First, thank you for your updates. This is but one thread I've hit upon regarding UI.

Before developing in Storyline, I was part of the "much larger audience" that experiences your product: as a learner. Using the courseware I wondered if the developers were lazy or just had no idea about user experience (or simply didn't care if we were frustrated by clicking the "wrong" buttons, etc.). I found that the buttons replacing other buttons in the same position was amazingly confusing and led to returning to slides I didn't want to return to (in a gated slide scenario, the previous button will replace where "next" usually is - and I, like most folks, don't expect we'll have to "read" buttons in our navigation once we know where they are), or I'd not know there was a "submit" button (again, shifted all the other navigation over and wasn't very noticeable when it showed up, nor was there even some sort of color indicator or something to call my attention to it).

Working with the responsive player is worse, and as a developer, I cringe about the user experience. For example, since the "Next" arrow can't show a visible disabled state, as developers, we have a choice, either hide it (which holds true for the desktop and mobile player placements) which now moves the Previous button where Next should be, or we disable it, which is visible in the "desktop" view, but in the responsive view, it's terribly confusing for the user as it looks like they can move forward. They can either punch that button all they like and nothing happens, or we can toss an error to them ("finish this slide.") -- each of these are not in the least user-centric.

In this case - we have an audio button with no audio on the page. Again, or choices are: keep the scrub bar and leave the user wondering if their headsets are broken, or remove it and leave them wondering  -- well if the page is broken (there's now "half" the visual that there should be audio). Again, both not user-centric.

I know you are working on updating the player functionality for this fall. I hope you'll place your "largest audience," the learners, in focus. All the fancy transitions and movements in a page are hard to make up for frustration in UI. It would probably be an excellent investment to reach out to [someone like] Nielsen Norman Group to get their thoughts about what this might look and function like from a learner perspective. 

Personally, I develop with a "human first" approach, with a core philosophy of not providing opportunities for users to "make mistakes" when it comes to UI. While I can manage everything on screen to improve this experience, often taking extra time to "do what's right" vs. "do what's easy for me," I feel very hampered by the player, which pains me every time I test - knowing the experience is sub-par at best for learners, and frustrating and confusing at worst.

I'm also not sure why it becomes necessary for the developers to formulate "creative workarounds" for functionality that should be a central part of the product. "hacking" published files post-publish is riddled with the opportunity for human error - including simply "forgetting" to make the change. It can also add significant time to re-test each time we publish, especially if there are several places we need to "hack" in external files.

In another post, Simon reiterated the importance of "pixel-perfect" placement of each character to eLearning - I wish this type of passion was directed towards the player UI/UX.

I totally understand and respect the prioritization process, but perhaps if you look at this honestly from the lens of your ultimate, largest audience: all those learners, it might change perspective a bit.

Best regards,

Ashley Terwilliger-Pollard

Hi Lisa,

Thank you for taking the time to share this. It's something I passed along to my Product team and they found it insightful and useful as we continue to look at what's next for Articulate. 

You may hear from one of my colleagues via email (or you might have already) so thank you again for sharing here and keeping us honest and on target!