Articulate Storyline & Tincan API change activity id for modules

Hello,

I am developing a couple of courses, using the tin can api for tracking the user results.

I am wondering if it is possible to override from Articulate Storyline the module id of the slides.

For example, if my course is made by 2 slides: Page 1 and Page 2, when I publish a course with tincan api selected, for each slide it will be generated an xml element in the file tincan.xml like 

<activity id="5v1xv1QCA93" type="module">

     <name lang="und">Page 1</name>

     <description lang="und">Page 1</description>

</activity>

While I would like to change the activity id of the module that corresponds to Page 1 to "page1activityId" ( I would like to obtain: <activity id="page1activityId" type="module"&gt,

is that possible?

Dan

5 Replies
Geordie Oxley

I've tried changing the xml file, but it makes no difference on ScormCloud. This is very frustrating as the results ending up in our other LRS are then quite hard to read. We will need to compare them to the XML file.

I'd like to understand what is Storyline's reason for providing  IDs that have no meaning. ??

Niels van Drimmelen

It's perfectly okay for an activity provider (like packages published by Storyline) to only provide the ID. The ID is what uniquely defines the activity. The Tincan specification allows for storage of the additonal metadata like a name or description in the xml file.

Adobe Captivate would store this descriptive information in the statements/LRS.

I guess there are pro's and con's:

  • When stored in the LRS, the description can't be changed anymore.
  • Storing the metadata along with the statement duplicates this data, as it is stored with every statement.
  • Extra data means additional costs from bandwidth an storage perspective.
  • More complex reporting, as you have to match the ID with an external xml file.
Andrew Downes

Hi,

I just posted in another thread by Geordie that Storyline 2's Tin Can tracking, whilst not perfect, is a big improvement on Storyline 1. Upgrading may fix this issue and if not will certainly make it easier to fix, especially if you're comfortable with editing the published files. 

Andrew

Justin Grenier

Good Morning, all.

I apologize that it took us some time to research the behavior you are seeing and consult with our Engineers so that we could understand and explain why our Tin Can API interface works this way.

The Tin Can API allows an activity to be defined within the tincan.xml file or directly within a statement. Articulate defines activities in the tincan.xml file.

When posting a statement to the Tin Can endpoint, the statement will reference objects defined in the tincan.xml by ID. The tincan.xml file will also contain definitions for choices, scale, source, target, and steps for the corresponding cmi.interaction type. You can find the xsd file describing the format of the tincan.xml file here.  You can also read more technical information to help LMS developers implement the Tin Can API to fully support Articulate content here.

In other words, the tincan.xml document tells the LMS all the metadata about the content, as in each question text, each question choice, and so on. Then, our JSON Statements post only the unique identifiers to the LMS. In order to come up with the meaningful descriptors for each answer choice that the learner makes, the LMS needs to cross reference the unique identifiers within the tincan.xml file.

This architecture is all a part of the Tin Can API specification, and you can read more about it here.  Here's an excerpt from that document that references specifically what we are talking about right now:

"What TinCan.xml should have is...  ...any activity details (such as activity descriptions) that should be available to reporting systems, but will not be (or may not be) sent by the activity provider when reporting statements...  ...That is, TinCan.xml may be used to describe activities to the LRS, as an alternative to doing that description at runtime."

The specific reason that we do this (explicitly exclude meaningful descriptors for each answer choice that the learner makes from our Statement JSON in favor of including them within the tincan.xml file) is so that the LMS will know about all the questions and answers and not just the ones the user selected.

Please note that Articulate software and its published output is supported as is. We cannot offer advice on customizing the published output to work in a specific LMS environment.  Working here with  the experts in our community on this issue is the right place to be when considering customizing our published output.

If you are looking to implement customizations for your LMS, you may want to look at hiring a consultant to assist you for a fee. We recommend Rustici Software. You can contact them here.

A couple of our Community Members have also filed private Support Cases on this matter, and I will also be sharing the same information there.

Please let us know if you need anything else.  Thanks!