Forum Discussion
Rise 360’s new Custom Code Block — how far can it go to replace the need for Storyline blocks?
You and I are doing some similar work with allowing learners to complete PDFs via pdf-lib! I ran into the same issues as you with the sandboxed code block preventing the PDF download. I found a couple of workarounds, but unfortunately, they broke once I got to the SCORM point (since by then, we're running an iframe in an iframe in an iframe in a... you guessed it... iframe).
The most reliable solution I've found so far is to use my custom code as a web object in a Storyline project instead of a code block. I realize that takes away the automatic vertical sizing of the code block, so it won't work in all use cases. But if your app has a relatively consistent height and you can live with it running in a fixed Storyline block, you can have your custom app do all the fancy work, pass the PDF details as a JSON payload using postMessage, and set a Storyline variable to flag completion. Essentially it works like this:
- Create a Storyline true/false variable and a trigger that completes the course when that variable changes to true.
- In Storyline, a JavaScript trigger loads and calls pdf-lib and save-as to get and fill the form and facilitate download, just as you would if you were making a purely Storyline-based interaction.
- In the same JavaScript trigger, add an event listener to the window to listen for postMessage of the types you define. One message type would be for the JSON payload sent from your app, and the other message type would be for completion and would set the Storyline completion variable to true.
- In your custom app (which will be in the web object), pass your two messages (the data for filling the PDF and the completion status) using postMessage.
I've done a lot of work with PDFs in my learning interactions, but for whatever reason, I have not been using localStorage to retain data between sessions or use it later in a course. Do you find that to be a reliable way to go about it for most users/browsers/devices? I have always just included verbiage in my lessons that the learner had better finish and download their PDF before they close the lesson. 😀 Maybe I could tap into localStorage to help mitigate some of that - and to refer back to previous data later in a lesson.
Edit to add: I realize the whole point of your post was to see how much a code block can do to prevent the need for relying on Storlyine - and I just said the main fix I found was to use Storyline. Ha! I guess it was a long-winded way of agreeing with you that more advanced PDF stuff may still require Storyline. But my main point was also that it's possible to build a custom interaction and wrap it in Storyline to get around the sandbox problem for downloads.
Local Browser Storage works fine if you accept the limitations - the data is stored in that browser's local memory. - So if you change browser half-way through the course OR if you change system - you lose the data. OR also if you clear the browser cache!!
I have done projects where I have stored the data in the SCORM 2004 database (there is a standard defined field in SCORM called "comments_from_learner") it worked fine and was more persistent than local browser memory - but the JavaScript was brutal!! As you say you are running in an Storyline iframe within a RISE iframe within a SCORM iframe etc. etc. Getting to the SCORM level is tricky. But is does work!
Related Content
- 5 months ago
- 3 months ago
- 12 months ago
- 5 months ago