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 "Ideas" Category

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.

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

No Comments
 

Semantic Interoperability

Posted by

Categories: Best Practices, Ideas, Recipes, Registry, Standards, xAPI

Posted 24 January 2017

 

whatis-themeaning-meme-25449

 

You’re going to hear us talk a lot about semantic interoperability this year. So we might as well present a working definition.

Semantic interoperability is when information—the meaning behind captured data—is 
portable and well understood by any subsequent system requesting and reviewing it.

 

Why will we be talking about it a lot? Because without semantic interoperability, the Experience API (xAPI) has a limited future.

For us, semantic interoperability in xAPI will be achieved when there is a generally accepted information model. We expect profiles to help with this a great deal. There’s a strong possibility that collaborative work between ADL and IMS could help a great deal.

Then: Too Many Constraints

Consider SCORM, the usage of which remains widespread in LMSs everywhere. The CMI data model leveraged by SCORM is closely linked to its information model. There is a finite set of data that can be recorded about the types of learning experiences common to online training, and summarizing information from that data is a relatively straightforward exercise. So straightforward, in fact, that practitioners have long cared primarily about a big four—score, completion, satisfaction (i.e., pass/fail), and duration. SCORM makes requesting and understanding the big four easy.

Now: Too Much Flexibility

xAPI, on the other hand, is fundamentally a communication protocol applied as a specification for elearning. In xAPI, apart from a few familiar holdovers from SCORM (the big four, native support for interactions), there is no limit to what can be captured about a given learning experience. One could literally choose any verb available in any language. Or one could create a new activity definition to describe any type of experience.

Can you imagine how difficult it would be to report on data with so few constraints? We can. Because we’ve been trying.

Needed: Leadership

Even when there is consensus that a concept has sufficient value to merit a profile, there can be difficulty. Take video, for instance. Not only is there a profile in our Registry, there’s also a Community of Practice still working on a version. If there are multiple working versions of what data to capture, then how is a reporting system attempting to derive meaning about “video” supposed to do so?

We think the answer right now is: leadership. The concept of Registry has utility to semantic interoperability in xAPI, and we have a feature roadmap for it. Still, we recognize the difficulty in a single industry participant to establish credibility and trust.

What would alternatives look like? We think ADL could assert an information model. As a subtle alternative, ADL could host a collaborative process with some authority. This might look like the establishment of a baseline with a community process similar to how the specification itself operates now—managed workflow in GitHub supported by regular calls.

Expect to hear more from us on this topic because we think it’s critical to the future success of xAPI.

No Comments
 

More of the same

Posted by

Categories: Announcements, Ideas, News, Standards

Posted 2 February 2016

 

Welcome to week one of the post-acquisition Rustici Software world. I just thought I’d take a moment here to discuss one of the reasons we agreed to sell Rustici Software to LTG, because it’s not all about the money.

Mike and I were seeking investment funding for Watershed, but we really weren’t on the lookout for anything related to Rustici Software. It was a profitable business, I know very well how to run it, and we have several sets of work that give us cause for optimism. LTG, however, saw the value in both Watershed from an investment point of view and Rustici Software from a market and profitability point of view.

After LTG’s first visit, Mike and I asked ourselves two questions.

  • Did we believe that we would be able to maintain our strange and highly-valued culture through an acquisition? Having a place we want to come to work has always been a fundamental requirement for us.
  • Did we believe that we would be able to serve our customers in the way we always had?

Throughout the negotiations, due diligence, and these two long days as an LTG company 😉 we’ve consistently believed that we could do both of those things and still do. LTG is not an LMS provider like some of our prior suitors have been. We always used to worry that an acquisition of that sort might include aggressive interactions with our customers. With LTG, we’re going to continue to be agnostic, supportive of the standards, and generally the same company we always have been. We’re excited about it, and excited about continuing to support our customers and the industry in general in exactly the same way.

No Comments
 

I Want This: Tin Can Plans, Goals and Targets

Posted by

Categories: Ideas, Recipes, Statements, xAPI

Posted 27 August 2015

 

Learning plans, goals and targets are important. Setting goals for learning allows us to evaluate whether or not we are learning the things that we set out to learn. It’s standard practice for e-learning courses and qualifications to have learning outcomes attached to them, and these are used to measure if our learning has been successful. They are also used by educators and trainers to evaluate whether or not their teaching and training have been effective, and are used to inform interventions, further learning requirements and amendments to learning materials and lesson plans.

Learning Goals with Tin Can

Brian Miller touched on the use of sub-statements in Tin Can to represent future plans. The spec puts it this way: “One interesting use of sub-statements is in creating statements of intention.” and gives the following example:

{
    "actor": {
        "objectType": "Agent",
        "mbox":"mailto:test@example.com"
    },
    "verb" : {
        "id":"http://example.com/planned",
        "display": {
            "en-US":"planned"
        }
    },
    "object": {
        "objectType": "SubStatement",
        "actor" : {
            "objectType": "Agent",
            "mbox":"mailto:test@example.com"
        },
        "verb" : {
            "id":"http://example.com/visited",
            "display": {
                "en-US":"will visit"
            }
        },
        "object": {
            "id":"http://example.com/website",
            "definition": {
                "name" : {
                    "en-US":"Some Awesome Website"
                }
            }
        }
    }
}

MORE…

No Comments
 

Statements come from all kinds of places: content created in authoring tools, mobile apps, learning platforms and business systems. It’s not always immediately obvious which application the statement came from, which might be useful to know. This blog explains how you can tag the statements your tool or product generates and why that information is useful.

We’ve worked hard to make the Tin Can (xAPI) spec as clear as possible and have required Learning Record Stores (LRSs) to validate incoming data to ensure the same data structure is always used. There’s no way for statements to be sent to a conformant LRS unless they follow the prescribed data structure, and you’ll find that the major LRSs are strict with the data they accept.
MORE…

1 Comment