We've recently updated to Captivate 2019 from Captivate 8. I've installed all updates the Captivate updater can find. This happens for both projects converted from Captivate 8 (that used to publish and open with no issues through C8) and ones created new in 2019. I made a test project that's just one slide with Test on it and still get the error. The issue is:
This is affecting multiple users (everyone that's tested it for me), and I can reproduce it consistently across FireFox, Chrome, and Edge on Windows and Mac.
The modules are being authored in Windows 10 using the most up-to-date Captivate 2019.
I'm not sure how to get debug tools to tell me exactly what is failing to load, but it looks like it's hanging on something to do with the CPXHRLoader.js file.
The issue seems similar but not identical to Major Issue and the solutions in that thread haven't helped.
Between these two versions, Adobe changed the way that certain multimedia is published from Adobe Captivate. Many image files in your HTML5 project are now converted to JSON files. The reason for the change is that using JSON files speeds up the delivery of your eLearning course, in particular to mobile devices. This change occurred with one of the interim releases of Captivate 9. Ask your IT department if your web server for the company intranet has the mime type for JSON enabled.
This could occur for other reasons but this certainly could be one reason why users are experiencing the spinning wheel of death.
I agree that is the most likely culprit. But don't agree about speeding up delivery.
What it does do is increase the amount of time for the project to load.
The base64 encoded images are 33% larger that the standard png and take a bit more time to render.
The benefit is that it doesn't have to ping t he server every time an new image is encountered since it has already been downloaded in the JSON files.
So ping the server 5 times for 5 JSON files which are larger or ping the server 200 times over a period of time when a new image is needed.
Doesn't your explanation suggest that the end result for the end user is that the browser can load data quickly without delaying page rendering with all those extra pings. Isn't the end result a page that loads faster? It sounds like your splitting hairs. I'm just curious. Help me understand the end benefit of JSON if it isn't faster page render.
Whether or not JSON improves the overall performance has a lot to do with HOW MANY PNGs your project might need to download. If you don't have that many, then the improvement would be negligible and in some cases might even be negative. But if you have lots of PNGs then the increase could definitely be worth it because you are saving on requests to the web server or LMS.
Reducing request-load on the server is never seen as a bad thing in my experience because many organisations don't appreciate what can happen to their (often under-powered) web servers as they release more and more e-learning courses to more and more users. I've seen quite small courses bring an LMS server to its knees once hundreds of users climbed on to view it.
Captivate uses JSON for all of its own interface PNGs and there are scores of those (though not all are used in each course module). And if you have lots of captions or smart shapes in your project, these are likely also being converted into PNGs.
So although JSON has some downsides (e.g. the slower page render) under certain circumstances (e.g. a course with hundreds or even thousands of PNGs) it might come into its own by saving on the delay caused by server requests.
Perfect! We opened up .json on the servers and it began working. Thanks!