ACM Logo  An ACM Publication  |  CONTRIBUTE  |  FOLLOW    

Should Instructional Designers care about the Tin Can API?

By David Kelly, Kevin Thorn / March 2013

TYPE: EMERGING TECHNOLOGIES
Print Email
Comments Instapaper

Over the last year, there's been a great deal of attention paid to "Tin Can" (currently referred to as the Experience API). Just about every industry conference last year had sessions discussing the API, explaining what it is and how it may forever change the world of organizational learning.

As an observer of the hype surrounding Tin Can, we've noticed a few trends. Most of the discussions are very technical, from how the experience API works to how to write for it. As an emerging API, this makes sense. The API is evolving; therefore most of the conversations would involve those who are helping shape the API—people who can actually write code.

However it is in that fact that a gap exists. If the Experience API is the future of learning and performance, and it requires the ability to actually write code, how does it impact the vast majority of instructional designers who do not have coding skills?

It's that question that we look to address in this article. At the most recent ASTD TechKnowledge Conference, we facilitated a session entitled "What is Tin Can, and Why Should I Care?" The purpose of this session was to discuss the API from the perspective of the majority of workers in the learning and performance space—trainers, instructional designers, etc. This article summarizes and continues that discussion.

Please note, our intention is not to address the debate as to whether or not instructional designers should have the ability to write code; we are simply acknowledging today's reality in which most instructional designers use tools that do not require coding skills.

The ultimate purpose of this article is not to tell you if the Experience API is or is not important for you. Our goal is to share with you what the Experience API is and to compare that to the world of today's instructional designer. Our hope is that by doing so, you can better understand what Tin Can actually is, how it impacts the world of organizational learning today, and how it may impact the world of organizational learning in the future

With that understanding you will be better equipped to decide for yourself if you should care.

Today's World Of Instructional Design

First some baseline assumptions. The vast majority of workers designing learning experiences today are labeled instructional designers. The reality is that most instructional design positions are actually hybrid instructional designer/developer positions: The person designing the learning experience is usually also the person developing it. In addition, that development is usually done using a rapid development tool (such as Storyline, Captivate, or Lectora). These tools do not require the user to write any code. As such, most instructional designers do not have coding skills.

What Is Tin Can (The Experience Api)?

Rustici Software, who has been working with Advanced Distributed Learning (ADL) to develop the Experience API (Tin Can), describes it this way:

The Tin Can API is a brand new learning technology specification that opens up an entire world of experiences (online and offline). This API captures the activities that happen as part of learning experiences. A wide range of systems can now securely communicate with a simple vocabulary that captures this stream of activities.

For a high percentage of instructional designers, the response to reading that description starts and ends with "Huh?" So let's try to build a bridge between what the Experience API is, and how it translates to the world of the instructional designer.

Tin Can is an API, or application programming interface, which enables software components to talk to one another and share data. As a comparison to the instructional designer world, Tin Can is sometimes referred to as "the next generation of SCORM." Those developing Tin Can frown on this description because it places Tin Can into an extremely small box in terms of its functionality. However using "next generation of SCORM" is a good place to start a simple discussion, as it helps connect the Experience API to existing instructional design knowledge.

For many instructional designers, SCORM is really nothing more than the file format that projects need to be published to in order for the learning management system to accept it. SCORM, more than the development tools used, in many ways also dictates the type of data that the eLearning modules track. And that data is extremely limited, including data such as completion status, pass/fail, and test scores. These are really not meaningful data points.

The Experience API looks at data differently, and opens nearly limitless options in terms of what can be tracked. Tin Can can track almost anything, and its data generally follows the simple format of noun-verb-object. Looked at it another way, the Experience API tracks "I did this." There are plenty of examples of how this expands the type of data that can be tracked, such as:

  • David experienced slide 5.
  • David answered question 6.
  • David experienced this webpage.
  • David read this book.
  • David commented on an eLearn Magazine article.
  • David watched this Youtube video.

These bullets represent part of the challenges that exist for instructional designers. The first two bullets dealing with slides and questions are fairly easily connected to the types of eLearning experiences that instructional designers build. The other bullets take place outside of the courses and modules we build, and usually happen spontaneously and without being part of any formal learning program.

The Instructional Design Gaps

There are a number of gaps between the potential of the Experience API and the world of the current instructional designer. Let's look at three of the major ones.

The Design Gap. Most instructional designers work within a controlled environment, where courses are created and uploaded to a learning management system through which learners can access content. Instructional designers generally have the skills required to build these types of experiences.

However, the Experience API looks at the larger scope of learning. It acknowledges all of the informal ways that people learn. It has the ability to track activity that takes place during actual work, rather than being restricted to simulation environments. In short, it opens a door to an entire world of information through which more data can be collected, and more impactful stories can be told.

The design skills of today's instructional designer do not support building the types of experiences that the Experience API makes possible. Most designers build experiences where content is packaged and pushed to learners. The idea that experiences outside these structured courses have value is something most instructional designers might agree with conceptually, but have no idea where to start in terms of designing experiences or environments that support the full spectrum of learning.

The Technical Skills Gap. Most instructional designers have experience using one or more rapid development tools, such as Articulate's Storyline or Adobe's Captivate. These are amazing tools that allow developers to create content in an extremely user-friendly environment. These tools make eLearning development much more accessible to people assigned development duties. However, these tools also diluted (and in some cases, eliminated) a very valuable skill: coding.

In the early days of eLearning, most courseware was developed in Adobe Flash. In order to create something in Flash, you need to write code that actually builds the experience. Flash isn't a rapid development tool. The plus of Flash is that because you are coding the experience from scratch, you can create almost any experience your designers can dream up. The downside of Flash is that it requires a much deeper skillset in order to write code for it.

While some of the rapid development tools can leverage the Experience API, they are doing so in a very limited fashion, similar to the "David viewed slide 5" example shared earlier. The types of Experience API statements that rapid development tools can track today do not amount to meaningful experiences at all.

In order to track meaningful data, code must be written. Perhaps at some point rapid development tools and learning management systems will be able to build experiences that generate and track valuable data without the requirement of writing code. For the foreseeable future though, leveraging the power of the Experience API requires instructional designers to either develop coding skills themselves, or to partner with IT departments that may be able to write the code for them.

The Strategic Gap. Learning departments collect a great deal of data today. Unfortunately, very little of that data is actionable or useful to an organization. Completions and test scores are great for tracking compliance, but they do very little for analyzing or improving performance.

As we've discussed, the Experience API can track almost any kind of learning experience. Just about anything an individual can do will generate a trackable statement. The data possibilities are limitless.

But you still need a plan. We collect a lot of data through our learning management systems today, and we provide plenty of reporting. Yet we don't use the limited data we collect today strategically in any way that provides organizational value. Yes, the Experience API can track just about anything, but data without purpose is meaningless.

The Experience API isn't a plan; it's a way that a plan can be better executed. It requires looking at data differently, and asking what types of data we want to collect, why we want to collect it, and what meaningful actions we plan to take based on the data.

Most instructional designers never have to consider the types of data they want to collect. Data always been dictated by the development tools we use and the learning management systems that track our courses.

Leveraging the Experience API will require most instructional designers to look at data in ways they have never looked at it before.

So Should Instructional Designers Care About Tin Can?

For the vast majority of instructional designers working today—those who likely serve as designer and developer, use rapid development tools, and do not have coding skills—the Experience API is not something that is going to impact the work you do anytime soon. While there is a great deal of hype surrounding the promise and potential of the Experience API, there is very little urgency attached to implementing a strategy that incorporates the Experience API.

However, that doesn't mean instructional designers should ignore it.

While the Experience API is getting a great deal of attention within the learning and performance industry, this discussion isn't really just about the Experience API. There are projects in academia and other fields that are similar. The Experience API is just one example of a larger shift toward collecting more meaningful data in order to tell better stories, increase understanding, and take more informed actions.

That fundamental shift is coming, whether it will be from the Experience API or some other source. For most organizations, the ripples of the shift's impact will not be felt for at least the next few years. Depending on your organizational culture, it may be even longer before this type of data collection and tracking becomes a factor. But realistically, it's not a question of if it will someday be a factor; it's a question of when.

This shift will, by necessity, redefine the expected skills of instructional designers. For this reason alone, it's important that instructional designers pay attention to what is going on around them, so that they can begin to prepare for the changes to come.

About the Authors

David Kelly is the Director for the Center for Learning at ACLD. He has been designing and managing learning programs as an internal learning and performance consultant and training director for over 12 years. Kelly has been a leader in ASTD, serving as a local board member and national adviser. He is active in the learning community, and can often be seen speaking at industry conferences and events.

Kevin Thorn is a self-taught, award-winning e-learning designer and developer with a passion for the art of visual communications. After retiring from the Army, Kevin embarked on a 15-year career in the corporate workforce. He earned a B.S. in Information Technology Management from Christian Brothers University. His current role is owner and Chief NuggetHead of NuggetHead Studioz, a design, development, and consulting business including e-learning design and development, illustration and graphic design, and training and consulting. Thorn approaches every project with the creative awareness and knowledge to take a project from conception to completion, and he can be found around learning communities on Twitter as @LearnNuggets, or at LearnNuggets.com where he writes opinions, reviews, and tutorials.

© 2013 ACM 1535-394X/13/03 $15.00

DOI: 10.1145/2446514.2446579



Comments

  • There are no comments at this time.