Storyline file size

Hi all,

I am curious about the Storyline file size (not the publish size). Here are two case study:

1. Start with a new file, and just created one slide. The file size is around 165KB.

2. Start with existing file that has 65 slides. The file size is around 40MB. Deleted all the slide except one slide. The file size went down to 2MB. 

So here is my question? Why can the file size does not go down even more? Is Storyline keeping all the "junk"? 

Can someone explain this? and if there is a way to "optimize" the file size?

Thanks in advance.

45 Replies
Cameron Wood

This bloating issue is still a problem in Storyline 360. Save as only removes so much cached data, there is still at least 30% of the data remaining. I have 40 story files that only have a single video in them that are double the size of the video. Makes working out of a repository extremely aggravating and development takes a huge hit having to re-insert videos and there triggers/animations every time we change a video.

I'm not interested in sending all of my story files for you to look at. That is not a solution for this problem anymore as from all the users above with the same problem and responses.

I'm going to move our enterprise license and all the seats to Captivate.

Justin Grenier

Really sorry for the trouble, Cameron!

A project file might not immediately shrink in size when you delete a video. Storyline keeps deleted assets temporarily after you delete them in case you need to click Undo to restore them. The good news is your project file will eventually shrink, usually after saving it a couple times. But you can also get it to shrink right away by saving and closing the project file, then re-opening it and saving it again.

Cameron Wood

I went through and tested the re-saving option on multiple files. I opened and resaved 6 times resulting in a file size that was no less than 2X the video file it contained. The only way to get it down to normal size was to import the scene into a new file, which is just too daunting of a task when you have 40 courses (all with individual story files/SCOs for each lesson) and a catalog of 100+ more courses on the docket to be converted out of flash.

I realize most companies will not have this large of a course catalog, but with companies that do, this is what we would call a "critical" or "game-ending" issue. And from what I can see this issue is 5 years old (according to other's posts).

We appreciate your given solutions, but as of right now they just aren't conducive to a large training department.

Justin Grenier

Wow Cameron, it sounds like you've been through the ringer to no avail.  As you mentioned, there have been a couple of other folks in this thread who've also found that the save-close-reopen-save trick didn't work for them.

The sticking point has been that we haven't been able to reproduce this behavior internally, and I can't see a record of where someone was able to share a file with us that exhibited these symptoms.

I understand you'd also rather not share your file, but since it's the best way for us to demonstrate the problem and document a defect, we'd happily accept a .story project shared here privately if you change your mind.

Cameron Wood

Our company conforms with export compliance laws and can't share data with foreign nationals (government contractor). Since we have no way of screening your employees, the best I can do is share a screenshot of the story file size and the video's size side by side.

Attached is a screenshot.

Justin Grenier

Thanks for that, Cameron.  The red exclamation point icon overlay is a little unexpected.  Is there a backup service monitoring your files?

You also mentioned that you are working out of a repository.  Does this mean that you are working from a network drive?  Does the problem persist if you try the save-close-reopen-save trick on your local hard drive?

I also wanted to share a link to our Trust Center, in case that might help with compliance concerns.  We have a mutual NDA that can be signed privately if you like.

Cameron Wood

Hi Justin. That exclamation point icon is just a TortoiseSVN marker saying the file is in a conflicted state (changed based on file size) . All the files are on local SSD's, and when we want to commit them to a network drive, we perform a separate upload. There is no network drive we are working off of or real-time syncing service being used. So when I say repository, its just files marked locally that we upload 1-3 times daily.

I will hand your white-paper, Security policies and NDA to our export compliance team, but without confirming citizenship of everyone who has access to where the files are stored, I doubt we will be able to send you any data. But, I will run it by them and see what they say.

Tennille Nicolette

This issue of Storyline (3/360) secretly keeping every deleted object and bloating the file size is difficult to deal with. It affects delivery quality (download speed). Working around it by carefully cropping files outside Storyline is time-consuming and annoying. Please develop an auto-purge of deleted objects at file save.  

Matt Stafford-Clack

Hi, similar problem though happening from a different angle, I guess.

I've been focused on minimising the size of a specific output file when you publish for HTML5 (paths.js) as in testing the size of this file (and hence the unexpectedly long download time) was causing the course launch to time out within strictly managed networks.

So after publishing I habitually check the paths.js file. What I noticed was that when I imported all the slides into a new empty course (to shake off some file corruption that seemed to be creeping in - "this project is locked by another process") that paths.js file had dramatically increased in size from 3.2MB to 5.6MB even though nothing content- or navigation-wise had changed.

It's almost as if the import brought some large component of the existing information with it then "forgot" it had it and re-created it again. Digging a bit deeper I found some sub-files within the .story container itself that definitely contained "historical" content that was no longer in the course - specifically summary.xml within docProps. Further, that historical content was more than a few save, close and restarts ago, in fact it predated the import, so should presumably have been purged a while back?

Another interesting wrinkle is that the summary.xml file showed my slide and navigation count as 440 - exactly double the number of slides I thought I had!

Any thoughts?

Thanks

Matt

 

Matt Stafford-Clack

Just a thought in case it helps: a large chunk of the course I'm currently working on was originally part of another course created in Storyline 2, upgraded to Storyline 3, then imported into this new project so I didn't have to rebuild it. So it's a mixture of old, upgraded, SL2 slides and brand new ones.

Is it possible that there are enough differences in how SL2 handled publishing content for HTML5 (particularly text as that seems to be the root of my own situation) and SL3's upgraded handling that SL3 doesn't "know" what to do with the legacy SL2 information, so just leaves it as junk code in these files?

For a small course I can see that having a bit of unused code floating around that doesn't interact with anything wouldn't have any impact, but for very large, text heavy courses like mine it might start to manifest as a problem.

Matt

Ashley Terwilliger

Hi Matt,

That's another good thought - and the HTML5 publishing methods from SL2 to SL3 (or SL360) were a total rewrite to support a broader HTML5 output. I wouldn't have thought that it'd carry over that old code too - but I'm far from a programmer or coder! I did share the update here with my team, so they'll use that info as they continue to investigate. 

Let us know if you stumble on any other tidbits! 

Matt Stafford-Clack

Hi Ashley,

A further tidbit as requested!

It's been happening for a while, but I hadn't made the (possible) connection to the current issue, where every time I open one of my courses for editing I get a warning about a missing font. Fair enough except the font it's warning me about is not used at all in these current courses! It was however used in some slides I imported from another project many moons ago before I changed the fonts to match the rest of the content.

It's got me thinking of two things:

  1. This would seem to support my guess that SL3, at least in my case, is dealing with some historic data somewhere that isn't clearing properly. Unless there's another reason the programme might pop up that warning?
  2. Is there anything SL3 does when it thinks there are uninstalled fonts that might be contributing? Perhaps it collects/generates more information in the paths.js file about the attributes of the text objects as a precaution - given the amount of text I have across the course even a small amount of additional code per line of text would multiply up rapidly.

Regards,

Matt

Ashley Terwilliger

Hi Matt, 

There was an earlier issue where that messaging would appear in error, such as when the fonts weren't used, but that has been fixed in an earlier update of Storyline 3 and Storyline 360. 

I can't remember if we've checked that already, that you're on the latest update of Storyline 3? It would be update 4. 

I can definitely share the other tidbits with the team, and we'll keep you posted here.