Serious eLearning: Use Interactivity to Prompt Deep Engagement

Elements of Interactivity

The Serious eLearning Manifesto challenges us to move beyond typical eLearning to the values  and principles of Serious eLearning.   One of those principles is, to quote the manifesto, ‘Use Interactivity to Prompt Deep Engagement’.  The sky is the limit in terms of what that actually means.  We know that it means something beyond page turners and roll overs.  Authoring tools offer us templates that have interactivity logic baked into the template.  The tools’ form-based interfaces allow us to provide information that feeds the template.  To do something original – outside of the constraints of a page turner presentation, or even an interaction template — requires a bit of code.  Few authoring tools allow you to realize your design fully without the knowledge and application of some basic coding.

ZebraZapps is  one of the notable exceptions.  ZebraZapps enables you to build complex interactions by wiring objects together.  A click, hover, drag or collision, for example, on one object could change the properties of another.  Dragging the earth and moon along their orbital path can cause the rise and fall of a tide graphic.  Authors connect the drag of an object constrained to a path to the height property of another object.  Expressing this relationship comes from wiring the drag event of one object to the property height of another object.  This expressiveness through the action of wiring is rare.  Most systems enable this expressiveness through language.  In other words, code.

If you google “should instructional designers learn to code” you’ll get more than 37 million results and many opinions.  My own view relates to the situation that many instructional designers find themselves in.  Whether they support a university department or mid-sized firm, they lack access to a programmer.  They are limited to what they know and how well they can work an authoring tool like Storyline or Captivate.  For them, a little knowledge of code can go a long way.  With a little knowledge, they can realize some pretty sophisticated designs.  They can do more than ‘click and present’. 

In the late 80s I was driving down a dark, country road listening to MPR.  The story was on Interactive Video.  Laserdiscs.  I was enthralled by the possibilities.  I asked my dean who was completing an advanced degree at the time in computer-based learning, what I needed to learn to control an interactive video laserdisc.  He answered “C”.  C was a programming language and his answer, which was actually incorrect, sealed my fate.  I began studying my first programming language oblivious to tools like TenCore and Course of Action (progenitor of Authorware) that afforded a much simpler way to control the laserdisc.

To finish this anecdote, I also began to study instructional design at the University of Minnesota.  At my first Wisconsin Distance Teaching and Learning Conference, I attended a pre-conference cracker barrel session.  Sitting around drinking wine were a bunch of researchers from Alberta’s Athabasca University.  I posed the question to them: “should instructional designers learn to code”.  The answer from at least one was unequivocal.  Become an instructional designer or a programmer.  You can’t do both.  There is too much to learn in either discipline.

So, I don’t necessarily take issue with that.  There is so much to learn in either discipline.  But modern authoring systems give us a way forward where we don’t have to totally geek out.  With just a few coding skills we can go long long way to realizing the serious eLearning principle:  “Use Interactivity to Prompt Deep Engagement.”

So let’s explore the basic prerequisites to interactivity.   There are three parts to this post.  First, this post discusses the relationships between computer code and this thing called interactivity.   Secondly, this video (LodeStar 9 — Elements Of Interactivity – YouTube) demonstrates a simple interaction that is made possible with the LodeStar eLearning authoring tool and its script (code) editor. Lastly, this DIY tutorial (Making your projects interactive and interesting with a little bit of code | LodeStar Help (wordpress.com)) walks through the video example step by step.

But first we need to look at ‘interactivity’ and understand where we benefit from some knowledge of coding.

The Serious eLearning Manifesto states that “We will use elearning’s unique interactive capabilities to support reflection, application, rehearsal, elaboration, contextualization, debate, evaluation, synthesization, et cetera”.   When we examine this list of strategies/activities and consider the unique interactive capabilities that will support them, we start with the following:

  • Ability to store information about the learners and their behavior.
  • Ability to offer something different and individualized based on this information.
  • Ability to create a visual, manipulatable, and functional learning environment that suggests an authentic (if not totally realistic) context.

That’s not an exhaustive list.  It’s a start.  It promises more than page turners and roll-overs.  Now, we need to match these capabilities with the authoring tool and the required code.

 

Ability to store information about the learners and their behavior.

Variables are used in code to store information.  The information can range from a number to a sentence to a list to a full essay.  Variables provide a human-friendly way to store and retrieve information.  They represent addresses in the computer’s memory.  As instructional designers we don’t need to know anything about those gobbledygook addresses or how the information is stored physically in the computer.  We usually need to know whether the variable is intended to store a number or a string of characters. (See Appendix A) 

So what can we store in a variable?  The answer is many things. 

  • Points scored
  • Type of question answered incorrectly
  • Number of tries
  • Learner’s journal entry
  • Bookmarked page where the learner left off
  • Much much more

In a recent eLearning program, our objective was to help the learners use LinkedIn effectively to promote their professional brand.  Their eLearning task was to help a fictitious character build up his Social Selling Index.  The index is made up of four components: brand, people, insights and relationships.  Successful completion of the activities increased the character’s brand index, people index, insights index, and relationships index.  We created four variables and, you guessed it, they were:  brand, people, insights, and relationships.  Each activity was categorized and affected one of these indices.  In other words, we increased the numerical value in the corresponding variable.

Variables included in a LodeStar authored eLearning module

This contributed to what the Serious eLearning Manifesto calls authentic context.  The performance objective was to help employees increase their SSI.  The activities in the eLearning module increased the character’s SSI.  We could have designed a presentation and a quiz.  We didn’t.  But to achieve that authentic context, we needed to store values in variables. 

To learn more about variables, complete the hands-on exercise shown in the video (mentioned above) and the accompanying tutorial.  You can download LodeStar 9 and use it at no charge to complete the exercise.  LodeStar Learning Corporation

Ability to offer something different and individualized based on this information.

In another recent project, we created a simple simulation of a workplace engagement platform.  The simulation helped guide employees through the steps of requesting feedback from their supervisor, co-worker or reports. A future simulation will be focused less on the procedural and more on the best practices of soliciting and giving feedback.  The first simulation was a post-training exercise. Our HR Director conducted the training.  The post-training exercise helped refresh participants’ memory on the basic steps.   The strategy was to add points for correct choices and subtract points for incorrect choices.  In response to wrong choices, feedback steered participants in the right direction.    A counter in the bottom left corner showed the result of correct and incorrect choices.  It was a bit of gamification but always with the intent to guide participants to the right choice.  In other words, guided practice.

So what role does code play?

This simple simulation wasn’t built from a template with some sort of pre-defined logic.  It was custom built for our purposes.  But it was a very simple construction. We began with a blank screen, uploaded screenshots and defined click/touch areas.

As a result of click, we wanted to a) add or subtract points and b) branch to a new screen or display an overlay.  We never subtracted points multiple times in response to multiple clicks on the same thing – but we always showed feedback.

Code can help us to:

  • Check if the item has been clicked before.  If no and if correct choice, add points and then branch.  If no and if not correct, subtract points and provide corrective feedback.  If yes and incorrect, increment a counter to provide another level of feedback with more urgency.
  • Store a value that enables us to check if item has been clicked.

These rules are simple.  They can be complex.  In this simple example, we use variables and conditional logic (i.e. if statements).  We also use branching, which, in this case means, display an overlay or display a new screen with hotspots and more code that gets executed when the invisible hotspot is clicked on.

A Simple eLearning Simulation

To be true to this section heading (i.e. Offer something individualized) , we could have gone further.   If the participant breezed through a scenario, we could have used conditional logic to increase the difficulty of the scenario.   If the participant stumbled through, we could have kept the level of difficulty the same (i.e. plateau).  The same tools apply: variables and if-then statements.  I’m tempted to say that this approach is simpler than trying to shoehorn a pre-programmed template to your needs.  

Ability to create a visual, manipulatable, and functional learning environment that suggests an authentic (if not totally realistic) context.

The screenshot below shows the beginnings of a tutorial on automatic direction finding (ADF), an older navigational method for airplane pilots.  There is just enough detail to make this panel somewhat realistic but the panel is a simple composition of ellipses, paths, rectangles and text.  The Scalable Vector Graphic (SVG) is composed of these elements.  Each element can generate a click event that can result in the execution of some code.  In the screenshot we are highlighting a switch that has the id of g2423.  When this switch is clicked, with a bit of code, we can cause something to happen.   The graphical element is tied to a LodeStar branch option.  The branch option executes commands that relate to a NDB (Non-Directional Beacon) that the pilot can tune in – in this case, the audio playback of Morse Code to identify the beacon.   As I’ve heard Ethan Edwards from Allen Interactions say many times, you just need enough realism to accomplish your learning objective.  Any more and you’re wasting your time or your client’s money or both.

Automatic Direction Finding — eLearning Module

To show another example, in the video and tutorial link referenced in the conclusion, I walk through a simple example of how to make Scalable Vector Graphics interactive.  I walk through an example of a traffic light switch.   I chose this example because it is a little easier to understand than the ADF on an airplane.

A LodeStar Learning tutorial on variables, conditional statements, functions, and SVG graphics

 

Conclusion

In the pursuit of serious eLearning and meaningful interactivity, I’ve noted LodeStar’s ability to support variables, conditional statements, branch options and the ability to change the properties of objects.  Other authoring systems also support these concepts and require the author to understand the basics behind variables, conditional statements and logic in general.  Allen Learning Technologies’ ZebraZapps requires no coding – but it does require the instructional designer to think logically.  Wiring replaces code, but logical reasoning is still required.  Articulate Storyline has the concept of triggers and supports events such as clicks, hovers and drags.  Those events can be tied to property changes of Storyline’s native vector format.  Storyline also supports variables and has an easy-to-use interface for building sophisticated conditional statements.  Adobe Captivate supports the association of actions with graphics.  For example, the learner can click on a rectangle associated with an action such as show/hide and increment/decrement.   Captivate also supports an interface that can apply conditional logic to an action.  For example, a variable might keep track of slide states.  Each state can house different text.  As the learner clicks a rectangle, an ‘if’ condition displays the matching text based on the current value of the variable.   In short, Storyline and Captivate support the idea of variables, events, conditional statements and the ability to dynamically change the properties of graphics.  ZebraZapps has the same ability but without requiring a line of code. 

Whatever the authoring tools’ approach, the ability to store information about the learners, to offer something different and tailored for the learner, and the ability to create a visual, manipulatable, and functional learning environment relies on the instructional designer’s logical thinking and the authoring tools’ ability to store values, change course based on conditions, and modify the visual environment in some way.

These resources can help you get started.  The first two, I’ve already mentioned.  The third is a terrific resource to learn the basics of coding.

LodeStar 9 — Elements Of Interactivity – YouTube

Making your projects interactive and interesting with a little bit of code | LodeStar Help (wordpress.com)

Learn to Code – for Free | Codecademy

Appendix A

To illustrate the concept of data type in variables, examine the following table:

Name                    Rank

Joe                         11

Anna                      2

Kim                        1

In the preceding table, Kim came in first place, Anna in second, and Joe in eleventh place.    A variable stores a person’s rank.  If we interpreted the information in the variable as a number, then this would be the sorted order:

Kim     1

Anna   2

Joe       11

If we treated the variable as a string of characters, this would be the sorted order:

Kim     1

Joe       11

Anna  2

In the second case, the value stored in the variable is treated as a character.  In the computer’s character table, ‘1’ is assigned the numerical value of 49.  ‘2’ is assigned the numerical value of 50.  The computer compares the first character 1 to the first character of 2.  It looks up the character value and processes the comparison as 49 to 50.  49 is lower, therefore, the computer places 11 before 2.    But that’s practically all there is to the complexity.  Variables store information.  It matters whether we interpret the information as numbers or as characters. This is known as the data type of the variable.