\n

E-Learning Heroes is handy for getting quick tech support for your Articulate 360 projects when you need it. But what if I told you there’s an even faster way to troubleshoot the most common technical problems, a checklist that takes just a few moments and doesn’t require you to be super-techie, open a support ticket, or even draft a forum post?

Next time your project hits a snag, save yourself some time and frustration by checking off these three items:

\n

Item #1: Your Project File’s Location

\n

If you’re working in an office or corporate setting, odds are your computer is part of a group of computers all sharing access to the same computer or server on a network. If this arrangement sounds familiar to you, you likely have access to a network drive—that is, a drive where files are stored and shared with your coworkers.

\n

A local drive, on the other hand, is a disk drive that physically resides on your computer and isn’t part of another computer on your network. For example, most computers running Microsoft Windows have a local drive known as the C: drive.

\n

Creating new projects or editing existing projects from a network drive rather than a local drive, or publishing your projects to a network drive rather than a local drive, can lead to troublesome technical glitches like file corruption, crashes, or an inability to save changes.

\n

Why can working from a network drive cause these troubles? The short answer is that it introduces more complexity. Here’s how I like to think of it: Imagine you’re storing a file folder in a file cabinet beneath your desk. Pretty quick and easy to access, isn’t it? And if something changes about the contents of the file, or the file folder goes missing, you’re the one in control—not many people have access to your file and there aren’t many places it could be.

\n

Now imagine that you’re storing a file folder in a colleague’s file cabinet across the country. While storing it elsewhere saves you some precious drawer space, sending the file folder back and forth introduces more variables into the mix. For instance: what’s going on with the file when you’re not using it? Where is it being stored, and under what conditions? How long will it take your colleague to send it to you? What if some of the file’s contents are missing when you get it? Or what if it’s lost along the way?

\n

What this means for you and your projects is: When trouble strikes, make sure you’re reducing the complexity by saving and accessing project files from a local drive and not a network drive. If you need to place a copy of your project on a network drive or on a USB drive for backup, versioning control, or collaboration with coworkers, do that only after you’ve closed Storyline or Studio. Try to avoid reopening the project again until you’ve copied it back to your local hard drive.

\n

For more tips on creating, editing, and publishing Articulate projects to your local hard drive, check out this support article.

\n

Item #2: Your Software’s Update Status

\n

We’re constantly working hard to improve our products, so updates are released pretty regularly. Keeping your software updated ensures that you have all the latest and greatest performance improvements and bug fixes.

\n

If you have Articulate 360, you’ll be notified of updates via the desktop app.

\n

\n

If you’re using a perpetual version of our software and you have the “Check for Updates” option enabled, your Articulate software will automatically notify you when a new version of the software is available. However, if you’re not sure if this option is enabled, it’s super-easy to manually check for updates.

\n

First, go to the help ribbon in Storyline, Studio, or Replay and select Check for Updates.

\n

\n

Once you’ve clicked Check for Updates you’ll be prompted to either download new updates or we’ll confirm that you’re running the latest version of our software.

\n

\n

 

\n

You can also use the help ribbon to quickly access the software-specific forum hub. Notices about newly released updates are typically “pinned” or anchored to the top of the discussion list.

\n

Pro Tip: Each time you install a free update, you’ll be prompted to reactivate your software. This may seem like a headache, but all you really have to do is click Activate to complete the process because the software remembers your serial number.

\n

Item #3: Your Published Project’s Location

\n

Just as the location of your working project files can impact how it behaves when you’re creating and editing a project, the location of your published content can also influence how it behaves. If your published content isn’t working the way you anticipated, take a second look at where and how you’re accessing it.  

\n

Published content should always be accessed and tested from the intended environment, as described in this support article. For example, if you published your project for the web, you should upload it to a web server for testing; and if you published it for an LMS, upload your content to an LMS or to a free service such as SCORM Cloud for testing.

\n

Also, check to ensure that you’re loading all of the published project output files to your web server or LMS, and not just the story.html or presenter.html files.

\n

Pro Tip: If your intent is for content to be viewed locally, try publishing for CD and then double-click the launch_story.exe file from the resulting output files. Often local security restrictions on your computer, web browser, and Flash player can cause certain features to fail.

\n

Next Steps

\n

What happens if you’ve checked all of these items off of your troubleshooting list and things still aren’t working? That’s where the appropriate product-specific forum can help you crowdsource your sleuthing efforts.

\n

Before you draft a new forum post, it’s a good idea to start with a quick search to see if anyone else has had the same problem you’re experiencing. For tips on power-searching, check out this handy how-to article.

\n

And if a search doesn’t turn up what you need, it’s time to draft a new forum post describing the problem in detail. In the body of your post, it’s helpful to verify that you’ve completed this checklist—just so we don’t ask you to start over at Item #1. It’s also a good idea to have any of the following attached to your post:

\n

\n
1. The problem slides from your project file (.story file or a Presenter package)
\n
2. A video capture of the unwanted/unexpected behaviors you’re experiencing
\n
3. Static screenshot(s) of the unwanted/unexpected behaviors
\n

\n

For more pointers on writing discussion posts that get quick answers, check out this helpful article.

\n

Summary

\n

Technology can be a little confounding at times, but with these basic troubleshooting tips, you can save yourself some time by diagnosing many of the most common technical issues on your own. Even better: when you can help us understand what’s not contributing to the problem, the ELH community can help you identify the real culprit a whole lot faster!

\n

Looking for even more troubleshooting tips? Check out these recent articles:

\n

\n
• The Secret to LMS Debugging
\n
• How to Troubleshoot Your LMS with SCORM Cloud.
\n

\n

What does your troubleshooting checklist look like? Share your tips and feedback in the comments below.

\n

Want to try something you learned here, but don’t have Articulate 360? Start a free 30-day trial. And subscribe to our newsletter to get the latest product updates, e-learning examples, and expert advice sent directly to your inbox. If you have questions, please share them in the comments.

\n

E-Learning Heroes is handy for getting quick tech support for your Articulate 360 projects when you need it. But what if I told you there’s an even faster way to troubleshoot the most common technical problems, a checklist that takes just a few moments and doesn’t require you to be super-techie, open a support ticket, or even draft a forum post?

Next time your project hits a snag, save yourself some time and frustration by checking off these three items:

\n

Item #1: Your Project File’s Location

\n

If you’re working in an office or corporate setting, odds are your computer is part of a group of computers all sharing access to the same computer or server on a network. If this arrangement sounds familiar to you, you likely have access to a network drive—that is, a drive where files are stored and shared with your coworkers.

\n

A local drive, on the other hand, is a disk drive that physically resides on your computer and isn’t part of another computer on your network. For example, most computers running Microsoft Windows have a local drive known as the C: drive.

\n

Creating new projects or editing existing projects from a network drive rather than a local drive, or publishing your projects to a network drive rather than a local drive, can lead to troublesome technical glitches like file corruption, crashes, or an inability to save changes.

\n

Why can working from a network drive cause these troubles? The short answer is that it introduces more complexity. Here’s how I like to think of it: Imagine you’re storing a file folder in a file cabinet beneath your desk. Pretty quick and easy to access, isn’t it? And if something changes about the contents of the file, or the file folder goes missing, you’re the one in control—not many people have access to your file and there aren’t many places it could be.

\n

Now imagine that you’re storing a file folder in a colleague’s file cabinet across the country. While storing it elsewhere saves you some precious drawer space, sending the file folder back and forth introduces more variables into the mix. For instance: what’s going on with the file when you’re not using it? Where is it being stored, and under what conditions? How long will it take your colleague to send it to you? What if some of the file’s contents are missing when you get it? Or what if it’s lost along the way?

\n

What this means for you and your projects is: When trouble strikes, make sure you’re reducing the complexity by saving and accessing project files from a local drive and not a network drive. If you need to place a copy of your project on a network drive or on a USB drive for backup, versioning control, or collaboration with coworkers, do that only after you’ve closed Storyline or Studio. Try to avoid reopening the project again until you’ve copied it back to your local hard drive.

\n

For more tips on creating, editing, and publishing Articulate projects to your local hard drive, check out this support article.

\n

Item #2: Your Software’s Update Status

\n

We’re constantly working hard to improve our products, so updates are released pretty regularly. Keeping your software updated ensures that you have all the latest and greatest performance improvements and bug fixes.

\n

If you have Articulate 360, you’ll be notified of updates via the desktop app.

\n

\n

If you’re using a perpetual version of our software and you have the “Check for Updates” option enabled, your Articulate software will automatically notify you when a new version of the software is available. However, if you’re not sure if this option is enabled, it’s super-easy to manually check for updates.

\n

First, go to the help ribbon in Storyline, Studio, or Replay and select Check for Updates.

\n

\n

Once you’ve clicked Check for Updates you’ll be prompted to either download new updates or we’ll confirm that you’re running the latest version of our software.

\n

\n

 

\n

You can also use the help ribbon to quickly access the software-specific forum hub. Notices about newly released updates are typically “pinned” or anchored to the top of the discussion list.

\n

Pro Tip: Each time you install a free update, you’ll be prompted to reactivate your software. This may seem like a headache, but all you really have to do is click Activate to complete the process because the software remembers your serial number.

\n

Item #3: Your Published Project’s Location

\n

Just as the location of your working project files can impact how it behaves when you’re creating and editing a project, the location of your published content can also influence how it behaves. If your published content isn’t working the way you anticipated, take a second look at where and how you’re accessing it.  

\n

Published content should always be accessed and tested from the intended environment, as described in this support article. For example, if you published your project for the web, you should upload it to a web server for testing; and if you published it for an LMS, upload your content to an LMS or to a free service such as SCORM Cloud for testing.

\n

Also, check to ensure that you’re loading all of the published project output files to your web server or LMS, and not just the story.html or presenter.html files.

\n

Pro Tip: If your intent is for content to be viewed locally, try publishing for CD and then double-click the launch_story.exe file from the resulting output files. Often local security restrictions on your computer, web browser, and Flash player can cause certain features to fail.

\n

Next Steps

\n

What happens if you’ve checked all of these items off of your troubleshooting list and things still aren’t working? That’s where the appropriate product-specific forum can help you crowdsource your sleuthing efforts.

\n

Before you draft a new forum post, it’s a good idea to start with a quick search to see if anyone else has had the same problem you’re experiencing. For tips on power-searching, check out this handy how-to article.

\n

And if a search doesn’t turn up what you need, it’s time to draft a new forum post describing the problem in detail. In the body of your post, it’s helpful to verify that you’ve completed this checklist—just so we don’t ask you to start over at Item #1. It’s also a good idea to have any of the following attached to your post:

\n

\n
1. The problem slides from your project file (.story file or a Presenter package)
\n
2. A video capture of the unwanted/unexpected behaviors you’re experiencing
\n
3. Static screenshot(s) of the unwanted/unexpected behaviors
\n

\n

For more pointers on writing discussion posts that get quick answers, check out this helpful article.

\n

Summary

\n

Technology can be a little confounding at times, but with these basic troubleshooting tips, you can save yourself some time by diagnosing many of the most common technical issues on your own. Even better: when you can help us understand what’s not contributing to the problem, the ELH community can help you identify the real culprit a whole lot faster!

\n

Looking for even more troubleshooting tips? Check out these recent articles:

\n

\n
• The Secret to LMS Debugging
\n
• How to Troubleshoot Your LMS with SCORM Cloud.
\n

\n

What does your troubleshooting checklist look like? Share your tips and feedback in the comments below.

\n

Want to try something you learned here, but don’t have Articulate 360? Start a free 30-day trial. And subscribe to our newsletter to get the latest product updates, e-learning examples, and expert advice sent directly to your inbox. If you have questions, please share them in the comments.

Excellent tips. Thank you!

You're very welcome! Glad you found the article helpful, Corey.

Thanks for this

My pleasure, Lee!

Nice list! Also, if you do use JavaScript (JS) in your Storyline, don't forget that you need to publish to test. And when you test, open the browser in Developer mode (Ctrl+Shift_I in Chrome) even if you don't ever want to code too much. If you see big red issues, it tells you what's wrong with your JavaScript. It could be a simple syntax error like forgetting about the \";\". Otherwise, you might just stare at the screen because there's no error message shows up :)

Great points and I really love that you shared your Chrome trick with us. That's an awesome timesaver!