Contact Us Support Forum Get Email Updates
 
 

Thanks! Someone will be in touch with you shortly.

Rather just email us? Email us here.
Rather speak with someone in person?
Call any time with Experience API questions:

866.497.2676

Archive for the "xAPI" Category

Last week, the Department of Defense (DoD) signed the updated DoDI 1322.26 Distributed Learning (DL). The latest DoDI advises all entities within the DoD to procure eLearning technology solutions that are compliant with the SCORM or Experience API (xAPI) specifications.

This Instruction replaces the 2006 version of DoDI 1322.26, “Development, Management, and Delivery of Distributed Learning,” which mandated (as opposed to advised) the use of SCORM in all eLearning technology used by the DoD. With the updated DoDI released, DoD entities can source the right DL solution based on their requirements, as opposed to being limited by the SCORM-focused scope of the older Instruction.

So what’s all the fuss about?

The 2006 DoDI required any DL technology to be SCORM conformant. After xAPI was released in 2013, it was hard for government organizations to purchase modern products as xAPI was not supported by the existing Instruction and there was no way to verify if an xAPI solution conformed to the specification. Now, government organizations have the flexibility to procure the right technical solution based on their requirements, and a means to verify that the products conform to either SCORM or xAPI.

So why are we so excited?

We are excited because this is the culmination of a lot of work for many people at both ADL and Rustici Software. In 2015, we at Rustici were awarded a BAA from ADL to help them revise the 2006 DoDI 1322.26. You can read more about that story on the Rustici Software blog if you’d like.

So how can I find an xAPI compliant product?

Lucky for you, ADL recently launched a list of Conformant LRSs as part of their xAPI Adopter Registry. If you’re looking to procure an xAPI conformant LRS, this is a great place to start. If you’re looking for resources about xAPI conformance, check out the official xAPI reference and support resource for DoDI 1322.26.

1 Comment
 

Part One: How We Decide to Do Work

Posted by

Categories: Ideas, Spec Effort, Standards, xAPI

Posted 21 September 2017

 

A couple of days ago, I wrote about the state of ADL and Rustici Software’s take on it. One of the real community leaders, Aaron Silvers, then shared his perspective, partially in response. If you read them both, you’ll see some overlap and gaps in our responses, but the thing I want to address is that it seemed Aaron was asking a question or making a request of me (Tim?) or Rustici Software in the process.

Important note for those unfamiliar with this space: I work at Rustici Software, a for-profit software company. Since we started working with standards in 2003, we’ve been active within the community and try to build software that spares customers having to deal with the standards. This website, like scorm.com before it, is how we interact with and provide resources to that community.

Aaron may not have been asking these questions, but in order to answer his, I have to explore two questions:

  • How does Rustici Software decide to do work?
  • How does Rustici Software decide which work to do?

How we decide to do work

There are two kinds of work that are clear yeses for us.

  • Work that serves two or more other organizations well enough that they’ll pay us enough to justify the work.
  • Work that we can do now because it helps us do our jobs better.


Number one might be pretty obvious to you. This is the essence of a products company.

Number two is a little less obvious, but just as true. Back in the SCORM days, one of the fundamental problems was that it was simply tough to tell what was going on when a LMS launched a piece of content. As good developers do, the venerable Mike Rustici added debugging tools so he could see what was going on. (Keep in mind, this was way back in the days prior to good debugging tools being built directly into the browsers.) Mike was solving a problem he had, but he quickly saw the broader utility of those debugging tools.

We listed that debugging log as a top feature of SCORM Engine from day one. We also decided that it was worth sharing with the world. We wrapped a little bit of code and interface around our core product (SCORM Engine), labeled it SCORM Test Track, and shared it. It’s been subsumed by SCORM Cloud now, but that capability brought thousands of people to Rustici Software and introduced them to things that we do well.

Those debug logs, and Test Track, have had real, lasting, positive impact, for both the community and for us at Rustici Software. If we’re going to do work that fails at number one (making money directly), then we want to have an impact.

ADL’s guiding hand

For most of the last 15 years, ADL has been the primary organizing force in the corporate elearning standards space. This force is realized in two ways:

  • ADL funds research of a specific type, with specific organizations, which causes things to happen to the eLearning standards.
  • ADL decides what is in – in scope, in the spec, in the agenda for the specification meetings. This is mostly good, because a community needs organization and leadership.

This had led to real and important work. Project Tin Can was a successful initial effort on our part, funded entirely by ADL, that led to what you now know as xAPI. Similarly, ADL funded the work that DISC did in 2016-2017 that led to an xAPI profile definition specification. This money from ADL provided incentive, and ADL’s guidance provided direction.

ADL has served as the arbiter, allowing certain things to become a part of the core xAPI specification, and pushing others into other areas (cmi5, for example). They also made decisions about which community projects to highlight, which ones to work from.

Our rules about taking work are somewhat different with regard to standards bodies. On multiple occasions over the last 3 years, work that Rustici has done and offered to the community in various ways (OSS or hosted service) has been passed over or recreated. This includes:

What should we do from here?

So here’s the crux of it: Based on the current budgetary environment in the US, ADL does not currently have the ability to fund additional research, nor do they have a large number of resources to do work in house. They have retained, however, their position of authority; they decide what’s in, or they do until they don’t.

At some point, we had to start asking ourselves this question: If ADL doesn’t explicitly approve work we’re doing for community use ahead of time with their funding, does it serve us or anyone for us to take on big chunks of work like this? Simply, under what circumstances are we willing to do work to support the community without being paid?

So I have a question for the community… for you, the reader who trudged through just this many words. If we stand up an xAPI Profile Server and a service to test for valid, well-structured xAPI Profiles, on our servers, evolving it at the pace and in the manner we see fit based on the problems expressed to us by our customers and the community, will you use it? Would you allow us to play a significant, central role in that way? And to ADL, would you approve of that?

My sense is that the community would like for us to build these things, but only under very specific conditions.

OK. I’m about 1000? words into a post and I’ve answered one question. But I’m going to stop here. The answer to this one precedes the answer to the second: How does Rustici Software decide which work to do? We’ll come back to that one in a post we publish next week.* Until then, let us know if you’re open to using tools that we build.

* Update: We are still pulling together our thoughts on which work we plan to do based on conversations with standards folks and our own internal team. This is coming, it’s just going to take a little longer than we thought. 

Have a more nuanced response? Email it to us: info@experienceapi.com.

3 Comments
 

IEEE LTSC xAPI TAG A-OK

Posted by

Categories: Announcements, Spec Effort, Standards, xAPI

Posted 15 September 2017

 

Shelly Blake-Plock announced last night via LinkedIn that he would be leading a Technical Advisory Group (TAG) for IEEE LTSC (Learning Technologies Standards Committee). This is good news, as Shelly is going to carry a real load in leading that group. In his own words, Shelly describes the work in this way:

Our initial purpose is to create an IEEE technical report as a reference and implementation guide for xAPI 1.0.3. More broadly, we’ll be providing an open place for discussion among xAPI stakeholders and we’ll potentially be making recommendations about needs to support widespread use of the specification based on our activity in writing the report.

Our start point is the xAPI 1.0.3 specification. We’ll discuss all aspects of xAPI such as xAPI Profiles and the relation of xAPI to SCORM and cmi5. The end point is open-ended and in our discussion we will work to define the scope of the TAG.

My version: We’re glad the initial purpose of this group points toward standardization. IEEE stamping xAPI would encourage adoption, particularly outside of the US. It would send a positive message to the community at large that xAPI is a real and complete and adoptable thing.

My priority for this group is to remain focused on the standardization of xAPI 1.0.3, rather than evolution. Broader conversations about profiles and other things that xAPI requires (e.g. evolution of the specification and surrounding specifications) are happening in many venues, and I hope this doesn’t spread the community too thin. Instead, I hope they can successfully take the steps that help IEEE consider it for standardization. This is just step one of many in that regard.

So, thanks to Shelly for leading this. We, as Rustici Software, will be sending along one of our experts to participate as well. Ben Clark played an active role in the evolution of SCORM during the 2000s, and was the true leader on Project Tin Can, which led to the advent of xAPI. He’s pretty well informed.

If you’re the adventurous sort, Shelly has invited all comers. His LinkedIn post will point you in the right direction.

No Comments
 

Responding to recent ADL funding news

Posted by

Categories: Announcements, Spec Effort, Standards, xAPI

Posted 6 September 2017

 

I’ve spent a lot of time over the last couple of weeks learning about some things that are happening with ADL (the governing body for SCORM and closest thing we currently have to a single steward for xAPI right now).

My first tl;dr

  • Some funding things happened at ADL, but ADL will continue to do work on xAPI and with the xAPI community.
  • If ADL is limited in its ability to support xAPI or SCORM, Rustici Software and others are willing and able to step in and do what is necessary (even if there isn’t consensus about exactly what that would be just yet).

Wait. Even that was too long.

A better tl;dr

SCORM and xAPI are both still just fine. Use them exactly as you were planning to before you read this.

Now the long version.

The closest thing we have to news is this. ADL’s funding has been reduced substantially in the short-term. Basically, this means that ADL will make cuts on a temporary basis, and several people who have worked there over the last few years won’t be in the short term. (There are some great people considering their futures, if you’re looking for some expertise.)

ADL’s budget is included in the proper FY18 budget, at a level that is slightly smaller than prior years, but still significant ($11M+ as I read it). Supposing that comes through in February of 2018, they would hire people (familiar faces or new ones) and continue with the same or related work.

Truthfully, we can’t predict what the priorities of that organization will be in the short or long term, but we never really could. Until they say otherwise, I believe that ADL will continue to provide the infrastructure that supports xAPI and SCORM both. This includes the websites that have resources and examples. At Rustici, we have some comparable resources available, and we’ll continue to offer those. If ADL finds itself unable to do certain things at some point in the future, Rustici Software will fill the most important gaps.

Other people and organizations are stepping up and expressing their care and interest in contributing to the evolution and support of xAPI. This can be nothing other than good news. (OK, quietly, and for a small group of us, this can be a little confusing and frustrating. We have to navigate the different bodies and their respective merits. But that’s a problem for a few, not for the many. A service Rustici provides to its customers is absorbing this angst on their behalf.)

Ultimately, what we need as a vendor community and really an L&D community is consensus. We need to agree about how content and LMSs communicate at runtime, and we need to agree about how two systems talk to each other about the things people do. In the end, standards and specifications are a documented form of consensus.

Standards bodies provide some rails for reaching and documenting that consensus. I think ADL’s done a great job of this over time. For as long as there is good, consolidated, effective leadership in these communities, we greatly prefer to defer to and serve that leadership. Should ADL’s leadership wane, Rustici Software would increase our participation and influence consistent with our views on what is best for the community.

2 Comments
 

We’re calling it, “Experience API”

Posted by

Categories: Announcements, xAPI

Posted 20 July 2017

 

Just a little editor’s note for everyone. You may notice that this site now redirects you more aggressively toward its experienceapi.com representation. In 2015, we heavily revised experienceapi.com and established that, when it came to using xAPI vs. Tin Can, “We call it whatever you call it.” Our goal was to provide resources and advice to people in the way they were looking for it. If they wanted to use “Experience API,” that’s what we’d use. If they wanted to use “Tin Can,” we were on board.

Both in real life and here on the website, we’re pushing a little harder toward xAPI at this point. We’re never going to yell at someone who says Tin Can, but we may just refer to it as xAPI. You’ll also see that we’ve changed all of the references to be explicitly xAPI rather than Tin Can. I promise, we’ve done something more than just “find and replace”, but if you happen upon a place where we missed a Tin Can reference, feel free to let us know. The one caveat is that we’re keeping historical references to “Project Tin Can,” the origin of the Experience API.

We’ll also be updating our prototypes to the new language. As anyone who writes code can appreciate, changing code doesn’t happen overnight, so it will take some time.

No Comments