Forum Discussion
I have a project where users need to be able to enter short essay length texts that were then able to be gathered as a PDF for their own proof, as well as being able to be stored on a server for later use/review by the trainer.
In my project I found that trying to open and modify the PDFs using some of the available javascript libraries was a bit troublesome and dealing with page breaks in fields in PDFs or just creating fresh documents each time was time consuming. The Storyline workflow for developing and debugging javascript actions is difficult and time consuming, having to rely on publishing the package each time a script needed to change.
I tinkered with using localStorage and sessionStorage for remembering the values, but on a shared device where one user logs off from the web app that hosts the course (the computer has only one user) and another user logs on, the values could get mixed and one user could potentially see another users data. I also needed to be able to store the result, save and pick it up later on (potentially weeks later) from potentially other devices such as an iPad.
The Rise courses hosting these Storyline modules are published to SCORM and hosted on a Moodle LMS, so I could rely on some details that API has present at runtime. Injecting values to the SCORM backend from Storyline within Rise proved to be too tricky in my timeframe. Writing the value to a LRS seemed trivial but getting the value back again and generating a user-downloadable pdf from the LRS was not. The only viable option for me was 'externally' referenced storage.
I ended up building a generic routine that first reads the learners name/id using the scorm api from within Storyline, and then some extras to get unique identifers about the course and storyline interaction instance that were available when published to SCORM (bits of javascript that can only run when the story package within rise is hosted on the same domain; it's not when you publish to Review or Reach, but IS when you publish to web or Scorm).
I then made a back-end in PHP to store, read and compile the text entries (or any value, really). PHP has some nice PDF building libraries that handle building documents so much more nicely than is easy to implement through the Storyline 'execute javascript feature. There's a few other niceties put in place like matching the storyline background to the block and removing the extra outer padding that you can't turn off in Rise, switching storage servers depending on where it is published, etc.
Anyway, here's a demo:
https://360.articulate.com/review/content/bf97c5a3-b2d2-4cc1-9130-a998905da417/review
When I have a bit of spare time, I might put this together as some kind of resource.