Using JavaScript with Articulate Storyline #132: Challenge | Recap
Extend Your E-Learning Development Skills with JavaScript
In a recent screencast challenge, we looked at using variables...
Published 9 years ago
Version 1.0
Blog Post
Three very important things: 1) You must publish your course to test JavaScript. It won't work in Preview mode. 2) When you publish, use the Developer mode in your browser (Ctrl+Shift+I in Chrome) to see if any error occurs. One little ";" missing can cause mysterious nothing on the screen unless you look at errors in developer mode. If there's a red error, it tells at least what's wrong.
3) Is optional but helps a lot. Your JavaScript ends up in a file /story_content/user.js. Why is it good for you? If you publish your file and it's not working, you can open that user.js and try to fix it there. Save it and reload the published version. This way, you don't need to rebuplish every time you try something. However, remember to fix it in your source too.
Welcome to the dark side;
3) Is optional but helps a lot. Your JavaScript ends up in a file /story_content/user.js. Why is it good for you? If you publish your file and it's not working, you can open that user.js and try to fix it there. Save it and reload the published version. This way, you don't need to rebuplish every time you try something. However, remember to fix it in your source too.
Welcome to the dark side;
- Great tip Zsolt, I use Flow as my FTP client because it has a built in script editor so i can edit the JS file and find errors.
A couple of things I always do when test JS is add a trigger to show an alert on the first slide (this way I can see if JS is working as one broken line breaks it all). For long code step through it add an alert part way through if the alert doesn't fire the error is above that line then move the left line until you isolate the error.
There are some great online code checkers, be careful using text editors for writing your code as it can substitute smart quotes (Mac textEdit does this which i found out last week).- I have a WAMP server installed on my laptop. That's an easy way to test without using FTP. As for editing, Notepad++ does a great job.
The alert is a good one! - @Phil Major @Zsolt Olah Alerts( ) for debugging/testing i dislike. Mostly because they break the flow of your scripts. console.log( ) i prefer. It in fact does the same thing..sending out a message... but then not in view...but silently to the console.
If for some reason you cannot check your console when testing, i debug onscreen in a course by creating a textfield in which i dynamically change text at keypoints in my code.
- It's nice on the dark side!
- Excellent tips Zolt! Thank you for those.
- LOL...
I just couldn't stop laughing... Sounds sooooo much like a real dark side! - Thanks for the tip Zsolt.
- Thanks for all your tips and source files Zsolt. I hope to get a chance to post one this week.
- It's Memorial day weekend! BBQ, wine and beer time :) But my Millennial Aquarium is coming probably tomorrow.
Zsolt
Sent from my iPhone
- Awesome...Thanks for the tips Zsolt...
- I use Adobe Brackets to do my programming in. It has a live preview mode that is very helpful. This is also how I get around Chrome's and IE's security to test out my javascscript since they won't run any JS that has been launched on a local machine.
- And some extra tips:
4) Use an external editor for creating your javascripts. Sublime Text for example. Colorcoding makes it easier.
5) If you want to use a function on different slides, you can. Add it in a separate script you load on slide1 and you can call that function anytime, everywhere
