SCORM customization to remove slide?

Hi lorraineS​ it is not possible to update the text in Storyline without using the source file and re-publishing. The reason is that when published, various calculations are made regarding the length of the line of text and space it accommodates. This is added to the published output so that the browser renders the slide accurately.

The text you are looking at in a Storyline course running in a browser is an SVG rendering (image) of the slide text. There is then another version of the text that you cannot see which is available for assistive technology.

You will find that if you edit the text that is associated with the SVG rendering, it will affect how the text renders and you are likely to have overlapped characters, too much spacing and other weirdness going on. The reason being, the project is expecting a different line length and characters.

Images are simpler, as you can just find the image and swap out with a new one as long as you use the same image name, format and aspect ratio.

I think what I'm saying is, it's not worth it. It's best to keep the Storyline author file up-to-date with the latest changes and publish from there.

Sam's comment aligns with my understanding of editing the source content itself. What you describe would be amazing but isn't currently something I've seen pulled off.

If the conditional changes you describe are predictable and simple enough, the next best thing would be some sort of .ini-like file. The implementation might not be a breeze for everyone, but the solution (as I've implemented with prior projects) would be to have the eLearning read a text file when it's launched, a text file that contains different settings and text.

One of my specific implementations was to adjust the number of scenarios available to learners in an eLearning hosted on a web server. Users would navigate to the course through an intranet URL, and when the course loaded, it would check a .js file that included a simple JSON object. One of the key-value pairs described the number of scenarios to allow the learner to choose from. The first ten scenarios were designed for learners taking customer-facing calls and the second ten scenarios were for learners taking client-facing calls. Some new hires needed to train on all 20 but some only needed to train on the first 10.

It didn't make sense to have two separate versions of the same course with one containing ten scenarios and one containing 20, but leadership didn't want to leave scenario selection up to the learners, and the course had no way of validating which ones a particular learner should've been taking, so we let one number variable in the .js file do it for us. Oh, a class is starting in a few weeks and they only need the first ten scenarios? Open up the course's .js file, change the 20 to a 10, and then save. The next time it ran, the course would check that file, and then use it to limit the learner on the scenario-selection screen.. The right-arrow would literally stop at 10, preventing the learner from accessing the subsequent scenarios. When it came time to open up the rest, edit the file back to a 20, and now the arrow can load the 11th scenario, and then the 12th...

If your alterations to the course are predictable enough, such as certain clients not needing certain slides, I can imagine a way to put that in a JS object, have it read at runtime, and then the course adapt to skip those slides. And if certain specific onscreen text is actually a variable that's loaded at runtime, that can be affected as well through that JSON.

This would require appreciable planning ahead, but it is doable so long as you're not wanting to change unpredictable things at the whim of every new client.

I would ask, why not edit the storyline. Some things are possible others are not worth it. But, the big issue is that by doing this your Storyline file is not in sync with the client version so if they ask for an edit that needs athe storyline file opening then you will have to make those edits again in the source file. Honestly not worth the trouble, most of the things you suggest are easier to change in the source file that finding where they are in the published file.

AndrewBlemings-​ is one of the options you can try and will definitely work. You would need to factor this into the initial build.