Publishing HTML - URGENT

Report · Oct 23, 2019

Please Help

I'm trying to publish a HTML file but it defaults to a play button in order to initiate the files that I want to display. It did not work like that in the past. I'm on version 2019. I'm a novice user and only use Captivate a few times a year if that.

I need help ASAP.

Report · Oct 23, 2019

Also, this is what displayed when I publish the file. http://localhost:59853/preview/HTML5Temp220728287406Publish/index.html

Report · Oct 24, 2019

Giving us a link to your localhost server is not going to do any good. We cannot see that link because it only exists on your own computer.

The new button that users need to click in order to initiate playback is simply something that is now required by all web browsers. It's the sad result of internet marketers being too greedy. Their abuse of previous web standards to initiate download and playback of multimedia files without end user permissions triggered so many complaints that browser manufacturers have tried to take actions that require the user to invoke the playback of their own free will.

E-learning courses are the losers in all of this because they shouldn't really need to ask permission of the user because the content is normally being selected by the user before they see this screen. But it is what it is and there is very little we can do about it. Captivate is simply obeying the new standards that have been introduced by the browsers.

Report · Oct 24, 2019

I do not believe that Adobe is required to force the play button on us.

You may review the following post for a potential solution.

https://community.adobe.com/t5/Captivate/Captivate-Project-start-bypass-the-play-button/td-p/1068824...

Report · Oct 24, 2019

Thank you for your response. I did read your post for a potential solution. However, I've never done the following "After publish - open the index.html file in your favorite editor." Is it easy to do?

Thank you. I need this resolved today.

Report · Oct 24, 2019

I try to refrain from using words like "easy" since it is a relative term. What is easy for me may not be so easy for you and vice-versa.

That being said - I do not feel the task to be one of high complexity - but you do need to be careful not to change something that should not be changed.

Here are a few steps you may consider.

Publish your project as HTML5
Locate the folder containing your published project.
Open the folder and find the index.html file
You will need to open the file in an editor of some sort. Notepad will work but if you have something like Notepad++ or Brackets which will number the lines for you like you see in the picture - that will be better. You should be able to right click on the index file and select the Open With... option and pick a program to open it with.
Add the highlighted code EXACTLY as shown.
Save the document.
Re-upload to your LMS or server if necessary.

If you are feeling a bit squeamish about it - that is OK - see if you can find someone at the office to assist. If something does break - you can still open your project file and publish a fresh copy and you will not have lost any ground.

Hopefully this helps.

Report · Oct 24, 2019

Hope you are not on a responsive project?

Report · Oct 24, 2019

I don't think it IS Adobe that is forcing the play button on us.

Developers can choose to select the Autoplay option in Preferences > Project > Start and End options, but the problem is that the web browsers may or may not obey that setting. The Adobe Help files explain the problem well (for a change):

https://helpx.adobe.com/captivate/kb/captivate-responsive-courses-not-autoplay-browsers.html

At this point there ARE ways to circumvent the restriction, and these programming hacks are being extensively implemented by web developers around the world. But my gut feeling is that these methods will eventually also be killed off by the browser manufacturers.

Adobe could also build these hacks into Captivate, but I don't think they want to put themselves in the position of adding something into the app which then stops working without warning when there's an update to a browser. That has happened too many times already and it usually causes a lot of complaints from the user base even when it's not Adobe's fault.

Report · Oct 24, 2019

I have to respectfully disagree here, Rod - or at least let me say that I am not convinced.

I recognize that web browsers have made updates and restrict autoplaying of media until a user interacts with the media. However, I see this as a completely different issue than the play button found on the launch of a Captivate project.

I will be the first to admit that I hate it when annoying ads magically start playing and I have no idea where the audio is coming from - that sucks. This is precisely what the autoplay blocking is meant to minimize... audio.

I have created many projects that have no audio in them any many more that have audio which will only play when a user clicks a button... yet somehow these projects still have the play button. I developed a project with no audio in Captivate and published it using the Publish for Devices (App) option. This app also started with a play button. So where is that browser involvement...? Any other app on my phone that has audio will play it - why not one published through Captivate...?

The autoplay is all about audio that plays all on its own. The browsers have this handled. I can bypass the play button and Google will still block my autoplaying audio until I interact with my project. That is what tells me they are separate. I believe Adobe forced the play button so that everyone must interact with the project and therefore any audio that is automatically playing for a project will work but I don't need Adobe to "Save me from myself".

I feel this needs to be an e-learning developer (you and me) response not a software developer (Adobe) response. We can, and should, make our own landing slide that forces the user to interact to begin - Adobe just needs to let our first slide show.

If we continue to make projects with audio that takes off on the first second of slide one and it is blocked - that's on us. But let it be on us!

Report · Oct 24, 2019

I understand what you mean and you make very good points. To be fair, I had not tested what would happen with projects that contained no audio at all. All of my projects have audio. So, that was an oversight on my part. Apologies.

The way that Adobe has chosen to implement this would appear 'heavy-handed' if it gets applied even to projects without audio. My guess is that it's being applied because Captivate content is still regarded as 'multimedia' even where audio or video is absent and Adobe wants to be seen as supporting what the browsers are trying to implement.

I can understand that to someone like yourself who has programming expertise and is used to being in full control of every aspect in their project, having that control taken away would be irksome to say the least. However, Captivate has always been intended (and strongly advertised) as a tool that did NOT require the developer to do any coding. It's targeted at basic users (even though it has more than enough horsepower to satisfy professionals at the other end of the spectrum like yourself). So, although experienced users might feel that we should be given the choice to 'opt-into' this arrangement, Adobe seems to be thinking mainly about the other 90% of Captivate users that DO need to be protected from themselves. You know who they are...they're the reason we lose hours of quality time each week answering very basic questions on this forum.

Report · Oct 24, 2019

You do not have to apologize for anything, Rod.

It is good to have civil dialog and share points.

I would argue that even those who are new to Captivate and have zero programming experience, the basic users, can make a title slide with no automatically playing audio. I would even go so far as to say that it would be easier to do that for the basic user than the amount of effort it takes to make that plain ol' play button slide - which is not a part of the project - look like it really is a part of the project.

Report · Oct 31, 2019

Stagprime, I appreciate you chiming in on this - especially because you're validating my point of view! 🙂

I'd suggest that the best solution would be to not rely on the user at all in either direction. The Captivate publishing process should detect whether audio exists on the first slide and add or skip the "Play" screen as necessary. The program certainly has the information it needs to make that decision. And beyond that, the "Play" screen certainly could be automatically created as an overlay to the first slide automatically, I'd think. I'm pretty frustrated with the way it's implemented currently.

Alas, for the moment, it is what it is, regardless of how I feel about it.

Adobe Community

Publishing HTML - URGENT