Storyline Magic: Single Slide, Dynamic Sorting Items, Customized Feedback, Change Without Republishing

Drag and Sort

Articulate Storyline provides drag and drop question type activity out of the box. You simply add a new slide as a graded question, and select the drag and drop feature. It even gives you the opportunity to set up feedback based on three outcomes: correct (everything is in the right place), incorrect (you exceeded the number of tries), and try again (not everything is in the right place, go try it again).

Try it first: http://rabbitoreg.com/examples/dragandsort/story.html

Download source (SL360): http://rabbitoreg.com/examples/dragandsort/source.zip

Mistakes vs. Errors? Would you give the same feedback?

However, there are occasions when you need more than that. Feedback is one of the most underrated values of elearning. I often see designers focus on teaching the content, and using feedback as an assessment (in the worst case just stating if it’s correct or not). When we’re correct we don’t learn much, maybe we get a pat on the back for knowing (or guessing) something. When we make a mistake, that’s the golden opportunity to learn something new. That’s where feedback and reflection come into play.

But there’s caveat. Generic feedback might not help, even frustrate the users. Without getting into a philosophical discussion here about the difference between an error and a mistake, let’s think about the role of the feedback. When a user submits an incorrect solution, it may be a mistake or an error. A mistake is a choice that turns out to be wrong. With a reminder of why it is wrong, you can self-correct, because you KNOW the right thing, you just made a mistake. An error is often the sign of lack of knowledge. A simple reminder may not be enough, a deeper understanding of foundations is needed. Therefore, the feedback should be different.

But how do we know if it’s a mistake or an error? We probably don’t. But we can guess. Let’s say a process includes four steps. The order of the steps are really important. This is some knowledge users need to able to recall before the practice in real life. (Example, back in my days of college I had to learn how to program a CNC machine. It’s basically a giant machine that cuts metal. If you don’t follow the right steps, the blade breaks. It’s a very expensive mistake or error to make.)

Sorting four steps in the right order doesn’t mean the user can follow these steps!!! But, being not even able to sort them in the right order is a risk. So, you can list the four steps and have the user sort them. This activity involves recognition and sorting. To make this more realistic, based on observations or research, you may want to add additional steps that users often make unnecessarily. Let’s say you have 5 steps listed for the four slots to drag. Now, it’s not simply recognition of steps, the mental process includes elimination as well.

Five items to drag and sort into four slots gives you lots of combinations (1234, 1243, 1423, 1235, 1245, etc.). There’s only one correct answer. However, you may say that the combinations are not equally wrong. You may pick the right items but not in the right order (1243). Or, you may pick the item that does not even belong in the process (1235). Would you give the same feedback in real life? No. One of them is a sorting issue, the other is an elimination (and maybe sorting).

This is where you can guess about mistakes and errors. If someone consistently tries to add Step 5 into the mix, that is more likely an error.

Business Challenge: ONE SLIDE to make all this happen in Storyline

Here’s the business challenge and solution in a short clip:

Inside Storyline

All this is done with a couple of slides inside Storyline:

A landing page to decide which process to load
The drag and drop activity itself
End page for now
A lightbox page for showing descriptions
A slide with a webobject (there’s nothing on the slide per se. this is used only to copy supporting JavaScript files to production, so when you publish, you don’t need to edit anything after)

Let’s look at the process in details!

Landing page. This is where you can select between two processes to show how Storyline can load items on the fly into the same activity. This basically means you build one slide with one drag and drop, and use it as many times as you want with different content.

Fun challenge for you: spot the difference between A and B!

We’ll come back to the answer. For now, let’s assume we picked Process 1. On the top-left, you see the process title. Under the title, the four slots for the steps. On the right, we have five steps listed. They are numbered for you for testing purposes. You can drag each blue item from the right to the left.

Notice the Attempt 1/3 button is grayed out until you have all four items dragged and dropped.

You may not know what exactly is behind these steps, so let’s provide you details as you click on the magnifier glass.

You see the title of the steps you clicked on, as well as the description below. Let’s say I decided to go with this order: 1235. That means, overall, my solution is incorrect. But that itself wouldn’t give me much more info why. Instead, we give customized feedback in two ways.

First, we let the user know that 3 items are correct (right item, right place), and one is incorrect (should not be included). This feedback screen is one, single lightbox. Nothing is hardcoded here. The number correct, incorrect, and misplaced items are calculated each time. We also see there’s a “Feedback for 1235” placeholder text. Where does that come from? It’s coming from the same place everything else (items, item descriptions, etc.). It comes from an external XML file.

This external XML (text) file contains all the information for the project. In the source zip, you can find this file card_data.xml in the zsolt_demo3 folder (or in the published version under story_content\WebObjects\6XW3cz3Ep1Q\card_data.xml). Currently, it includes two processes. Each process has five steps (item name and description), and feedback for combinations lik 1234, 1235, 1253, etc.

Why is this better than adding all this in Storyline? Many reasons. For one, you can change any of this text without editing or republishing the module (you can try to edit some of the lorum text in the story_content\WebObjects\6XW3cz3Ep1Q\card_data.xml file and refresh the module in the browser). This gives you flexibility to adjust descriptions, or even swap items to update. You do not need to create feedback for every single combination: 1234, 1235, 1253, 1523, etc. The system checks for a specific code (whatever the user’s solution is), and if there’s no feedback for that code, it uses the generic feedback (“0000”). This means you can add feedback later on, if you wanted to.

The other big advantage is that you separate the logic and the content. The Storyline interaction doesn’t care what the steps are or what’s in the descriptions. It’s exactly the same activity for process 1 and process 2. So, you build one slide for the drag and drop, and one slide for the lightbox. That’s it. Two slides handle any number of scenarios. You can build the activity as an engine, and just change the XML file in the published folder for different versions if you need.

Things to be aware of

This solution is using JavaScript (and jQuery). That means it will not run if you want to publish this through the Articulate Storyline app. (The html5 version runs well on any supported device but not the app version)
The XML loading requires a webserver. What does that mean? If you upload this to an LMS, that’s fine. If you have a site that serves webpages (Apache, IIS, etc.) it will work. So, for normal production there’s no difference. However, for security reasons (because the Storyline published output actually READS a file on your computer), you can’t run this just by downloading to your hard drive. It would give you a “Something went wrong” error.
How do I test and explore these locally? I use WampServer (http://www.wampserver.com/en/) for my Windows system. It’s an easy download an setup. It creates a “webserver” on your hard drive. You can than type in http://localhost/drag3/story_html.html in your browser. In reality, it creates a folder on the your drive: C:\wamp64\www and anything you put in that www folder, you can access through your browser under http://localhost. This is good for testing JavaScript as well.
If you try it three times, you get to the incorrect feedback. There are no other scenes in the module, so continuing from there you’ll just end up in a white resting space 🙂 Obviously, you would need some content to provide learning about the topic. You can also retain the three codes (orders) if that helps you determine what content you’re suggesting for the user to review.

*About the difference in screens. The first screen is on a desktop, the second is on a mobile. The difference is “Select” vs. “Tap”. When the module loads, it detects whether you’re on mobile or not and sets a T/F variable. You can use that to show different things on mobile vs. desktop.