Forum Discussion
Storyline Media Organization
I'm trying to address some issues related to Storyline's media organization and the media library:
1. Renaming or relocating source media files (e.g. to reflect a changed source file path or naming policy or to create a "fork" of an existing learning module that uses it's own source media folder in which designers make changes to source media files explicitly for the new version, while the original version stays untouched)
2. Reliably identify changed media files in Storyline's media library. We're using a SVN system that changes the "modified" date/time value to the time of downloading, which becomes an issue combined with Storyline's policy of not newly importing a media file that is already present in the exact same binary version: When I download a project that another team member has created via SVN to the identical file path on my computer, the media library marks many source files as "newer", while at the same time I cannot re-import them because they are binary identical.
3. Creating a comprehensive overview of all media paths and files that are currently being used in a larger project comprising multiple Storyline files (e.g. to quickly identify which Storyline modules need attention when a particular source file that is used across the modules has changed, or to figure out which source files are actually being used in Storyline modules and which are not).
Since a *.story file is technically a ZIP file containing all used media, I can unzip it and have a look at the data organization inside. I have identified the story.xml and theme.xml files contained to hold the information on media source file paths and names and have already solved issue #1 for a project through simple search & replace operations, and the result seems to work just fine.
Now I'm looking at creating scripts (e.g. in Python) to have automated solutions for all described issues. At this point, a documentation of the XML files contained in Storyline and their internal structures would be very helpful. However, I could not find anything like that so far. Is there a documentation already available, or can Articulate make it available for us?
And of course: Are there any plans from the Articulate side to create solutions for issues such as described above inside Storyline?
2 Replies
Hi Martin,
The "Compare" feature in StoryAudit (storyaudit.app) should resolve #2 for you. It diffs two versions of a project by actually hashing the media file contents rather than trusting file modified-dates the way Storyline's own import dialog does, so it'll tell you definitively whether a file changed or not, even after an SVN checkout resets timestamps on files that are actually still identical.
It won't stop Storyline's own "newer" flag or its refusal to re-import binary-identical files from appearing in the first place, which is the bigger issue, but you can use Compare's result to know when it's safe to ignore that flag.
It could handle #3 too, but DShaw's already got you covered there with Media Ledger.
StoryAudit isn't free but has a free trial, so give it a run and see if it solves #2 for you.
There's no official documentation of the internal XML and as far as I know there never has been. I've been mapping it while building some free tools, so here's what I can confirm from pulling apart real project files.
Your search and replace approach is sound. The reason editing both files works is that the media list in theme.xml is a byte-for-byte duplicate of the one in story.xml, so they have to be kept in step or the two lists disagree.
The useful bit you may not have found yet: every <media> element carries an md5Checksum, and its <stream> value is the MD5 of the file as packaged under story/media. The packaged filenames (the generated R5XcGWXUIVZV.jpg style names) appear nowhere else in the XML, so that checksum is the only reliable join between the metadata holding your source paths and the actual bytes. I tested this across a batch of my own projects and every checksum matched. For your Python scripts, hash the packaged files and join on that.
Usage is not recorded in the slide XML at all. It lives in the OPC relationship files: story/slides/_rels/slideN.xml.rels, with the same pattern for slideLayouts and slideMasters. Look for Relationship Type="media"; the Targets are absolute paths like /story/media/xxx.jpg.
A few smaller findings. Slide display names are the name attribute on the <sld> root element of each slide part. Scene names sit in story.xml under sceneLst, and the <sldId> values inside a scene are relationship ids you resolve through story/_rels/story.xml.rels. And if a file contains question banks, those are <scene> elements under quizMgr > bankLst rather than sceneLst.
On your point 2, honestly, I don't think that one is fixable from outside. The refusal to re-import binary-identical files is SL's own import logic. What you might be able to fix is the false 'newer' flags client side maybe...
Your point 3 is the one I built a tool for, originally for my own use. It's a browser tool, drop several .story files in and it hashes everything under story/media, joins the checksums back to the recorded source paths, and walks the rels for slide, layout and master usage. It reports which files are shared across modules, which are stored twice inside one module under different generated names, which have the same source filename but different contents (the nasty one for a team sharing source media), and which are referenced by nothing. On four of my own recent projects it found 63 media files collapsing to 56 unique assets, 14 of them referenced by nothing at all! Runs entirely client side in the browser tab. There's a CSV export. It's 100% free to use...
