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?

The video control functions are limited. In order for us to not allow them to fast forward through a video, we have to sacrifice the speed button controls. We we want them to be able to control the speed in which they watch the videos, but not fast forward without watching the videos, if that makes sense.  

Thanks for that! I think that is a little too many steps for us at the moment.

Hi Robin,
I've witnessed eLearning participants take courses with locked down playhead controllers actively avoid any engagement with the course by simply opening them in a second screen and allowing slides to play out before glancing over and clicking next. Disengagers gonna disengage. But I think those people are a very small percentage. 

Seat time requirements can dictate using locked down navigation/video controls, but lacking those requirements, I think giving participants autonomy and responsibility is a better strategy. 

It sounds like your project -- which goes to a level where learners are expected to create an essay -- is engaging and sufficient to cause them to want to view the content. 

Just my 2 cents!

Bob

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?

Sure thing. I’ve attached the two Storyline files that store/retrieve the text, and call the PDF generator. You need to publish these to Review then include them in your Rise package to make them work (they work in the editor/preview as well). You don’t have to modify anything in the Rise outputs.

You can download my Moodle back-end plugin on my github - https://github.com/frumbert/local_blobstorebackend (in production in Moodle 3.11, haven’t tried anything older/newer but is probably fine). There is a default fallback service which the Review version will be using which communicates back to https://blob.frumbert.org (source: https://github.com/frumbert/blob.frumbert.org) for raw storage.

The code documentation is a bit rough - message me if you need to understand it more or if it doesn’t work in your situation.

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 🤣

the size of the two .story files is 0 bytes each, something must have gone wrong during uploading

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.)