By Robert “Bob” Bilyk
Introduction
I recently watched Ethan Edwards present ‘Cracking the e-Learning Authoring Challenge’. This post is my attempt at cracking the e-Learning authoring challenge.
But first a little background.
As many of you have the privilege of knowing, Ethan Edwards is the Chief Instructional Strategist for Allen Interactions. Cracking the challenge is all about building interactivity in an authoring tool – specifically, CCAF interactivity. CCAF is an acronym for Context-Challenge-Action-Feedback. The four components of CCAF are part of Michael Allen’s CCAF Design Model for effective learning experiences. Michael Allen is the founder of Allen Interactions, the author of numerous books on eLearning, and the chief architect of Authorware and ZebraZapps. Both authoring systems were designed for people with little technical expertise to be able to build – you guessed it — CCAF learning experiences.
In Ethan’s presentation, he demonstrates building a CCAF activity with Articulate Storyline. In a nutshell, the CCAF learning experience is the experience of “doing”. Rather than reading or viewing content, the learner experiences first-hand the application of principles, concepts, strategies, and problem-solving in completing a task and succeeding at a challenge.
In Ethan’s demo, his task is to detect a refrigerant leak. The learner is shown refrigeration equipment and given a leak detector. The learner doesn’t at first read a pdf or watch a video but performs an action. In CCAF activities, text and videos might come in the form of feedback to a learner’s action.
Some of the CCAF learning experiences that I designed include running a multiple hearth wastewater incinerator, troubleshooting a cable network, supporting the adoption of a special needs child, designing an online class, assessing risk of recidivism, and, most recently, searching for documents in a document management system. In all cases, most of the learning came from being immersed in a ‘real world’ setting’, presented with a challenge, and getting feedback because of learner actions.
Ethan’s presentation piqued my curiosity and a bit of self-reflection. He lists things that are essential in an authoring tool to enable the design of a CCAF learning experience. As a toolmaker, I explored each of the items on his list and I applied them to a small project built with our own LodeStar eLearning authoring tool.
As we explore each item on Ethan’s list, I’ll illustrate with LodeStar. If you follow along, you’ll see the development of a simple CCAF application. You’ll learn about the components of CCAF. And you’ll also learn a little about LodeStar and its capabilities.
But first an important caveat. CCAF comes in all forms, shapes and sizes. Ethan’s example and my example happen to be very simple simulations. The principles of CCAF are not limited to simulations. They can be applied to anything that requires action on the part of the learner — which includes making a decision, crafting a plan, analyzing and solving a problem — a host of things.
This is but one example of CCAF to illustrate its principles and test whether or not our authoring tool is up to the challenge.
Introduction to the Demo Application
The objective of the application is for learners to test an electrical outlet and determine which wires are hot or ‘energized’. In completing this task, the learner must turn on an electrical multimeter and connect its probes to the various wires in an electrical outlet. A multimeter is a measuring instrument that typically measures voltage, resistance, and current. Once someone has learned the difference between these things, the practical skill is in choosing the right setting for the task and safely using the meter to complete the task.
So that’s the challenge: find the hot wire with a multimeter. The context is a simple residential electrical outlet.
Typical eLearning applications would use text, graphics and video to illustrate the use of the multimeter and explain underlying concepts. CCAF applications challenge learners to complete the task in a manner that is an educational approximation of the ‘real thing’. Text, graphics and video can offer explanations but not in lieu of the real-world task and often as a form of feedback.
Basic Capabilities
But let’s start with an overview of the basic requirements. To paraphrase Ethan, an authoring tool must have these capabilities:
- Complete visual freedom
- Variables
- Alternative branching
- Conditional logic
- Action/response structures
I’ll elaborate on each of these requirements in my demonstration.
Complete Visual Freedom
LodeStar combines HTML flow layout and SVG layout. Images imported into the HTML editor are placed in the HTML flow and are laid out according to the rules of HTML. Images can also be taken out of the flow and applied with a CSS rule so that text flows around the image.
In addition, LodeStar authors can use the Scalable Vector Graphics (SVG) canvas to layout out graphics freely in any position on the x and y axis.
In other words, the graphical elements on the SVG canvas are laid out freely. The SVG canvas itself is just another HTML element. Depicted below is a flow of HTML elements like text, images, divs, tables, etc. The SVG canvas is in the ‘flow’ right along with them. Inside the canvas, graphical elements can be positioned anywhere, but the canvas itself follows the HTML document flow. shrinking and expanding as needed.
The visual freedom is that LodeStar combines the benefits of a responsive HTML flow with the precise positioning of an SVG canvas.
I started with a multimeter image that I took from Pexels.com, a repository of free stock photos. I used Photoshop to cut out the dial and imported it in the SVG canvas as a separate image. I did this because I wanted the learner to be able to rotate the switch to place the multimeter in the right mode. I also imported the image of an electrical box so that I could draw wires overtop.
Variables
As I wrote in the Humble Variable (The Humble Variable | LodeStar Web Journal (wordpress.com)), variables are critical to some eLearning designs. In this example, I need to store the position of the multimeter switch. That’s what variables do. They are storage places in the computer memory. As the learner clicks on the switch, the dial rotates. As an author, I must store the value of that rotation. If the value of the rotation is 40 degrees, the code judges the switch to be in the right position.
To enter the code that uses the variable, I right-click on the switch and select, ‘Select Branch Options’. Branch Options are basically things that happen as a result of displaying a page or clicking on a button or choosing a multiple-choice option or doing one of many things.
Branch Options can be as simple as turning a page or as complex as executing a whole list of instructions. The following is a basic example of the latter:
The Multimeter code
var rotation = getValue(“dialRotation”);
rotation+= 10;
setValue(“dialRotation”, rotation);
changeRotation(“dial”,rotation ,13,27);
if(rotation % 360 == 40){
changeOpacity(“display”, 1);
appendValue(“actions”, “Turned on multimeter. <br>”);
}
else{
changeOpacity(“display”, 0);
}
This code looks complicated to a non-programmer. But it is not. It just takes practice to write. It’s on the same difficulty level as an Excel formula.
Here is the same code but with an explanation (in italics) underneath:
var rotation = getValue(“dialRotation”);
get the value of dialRotation from long-term memory and assign it to a local or temporary variable named ‘rotation’
rotation+= 10;
add 10 degrees to value of rotation. In other words, rotation = the old value of rotation plus 10.
setValue(“dialRotation”, rotation);
store the new value in long-term memory in a location called ‘dialRotation’
changeRotation(“dial”,rotation ,13,27);
change the property of a graphic with the ID of ‘dial’. All LodeStar graphics can be assigned an ‘ID’.
More specifically, change the rotation property by 10 degrees (the value of rotation). Pivot the rotation at the precise point that equals 13% of the width of the SVG canvas and 27% of the height of the canvas. That point is the center of the dial in its current position on the canvas. If the dial were in the dead center of the canvas we would use 50, 50.
if(rotation % 360 == 40){
This line can be simplified to if(rotation == 40) I used the modulo operator (that is, ‘%’) in case the learner kept rotating the dial around and around. If rotation = 400, then 400 % 360 would equal 40. 360 divides into 400 once with a remainder of 40. So, if rotation is equal to 40, then do the following:
changeOpacity(“display”, 1);
change the opacity of a graphic with the id of ‘display’ This is the text box used to show the voltage.
appendValue(“actions”, “Turned on multimeter. <br>”);
store the learner’s actions in long-term memory in a place called ‘actions’
}
else{
changeOpacity(“display”, 0);
if the rotation of the dial does not equal 40, then shut off the display by changing its opacity to 0.
}
The Probe Code
I won’t explain the probe code in as much detail. Basically, when you drag the red or black probe, then the following code is executed. It essentially checks whether or not the probes are in the right spot. If they are, the multimeter display shows 110 volts.
var condition1 = isOverlap(“RedProbeTip”, “BlackWireBTarget”);
var condition2 = isOverlap(“BlackProbeTip”, “box”);
if(condition1 == true && condition2 == true){
changeText(“display”, “110.0”);
appendValue(“actions”, “Moved red probe to correct position. Black probe in correct position.<br>”);
}
else if(condition1 == true){
changeText(“display”, “0”);
appendValue(“actions”, “Moved red probe to correct position.<br>”);
}
else{
changeText(“display”, “0”);
appendValue(“actions”, “Moved red probe to incorrect position.<br>”);
}
These are the drag branch options that are tied to an object with a specific ID.
Alternative branching
Once the learner has tested the wires with the probes, with one probe connected to the wire and the other grounded, then the learner must select A, B, C, or D. Here’s where alternative branching comes in. Learners who select the right answer might go on to a more difficult scenario. The above scenario is as easy as it gets. Perhaps they must do a continuity test to detect where there is a break in the circuit. Learners who select the wrong answer can be branched to a simple circuit or given an explanation that one black wire is coming directly from the power source, and the second black wire is passing on that power to the next outlet or switch.
CCAF applications accommodate the differences in learners. The application can alter the sequence of experiences based on learner performance. This is a profoundly different thing than typical eLearning applications where every learner reads the same text, watches the same videos, and completes the same quiz.
Conditional Logic
Ethan also lists conditional logic as a basic requirement of CCAF applications. Conditional logic comes in the form of if-else statements as evidenced by the code. Conditional logic also comes in the form of alternative branching. Select the wrong answer and then get help. In LodeStar, conditional logic is supported by not only its language and branch options but also by logic gates.
In the display below, we see what happens when the learner reaches a gate. (Incidentally, learners don’t actually see a gate. When they page forward, the application checks the gate’s logic and then branches them according to some condition. In this example, the author might configure the Gate with a pass threshold. Let’s say 80%. If the learner meets or exceeds a score of 80%, they are branched to the ‘Results’ page’. If not, they may be routed to Circuit Basics. Follow the dotted lines.
Action/response structures
In our example, the learner moves the probes around. If the multimeter is turned on, the learner sees a voltage display. The action is moving the probe. The response is a voltage display.
First, this a ‘real world’ action and ‘real world’ response. I write ‘real-world’ in contrast to what happens in a typical multiple-choice question. In a multiple-choice question, the learner clicks on a radio button and possibly sees a checkmark. That’s only ‘real-world’ to an educational institution. The world doesn’t present itself as set of multiple-choice questions.
Second, when the learner sees a voltage display, that is feedback in the CCAF sense of the word. The learner does something and then gets feedback. Now, in our example, we did choose to combine ‘real-world’ feedback with a multiple-choice question. Ultimately, the learner is asked to choose the letter next to the ‘hot’ wire. In our example, we logged the learner’s actions and can unravel how they arrived at their final decision. Did they connect the red probe to the right wire and did they ground the black probe? If they selected the right answer but didn’t perform the correct actions that would lead to the right answer, we know they haven’t learned anything at all.
Conclusion
Authoring tools that enable one to create CCAF must have these capabilities: complete visual freedom, variable support, alternative branching, conditional logic, and action/response structures.
The hot wire example is an example of a very simple simulation. But, as I wrote, the concept of CCAF isn’t restricted to this type of simulation. CCAF can be found in decision making scenarios, for example. The learner might be placed in a situation and challenged to make the right decision or say the right thing. That too is CCAF. CCAF lies at the heart of effective learning experiences.
LodeStar Web Journal 