I design a lot of learning experiences, but usually they’re accessed directly by users with the web address, or via our LMS.
But what if you were asked to design a learning experience that would live on a computer kiosk, waiting for passersby to engage?
I wrote recently about my experience re-designing my Open Access Jeopardy game for standalone use on a giant touchscreen TV. I had actually created two versions: one to be included on an email to all faculty at our institution that they could play on their own, and another for use on the touchscreen TV.
There is one big challenge with designing an effective learning experience for a kiosk: how do you set it to refresh periodically, if someone abandons what they were working on?
I was thinking of museum or information kiosks: they’re fun to play with, but users don’t reset it for the next person, because you know it will reset automatically. I had NO IDEA how to accomplish this myself, but I know it has to be done because the Open Access Jeopardy game has THIRTY questions and I really doubt learners are really going to make it through all of them.
But I didn’t know how to develop an auto-reset because Articulate Storyline doesn’t have a “time-out” feature that will trigger a reset, and it doesn’t have the ability to jump to a given point on a timeline.
My initial solution to this challenge was to program in several reset points on the base layer. When triggered, a layer appears that counts down to a reset, which can be cancelled.
But, of course, there is a better way!
As long as the kiosk has an internet connection, the Storyline course can be hosted on a server and pulled up in a web browser.
And somehow, I didn’t think of this at first, but there is actually a plugin for Chrome called Kiosk that does exactly what I was looking for: automatically resets the web page at given intervals. Additionally, it locks down the browser with a username and password to control the experience and keep users from navigating elsewhere.
Brilliant!
However, I gave myself an additional challenge with this project: I wanted to collect statistics on how many people actually stop by and play the game.
Normally, I embed my Storyline courses into LibGuides as iframes, or I load them as SCORM packages into our LMS.
I didn’t want the LibGuide experience for this one because I wanted a really clean look that kept the focus on the game.
I didn’t want to load it into our LMS because I didn’t have a good place to put it, plus an LMS login would timeout periodically.
I have some experience using Google Analytics, so I decided to give that a shot! (Google Analytics is free, by the way, and you can generate up to 100 separate instances [you need one instance for each website you want to track]).
BUT – if your tutorial is automatically resetting periodically, how do you distinguish between visits to the web page as a result of resets, and actual players stopping by to interact with the course?
You create two separate Storyline experiences, of course! And assign each their own Google Analytics instance.
I ended up designing a separate Splash page from the game itself. The Splash page is a grayed out image that invites passersby to play:
When users click on the Let’s Play! button, the browser opens up the webpage that contains the actual Game:
The Splash page lives at /OAjeopardy2-kiosk/story.html, while the actual Game lives at /OAJeopardy2-Kiosk-Game/story.html.
When an abandoned Game automatically resets, or Kiosk refreshes after no activity, the original Splash page loads again. Thus, the Game would ONLY load when someone actually wanted to play.
I created two Google Analytics instances for these: one for the Splash page, one for the Game. You just have to embed the code into the <head> section of each of the .html files for each Storyline course: in story.html, in story_flash.html, and in story_html5.html.
I had to do some flowcharting and make some careful notes to make sure I didn’t screw anything up.
I thought this would work great! It would be a seamless experience for the user, and I would collect Google Analytics on how many times the Splash page refreshed as well as on how many times the Game page would be visited by actual players.
However, of course there was another problem I didn’t think of (story of my life!).
This approach unfortunately leads to lots of new tabs in the browser, IF the browser even allows pop-ups. If you use Kiosk with Chrome, the new tab will actually open as a smaller window and it’s very strange.
UGH. Why can’t things just work the way I dream they will?
Of course there are extensions for Chrome to try to fix this problem: I tried out a couple, including an extension called TheOne and another called OneWindow.
Alas, Open Access Jeopardy defeated both of them.
I discovered the solution: use javascript to open the URL for the Game and Splash pages instead of the standard Jump to URL.
Here’s the code, thanks to this StackOverflow page:
window.open(“https://www.youraddress.com”,”_self”)
I deleted the trigger that jumped to the URL, and instead created a new Execute Javascript trigger where I entered the above javascript (replacing it with my splash/game URLs respectively).
IT WORKS!!! Now, no new tabs are created: everything opens in the same tab in Chrome.
I did plug in the Google Analytics code to both the Splash and the Game html files, and 24-48 hours later, I got data! (Seems to take a day or two for data to collect).
Yeah, OK, so I had a whole 5 people play the game itself. But since I have a separate Google Analytics code plugged into the Splash page, I saw that it refreshed 9 times, so at least my Game statistics are legit!
I mentioned earlier that I created two versions of this game: one to be emailed out to faculty as well that doesn’t auto-reset.
I plugged Google Analytics into that, too!
LOOK AT THESE STATS.
OK, so in the great scheme of things we still didn’t get many visitors, but I learned that faculty were most likely to click on the link to the game when they got the email (sent out on October 23rd, obviously).
You know what else is really interesting?
The fact that 61% of users were kicked to the Flash version of the game, and 39% of them used the HTML5 version.
This is really valuable information about how my users are interacting with this game, and it makes me SO GLAD I was able to upgrade to Storyline 3 because the HTML5 output is so much more stable and does what it’s supposed to.
Using Google Analytics, I can also see what browser and device my users are on.
Want to do this yourself? Here’s how:
Here’s what you need:
- Storyline project for your Splash page
- Storyline project for your Game/Experience
- Web server
- Google Analytics instance for your Game/Experience, and also for your Splash if you want
Here’s how to do it:
- Develop your Splash project and your Game/Experience project. As an example, here’s my Splash page for Jeopardy, and here’s my actual game. (Want the source files? Have at it).
- Decide where your project will live on your web server – write down the URLs for both your Splash page and your Game page. These should live in separate folders.
For instance – my Splash page is at OAJeopardy2-Kiosk/story.html, and my Game is at OAJeopardy2-Kiosk-Game/story.html. - For your Splash page, create a trigger to Execute Javascript when your user clicks the button to play the game. Use this Javascript code, which will force the URL to open in the same tab/window rather than a new one:
window.open(“https://www.youraddress.com”,”_self”)
The URL is where your game will live. DON’T just use Jump to URL because this will open a pop-up window and that’s messy and doesn’t work with the Kiosk extension (and some browsers won’t allow pop-ups at all!). - For your Game, build in some sort of reset screen or action, and again, create an Execute Javascript trigger with the same javascript code, EXCEPT this time the URL will be where your Splash page will live.
I have my game set up with a dramatic fading Reset screen that automatically executes the javascript at the end of its timeline. - Publish your projects and copy them onto your server. Make sure they’re accessible at the URLs that you already planned out in Step 2.
- Set up your Google Analytics instances (aka properties). Here’s some help on how to set up your Google Analytics properties.
I set up a property for my Splash page, and one for my Game, just so I could confirm the stats were different and everything was working properly! - Insert the proper Google Analytics code into the <HEAD> of story.html, story_flash.html, and story_html5.html for the Game. (Right-click on these files and select Open in Notepad or Text Editor or similar so you can see the code. You can CTRL-F to find the head). Make sure you save! You’ll have to wait 24-48 hours for stats to start appearing in Google Analytics.
- Install the extension Kiosk for Chrome on the device that you plan to use as a Kiosk.
- Before you’re ready to unveil your new project to the world, launch the Kiosk app, and enter the URL for the Splash page as the Content URL. Be sure to whitelist your domain – you want to ensure that Kiosk will allow the new URL to open! Tweak the rest of the settings however you’d like.
- Test, test, test!
- OK, now unveil your project to the world! Enjoy watching user interactions and collecting stats from the comfort of your computer by using Google Analytics.
For bonus credit, figure out how to use xAPI instead of Google Analytics!
Enjoy!