Storyline eLearning TechTalk For Beginners: Part 1

The other day I had the pleasure to chat with Devlin Peck about pushing the boundaries of Articulate Storyline by using JavaScript [1]. The discussion was meant for beginners. Nothing too technical. Through the conversation, we explored reasons why someone would benefit from learning JavaScript along with Storyline. I’ve received a ton of comments and questions about the topic and a pattern emerged.

Whether you use JavaScript or not in eLearning (not only with Storyline), there are some fundamentals you need first. This is a two-piece article for those who are new to the technology side of eLearning.

Is This Article For Me?

This article covers the fundamentals you need to know before you jump into JavaScript or even just basic troubleshooting your published eLearning courses. You can quickly decide if this article is for you. If you know the answer to these questions in the context of eLearning, you are too advanced for this article:

  • What’s the difference between http, https, SSL, and TSL?
  • How do HTML, CSS, and JavaScript work together to produce the web page you see?
  • How do you use the browser’s Console to check if all files are downloaded correctly?
  • How do you check for errors and warnings in troubleshooting a published course?
  • What’s the Storyline Player? And how does it communicate with JavaScript?
  • How to get and set Storyline variables from inside a web browser?

Troubleshooting In The Browser

You published a course, and when you try to view it, it’s blank. No error message. Nothing. Just blank. It’s not working. What do you do?

To troubleshoot this problem you need to open up the hood and peep into one of the most common applications in the world: your internet browser. When you type a URL in the browser, you expect to see the particular site’s web page instantly (or if you have a slower connection after some lag). Did you know that what you see is NOT a page on that particular site?

Let me explain:

  1. You type in a URL, let’s say https://www.rabbitoreg.com, which is my blog.
  2. If your browser is connected to the internet, the first thing it will attempt is to find out the “IP address” that belongs to www.rabbitoreg.com. There are servers on the internet that just do that. It’s like finding the address of your friend based on their name (assuming it’s unique). Why do we need URL addresses and behind-the-scenes IP addresses? They are practical because you can keep a URL such as www.rabbitoreg.com and change the actual servers without disruption for your users. For example, you can move from Hostgator to Bluehost. Your audience will never notice. At the same time, it would be hard to remember and marker a bunch of numbers as URLs.
  3. Once the IP address is found, then your browser “pings” the webserver that owns this IP address. It’s like relaying the message that someone wants to see this particular page on that server.
  4. The server then checks if this page exists at all. If it does, it checks if anyone has access to it or whether it is restricted to certain users. If it is public, then it starts serving bytes to the browser. It’s like “Hey, here’s all the info, go and put it together.”
  5. The browser then receives these “packets” of info and interprets what’s in them. (The reason why the browser and the server can understand each other is that they agreed on what language they use, what protocol they communicate through, and the port or channel they’re on. Here’s more info if you’re into this stuff [2].)
  6. Once the browser receives the initial packets and puts them together (this is your HTML page) locally, it starts interpreting the HTML page. The page may tell the browser to fetch more files, such as JavaScript files, graphics, CSS files for colors and layout, external data, etc.
  7. Once all files are loaded, the browser also executes JavaScript code found on the page.
  8. When all is said and done, you see the page in your browser.
  9. All this communication between your local browser and the web server on the internet can be wide open. Literally, anyone can listen to what you’re doing if the communication is not encrypted. Sometimes it doesn’t matter. However, when you’re talking to your bank, you may not want the world to see that. This is why “secure” communication is important. Secure communication means that all the information is encrypted between the browser and the webserver. It can only happen on https protocol (rather than http). There’s a lot more to learn about this such as SSL/TLS [3].

A couple of fundamental points here: HOW the page looks depends on your browser because the server just sends the information but the “rendering” and interpretation happen locally in your browser. That’s why it is a nightmare sometimes for eLearning developers to test something in Chrome, Firefox, Opera, Safari, IE (rest in peace), Edge, etc. Not to mention that each of these browsers may have different versions running on different operating systems.

Browser Troubleshooting: Now What?

Great story, but what do I do with all this?

Good question. This whole “handshake” and info exchange happens so fast in today’s world that often a page appears instantly. However, all browsers provide you a way to monitor and debug issues, they’re just hidden from amateurs.

In Chrome you can open the developer window through a shortcut Ctrl+Shift+I (or … More →Developer Tools). This is going to be your friend! Even if you never use JavaScript, mastering the developer window can solve you a bunch of headaches.

HTML, CSS, And JavaScript In The Browser

In the context of web pages, you may hear three terms a lot: HTML, CSS, and JavaScript. To simplify, think of HTML as the content to be shown. It is a markup language you can see if you right-click on any page and select View page source. CSS determines how the page looks: the layout, colors, styles, etc. It is usually in a separate file the page loads. Nowadays, you can do really fancy things such as animations with pure CSS without any JavaScript [4]. And finally, JavaScript, which can manipulate the page, provide interactions, hide and reveal elements, calculate values, handle forms, etc. Since JavaScript has been used for a long time and often, there are frameworks (Vue, Angular, React, etc.) created for specific use cases [5]. A framework is like a bunch of pre-built components so you don’t start from scratch.

Vanilla JavaScript

Out of the box, without using any additional frameworks, all browsers understand JavaScript. This is the plain version of JavaScript, what we often refer to as vanilla JavaScript. The examples in the article are all vanilla JavaScript.

Elements, Console, And Network Tabs In Chrome

Let’s start with the Network tab. The Network tab shows all the files and bits of information the browser is sending or receiving. We call this Network traffic. Stay on this Network tab and refresh the page (F5). You’ll see in real-time how fast files are downloading.

One of the most important pieces of information on this page is the status of each item. This is the second column, after the name of the file. The thing is your browser may ask the webserver for thousands of individual items. For each item, the server acknowledges the ask with a status number. The code 200 means everything is okay.

(Did you know that Google has an app for Chrome called OK 200? The reason it’s called OK 200 is that 200 is the code web servers send if the request is served without any issue.)

Other well-known numbers:

  • 404 – Unkown

    This happens when the browser requests an item that does not exist on the webserver.
  • 401 – Forbidden

    In this case, the browser made a valid request but the webserver refuses to serve the information. This could be because the user is not logged in or logged in but does not have the permissions to see the item.
  • 500 – Internal Server Error

    That’s bad. I mean really bad because it means an “unknown reason” caused the problem on the server. Browsers can’t fix that.

For anything else, check out this list [4].

So, back to the original question: no error, only a blank page. What do you do? You open the developer window, go to the Network tab, and refresh the page. You may see problems with certain files (usually red) with an error code. Those might be the culprit.

The Console Tab

The Console tab is your buddy for all troubleshooting beyond the initial Network tab. Even if all files are loaded fine, you can have tons of issues with them. In fact, the Console tab is where you’re going to spend most of your detective work. For starters, the Console tab displays errors and warnings for your web page. Some of these are non-vital, others can break the whole page.

Tip: If you work with clients and they report “it’s not working” sort of errors (which is basically useless information for you), ask them to do the same. Open their developer window, open the tab and take a screenshot of what they see. This is a much better starting point for troubleshooting than “it’s not working”

The Common Culprit: Embedded Objects In Storyline

One question I often get is about embedded web objects not showing up in Storyline. When you publish your course, Storyline tries to show your embedded object (which would be a site) in an iframe. An iframe is like a browser in the browser. It looks like part of the web page but actually, it is completely independent like

Go to Source