Adding a long text entry box to Rise / Storyline

Oct 29, 2020

Tim St. Clair
By Tim St. Clair

I am using Rise with Storyline being used to extend interaction where they are lacking. I require learners to enter long, (mostly reflective) journal-type entries into text boxes. These are typically 300-400 words. It is highly desirable to have them put in an entry before I release more content.

Rise has no such feature, and I've been using the embed activity type and relying on third-party forms to host a textarea where users can type in their content. This is fraught with problems: What if the form host goes offline / shuts down their service (yep, happened, more than once). What if they change their TOS and suddenly there's ads being shown (also happened). What if they do a product redesign and your content no longer fits (yes, happened as well). Or, am I happy to have a public-facing github repo I can serve from that anybody can just access from where-ever? Here's my favourite: Client has corporate desktops and their [forced] browser is still IE11 - but third party form host has dropped support for it. Ugh!

All this just to store a text box?

I've been trying to solve this by using Storyline 360, but it's not quite up to scratch either, because of scrolling and keyboard interaction problems in that product, and mobile/tablet support. The cool bit is that you can make the continue button only show up when the course is completed, such as saving the interaction. But there are lots of downsides. For instance, did you know a text entry box doesn't (won't) show a scrollbar, even if it needs one? And interactions such as using the scroll wheel or cursor keys won't cause the text entry box to scroll? The tablet / mobile experience is awful because of the need to click to open the interaction, then the text size scales relative to the stage so it can be all but unreadable (essay writing on a phone isn't something I have to solve, it's mostly tablets and desktops).

If I take out the scrolling panel and just have a text entry then it removes the problematic overflow issues, but there is no indication whatsoever that the panel is scrollable. Mouse wheel works; cursor keys work; tablet/mobile still is as unfriendly as ever; there's never a scrollbar even if it needs one, and my learners are the type who need such visual cues.

Thinking more outside the box, I've been tinkering with the idea of embedding a plain old textarea inside an iframe which then gets copied into the final scorm package. This has its up- and down-sides as well. An upside of this is that the textarea works everywhere, is easily responsive, text is readable and with some trickery the text can be persisted, and can inherit the background colour / font styling etc of the block it is hosted in, or grow in height to prevent scrollbars.

The big down-side is that to insert it you have to use an iframe, which has to be hosted on the internet somewhere at design time (I use github pages) but substituted with a local copy after publishing. It won't function properly at design time entirely as intended because of cross-site scripting protection in browsers. The process for patching in the content after its published is also pretty tricky if you aren't used to coding.

The biggest downside to this is that the Continue button is immediately available because the block isn't completable. My example above uses the same system that Storyline does when communicating completion data between the iframe and host, effectively this (minus the xapi verbs, etc):

 var message = {
  windowName: parent.document.querySelector("iframe[src='"+location.href+"']").closest('[data-block-id').dataset.blockId,
  payload: {
    result: {
      completion: true,
      score: { scaled: 1 },
      success: true
    }
  },
  type: "course:update"
 }
 window.parent.postMessage(message, '*');

but the problem remains that the embed block isn't completable in the first place and as such the player won't lock the Continue button (I'm making some in-roads into modifying the Runtime object as I initialise my textarea and triggering a reflow on the player to switch it back to a 'must-complete-above' button, but this is getting in to ridiculously unsupported territory now).

All this would be moot if there were plans to just support plain text entry as an interaction, or if Storyline showed scrollbars when it needed to and didn't scale the fonts relative to the stage, or if the embed interaction had conditional completion flags (wouldn't it be great to complete after you watched a Vimeo, for example? Their player supports the messaging events, but Rise doesn't listen to them).

Has anybody got a better way to enter long text that is consistent?

12 Replies
Tim St. Clair
over 2 years ago12/15/21 at 3:22 am (UTC)

... some time later, I find myself on another project and needing to revisit the same again. I've attached a simple Storyline file which does some of what I need. To get to this basic interaction I've learned a lot along the way. I also want to show the user when they had already stored a value, as in my Rise course users move forward or backwards in the navigation quite a bit to pick up details here and there - so when they went back to previous pages and discovered that their answers didn't appear to have saved after all (and being text entries, it's a big deal when what you spent ages typing in suddenly isn't there anymore), things got more complicated.

  1. My scrolling issue with Storyline and scrollbars is actually a bug in the "modern" player. Scrolling panels, in particular the text entry fields, just will not show scrollbars. Not so with the "classic" player - the exact same file published with classic works as intended. Just need to turn off the navigation, choose a custom theme to turn off the ugly classic background (I chose "my background.xml", which lives in C:\Users\YOURNAME\AppData\Roaming\Articulate\Storyline\360\Frames\StoryFrame\ColorSchemes - spent some time figuring out how this file works since there appears to be no documentation about it anywhere).
  2. When you play a storyline file in a LMS, any variables you set are persisted in the scorm suspend data. This is easy to read and write using player.SetVar("varname",value). You write the varible, it get saved right? No! You write the variable AND THEN the user navigates to the next slide and THEN it commits this value to the SCORM data. Since my storyline was a single frame that showed a layer after the interaction, it never left the frame; it never saved the data. So now instead of a second layer, I have a second slide. There is no "Set this variable and then save it" feature or command. We work with what we have.
  3. You'd think this would make storing and showing values easy. Publish a Storyline file and put it into the LMS and yep - variables are saved between launches. My learners can put in the value in the text box, exit the course, come back later, the box still shows what they typed in. But then I discovered a big old gotcha - when you embed a Storyline file into Rise as an interaction, it doesn't persist anything - just throws it away.
  4. In my storyline course, I set a variable called 'Saved' after the user clicks the submit button, then head to the last slide to show the feedback. The last slide also has a Back button which unsets the Saved variable. Next, I make a value that should be unique NOT ONLY for a user but also in case I have embedded multiple instances of the same Storyline interaction on the same page in Rise (since Rise will refer to the same file if it has already been used, rather than storing multiple copies). So the unique value has to discover which iframe is used to embed the Storyline package, then determine the user who is doing the interaction (in case the computer is shared, such as in a classroom lab), and make that the unique value. It then stores this in the BROWSERS local storage. Not great. It's not anywhere in the LMS. I can't read it without going to that machine and looking at the local storage. A better option will be to post it to some external service using ajax or xapi or something (it's on the to-do). When the interaction loads again, I read the local storage value and if its set put that into the text box but also set the Saved variable and then send them back to the feedback page again by doing a jump trigger. Trigger order is important.
  5. One major annoyance is that Storyline can't preview javascript. It shows a warning about it every time. I ended up setting up a web server and publishing the Storyline each time to that folder (luckily it overwrites without prompting) to test my javascript changes. Highly frustrating. EVEN worse is when I want to test within Rise - I have to publish from Storyline to Review 360, THEN in Rise change the interaction to point to something different, THEN change the interaction a second time to point to the file that I just updated from Storyline, THEN export the Rise course to a SCORM testing harness (a bit like a dummy LMS) so that I can see the course picking up or setting scorm values. It's like 20 clicks in an exact order just to test a single javascript change. Rise has this wierd problably-bug where when you want to re-select the same interaction from Review (because you updated it from Storyline), it might update it, but then again it might not, and you probably won't know either way until you export the course. A "reload/refresh" button on the settings page to re-link to the same Review interaction would go a looooong way.
  6. A second annoyance is that in Storyline if you're editing your javascript and accidentally hit escape key, that window dissapears and all your changes are gone. No warnings that the value had changed, and no autosave. I did this more often than I should have. Grrrr!
  7. I have picked up techniques in javascript inside Storyline, such as using var player = GetPlayer(); to get access to SetVar and GetVar which can read and write variables set in Storyline. I have discovered a routine people are using for findLMSAPI to attach to the SCORM runtime that the Storyline player uses, and be able to use the methods available there like lmsAPI.GetStudentName(), which uses the SCORM data to find out the name of the learner who is doing the course. These are inside the attached storyline file for anyones reference.
  8. Having Rise release the Continue button after a storyline interaction only seems to work if the Storyline performs a score? I read that somewhere, I couldn't make it work for a non-quiz based interaction like this. (I couldn't make it work at all, to tell the truth).

The whole experience for just storing a text entry is a real problem for me. The need to be able to enter text and have it store is something I dearly miss in Rise; Storyline can do it (even with its silly scrolling bugs and at-times terrible user experience).

I hadn't done a lot of Storyline interactions and embedding them into Rise, so the discovery that Rise doesn't care about Storyline's outputted user data (which page they are on, what states slides are in) is a real downer for me. It's the exact stuff I need to be able to track and report on.

Rise just has this gaping hole that prevents any interaction data about the Storyline embed from ever being stored or persisted. It also seems that for every thousand "wouldn't it be good if Rise could ..." type request or comment only one or two slip through as new features every year. Rise has so much untapped potential.

If Rise persisted the storyline data out of the box, all this would magically become easy and I could throw away my complex javascript altogether. 

Phil Mayor
over 2 years ago12/15/21 at 7:55 am (UTC)

Great explanations Tim.

My initial reaction was to say wouldn't it be better if Rise implemented a text entry tool that sent the data to the lMS and resumed (even better if it would allow the blocks to communicate with each other).

However, I also get what you mean with the storyline blocks if they could resume then it would be so useful for other interactions built using Storyline.

I think there is an argument for Rise to have variables, other tools such as Adapt, Evolve, Gomo have these would be even better if the variables could be easily passed between storyline and Rise. I love the tool for its simplicity but often there is a need for more.

Snorre Rubin
2 years ago02/03/22 at 1:43 pm (UTC)

I have created a solution for this.

The attached story-file, when exported and added as a block does a number of things:

  1. hides the actual storyline block
  2. creates a more responsive user input field
  3. saves/retrieves the user generated data from the lms via user-comments. 

Note that number 3 works in SCORM2004, as the codes are rather specific. I am sure the commands can be amended to fit other LMS-standards.

Tim St. Clair
1 year ago02/06/23 at 8:49 am (UTC)

I have again tried to attack this problem in a few different ways. I need to:

  • Attach multiple text entries in a course
  • Have entering the text(s) be able to complete the activity so that you can use the 'Continue after completing the activity above' feature.

I tried taking Snorre's example (thanks!) and modifying it to work with whichever SCORM version you publish Rise to, but discovered there really isn't anywhere to store the responses - in Scorm 1.2 the user comment field is append only. So I implemented a bit of detection to see if SCORM 2004 is present and if not, to use sessionStorage (which persists in the browser until the user closes the tab). Not a fantastic solution, and leaves me wishing for something native in Rise. It *might* be compatible with AICC, but I have no harness to test it in.

I've attached two storyline files.

  1. 'Dynamic User Input using Scorm' is based on Snorre Rubin's idea. It uses javascript to modify the parent to hide the storyline file and implement a textarea that saves when it the focus moves out of the textarea. It has feedback showing that the value has been saved, and optionally has the ability to add question text, placeholder text, and completes the activity when it saves successfully. It only supports one textarea at a time.
    1. Pros: It looks better in the published Rise course, as it uses the 'Text Block' styles to maintain the existing look of text, and the font / background / padding is maintained properly. It will save in the SCORM user comments field in 2004
    2. Cons: It does NOT work in any Preview or Review functionality, as Articulate do not run javascript in those environments. You have to export it and host it on a LMS or testing harness. You have to edit Storyline variables to set it up.
  2. 'Two text entries' is my stab at allowing multiple text inputs. My requirement was that some responses allowed more than one text entry before it would be saved/completed, so I tried to make a generic storyline file that's easy to modify if there is only a single entry.
    1. Pros: It works in the editor, preview and review tools. It can support 1 or more text entries.
    2. Cons: The text renders using Storylines engine, not Rise's engine, so fonts / sizes and such as less predictable. The data is only saved to sessionStorage, which is lost when the tab hosting the course is closed. When using 'Modern' skin, you don't have a scrollbar on the text entries (it's a bug). The triggers are tricky - you have to edit a Tally condition to match the number of entries.

I had thought about implementing some other features but have run out of time/energy this round:

  • Using text compression to store the inputs to allow more data to be stored without hitting limits (and Rise has that handy lzwcompress library sitting there which it uses internally for suspend data)
  • Posting/Retrieving the data to an external storage endpoint
  • Posting/Retrieving the data using xAPI calls

I hope this helps someone out in the future. I also hope that Articulate officially implement a Text question type to save these flimsy solutions.

Tim St. Clair
7 months ago09/26/23 at 2:27 am (UTC)

Since writing this post, I've tried several ideas out.

 

At the end of this thread - https://community.articulate.com/discussions/rise-360/learner-notes-input-boxes?page=3 - there's a demo of a note-taking feature I to Rise added using a storyline course.

I also have a demo course for playing with text entry load/store/pdf: https://360.articulate.com/review/content/bf97c5a3-b2d2-4cc1-9130-a998905da417/review ( from https://community.articulate.com/discussions/articulate-storyline/rise-storyline-reflections-journaling-issues)

And another crack at it in this thread - https://community.articulate.com/discussions/rise-360/adding-a-text-box-for-user-input-in-rise360

I think the latest storyline file containing the text entry and all the other bits would be the one in my repository (https://github.com/frumbert/local_blobstorebackend) - the storyline file is in the assets folder. This is a work in progress.

 

Sign In to Reply