Follow These Tips to Reduce Your Risk of Corrupting or Losing Project Files

It’s every e-learning developer’s worst nightmare: you’re hard at work in an application, deep in development, when all of a sudden—the software freezes! You start frantically clicking around … this can’t be happening! When did you last save the file? Are you going to lose all that work?!?

Others (not you, right?) have faced the horror of having an entire project, representing weeks or even months of work, become corrupt and completely unusable. Different scenario, same result. Yuk.

File corruption can happen, even in the best software, and even if you’re following all the recommended best practices. It’s not just a software crash that could wipe out or damage project files; it could be a power outage, your computer crashing, or even just the size of your project file, as very large files have a higher risk of corrupting.

You need to be prepared if a problem occurs and know what options can help to prevent it. To be ready if it happens, follow these pro tips.

Work Locally

You should always save and publish all of your Articulate Storyline files and projects to your local hard drive, which is typically your C: drive. Working on a network drive or an external (USB) drive can cause erratic behavior due to latency, which is the amount of time it takes for the information to traverse the systems. As a result, your files might become corrupted, you could be unable to save changes, or your application might “freeze” altogether.

If you need to copy your project over to a network drive or a USB drive for backup or versioning purposes, only do it once you’ve saved the file and exited the Storyline application. Do not reopen the project file until it’s finished copying.

To learn even more about the importance of working locally, read this helpful article by Trina Rimmer: Save Time with This E-Learning Project Troubleshooting Checklist.

Use Proper File-Naming Conventions

It’s important that you follow some important basic conventions when you name your project files and published output. Do not use special characters, accents, or symbols in your Storyline file names or in any file paths. And avoid using spaces in your file names and file paths; spaces will be replaced by symbols (i.e., %) when you publish the course, which looks messy and could possibly contribute to file corruption.

Here are a few suggestions for naming your files without spaces:

  • Use an Underscore or Dash: Instead of using spaces between the words, use a dash or an underscore. For example, safety_training_101.story, or retail-module-3.story.
  • Use CamelCase: CamelCase is a practice often used in the web development world that includes writing words or sentences so each word begins with a capital letter; for example, SafetyTraining101.story or RetailModule3.story.

With either of these tips, you can easily read your file names without using spaces. Another best practice: always use short names to ensure the file paths to your projects and published output are well under the 260-character limit imposed by Microsoft Windows.

Save Often

Get into the habit of saving your work at least every 5 to 10 minutes. The fastest and easiest way to save your file is to simply hit CTRL+S on your keyboard. You should save so often it becomes automatic and you don’t even notice when you’re doing it.

When you see an asterisk (*) next to your project file’s name, it means your project has changes and needs to be saved:

It also should go without saying that you should always save after you do something complex, confusing, or time-consuming that you don’t want to have to repeat.

Create Versions

In addition to constantly saving your project file, you should be “versioning” as well. To create a version is simply to do a Save As of the file and then save it with a new name; this makes a new version of the file. The number of versions you create will depend on you and your requirements, but here are a few ideas:

  • Daily: You might consider creating a new version of the *.story file every day and including that day’s date in the title. For example: safety-training-03-22-2016.story. This way, if you need to go back to a previous version, you’ll have every day to choose from.
  • Weekly: Versioning every day might be too often for your needs; if that’s the case consider doing at the very least a weekly version of your document. If you choose to store versions less frequently than weekly, you might find you have to re-do a lot of work to get your project file back where you need it to be.
  • Major Changes: It’s definitely a good idea to always create a new version when there’s a major change to the file, including navigation changes or any design changes that are going to apply project-wide. If you change your mind, or need to go back for any reason, you’ll be thankful you made the new version.

How long do you want to hang on to all those versions? It depends, but until the project is delivered is probably a safe bet. After that, you might want to hang on to a couple of versions but are probably safe deleting the rest.

Back Up Your Work

Saving your work religiously and creating file versions won’t do you much good if your computer crashes. To save yourself major headaches when something unpredictable occurs, you need to back up your work OFTEN. How often? How many hours of work are you willing to re-do should a crash occur? I recommend backing up your work at least once a day.

Let’s have a look at some of the options for backing up your work:

  • File-Hosting Service: One option is to use a file-hosting service to back up your project files. The options abound: Dropbox, Carbonite, Backblaze, and many more. Some of these services automatically back up all your files constantly, so you don’t even have to think about it.
  • File or Web Server: Another option is to use a file or web server to upload your files and back up your work.
  • External Hard Drive: A third option is to save your files to an external hard drive. If you do this, it’s still a good idea to back up that hard drive to a server or file-hosting service, in case the drive itself should ever become corrupt.

Yes, there are costs associated with these options, but it’s usually much less than the cost of losing your work, which can represent many, many hours of development time. If you work in an office setting, check to see if the IT department has a backup system already in place. If so, ask about the policy, and then consider making your own backups as well, as an extra precaution.

Enable Auto-Recovery

Storyline does have a handy auto-recovery feature. To initiate the feature, you need to save your project file at least once. It should be enabled by default; but to make sure, or to make adjustments to the intervals, click on File from the Storyline ribbon and select Storyline Options at the bottom of the menu. In the Storyline Options window, you’ll notice the AutoRecovery option.  

When you select this option, Storyline will automatically save a copy of your project at the specified interval and you can recover your work if the power goes out or the app shuts down unexpectedly. The default interval is every 10 minutes, but you can enter any whole number between 1 and 120. Learn more about the auto-recovery feature on this page: Setting Articulate Storyline Options.

Why does the auto-recovery feature exist? If Storyline crashes or closes unexpectedly, chances are you didn’t save before it closed. So, in the background, the application has been doing it for you. This means Storyline will prompt you, when you reopen the file, with a message to recover the file from the last auto-recovery save that occurred.

Exit the Application

Another best practice is to not leave the Storyline application open and unattended for long periods of time. If you leave the application running overnight, it’s possible that a malware scan or disk backup could run because the machine is idle, making your application vulnerable to crashing.

When you’re done working with your project file and about to step away, do a final save, close the application, and back up the latest version—just to be safe.

Check Temp Files

If there’s a crash and your file is lost or corrupt, don’t lose hope: there may still be a working version of your project in your temp files. Here's how to check:

  1. Open this folder in Windows Explorer: %appdata%\Articulate\Storyline.
  2. Scan the contents of this folder for a file that starts with the name of your project.
  3. If you find the file, copy it to your desktop (if you find more than one, copy the latest version).
  4. Change the file extension of the copy on your desktop from *.tmp to *.story.
  5. Double-click the file to open it in Storyline.

If your project file is not there, it may be lost (sad face). But the good news is, if you’ve been following the recommended best practices above—versioning and backing up your work—you’ve hopefully only lost a minimal amount of work.

In Sum

These are just some of the tips you can follow to avoid corrupt and lost project files. Remember, it’s all about being proactive just in case the unpredictable happens!

Follow us on Twitter and come back to E-Learning Heroes regularly for more helpful advice on everything related to e-learning.

Darren Goossens

Very useful thanks, I'll try changing file names (to use a restricted range of characters) and working locally and see if it helps the sudden data loss. Not sure how it will help with the issue where you click in your document and suddenly it jumps you back some number of slides and all your changes are lost. That does not seem like a server/filename type issue, more like a bug in the main interface of the program. I find it weird to find such flaky behaviour. We work on a server as a collaborative organisation and no other application (InDesign, other Micro$oft products, etc) give the same trouble, though they use the same file names and path names and networked drives. Thanks for the info about working around the program's flaws, though, it will hopefully help us get some work d... Expand

Jennifer Brown

Working locally is essential. I don't think it's an application flaw with Storyline so much as it is a conflict with backup/active malware detection. IT security/backup/update processed often interfere with tools like Storyline, and IT rarely understands how Storyline works, unless they work with software developers. Remember that course developers are actually software developers. We may not be code warriors, but we are producing executables that send data from a local system, which resembles malware to aggressive/clunky security software. Storyline is going to react differently than tools like InDesign or most Microsoft products. Those don’t generate executables; Storyline does. Backup software can interrupt normal authoring tool functionality, in particular when you are publishing... Expand

Darren Goossens
Darren Goossens

Here is what I have discovered. Now and again, seemingly at random, while working in Storyline, I suddenly get jumped to another slide, and any changes I have made since working on that slide get lost. For example, say I'm editing a presentation and I've got up to slide 10 but I click in a box and the thing jumps back to slide 4. Then changes I've made since I last changed slide 4 seem to vanish, as if the whole presentation has been reverted. Note: I am now working locally, not on a server, and the pathname and filename have no blank spaces etc in them. Whether Storyline is generating executables or not is not relevant as far as I can see. And we're not doing that anyway -- all we're doing is writing slides at this point, just using tools within the Storyline GUI to insert pe... Expand

WPA Training

I use Dropbox for backing up automatically. But it only backups up the .story file AFTER you exit Storyline 360. Storyline keeps a hard lock on the file so Dropbox can't save it until after Storyline is closed. What I like about dropbox is it does the versioning for you. Every time you save it creates a new version. Yes you have to get in to the habit of closing Storyline every once in a while. I find that happens naturally for me anyway. I close Storyline to move on to other projects so it's never open longer than when I'm actually working on the file. If I'm working on a project for a long time, I make sure to close Storyline and let Dropbox backup the file. It's just like clicking on Save, but it also versions the file for you. If you have any questions of using Dropbox ... Expand