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 important 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.

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.

34 Comments
Nicole Legault
Jennifer Brown

I've always been an advocate of "Save Early, Save Often, Save As, and Save Local" having started out in tech support. It's good to see an "official" source that can be shared with IT support/new users. IT often requires proof, and they don't know how to respond to the emotional retelling of That Time You Lost A Week's Worth of Work and You Just Can't Go Through That Again. Great tips about naming. I do recommend using YYYY-MMDD date naming conventions, because they sort better. I use a variation of ShortName_v#-# for my Storyline files. The first number in the version originally is a 0 and won't change until release or client acceptance. The second number changes whenever other eyes look at the course. I've found that it's really easy for someone to get versions confused, especially... Expand

Nicole Legault
Stephanie Dyke
Victoria Aleman
Tatum Bernardo
Nicole Legault

Hi Pete! Thanks for bringing that point to our attention - it's a good observation, and one I did bring up internally for discussion with our developers. In a perfect world, the path to the published output should not contain encoded characters. However, as you pointed out, the published output folder name in Storyline does use spaces. That has been the case since Storyline 1, and it doesn't seem to be causing issues for our customers at this point in time. That aside, I'd still recommend you follow the best practice of changing the name of the published output folder (so it doesn't contain spaces) before you upload it, if only to be on the safe side and to not have a messy-looking URL string. Thanks for being such an observant community member, and for bringing up that very g... Expand