Update: The Output of Project Tin Can is Experience API.

next generation scorm evolution project tin can
 

Ready to really dive in?
View the full
Tin Can API spec.

View the Tin Can API
“quick start” guide.


Use our prototypes to see content that works independently of an LMS

There are three sample content types that we’ve provided as part of the prototype package: (Note: if you’ve already downloaded the prototype, no need to redownload it.)

  1. GolfExample_TCAPI: this is a more traditional course. Learn the basics of golf, and report statements based on progress and assessment.
  2. JsTetris_TCAPI: this is a javascript version of Tetris. Play the game, and statements are sent based on your score and what level you achieve.
  3. Locator_TCAPI: a location based piece of traning, in particular a location-aware tour of Nashville, TN museums.

Before you launch the prototype courses, you’ll need to decide if you want to track your content with our public LRS or with your own SCORM Cloud account, and you’ll need to configure the prototype to work with whichever you have chosen.

Download Prototype

 

Configuring to send Tin Can statements to the public LRS

After you’ve downloaded the prototype, find the config.js.template file. Rename this file to just config.js, and then open it with a text editor. We need to replace some bits of text in the config.js file with the code that points your content to the public LRS, and you’ll need to put in some user information. Don’t jump the gun though, there are special instructions, and you’ll want to use the code provided below. (Remember, this is going to the public LRS, so anyone can see it. Use fake user info if you want).

You’ll need to replace the endpoint, the learner email, and the learner name. Please copy/paste the lines provided below to completely replace the existing lines in the config.js file, then fill in your user information.

The endpoint line should look like this:

You can leave the authUser and authPassword settings as the defaults since we’re reporting to the public LRS.

The Actor line should look like this (replace with your email and first/last names, and make sure to add the “mailto:” part):

Save the file, and you’re ready to go. Run the “index.html” file found in the ClientPrototypes folder. Note: this isn’t the index.html file in the course folders, it’s the one in the ClientPrototypes folder. If you don’t see any configuration settings in the top section of the index.html page, then revisit your config.js file to make sure you got everything right.

Click on the different course types to initiate them. You’ll start generating Tin Can statements to the public LRS. You can view them by clicking on the “Statement Viewer button” or the “Report Sample button” in the index.html file, or you can view them in the public LRS here.

If you’ve installed your prototypes on a web server, don’t forget to point your phone to that index.html file and see the beginnings of how Tin Can works with mobile.

 

Configuring to send Tin Can statements to SCORM Cloud

After you’ve downloaded the prototype, find the ClientPrototypes folder and then the config.js.template file. Rename this file to just config.js, and then open it with a text editor. We need to replace some bits of text in the config.js file with the code that points your content to the your SCORM Cloud account and authenticates, and you’ll need to put in some user information. Don’t jump the gun though, there are special instructions, and you’ll want to use the code provided below. (Remember, Tin Can is still beta, so don’t use it for anything sensitive).

We’ll need a SCORM Cloud AppID and secret key. To get these, log in to SCORM Cloud, click “Apps”, then click “Add Application.” Name your new application (Tin Can Private LRS?), then click “Show App ID” next to your new application. You’ll use the AppID and Secret Key from this section of SCORM Cloud in the config.js file.

tin can scorm cloud LRS config

Now back to the config.js file. Please copy/paste the lines provided below to completely replace the existing lines in the config.js file, then fill in your own information.

The endpoint line should look like this (add your AppID from the SCORM Cloud apps page, and make sure to use a “/” after your AppID here):

The authUser line should look like this (insert your SCORM Cloud AppID once again):

The authPassword line should look like this (Insert your SCORM Cloud Secret Key):

The Actor line should look like this (replace with your email and first/last names, and make sure to add the “mailto:” part):

Save the file, and you’re ready to go. Run the “index.html” file found in the ClientPrototypes folder. Note: this isn’t the index.html file in the course folders, it’s the one in the ClientPrototypes folder. If you don’t see any configuration settings in the top section of the index.html page, then revisit your config.js file to make sure you got everything right.

Click on the different course types to initiate them. You’ll start generating Tin Can statements to your SCORM Cloud account. You can view them by clicking on the “Statement Viewer button” or the “Report Sample button” in the index.html file, or in the Statement Viewer in the apps section of your SCORM Cloud account.

When viewing statements in the SCORM Cloud statement viewer, make sure you’ve selected the appropriate App in the dropdown menu on the top/right of the page (it’ll be the title of the app that you created in SCORM Cloud to access the AppID and secret key).

tin can lrs scorm cloud statement viewer

Again, if you’ve installed your prototypes on a web server, don’t forget to point your phone to that index.html file and see the beginnings of how Tin Can works with mobile.

 


Want your own content to start reporting statements to your SCORM Cloud account or the public LRS?

If you want to be one of the first to start using the Tin Can API with your content we’ll work with you to make it happen. You won’t only be on the cutting edge of next-gen SCORM, we’d also like to feature you in our upcoming presentation at mLearnCon.

Email us, and we’ll help you adopt Tin Can.
tincan@scorm.com

 


Did we get it right?

We still need your input, collaboration, and discussions about problems and solutions with the Tin Can API. If there is any particular feature or problem regarding Tin Can that you want to discuss, find the appropriate section on the capabilities or weaknesses page, and let your voice be heard.

  • Jay

    I am confused. So let’s say I have an organization of 100 people and I want to configure a course to report to public LRS. Do I have to update the code for every single person (name, email, etc.)??? That seems very labor intensive.

  • Ben Clark

    Jay, with this prototype you would have to do that, but a real course clearly shouldn’t be written that way.

    Tin Can may be used to communicate with an LRS by providing information about the actor and the activity being communicated about. That information may be collected in ways that are outside the scope of the spec, and there are various reasonable options depending on the required level of centralization and identity verification. On the one hand, the user could be asked to put in their name and email address. On the other, the software (or content to use the term we’re used to) communicating via Tin Can could read the user’s network login information and use that. Or read from a configuration file that has been pushed out. etc.

    If you’re looking for a more traditional approach, we’ve proposed a guide for how a TinCan LRS can be integrated into an LMS, which includes a launch mechanism to pass authentication.

    Integrating an LRS in with an LMS: https://docs.google.com/a/scorm.com/document/d/1sux36OlWH4fNPEzuSxPmr7jiFhyn9uqe1F__bygJ5fU/edit

  • Ben Clark

    Jay, with this prototype you would have to do that, but a real course clearly shouldn’t be written that way.

    Tin Can may be used to communicate with an LRS by providing information about the actor and the activity being communicated about. That information may be collected in ways that are outside the scope of the spec, and there are various reasonable options depending on the required level of centralization and identity verification. On the one hand, the user could be asked to put in their name and email address. On the other, the software (or content to use the term we’re used to) communicating via Tin Can could read the user’s network login information and use that. Or read from a configuration file that has been pushed out. etc.

    If you’re looking for a more traditional approach, we’ve proposed a guide for how a TinCan LRS can be integrated into an LMS, which includes a launch mechanism to pass authentication.

    Integrating an LRS in with an LMS: https://docs.google.com/a/scorm.com/document/d/1sux36OlWH4fNPEzuSxPmr7jiFhyn9uqe1F__bygJ5fU/edit

  • Ben Clark

    Jay, with this prototype you would have to do that, but a real course clearly shouldn’t be written that way.

    Tin Can may be used to communicate with an LRS by providing information about the actor and the activity being communicated about. That information may be collected in ways that are outside the scope of the spec, and there are various reasonable options depending on the required level of centralization and identity verification. On the one hand, the user could be asked to put in their name and email address. On the other, the software (or content to use the term we’re used to) communicating via Tin Can could read the user’s network login information and use that. Or read from a configuration file that has been pushed out. etc.

    If you’re looking for a more traditional approach, we’ve proposed a guide for how a TinCan LRS can be integrated into an LMS, which includes a launch mechanism to pass authentication.

    Integrating an LRS in with an LMS: https://docs.google.com/a/scorm.com/document/d/1sux36OlWH4fNPEzuSxPmr7jiFhyn9uqe1F__bygJ5fU/edit