The volume slider on my HTML5 build doesn't work properly. If you click anywhere on the slider it drops to 0 volume and there is no way to turn it back up.
The volume control works normal on other builds just the HTML5 build seems to have the issue.
I've tested it across several projects and the issue appears in all of them. Is anyone else experiencing similar?
I know the web site and our emails have a heavy focus towards Articulate 360, but our Support and QA teams remain committed to supporting our perpetual products and providing as much information and updates as possible. I'm sorry if you've felt left behind and if there has been something to give you the impression that we'd no longer be fixing items.
Just to be sure it's clearly stated here, Articulate will continue to support the last 2 perpetual versions of each product (currently SL1, SL2, ST09, and ST13) as well as our new subscription tools. In other words, we'll keep supporting Storyline 2 for a long time.
I also saw in another forum discussion you pointed out some consistencies in our language that may have felt impersonal. I'm truly sorry for that as well, and it's something our team talks about on a regular basis of how to provide stellar customer support, be professional and recognize that we're all human and need to keep in mind that our official answer, often feels that way...too robotic and official.
As our team works with the QA team to determine bugs and issues to be targeted for fixes, it has been based on breadth of impact (number of customers impacted), depth of impact (severity for those impacted customers) and viability of other workarounds or solutions. The issue with the volume slider in HTML5 is still an open issue. It does have two workarounds mentioned by Leslie above and the element that individual users could adjust the volume control based on their system or device it. I do understand that it may be a larger issue for you if you're not able to utilize those two workarounds, so I'm going to personally bring this one up at our next meeting with QA. I still can't make any promises about a fix or a timeline, but I will ensure it gets a further look by our team.
I think this is a significant concern. We need our course to be scalable to fit iPads and up. We also want to deliver HTML5 to pretty much everything except IE (using our own redirect code) because of the limitations of Flash (we can customize more with HTML5). The client also wants the volume control in the player.
Thanks for adding your voice, Jacqui! You are in the right place, and we’ll be sure to let you know any further information we have to share as soon as we can. You'll receive a notification anytime new information is added here because you're now subscribed to this post.
I'm sorry I don't have any new information to share. We’re monitoring the way this behavior impacts our customers and figuring out how a change here might fit in with other priorities. I'm going to advocate for this issue in our next meeting, as this is one that impacts many of our users. I appreciate you for checking in on this, and I’ll be sure to let you know any further information I have to share as soon as I can!
Hi I have been testing the HTML 5 versions of our courses in IE and am experiencing the same issue with the imminent demise of Flash this is becoming a priority issue.
I hear you, Stephen. Thanks for sharing your experience with us. It’s definitely helpful to understand how many folks are experiencing this bug and how often they encounter it. That info helps us prioritize our development resources. We’re still working on this, and we’ll definitely let you know when we know more.
Hey Darren - I grabbed another users course where I had seen the issue previously reported and I'm not seeing the issue when upgrading the file :)
If you have a .story file that you'd like me to specifically take a look at, feel free to share - or feel free to download a trial and try it out yourself.
Hi Darren - This issue is still open at this time and I do not have an update regarding Storyline 2. We are trying to better prioritize user issues and gauge user impact, so thanks for letting us know that this is still impacting you.
Hi Darren - I believe Ashley addressed our support stance on our products above, which you can see here, and I know we are still working on items within Storyline 2.
I've had this same issue today with the HTML5 output in Chrome (in an LMS testing environment, which will be the final destination but on the client-side). I can confirm that the player locking is an effective temporary fix, but to the others' point about UX, this isn't ideal long-term. It'd be great to get this fixed in the next update. Thanks!
I'm having this issue (user touches the volume control, and all volume is muted...no way to turn it back up) in Chrome (course is published to SCORM), but my player is already set to "lock player at optimal size"?
Hello Malissa! Sorry to hear that you've run into an issue with this as well and it sounds like yours is not what we have reported. Would you be able to share your .story file so that we could take a look?
And I think you may have your answer, Jake. I too am having the same issue. Removing the scaling capability is not a great option. Neither is removing the volume controls.
This does speak to customer service "passion" at Articulate and will weigh strongly on my next decision for an L&D software solution. Particularly with more responsive design requests out there and more competition options. Frankly, the biggest competitor just got a huge leg up with responsive design.
This isn't the first time I've seen swings and misses as it relates to fixing issues we paid good money for. As it stands, I am not convinced I got what I paid for when simple things just don't work.
I guess that's the genius of calling a product "Beta" for the first two iterations. Maybe 360 Storyline (which is not so far marketed as Beta), will result in Articulate caring about and fixing the issues they create. I'd offer up my information for your "team who is working on this", but I don't want my time wasted like the others before me.
Absolutely, it shouldn't be that difficult a fix, especially when it is apparently fixed in Storyline 3, it begs the question what will happen if Google decides to make a change to Chrome again that affects Storyline playback, will Articulate still fix that in Storyline 2? Or leave us high and dry with inadequate workarounds as they seem to have done with this issue. As someone who had to sped a lot of time altering 70 modules recently because of this I share your pain.
I agreed with you Jake Hurt. It the same old rant. "Please submit to our QA team" and never a reply for fixes. I have been dealing with this too as of 10/20/2017.
sometimes when you want to solve something, you must open up the hood and get dirty... So that's what I did to help solve this problem.
I think I found a solution to the Google Chrome bug with the sound dial not working correctly (from what I tested, it seems corrected).
First of all, I had to dig into the file “/mobile/player_compiled.js”. This file is minified, so to understand the code more easily, I un-minified it.
The problem I identified is in the function “VolumeSlider.prototype.bindDragEvents”. More specifically in the click detection of the volume bar math code to convert the spot clicked into a % of volume to adjust.
Here is the original function:
VolumeSlider.prototype.bindDragEvents = function() { var a = this; a.dragging = !1; var b = function(b) { a.dragging = !0; c(b); return !1 }, c = function(b) { if (a.dragging) { var c = a.ref.offset().top, d = a.ref.height(); swipe.parseEventCoords(b); b = 1 - (swipe.rawY - c) / d; 0 > b && (b = 0); 1 < b && (b = 1); a.volume = parseInt(100 * b); a.update(); if (a.onDragUpdate) a.onDragUpdate(b); $.each(VolumeSlider.sliderList, function(b, c) { if (c != a) c.volume = a.volume, c.update() }); return !1 } }, d = function(b) { c(b); b = a.dragging; a.dragging = !1; if (b) return a.hide(), !1 }; player.isMobile ? ($(this.ref).bind("touchstart", b), $(window).bind("touchmove", c), $(this.ref).bind("touchmove", c), $(this.ref).bind("touchend", d), $(document.body).bind("touchend", d), $(window).bind("touchend", d), this.button.bind("touchend", function(b) { a.toggle(); MouseEvents.processHideables(b); return !1 })) : ($(this.ref).bind("mousedown touchstart", b), $(window).bind("mousemove touchmove", c), $(this.ref).bind("mouseup touchend", d), $(document.body).bind("mouseup touchend", d), $(window).bind("mouseup touchend", d), this.button.bind("click", function(b) { a.toggle(); MouseEvents.processHideables(b); return !1 })); MouseEvents.addHideable(".volume-slider", ".volume-slider,.icon.volume", function() { a.hide() }) };
The problematic line of code is this one: “b = 1 - (swipe.rawY - c) / d;”. This line is seeking where the user clicked on the volume bar vs the height of the bar (b = 1 (%where user clicked% - %top portion of the volume bar%) / %height of volume bar%). So, if you click on middle of bar, it gives “b = 1 – 0.5 = 0.5 = 50% of the volume.
Here is the catch with Google Chrome (compared to other browsers), the value reported by “swipe.rawY” is incorrect, to get the good value, we must use “swipe.y”.
Since you cannot just change the code with “swipe.y” since it will break the code for the other browser else than Chrome, we need to detect if Chrome browser and apply the fix on that case. How ? Simple, just detect Chrome with this line “var is_chrome = navigator.userAgent.toLowerCase().indexOf('chrome') > -1;”. Now the variable “is_chrome” will be TRUE if the current browser is Chrome.
We can now just do this:
var is_chrome = navigator.userAgent.toLowerCase().indexOf('chrome') > -1; if(is_chrome) { b = 1 - ((swipe.y - c) / d); } else { b = 1 - (swipe.rawY - c) / d; }
The final code should look like this:
VolumeSlider.prototype.bindDragEvents = function() { var is_chrome = navigator.userAgent.toLowerCase().indexOf('chrome') > -1; var a = this; a.dragging = !1; var b = function(b) { a.dragging = !0; c(b); return !1 }, c = function(b) { if (a.dragging) { var c = a.ref.offset().top, d = a.ref.height(); swipe.parseEventCoords(b); if(is_chrome) { b = 1 - ((swipe.y - c) / d); } else { b = 1 - (swipe.rawY - c) / d; } 0 > b && (b = 0); 1 < b && (b = 1); a.volume = parseInt(100 * b); a.update(); if (a.onDragUpdate) a.onDragUpdate(b); $.each(VolumeSlider.sliderList, function(b, c) { if (c != a) c.volume = a.volume, c.update() }); return !1 } }, d = function(b) { c(b); b = a.dragging; a.dragging = !1; if (b) return a.hide(), !1 }; player.isMobile ? ($(this.ref).bind("touchstart", b), $(window).bind("touchmove", c), $(this.ref).bind("touchmove", c), $(this.ref).bind("touchend", d), $(document.body).bind("touchend", d), $(window).bind("touchend", d), this.button.bind("touchend", function(b) { a.toggle(); MouseEvents.processHideables(b); return !1 })) : ($(this.ref).bind("mousedown touchstart", b), $(window).bind("mousemove touchmove", c), $(this.ref).bind("mouseup touchend", d), $(document.body).bind("mouseup touchend", d), $(window).bind("mouseup touchend", d), this.button.bind("click", function(b) { a.toggle(); MouseEvents.processHideables(b); return !1 })); MouseEvents.addHideable(".volume-slider", ".volume-slider,.icon.volume", function() { a.hide() }) };
I attached a version of the modified minified file with this message. Please note that the version of the original file is "var buildNumber=62;var buildDate="20160926 20:10";" running on STORYLINE 2.
Normally, we should wait for Articulate to prepare an official fix with this patch (if the code is tested and proved to solve the problem). If you absolutely need a fix now, you can just overwrite the original file in your project with my file (need to be done each time you republish). WARNING : I quickly tested this fix and it’s not an official patch, so use it at your own risk !
I’m just a bit surprised that the Articulate team never solved this problem been reported 2 years+ ago and took me around 2h to find the problem and apply a fix without any knowledge of the structure of the code… Hope the programmers will test my fix quickly and include the fix in the next Storyline 2 patch release.
Thanks Patrick, I was poking around the html hoping for a fix via the css. I do not know .js, but it's on my list of things to learn. Until then, I appreciate the fix!! Articulate should pay you for fixing this issue for them.... kinda sad, 2+ years and they couldn't throw a web developer at this for ~2 hours.
54 Replies
Hey Jake,
I know the web site and our emails have a heavy focus towards Articulate 360, but our Support and QA teams remain committed to supporting our perpetual products and providing as much information and updates as possible. I'm sorry if you've felt left behind and if there has been something to give you the impression that we'd no longer be fixing items.
Just to be sure it's clearly stated here, Articulate will continue to support the last 2 perpetual versions of each product (currently SL1, SL2, ST09, and ST13) as well as our new subscription tools. In other words, we'll keep supporting Storyline 2 for a long time.
I also saw in another forum discussion you pointed out some consistencies in our language that may have felt impersonal. I'm truly sorry for that as well, and it's something our team talks about on a regular basis of how to provide stellar customer support, be professional and recognize that we're all human and need to keep in mind that our official answer, often feels that way...too robotic and official.
As our team works with the QA team to determine bugs and issues to be targeted for fixes, it has been based on breadth of impact (number of customers impacted), depth of impact (severity for those impacted customers) and viability of other workarounds or solutions. The issue with the volume slider in HTML5 is still an open issue. It does have two workarounds mentioned by Leslie above and the element that individual users could adjust the volume control based on their system or device it. I do understand that it may be a larger issue for you if you're not able to utilize those two workarounds, so I'm going to personally bring this one up at our next meeting with QA. I still can't make any promises about a fix or a timeline, but I will ensure it gets a further look by our team.
I think this is a significant concern. We need our course to be scalable to fit iPads and up. We also want to deliver HTML5 to pretty much everything except IE (using our own redirect code) because of the limitations of Flash (we can customize more with HTML5). The client also wants the volume control in the player.
Following this thread is hopes of an update.
Thanks for adding your voice, Jacqui! You are in the right place, and we’ll be sure to let you know any further information we have to share as soon as we can. You'll receive a notification anytime new information is added here because you're now subscribed to this post.
No updates yet?
It was reported almost 2 years ago
Hi there Darren,
I'm sorry I don't have any new information to share. We’re monitoring the way this behavior impacts our customers and figuring out how a change here might fit in with other priorities. I'm going to advocate for this issue in our next meeting, as this is one that impacts many of our users. I appreciate you for checking in on this, and I’ll be sure to let you know any further information I have to share as soon as I can!
Hi I have been testing the HTML 5 versions of our courses in IE and am experiencing the same issue with the imminent demise of Flash this is becoming a priority issue.
I hear you, Stephen. Thanks for sharing your experience with us. It’s definitely helpful to understand how many folks are experiencing this bug and how often they encounter it. That info helps us prioritize our development resources. We’re still working on this, and we’ll definitely let you know when we know more.
As Stephen Wilson mentioned, it is becoming a priority issue now, I will wait for an update from Articulate team regarding the fix for the same.
Its been 2 years. High time this should be fixed.
ditto
Is this bug fixed in Storyline 3?
I just noticed it was released last week.
Hey Darren - I grabbed another users course where I had seen the issue previously reported and I'm not seeing the issue when upgrading the file :)
If you have a .story file that you'd like me to specifically take a look at, feel free to share - or feel free to download a trial and try it out yourself.
Hi Leslie,
Great news on the fix in Storyline 3.
Can it be applied to Storyline 2?
Hi Darren - This issue is still open at this time and I do not have an update regarding Storyline 2. We are trying to better prioritize user issues and gauge user impact, so thanks for letting us know that this is still impacting you.
User impact I suspect is high as the issue affects Google Chrome users.
Chrome as a browser has over 50% of market share.
If the issue is fixed with Storyline 3, why can't it be applied to Storyline 2?
Will we ever see another update for Storyline 2?
Hi Darren - I believe Ashley addressed our support stance on our products above, which you can see here, and I know we are still working on items within Storyline 2.
I've had this same issue today with the HTML5 output in Chrome (in an LMS testing environment, which will be the final destination but on the client-side). I can confirm that the player locking is an effective temporary fix, but to the others' point about UX, this isn't ideal long-term. It'd be great to get this fixed in the next update. Thanks!
They have a fix Ashley , it is in Storyline 3.
But Storyline 3 is not a free upgrade it is a new purchasable product.
I have my doubts we will ever see this fixed in Stroyline 2; but would like to be proved wrong.
I'm having this issue (user touches the volume control, and all volume is muted...no way to turn it back up) in Chrome (course is published to SCORM), but my player is already set to "lock player at optimal size"?
Any ideas why this would be?
Hello Malissa! Sorry to hear that you've run into an issue with this as well and it sounds like yours is not what we have reported. Would you be able to share your .story file so that we could take a look?
And I think you may have your answer, Jake. I too am having the same issue. Removing the scaling capability is not a great option. Neither is removing the volume controls.
This does speak to customer service "passion" at Articulate and will weigh strongly on my next decision for an L&D software solution. Particularly with more responsive design requests out there and more competition options. Frankly, the biggest competitor just got a huge leg up with responsive design.
This isn't the first time I've seen swings and misses as it relates to fixing issues we paid good money for. As it stands, I am not convinced I got what I paid for when simple things just don't work.
I guess that's the genius of calling a product "Beta" for the first two iterations. Maybe 360 Storyline (which is not so far marketed as Beta), will result in Articulate caring about and fixing the issues they create. I'd offer up my information for your "team who is working on this", but I don't want my time wasted like the others before me.
Hi Rusty
Absolutely, it shouldn't be that difficult a fix, especially when it is apparently fixed in Storyline 3, it begs the question what will happen if Google decides to make a change to Chrome again that affects Storyline playback, will Articulate still fix that in Storyline 2? Or leave us high and dry with inadequate workarounds as they seem to have done with this issue. As someone who had to sped a lot of time altering 70 modules recently because of this I share your pain.
I agreed with you Jake Hurt. It the same old rant. "Please submit to our QA team" and never a reply for fixes. I have been dealing with this too as of 10/20/2017.
Hi fellow Articulate users,
sometimes when you want to solve something, you must open up the hood and get dirty... So that's what I did to help solve this problem.
I think I found a solution to the Google Chrome bug with the sound dial not working correctly (from what I tested, it seems corrected).
First of all, I had to dig into the file “/mobile/player_compiled.js”. This file is minified, so to understand the code more easily, I un-minified it.
The problem I identified is in the function “VolumeSlider.prototype.bindDragEvents”. More specifically in the click detection of the volume bar math code to convert the spot clicked into a % of volume to adjust.
Here is the original function:
The problematic line of code is this one: “b = 1 - (swipe.rawY - c) / d;”. This line is seeking where the user clicked on the volume bar vs the height of the bar (b = 1 (%where user clicked% - %top portion of the volume bar%) / %height of volume bar%). So, if you click on middle of bar, it gives “b = 1 – 0.5 = 0.5 = 50% of the volume.
Here is the catch with Google Chrome (compared to other browsers), the value reported by “swipe.rawY” is incorrect, to get the good value, we must use “swipe.y”.
Since you cannot just change the code with “swipe.y” since it will break the code for the other browser else than Chrome, we need to detect if Chrome browser and apply the fix on that case. How ? Simple, just detect Chrome with this line “var is_chrome = navigator.userAgent.toLowerCase().indexOf('chrome') > -1;”. Now the variable “is_chrome” will be TRUE if the current browser is Chrome.
We can now just do this:
The final code should look like this:
I attached a version of the modified minified file with this message. Please note that the version of the original file is "var buildNumber=62;var buildDate="20160926 20:10";" running on STORYLINE 2.
Normally, we should wait for Articulate to prepare an official fix with this patch (if the code is tested and proved to solve the problem). If you absolutely need a fix now, you can just overwrite the original file in your project with my file (need to be done each time you republish). WARNING : I quickly tested this fix and it’s not an official patch, so use it at your own risk !
I’m just a bit surprised that the Articulate team never solved this problem been reported 2 years+ ago and took me around 2h to find the problem and apply a fix without any knowledge of the structure of the code… Hope the programmers will test my fix quickly and include the fix in the next Storyline 2 patch release.
Thanks !
Patrick Perron
Thanks Patrick, I was poking around the html hoping for a fix via the css. I do not know .js, but it's on my list of things to learn. Until then, I appreciate the fix!! Articulate should pay you for fixing this issue for them.... kinda sad, 2+ years and they couldn't throw a web developer at this for ~2 hours.
This discussion is closed. You can start a new discussion or contact Articulate Support.