Moving a story file

Hi Martha,

You should be able to share the .story file via Dropbox without a problem, but if there were specific fonts that you purchased or downloaded, those may not display if not install on the other computer (they'd be embedded in a published version of the Storyline ). 

You'll want to make sure that you take the .story file and any .storytemplate files and move them onto the new computer. 

The fonts that are going screwy are the Articulate fonts. I did have a Google font I was using, but it was fine after I realized that I needed to install that font on the new computer. 

After posting this, I found an older thread where the person appears to have had a similar problem to mine, and one of the solutions that they gave her was to delete the Articulate fonts and then repair Storyline by reinstalling. I've gotten as far as deleting the fonts, but then I realized that I didn't have the product key, since the laptop was sent to me with it installed, so I've been waiting to get that information and continuing to edit on my current machine while holding my breath that it doesn't crash.

I'm curious about why my file has problems when other people aren't having any. Maybe they aren't using the Articulate fonts.

Thanks Martha for the update - please keep us posted on if that solves your issue.

I will definitely let you know what happens, but it probably won't be until later in the week. Right now, I'm working against a big deadline where I need to deliver the first draft by tomorrow morning, and I've already lost several hours due to this problem, so as long as my computer is working, I'll use it to finish up the draft and worry about the rest later.

Understood Martha! Thanks for the update

I've had similar problems when moving the Story project file to a different computer, or when collaborating with a colleague who is going to work on a different phase of the project. Aside from fonts, I've had audio files suddenly disappear after I have imported them into the project file. Can anyone advise on how to transfer Story project files to avoid these issues? Thanks!

Hi Ruth and welcome to Heroes!

You'll want to follow the method outlined here for a collaborative work flow. 

Hi Ashley, thanks for the link to the suggested collaborative work flow. I'm not sure how that process involves collaboration with other people, however, with other computers. It seems to require that the same computer be used to edit or re publish project files. We work on some huge projects, and different people will be working on different phases of production: after the module is built, a different person will be importing and syncing the audio, for example. Any help there?

Hi Ruth, 

Different computers, all accessing the same files from the network drive, it'll be important for each person to download or copy it from the network and then work off the local drive. If you're all going to be working on separate parts of a file, you may want to divide it up so that there are not any version-ing issues where another user may overwrite your changes when placing the file back on the network drive. 

I understand about working on the local hard drive and version control. Maybe what I'm asking is so basic that it isn't getting through: simply put, in the past, when a coworker has taken a project file created on my computer and worked with it on his computer, occasionally sound files that I had imported into the project file seemed to disappear (even though they appeared in the timeline, they did not play, and he received a message that it could not be found).

My question is: Does my coworker need to have all the sound files, images and other media assets (although already imported into the project file), organized on his computer in the exact same folder structure as they are on mine, in order for us both to be able to edit the file without weird issues occurring?

Thanks.

Hi Ruth,

If you're sharing the .story file as previously described and each individual is opening it to work on from their local drive, any media (image, sound, etc.) that you've inserted can be moved and used within the project itself. A link to a local file, though will not be accessible. They also wouldn't be able to access the original media file outside of Storyline.

You may also want to look into the back up methods described here, especially if you're able to use dropbox. You could house the project files there in a shared folder (although for versioning purposes, you may want to implement a method where the individual needs to update the file with the date/time at the start to ensure you're both not overwriting the others work.). 

OK, well I don't know what else to say. We did share using Dropbox, and my coworker did not have the original media (image, audio) files on his C drive, as they had already been imported into the project file by me -- so according to your response, the audio should not have disappeared when he tried to work with the project file. That was my expectation as well; which is why I was baffled when several audio files disappeared. (Twilight Zone music...)

Hi Ruth,

Are all the images and audio files still in your original file? If you'd like to share it with me I'm happy to check and see what happens on my end. You can post it here in the forums or you can send it along to me by submitting a support case and including the following syntax at the beginning of the Description section -

::ashley::

That way it'll be assigned to me and I'll be able to investigate further. 

We do eLearning storyline projects for clients with external pdf files that they provide and we link to from storyline. When the project is done, they request the authoring (story) files. When the files get moved to their computers the pdf links are all still pointing to our local drives so they have to relink them all. Is the discussion in this thread still true of Storyline? It is an inconvenience to our clients. Is there a better way?

Hi A, 

Thanks for reaching out here. It's been reported as an issue in Storyline 2 after update 4 (we're currently on update 7). This issue is not present in Storyline 1 Update 10. For Storyline 2, as a workaround after you attach the resource file, publish the .STORY file. The resource will then be saved in the .STORY file.

We'll include this thread in the report filed with our team so that we can keep you posted once there is additional information to share. 

Ashley, 

Regarding linking PDFs, are you saying when you publish the file, the PDF gets embedded into the .story file? That has not been my practice. We have them hosted on a shared drive, and it ALWAYS points to the shared drive. 

When we then share with a client, we lose the links, so we have had to keep them together (this is up through Storyline 2 version 7. 

Thanks!

Hi Alex,

It was broken in Storyline 2, as I mentioned above for linking within the .story file and then sharing that - but when you publish the course, the file should be included as a part of the publish process regardless. We don't recommend working on a shared drive though - so that may be a part of the issue you're encountering. I'd look at working on local project files and ensuring you're linking and publishing locally as well. 

The issue in regards to the link within the .story file is still in the hands of our QA team, so I'll be sure to share any updates here once they're available. 

Thanks -- we have a few developers working on it though -- so it forces us to link to a shared drive. We pull down the .story file, but the links remain the same, it's the only way for them to consistently pull regardless of who publishes.

If we linked it to a webserver, it would always keep the weblink and wouldn't actually import the file into the storycontent folder, correct?

Hi Alex,

You could look at uploading it to the shared drive after the fact, following the collaboration article here. 

If you were linking to a document as a web object or URL on your server, that may be a better way to ensure the link stays active as it's not imported the file but referring to an external site. 

Hi Ashley

Has the issue with links to files (PDFs) been resolved? I'm using SL2 Update 10 and links to files (doc files in my case) still seem to be broken if the external file isn't there when I publish. Even if I've published beforehand it while it was there. The file doesn't appear in the external_files folder in the published output.

I have a project with several modules, with numerous linked files, that I need to hand over to a client soon (.story files). It will be very messy if we also have to pass over all the linked files and they then have to remake the links at their end.

Thanks.

Hi there, Dayn.  I'm sorry you're feeling hung up on this issue as well.  I can assure you that our QA team is investigating this behavior, so please stay tuned for an update.  We'll post a comment in this thread as soon as we can.

The workaround that we've identified for the resources not properly attaching is to attach the resource and then publish the file.  The resource file should then be properly saved in the .story file.  It sounds like you are not having success, though.

When you attach your resources and then publish your file, are you finding that those resources are still not being preserved in your .story file?  Is this happening in every file?  Also, are you working on your local C: drive, including your resources?  We'd be happy to help you test it out if you'd like to submit your files to us.

(edited to add a missing word)

What would be very helpful is if you could link to a pdf or external file with a RELATIVE path (instead of it defaulting to C;\mydrive\myproject...), That way we could hand over the story file with the pdfs inside of a directory and the links would be preserved. Hope we can do this soon, clients hire us to start projects and then want the files themselves so they can finish it in-house. Right now they have to re-link all the external files when they get the project, even if they are attached as a resource.

Hi A,

It's not a current set up, but again you're welcome to share your thoughts on this directly in the form a feature request. 

okay, thank you!