Is This Article For Me?
- What’s the difference between http, https, SSL, and TSL?
- 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?
- 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:
- You type in a URL, let’s say https://www.rabbitoreg.com, which is my blog.
- 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.
- 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.
- 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.”
- 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 .)
- When all is said and done, you see the page in your browser.
- 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 .
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.
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 .
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 a window in a window.
The Console the first thing I tell people to look at. You may see in the Console that the site “refused to show” in an iframe. It is a red error in the Console. For example, if you try to embed Google as a web object so people can search, it would refuse to show. (You can’t do anything about it unless the webserver itself specifically allows you to embed in the site.) The same thing happens if your published course is on an HTTP site and you’re trying to load another site from an https page.
If you type in alert(“Hello World!”) and hit enter, a popup message shows up. If you want to display this message in the Console itself: console.log(“Hello World!”), this would show the same message in the Console. Well, that’s kind of useless. Agreed. “Hello Worlds” are mostly just the first steps when learning a new programming language. But it will be a lifesaver for Storyline and the communication with its Player.
What Is The Storyline Player?
It is important to understand how Storyline courses operate in a browser when published. Storyline uses what they call the Player inside the browser. The Player is responsible for knowing what to show and when, handling variables, watching triggers, etc. This Player also “hides” Storyline variables from outside. The only way to read or write Storyline variables is through the Player. It’s kind of the gatekeeper for any change inside your published course.
To display the value of a Storyline variable in the Console try this command (assuming you have a Storyline variable called variablename):
console.log(“message”) you learned before just displays whatever is in the brackets.
GetPlayer() is a function that Storyline owns. A function is like a frequently executed program that does a specific thing. In this case, it returns the player for us to communicate with Storyline. You will not be able to use this function unless it is a Storyline published project you’re viewing in the browser. GetPlayer() returns an object that allows you to set and get variables by their names. Now that you have the Player’s attention, it lets you set or get variables.
The “.” (dot) in GetPlayer().GetVar(“variablename”) is a standard notation to access the GetVar() function inside GetPlayer(). You can’t just type GetVar(“variablename”) in the Console. It would not be recognized because it is only valid inside the Player.
To set a Storyline variable, you use:
With SetVar(), you need to tell Storyline what variable you’re setting to what value. Depending on the type of the variable, this command may look different:
GetPlayer().SetVar(“Very Smart”, false)
Does That Mean ANYONE Can Change Storyline Variables From Their Browser?
Yes, you can change your Storyline variables from within the Console. And yes, ANYONE can do that. As long as users know the name of the variable, they can set it right from their browser. So, next time you name your variables you may want to be more sophisticated than using Score, for example.
let player = GetPlayer();
Advanced Player actions
Now that you know how to get and set variables, here’s a final challenge for you. Assuming that you have an “Age” variable in Storyline, what will be the Console outputs after running this code? And why?
let player = GetPlayer();
console.log ( player.SetVar(“Age”, player.GetVar(“Age”) + 1) );
let age = player.GetVar(“Age”);
console.log ( age );
The answer is coming in part 2 of this article series.
Troubleshooting any HTML published course should start with the developer window. Check the errors in the Console, check the Network red lines (other than OK 200). A single error can break the whole course. Another advantage of using the Console is that it clear the cache for your page (if set properly). Often problems linger because the browser is using cached data.
Use the Console to interact with variables inside Storyline. This is useful when you’re doing quality assurance, for example, and you need to unlock certain things without going through the activity. You can just flip whatever variable Storyline is watching as a trigger to unlock a slide or activity.
Final Tip: When to use alert() versus consol.log()? Alert suspends all activities in the browser and displays a popup message. Console.log writes the message into the console but never interrupts your code. Which one to use when? The only time I suggest using alert() is when you want to STOP everything. This is useful, for example, when variables change so quickly that by the time you see the results in the Console, it’s too late. You can add step-by-step alert() commands to see how they’re changing. Note that you can have only one alert popup at a time.