Adding a long text entry box to Rise / Storyline

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