Table of Contents

Tin Can Content Support in learnexa

Support tin can as one content type in learnexa and tincan content should be able to store records in Learnexa LRS and any other LRS which support tincan api.

Design and Implementation

  1. Content Creation : Tincan content is handled very much similar to scorm content while creation. Any tincan package should be uploaded as a zip file which includes the activities and an xml file with name tincan.xml which acts as the manifest. The tincan manifest should be according to the xsd specified here - http://tincanapi.com/wp-content/assets/tincan.xsd . We support any tincan content which is of this form. Articulate and captivate content are supported as well.
    1. As a prerequisite site admin should configure LRS end point details in the manage site page to be able to create tincan content.
  2. Playing Content: Tincan content is played back in a similar way to scorm content in the player. Tin can content does not interact with LRS when played from course creation and content creation pages. It interacts with the LRS end points only from what i am working on panel when a user is taking the course.
  3. Communication through API: Tincan content can natively send requets to the end point which we pass to the content on launching. There are two ways specifying the end points.
    1. LRS end point directly : We directly let tincan content post statements to LRS without the inervention of the LMS. This has a restriction that both launching app and LRS should be of the same domain. Also, security is a concern here as we are letting the content take the encoded LRS api keys. This way does not work for us as content can't send crossdomain ajax requests.
    2. Via LMS endpoint: This is the way our communication is implemented. Tincan content will report statements to the Learenxa endpoint like - http://mycompany.learnexa.com/tincan/, then all statements will be posted LRS end point to http://mylrs.com/TCAPI/endpoint which ever is configured by the site admin. Authentication params and any required headers will be added to the request data by learnexa app and also some preprocessing of data is done to save completion and scores locally.
      1. Main advantages of this are - Support for multitenancy and crossdomain requests and LRS communication is more secure.
  4. Progress calculation and Reporting: Reporting is same as any other content. Only addition is we show all the learner statements in “Courses by User” report. Content is marked as complete when a statement is made from the content that the launched activity is either complete or passed or result has the “success” / “completion” filed value to true. In any other case content is not marked as complete.
  5. LMS to LRS communication: For Learnexa LRS it happens through the REST API and the ruby client for this API. More LRS s will be added over time which will also work similarly.

Table Design

Models -

TincanPackage - TincanPackage is extended from Document(which is extended from Asset) so that all the physically uploaded files would go to assets table and we resuse most of the code. We overwrite the paperclip settings and other methods for TincanPackage to suit the purpose.

TincanPackageDetail - This has the information of tincan content which is additional to any other asset. At present only manifest is saved here.

Tables -

Table name - tincan_package_deatils

This table stores the additional information of any tincan package which is not present for assets. At present we save manifest here.

Column_name type Description
id integer primary key
tincan_package_id integer Id of tincan package to which this belongs to
manifest longtext The parsed manifest object which is used as the course structure

* Note - The manifest column contains the TincanPackage::Manifest object which is generated after parsing the PIF.

Table name - tincan_sessions

This table saves the runtime information of any user who played this content. We track this based on enrollment_id because one tincan content may be present in more than one course. So, we need both course_id and the user_id when we need to track the progress of a user on a tincan package. Enrollment has both of these details. The number of attempts is stored in progress_scores table.

Column_name type Description
id integer primary key
tincan_package_id integer foreign key to tincan packages table. The tincan package id corresponding to which this session is created
enrollment_id integer foreign key to the users table. User who has launched this package.
runtime_data integer not used as of now.
progress_score integer
score integer not used as of now.
created_at date_time created date
updated_at date_timeupdated date

To be done

1) Book marking support (https://tracker.exphosted.com/view.php?id=5463) (Completed)

2) Oauth End points - Currently Basic authentication (2 legged oauth is supported). We may not need oAuth End points in the API at all as basic authentication works well for the API. In case needed in the future we can support oauth end points in the API.