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