Rise & Storyline: Reflections/Journaling issues

Hi Robin,

"localStorage" may be a method to tack your essays together from three different sessions. There are some threads about localStorage here and some videos on youtube.

In the Flash days, I used SharedObjects to do something analogous to what you describe and it worked well. localStorage places variable data on the client browser side and makes it either persistent or session only.

I'll be blunt, I think it could be a real headache to sort out and there may be issues based on browser support and individual browser settings.

Reading your post, I think the easier path is to work out your video dilemma. Is the size of the videos creating a performance problem or are you dealing with deployment standards? Could the videos be reduced in dimension or compressed further? Is Vimeo an okay compromise to stick with given the competing technical hurdles?

Hope this helps,

Bob

what was your problem with vimeo?

Hi Robin

We have done a number of projects in Storyline where the creation of a downloadable learning journal was required and I have published a couple of articles here on how to use JavaScript to do this.

I also published an article on doing this in RISE using local browser storage. The problem with RISE being that you can embed Storyline Blocks to collect learner input - BUT the Storyline variables are not retained once you exit the Storyline block. To some extent this is similar to your challenge. In the RISE demonstration we did, there are a number of Storyline blocks and we needed to consolidate the learner input from each block into a single pdf document at the end of the RISE course.

In your case you have a number of Storyline modules, but the problem is the same. As Robert correctly surmised, this can be done using local browser storage BUT, the caveat is that you will lose the data betweeen modules (a) if you change browser (b) if the learner clears the browser cache or (c) if you take each module on a different device. So, although it would work it isn't ideal.

The real answer is that you need to find somewhere to store the data between modules. And that means writing it to a file or a database somewhere. We use pdf forms as the template for our learning journal because it means they can be modified easily withoout having to change any code. We are about to start a project where we will attempt to open a pdf form template - write to it - save it with a filename specific to the learner - then pick that file up again and append more input to it. I will let you know how that goes!

The other possibility is to write the learner input to a Learning Record Store (LRS) using xAPI - but I'm sure there are far better qualified people here to advise you on using xAPI calls from Storyline.

Hope that helps.

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.

Hi Tim

Your demo is working perfectly on Review. I am looking for a solutions pretty close to yours. Do you like to share the ressource?

Hello Tim

Awesome! Thank you very much!
I will dive into the code and come back here in case of further questions.

@Tim: Unfortunately I am not able to open your files in Storyline360. I am getting the message, that the files can not be opened due to being made with an older version of Storyline. And if I try to import them into a Storyline project, Storyline crashes 🤣

Additionally, I am looking for a possibility to set a cerain number of characters for a text field. I tried JavaScript but I am not getting it to work porperly.  I think JS shouldn't be written directly into this chat, thus I am uploading the code as a picture. 

I am happy about suggestions on this.

Hmm. I’ve zipped these storyline files this time (even though storyline files ARE just zip files). Hopefully they attach properly this time.

Also, in your code, you don’t need domcontentloaded: Storyline is loaded, it is executing the javascript inside an event called from some condition such as the timeline beginning. If you change your event to input then it should handle any change within the text area (such as pasting), rather than checking for / blocking keystrokes.

Hello Tim and everybody 

Thank you for the hint about the JavaScript query.

After struggling a bit further on with the script, I found a much easier built in solution. Unfortunately I didn't know about it earlier due to a lack in documentation. 

One can simply limit the number of characters allowed in an input field by defining so in Storyline's form view. See screenshot attached.

(I wish really wish there was a better documentation on this.)