Skip to main content
Participant
December 13, 2017
Answered

Failure to initialize causes >2 minute load time (with an incomplete experience)

  • December 13, 2017
  • 1 reply
  • 499 views

Hello,

I'm having a great deal of issue when running project files locally within our organization. I've started to dive into how Captivate is managing the majority of what it builds for an HTML5 project and I'm starting to see a great deal of inconsistency with how assets are being handled.

Whenever the loading process chokes, it causes the project at times to take nearly 2 minutes to load. However, when loaded, it doesn't display any of the assets it failed to initialize. Running locally is how our team is testing internally, so pushing these to a web server is not an option. Most of the work is done on multi-platform machines, making an .exe out of the question as well.

Any suggestions would be much appreciated. I have recorded a video of the issue and it's unstable reproduction and am happy to share through an offline communication with anyone interested.

What is causing Failed to load resource: net::ERR_FILE_NOT_FOUND in Chrome <== Relative article that hasn't been marked "answered"

    This topic has been closed for replies.
    Correct answer mg_jodriscoll

    Captivate is merely one of the authoring tools available for creating slide-based e-learning content. The problems you are encountering are NOT the fault of Captivate.  These are simply limitations that come with the territory when you are creating multimedia HTML5 content that you want to run seamlessly within a web browser.

    The e-Learning world is moving over to HTML5 due to the demise of formats like Flash which will NOT be an option within just a few years or earlier.  An e-learning module is really a miniature software project. Captivate removes a lot of the complexity. But if you want to play in the multimedia e-learning space in a professional capacity, then you need to become technically proficient in the technologies upon which it is built and on which it depends to run.

    For the moment, if all you want is for people to review your content, and you are NOT building responsive e-learning, then you could potentially use the self-running EXE output from Captivate.  I have used that extensively where I needed to allow management and reviewers to see the content in a non-web environment BEFORE it was uploaded to the LMS for wider distribution in other web-friendly formats.


    Fair recommendations!

    However, to be fair, I do not believe this is a fault of HTML5, but rather the result of how Captivate is composing its JavaScript (CPM.js, CPXHRLoader.js, etc.) and relying on JSON (img1.json, imgmd.json, etc.) at the local level to manage the construct of any given web app. Just wanted to provide some clarity as HTML5 has little to do with this!

    Regarding the executable (.exe), it is unfortunately not an option with more-and-more of our publishers and clients switching over to Android/Mac based OS platforms.

    Although this solves the technical stability of using the current output of the HTML5/JS capabilities of Captivate, it still proposes the following questions for some of the publishers reading this:

    • Why does it work locally with some users and not others?
      • Captivate will continue to enhance its usage of the JavaScript/JSON language(s), creating more opportunity for better handling of SPA's, local caching, etc..

    • What does it work on my machine some of the time, then fail at other times?
      • It's a roll of the dice when you're trying to run an SPA through a file path and not leveraging a (recommended) local server environment implementation (MAMP, Express.js, etc.).

    Thanks for your time and explanation! I'll continue working with our publishers and helping them understand the technical limitations of SPA's and provide training on the benefits of hosting these projects with the intent of resolving these issues going forward.

    1 reply

    RodWard
    Community Expert
    Community Expert
    December 14, 2017

    If you are working with HTML5 then you really need to be testing the output in a web server environment.  Captivate is supposed to be able to provide such an environment when you use one of the HTML5 preview options, but I have noticed that many people seem to find this doesn't work flawlessly for them, and that issue seems to be increasing nowadays as more and more web browsers become VERY security conscious.

    I have often had to work in a locked down corporate IT environment where it was forbidden to install anything on your own PC.  However, I was still able to set up a localhost web server using XAMPP that included an Apache web server.  You can download the package from the internet and just copy the files to a folder on your local hard drive.  There are no EXE files or installation files to execute and you do not need to be an Administrator.

    Doing this allowed be to always test my HTML5 output in an actual localhost web environment.  Perhaps you and your team could do the same.

    Participant
    December 14, 2017

    Hi RodWard,

    Thanks for taking the time to response – this may be challenging, as this requires one of two things:

    • Client have the technical awareness to run a localhost for the SPA-like output of the (HTML5) Captivate project
    • Publisher to host the files and invest in resources to house, serve and manage the output of the (HTML5) Captivate project for review/delivery/etc.

    If this is a requirement of Captivate with it's modern SPA-approach, is there any insight into whether or not Adobe plans to provide a built-in service that allows it's customers to easily publish the files to an Adobe service – without requiring an engineer with a certain level of knowledge?

    It appears to be that the publisher must have the technical awareness/support in being able to host the HTML5 project and would recommend against running the files locally – as the results may vary from user to user. Or, at the very least (not recommended), in order for the publisher to create a stable review process, recommend leveraging browsers with less security measures for a more "consistent" outcome.

    Proposed Solution:

    • Publisher: Do not run these files locally through the file path, but instead, run them within a localhost environment when participating in an internal review.
    • Client Review: Provide a resolvable web portal that enables a similar expectation when using the more common SPA applications (React, Angular, etc.).

    Would that be a fair assessment?

    Any additional recommendations would be greatly appreciated as the struggle with finding the trade-off of leveraging Captivate for this type of exercise is a bit of a hard sell at the moment.

    RodWard
    Community Expert
    Community Expert
    December 14, 2017

    Captivate is merely one of the authoring tools available for creating slide-based e-learning content. The problems you are encountering are NOT the fault of Captivate.  These are simply limitations that come with the territory when you are creating multimedia HTML5 content that you want to run seamlessly within a web browser.

    The e-Learning world is moving over to HTML5 due to the demise of formats like Flash which will NOT be an option within just a few years or earlier.  An e-learning module is really a miniature software project. Captivate removes a lot of the complexity. But if you want to play in the multimedia e-learning space in a professional capacity, then you need to become technically proficient in the technologies upon which it is built and on which it depends to run.

    For the moment, if all you want is for people to review your content, and you are NOT building responsive e-learning, then you could potentially use the self-running EXE output from Captivate.  I have used that extensively where I needed to allow management and reviewers to see the content in a non-web environment BEFORE it was uploaded to the LMS for wider distribution in other web-friendly formats.