I think it is right to not include it in the SCORM module as Tin Can API goes so much further beyond SCORM, it relates to all manner of different types of learning activities.

I think there are two options with Tin Can API support:

1. Implement the Tin Can API so that tasks completed in Moodle can be pushed out to a Learner Record Store. This could send statements relating to completion of any activity or resource, or course enrolment/completion. I'm sure there are others. I guess this would involve extending the Moodle Web Services and adding a Settings page to put the connection details of the LRS, bearing in mind that different courses, cohorts or individual users may wish to connect to different LRS tools.

2. Make Moodle the actual Learner Record Store too, capable of accepting incoming Tin Can API statements from external systems.

As far as I am aware, the Rustici plugin for Moodle forces you to use their own LRS, which is not a very open way of doing things. If a Moodle plugin existed that allowed you to select an LRS of your choosing that would be better. Better still though, would be native support

I have found Tin Can API an absolutely minefield btw, so I collected my thoughts on Tin Can API on my blog which will hopefully be of use to anyone wanting to get their head around it.
http://www.open-thoughts.com/2012/10/understanding-tin-can-api

Not to mention that kind of reporting will be required too.

I completely agree with Mark - let's not see Tin Can as "a new version of SCORM", it's much more powerful than that. Tim Martin at Rustici is a very useful person to engage (and won't just try to push their plugin!)

I do wonder, however, whether MAHARA isn't a better place for Tin Can support (rather than Moodle). Tin Can facilitates a "stream" of learning events. Learner could then select some of these, package them into an e-portfolio in Mahara, and submit them for grading in Moodle.

(I've posted similar thoughts on the Mahara forums)

Thanks everyone!
Mark - whoever comes up with the funding on this is likely to have some form of control over which parts will be supported/added first. Thanks for posting info on your blog - I'll try to take a look.

Tim - I work with the Rustici guys with a range of stuff - I've had some conversations with Tim Martin about native support for Tin Can in Moodle already and they have offered help where they can - they are keen to see native support for Tin Can in Moodle too.

Mahara may want to implement some form of Tin Can support, but we really need native support in Moodle without requiring Mahara as an add-on - I agree that there are a range of different things that we can do to build on the featureset that Tin Can provides but it's likely we will start with a basic player and reports built into Moodle - the other stuff will probably come later (unless someone has a chunk of funding to implement more) - It might be nice to build some form of generic PHP library to implement Tin can support that can be used in Moodle/Mahara and elsewhere but it will probably rely a lot on who funds the work and the direction they want to take. (If I get the privilege of working on Tin Can support, I'd be trying to make as much of the codebase as generic as possible to allow re-use in other PHP projects.)

There is some talk going on at the moment between some people that might result in Tin Can support for Moodle coming sometime next year - but nothing is confirmed at this stage and no specs or funding has been dedicated to anything yet - I'll try to update this tracker issue if I hear anything that can be made public!

thanks,

Hi Dan,
do we need to change the title from Implement Tin Can support to Implement Experience API ("Tin Can" API)? See here and below: http://www.adlnet.gov/capabilities/tla/experience-api.

Besides, AICC will collaborate with ADL: http://aicc.org/joomla/dev/index.php?option=com_content&view=article&id=160

good point - updated

*UPDATED ROADMAP BELOW*

I work for a major airline where we plan to implement Articulate's Storyline content with Tin Can support to take advantage of the iPad mobile player. Our employees will soon be issued iPads where they will likely accomplish most of their on-line learning.

Efforts are currently under way to implement a native Moodle LRS that will establish the endpoints required for secure content access and collecting Tin Can statements as well as support for resume states. We are building a modified SCORM module that will simply establish a new datamodel for Tin Can content in the same way it handles AICC content packages. This will eliminate the need for additional tables in the database and will take advantage of all native SCORM reporting as all SCO track records will exist in the native SCORM format. Initially, the LRS will simply collect statements and map them to the SCORM tables. However, there is potentia for future use of the LRS in mapping to specific statement collection tables that could be used in a variety of ways. This would likely mary up well with future development of a module as discussed here.

Implementation is short-term. So, I'll keep our progress posted.

Cool : I'll look forward to your code, derived from hacking the SCORM module and from the direct experience on the field - read here, reporting i.e. collecting LRs w/o reporting it's actually limiting the experience of who/what will react based on those learning experiences.

Thanks Jamie - Just a heads up - it's really unlikely I'll accept a patch on top of the existing SCORM module to add Tin Can support - The SCORM code in Moodle isn't a great example of good Moodle code and adding further API support to it is like to increase our technical debt within the SCORM module quite considerably. I'd really like to see it implemented in a clean/easy to maintain self-contained module by itself.

but - I'm really interested to see your work - hopefully we can re-use/re-purpose some of it into a separate module when you're done.

If there's anything I can do to help with the initial planning/structure I'd be happy to discuss via teleconf/skype, just drop me an e-mail.

Thanks Dan and Matteo.

I fully agree with both of you on the SCORM module comments. Actually, the direction I've decided to take now is to implement a local plugin as a service. The new plugin will utilize the REST web service and provide a single endpoint for access. This seems to be the obvious solution since support for updates, database, events, etc. are all there.

I've already developed a modified version of SCORM for the main purpose of being able to store, manage, and deliver TIN CAN packages using those provided by Articulate for Storyline. Since Tin Can packages do not use the typical imsmanifest.xml but use a tincan.xml, I've had to address how the packages are identified, parsed, and handled much in the same way as traditional SCORMs. This allows use of all existing package management, delivery mechanisms, and tracking with minimal coding and no additional tables, reports, or gradebook handling. At present state, it is now able to handle the Storyline .zip packages as local uploads, downloads (local syncs), and external (using the URL of the tincan.xml file). In conjunction with the Tin Can plugin, the packages now launch with appropriate parameters providing all instructions needed (including an automatically generated token) for the Storyline packages to communicate with the Tin Can endpoint. This is necessary for tracking when using the Articulate Mobile Player.

The end result will be a fully functioning LRS that's independent from the SCORM module. However, logic will be provided to allow access to statements by Moodle modules. The plan is to provide some filtering of incoming statements/requests and detect if they are related to a Moodle module. If so, the module folder will be searched for a tcapilib.php file and associated helper functions. The module will have opportunity to intervene in LRS storage and response. In the case of SCORM, statements will be scanned for activity progress, completion and grade. Data will be mapped to SCORM cmi vars and stored as track information in the native SCORM tables giving access to all native SCORM reporting and tracking (somewhat the same as AICC). This opens the door for other modules to have equal access to the API.

LRS reporting is something we may not have a need for short term. So, there's opportunity for development of a plugin report. However, any reporting system given an access token would be able to pull and report on the LRS data. I plan to provide a couple of different permissions as part of the Tin Can plugin. Those can be expanded on as types of use expand.

For now, I'm working on the data table structure for the LRS. If anyone has any input as to how they see the data being stored in way that lends well to reporting, pass it on to me. I should be making additional progress sometime in the next couple of weeks.

sounds exciting! - would be great to see this in a git repo at some point so we can take a look at the progress.

it does concern me that you've modified the existing SCORM module - I hope you've ripped out a lot of the cruft/mess! - in any case it sounds like it could be really useful simply as a 3rd party plugin for now and we can tidy/improve it over time!

Just for the record:

1. ADL releases Experience API version 0.95 specification
2. Experience-API-Release-v0.95.pdf

Hi Jamie,
any update about your progress? Have you already had the opportunity to publish your code in a public repo?

TIA,
Matteo

The holidays are behind us and I'm getting back on track now. I wanted to bring you up to speed on where I am with the LRS.

I've completed construction of a local plugin web service that provides an endpoint for LRS communication and data storage. It provides the ability to integrate any Moodle activity module by simply including a special library file, 'tcapilib.php', that contains specific functions allowing the activity to interact with transaction requests handled by the LRS. This was an integral part of being able to leverage the existing SCORM module to deploy and track TIN CAN packages published from Articulate Storyline. The SCORM module was modified to allow handling of packages that are uploaded, downloaded, and external.

To give you an idea of how the piece works, here's a quick behind the scenes summary:

• A course creator creates a new SCORM using a tin can package exactly the same way as a normal scorm package. The interface and settings are all the same. The differences are in the code and how the manifest is parsed.
• When the user hits the course page which includes a tin can activity, the launch path for the SCORM activity is constructed to include all required parameters to be passed to the tin can resource including a Moodle token specific to the TCAPI web service. This token is retrieved or automatically created if it doesn't already exist. The token is used for TCAPI transactions as well as secure content access. The secure content access is specific to Articulate for use with the mobile player much in the way the Moodle Mobile requires it. Content retrieval uses the web service pluginfile.php method.
• The launch parameter also includes a reference to the Moodle activity type and specific activity id. This will be used by the TCAPI web service to further process requests through the specific activity module.
• When the content is launched it proceeds to make requests to the TCAPI web service (LRS) through a specified endpoint location. This endpoint is a php file. However, through .htaccess and use of a subdomain the administrator could set it up as a 'pretty URL' such as http://lrs.mymoodlesite.com as opposed to http://mymoodle.com/local/tcapi/endpoint.php. Either will work fine.
• The TCAPI web service does a quick check to see if any Moodle activity module should handle the request and hands it off to the module prior to sending a response. This is where the tcapilib.php file in the SCORM folder handles all incoming requests related to the tin can packages.
• Basically, the tcapilib.php provides a library of functions that takes LRS statements and translates them to a SCO track record. It also stores and retrieves state data.
• In the end, we get SCO track records for a tin can package that mirror what we would expect from a standard scorm package. The benefit is that the reporting, activity completion, grade book, module reset, etc. all work without having to build extra code.
• I should also mention that all LRS statements are also recorded for reporting. It's not necessary for my requirements. However, it's a good test bed for storing and retrieving statements.
• Other functionalities also exist. Capture and storage of actor and activities occur as part of LRS statements processing. (Actor information does not need to be passed when using this API since the unique token is associated with a specific user. Per specs, actor information does not need to be passed when the LRS can positively identify the user through authentication.) Tincan.xml processing and parsing was built in since all Storyline packages use .xml files to store information about activities.

The system works great!! The work I have left is to fill in the gaps regarding LRS requests that fall outside of what I've had to build in order to accomplish the above process. These include complex statement and activity queries as well as some other miscellaneous items I haven't thought of yet. I'll likely need to get the folks at Rustici involved to make sure I stay on course and cover all the bases.

I also need to properly document my code which I plan to start doing soon. I have managed to get the installation up and running smoothly using the XMLDB editor which was a new process for me but have not taken the time to build out a simple test library for function testing since this is not a familiar process for me.

I'll work on getting a sample TCAPI package as soon as I can get the documentation roughed out. I just finished the code migration to 2.4, but it should work with older versions of 2.x.

Hi Jamie, if you need any testers please keep me in mind, we currently use Storyline for most of our SCORM content and I can assist with any testing on our development servers. I'm really excited about Tin Can and all it's possibilities.

Thanks Andre

Ditto to Andre's comment. Happy to test and super excited about TC API within Moodle!

I'm currently setting up a Git repository to share the code. For now I'd like to do a couple more installation checks along with better documentation. Then I'd love to get your feedback and testing.

Does anyone have a good UI for testing an LRS such as the IOS app that is provided for Tin Can? It would be good to be able to do similar queries on the Moodle LRS.

One more note. I have not yet built in the ability to authenticate external access to the LRS according to the API standards. I know that OAuth has been worked on as an authentication for Moodle but does not yet exist.
Currently, authentication is simply via the authentication token assigned to users. However, if access is required by an external service such as a reporting tool or otherwise, that piece will need to exist.
Does anyone have any suggestions on this? Is there already a method that exists in Moodle to allow application registration and REST authentication that would satisfy these requirements?

You could take a look at the IMS LTI implementation in Moodle, as a consumer via mod/lti and as a provider via local_ltiprovider: they both use Oauth from IMS Basic LTI, http://code.google.com/p/ims-dev/source/browse.

I've been wrapped up in other projects lately. So, no real time to clean up and document. However, I did implement use of Git for depositing my source code. Search for 'jgsmitty' on github. You should see two projects, the experience API and the modified SCORM module. I'll try to get some instructions for installation, setup, and use in the readme file within the next day or so. It's critical to make sure the permissions are set when using the experience API plugin web service since it relies on the global web services and REST to be enabled. Also, the SCORM module is a modified version of a recent build. So, you can probably just replace your existing SCORM module with that one. (The changes to SCORM are documented within and stored as a different commit. So, if you want to modify your own version of SCORM, you'll need to simply mimic the changes as reflected from the initial commit to the changes commit.)
Naturally, I recommend testing on a separate development installation that's fresh. I'm currently using Moodle 2.4.1. So, it appears to be stable there.
I'll also try to outline current functionality of the API along with those yet to be built in the update to the readme file.

• Jamie

Thanks Jamie!
I'll take a look at the code in the next days and drop here my first impressions in the direction of helping Dan for some integration within the main stream.

Hello Jamie,

First of all, many thanks for your job.

I've installed the LRS (TCAPI). The table in the database are well installed.
I've replaced the scorm directory by your one.

I've created a small tin can activity with storyline(a small quizz of 3 questions)
The module is well read bay the système but it doesn't send anything to the LRS. The 5 tables created by the tcapi plugin relain desperately empty.

Moreover : if I want ton send something to the LRS from outside of moodle, I think the endpoint is hhp://mymoodlesite/local/tcapi/endpoint.php
but what do i need to use as login and password ?

Many thanks again for your contribution.

Regards,

Lilian

Hi Lilian.

I've just added installation and configuration notes to the TCAPI and SCORM packages.

I'm guessing you may need to enable web services and the REST web service protocol. That would be a reason for not seeing any communications stored in the TCAPI tables. And, yes you're correct that the http://mymoodlesite/local/tcapi/endpoint.php is the endpoint to use.

Authentication is limited to use of a token right now. So, there's no password or username required as in oAuth. That is typically reserved for requesting/getting statements for reporting purposes as opposed to posting/putting them for storage.

The token used is a special Tin Can API token and is automatically created when the SCORM tin can content is accessed by a user. So, there's no need to create one manually. However, you may create/view stored tokens under Site administration -> Plugins -> Web services -> Manage tokens. You can then use that token for creating and submitting statements outside of the SCORM module.

Keep in mind that this project was initially centered around the need to host and track TIN CAN packages from within Moodle. So, the LRS functionalities are greatly limited at this time to simply accept statements from TIN CAN content (tested with Storyline content only), and accept or return State data for Resume State functionality.

Also, as a side note:
There is no LRS reporting at this time. The LRS passes statement information to the modified SCORM module with then translates the statement into a SCORM track. So, you should be able to view tracking information and completion states the same as with a traditional SCORM.

If you continue to have challenges let me know. I'll be working on this over time and will continue to update the Git repository as well as post changes and developments here.

Jamie

hi Jamie,

Everything seems to be weel install according to your recommandations.
I'm steel facing 2 issues :

1 - when I'm using a tin can module (quiz articulate storyline)throught your modified scorm module, I have the error message : "Unable to connect to server. Please verify that you are connected to the internet. Retry?"

2- When I try to reach the LRS using the statement viewer prvided by Rusticy as reference, I have the message : "ther was a problem communicating wiht the learning reconrd store (0|)

I precise that I've created a specific user called "ws" associated to the right of using REST Web Services, I've created a token for him associated to all TCAPI functions.

Many thanks again for your job and your support.

Lilian

Keep in mind this project was designed to accept statements. So, it's not yet designed to use with a 'statement viewer'. It will not return statements via the LRS.
However, it should work with no problems when using to accept and track Storyline Tin Can packages.
Would you be able to post or send your sample package as a .zip? I'll be glad to test it on my server and try to uncover the problem.

Jamie

sorry, it is a french module

Many thanks,
You can find as attached file the tincan package.

For information, regarding the rusticy tools, it doesn't work either if I want to send statement.

Have a nice investigation

Regards,
Lilian

Lilian,

I was able to reproduce the errors using your provided package.
As a result, I uncovered a couple of bugs that were the cause. A new commit to the package is on Github now for your use.
While testing on the iPad, I also noticed that you did not opt to use the Articulate Mobile player. The HTML version of the content seemed to work fine. However, the Mobile player would provide a more fluid experience for the iPad and should not have any issues with tracking.

Regarding the statement generator on the Rustici site, the TCAPI service does not yet support the standards for authorization using a username and password combination. Instead, it accepts a single 'authentication' token as demonstrated in the Bookmarklet example in the latest Experience API documentation. The Storyline content is passed this token within the launch parameters by the SCORM module within Moodle, then returns the token with each transaction to the TCAPI endpoint. This provides the necessary 'known user' authentication required for limited access to the LRS.

Thanks for helping to test this out. If you'd like to continue testing, download the latest updates from Github. Based on my most recent tests, it should work for you!!

Jamie

I'm a tech writer hoping to contribute some documentation, but I'm new to both Experience and Moodle. I started reading the Experience documentation over at ADL, and now I'm wondering where the Experience-API-For-Moodle documentation will be stored? At that jgsmitty Github repository? Somewhere else?

Thanks,

Todd

I just loaded the latest commit to include support for Basic Auth and header-supported token-only Bookmarklet authentication. Cross-domain is also supported. So, you can use the Tin Can statement generator to post statements to your own server on Moodle! You will, however, need to copy the .htaccess file from the recent commit as it's required for PHP to have access to the 'Authentication' header for both Basic and Token-only authentication. PHP does a fine job with native functions capturing Basic Auth username and password. However, passing a token via the Authentication header is a bit more challenging. So, the header has to be exposed through a mod re-write in the .htaccess file. If anyone has any alternative suggestions, please let me know.

The Basic Auth uses the native web service auth plugin. So, it's nice and clean. More permissions will be added to the TCAPI plugin in the future for specific requests required in reporting. Also, I suppose a refactoring is in order to migrate to a renamed plugin 'XAPI'. ???

For OAuth, I've decided not to build in that functionality. I feel it's better left as a web service functionality that can be called from any web service if required. This would make for a more standardized approach.

I'm barely above water here but treading fast!! So any feedback is appreciated. I know I still need better documentation and testing. I'll work that in as I expand the functionality.

• Jamie

I should mention that the .htaccess file is only required if the PHP function apache_request_headers() is not available. If it is, everything should work fine without the mod re-write.

If you notice something to the contrary please let me know.

Also, don't forget to turn on the web service auth plugin for Basic Auth use.

Jamie

Hi Jamie,
I'm lacking the right amount of spare time so I've just done a quick look at the code. Here are my first comments:

1. TCAPI -> XAPI, Tin Can API -> Experience API, tcapilib.php -> xapilib.php: not sure, Tin Can is the codename while Experience API is the project name
2. Do not end PHP files with ?>: it is not required and it helps you in case of blank spaces after
3. Debug with ob*: I need to look at it better to share my experience in debugging plain text payloads e.g. AICC HACP
4. No need of including " retrofitted from MySQL" in table comments
5. CamelCase, why? See e.g. local_tcapi_activityParser, local_tcapi_metaParser, $propertyKeys, .... Generally speaking, code indentation => http://docs.moodle.org/dev/Coding_style
6. Why not using lib/weblib.php::get_file_argument in get_functionname (it should be get_function_name)?
7. Please add $plugin->component = 'local_tcapi'; in version.php: it will help people in getting an error if they'll use a wrong folder.

Need more time:

1. to understand the coupling with a specific Editor, app:/Articulate.swf
2. to think at how to avoid copying code from SCORM manifest processing
3. to elaborate the reasons behind the choice of mapping both SCORM 1.2 and SCORM 2004 CMI elements as well as considering failed to select incomplete for the completion status... mumbling at cmi.core.exit = suspend to implement a behaviour required in SCORM 2004, too.

I hope I'll give you proper feedbacks in the next weeks.

Thanks for sharing your efforts!
Matteo

Hello I am looking into the possibility of using TIN CAN API for moodle 1.9. Would this be at all possible?

Matteo,
Thanks for the notes. I'm currently addressing some issues with Articulate's mobile player reporting. I'll go through them more thoroughly when I get them resolved and repost

Brandon,
I've given much consideration to building a version for 1.9 since most Moodle users, including myself, have their production installations locked in at 1.9 for one reason or another. I'll need to address the native support for local plugins and web services. Much of that functionality was built into Moodle 2.x. So, it may be difficult and require much more coding. I'll continue to repost my thoughts and any work toward a 1.9 solution.

Hi Jamie,
http://www.articulate.com/tincanapi/ explains TinCan from Articulate perspective and links to https://docs.google.com/document/d/1F-9pm8_z5oMyCsfj0iEpjQAa1KaCFdqEqjWoDNRt5xg/edit to expose how to manage "Private Content" but there's no mention about it in the official 0.95 spec, yet.

BTW, to avoid that HTTP 301 round trip and to code something not coupled to a specific vendor, I'm thinking at suggesting an improvement to the core webservice/pluginfile, something like:

$ git diff

diff --git a/webservice/pluginfile.php b/webservice/pluginfile.php

index f49480f..5d5bd9d 100644

--- a/webservice/pluginfile.php

+++ b/webservice/pluginfile.php

@@ -39,7 +39,21 @@ require_once($CFG->libdir . '/filelib.php');

 require_once($CFG->dirroot . '/webservice/lib.php');

 //authenticate the user

-$token = required_param('token', PARAM_ALPHANUM);

+$token = optional_param('token', '', PARAM_ALPHANUM);

+$relativepath = get_file_argument();

+if (empty($token)) {

+    $args = explode('/', ltrim($relativepath, '/'));

+     // in this case we expect at least:

+     // - 'token' reserved keyword and token value

+     // - context, component and filearea

+    if ((count($args) < 5) || ($args[0] !== 'token')) {

+        print_error('missingparam', '', '', 'token');

+    }

+    $tokenkeyword = array_shift($args);

+    $token = clean_param(array_shift($args), PARAM_ALPHANUM);

+    $relativepath = implode('/', $args);

+}

+

 $webservicelib = new webservice();

 $authenticationinfo = $webservicelib->authenticate_user($token);

@@ -50,5 +64,4 @@ if (empty($enabledfiledownload)) {

 }

 //finally we can serve the file :)

-$relativepath = get_file_argument();

 file_pluginfile($relativepath, 0);

to let you implement:

diff --git a/datamodels/tincanlib.php b/datamodels/tincanlib.php

index 18efc96..7a320de 100644

--- a/datamodels/tincanlib.php

+++ b/datamodels/tincanlib.php

@@ -41,9 +41,7 @@ function scorm_get_tincan_launch_params($scorm,$sco,$launchUrl) {

 	// Only provide if using the pluginfile.php method for delivery.

 	if ($pos = strpos($launchUrl, '/pluginfile.php')) {

 		$wscontenturl = substr($launchUrl, $pos, strlen($sco->launch)*-1);

-		$wscontenturl = str_ireplace('/pluginfile.php', '/webservice/pluginfile.php', $wscontenturl);

-		$launch_params['content_endpoint'] = TCAPI_CONTENT_ENDPOINT.$wscontenturl;

-		$launch_params['content_token'] = $token->token;

+		$wscontenturl = str_ireplace('/pluginfile.php', '/webservice/pluginfile.php/token/' . $token->token, $wscontenturl);

 	}

 	$params_encoded = array();

 	foreach ($launch_params as $lk=>$lv)

With this approach the authentication is preserved, regardless the way the vendor suggests to adopt.

What do you think?

IMO, this is simply the Moodle Log which is already in the right format, and not a new module at all. Every action throughout Moodle is then included.

Hi Martin,
to simplify, yes, eXperience API is just "logging a user experience": storing statements which could be seen as logging (e.g. for Activity Streams) like Moodle already does with its own "I did this" in mdl_log but if you look at the specs you'll see the complete picture i.e. storing statements related not only to the system implementing the store (read, the LRS), including a new standard to provide&store data created by something potentially different from the standard Learning Packages (e.g. http://www.hybrid-learning.com/labs/2013/01/08/using-arduino-to-report-experience-api-statements/).
More at http://tincanapi.com/overview/ where you'll find how the statements could vary from the plain (but nice) Moodle model of subject/verb/object which core and contrib modules can (better, should) use.

BTW, you've given me food for thoughts about Logging v2: think about separate tables using JSON as data binding (i.e. the XAPI statements) into e.g. MongoDB, already available as a MUC store (it could be programmatically selected with MDL-36557) and kind of batch analytics like e.g. Piwik does on its own collected data to create stats for Moodle Activities as well as for External Activities... maybe I'm just talking too much about nonsenses .

Thanks for your suggestions Matteo and your support.

I've not had a lot of time to invest lately. However, I did recently discover an issue that prevented the Articulate Mobile Player from accessing embedded video from the TCAPI content end point.

It appears that the Mobile Player does not handle the 301 redirect for those specific requests. As a result, I was prompted to re-evaluate that method. Rather than modifying the webservice/pluginfile.php, I simply eliminated its use and included the same logic directly in the content end point file. This has effectively eliminated the 301 redirect as you suggested and resolved the Mobile Player video access problem.
My latest commits to the SCORM module and the API are on Github for your reference.

I'll follow up on your other suggestions in the near future.

Yes I've been looking at the TinCan API but I still have a problem with it. It's both too simple and too complex.

• I've not seen any any standard grammar or security for the activity streams, so combining data from various random internet sources seems (in actual practice) to be really difficult and of questionable actual usefulness for assessment.
• Scale. "Martin posted tweet" is one entry, and so is "Martin completed PhD".
• Integration. To do it properly we have to add this standard to all the big things on the internet like Youtube, twitter etc. Seems hard.
• It overlaps with Open Badges and even a little with LTI.

Anyway, despite all that:

1) It would be quite easy to create plugins for Moodle to publish our logs into a Tin Can format for consumption by other entities. Will keep this in mind especially for Logging 2.

2) I'm all for a mod/tincan module to support the smaller case of "a replacement for scorm".

Hi All,
@Jamie Smith: I'll look at the new code in the next days. I was pretty sure about HTTP 301 not correctly managed by Audio/Video players - common situation even for Desktop: a weakness IMHO in the xAPI suggestions that needs to be solved by the vendor -.
My conduct is not to duplicate the core code but to extend it if it is possible to explain the benefits to HQ through use cases: I'll take care of it. Time permitted I'd like to contribute at least cleaning up the code using Moodle guidelines and some suggestion of mines, I'll clone the repo some day and give you the idea of such a cleanup: unfortunately I'm lacking spare time in these days (so I'm moving slowly around Moodle stuff) and right mobile devices @home.
@Martin Dougiamas: you've nicely focused! That's the problem (same as Simple Sequencing in SCORM 1.3/2004): it's simple for Storing data while it's complex to Aggregate them 'cause of it requires an analytic layer and Scalability is the other concern: room potentially for Big Data here (Hadoop, ...). Thanks for taking the time to dive into TinCan . I could guess someone in Google is thinking to provide a beta service for a cloud-based LRS (big) store to collect more data to "track" users and increase the Google Activity Streams .

Matteo

OT: streams (and alerts) proposal, https://moodle.org/mod/forum/discuss.php?d=223812 and http://docs.moodle.org/dev/Streams_and_alerts.

Hi, is it worth splitting this tracker item in a few more focused streams, in order to avoid the inevitable overlap that is happening?

1. Martin's suggested mod/tincan module to support the smaller case of "a replacement for scorm". As I understand it, this is what Jamie's work is targetting. BTW, excellent work Jamie, I've been following your comments with interest

2. Publish Moodle logs into Tin Can format so that Moodle can push statements to an EXTERNAL LRS. This would appear to dovetail with Logging 2 and with my limited development knowledge could be a set of web services to push this data out of Moodle?

3. Build an INTERNAL LRS into Moodle, which could also be a 'feature' of Logging 2. Maybe this is part of 2 above anyway, they are closely related.

Picking up on the point about analytics, in my view this is a completely separate discussion. The analytics layer sits on top of the LRS is not really part of the TCAPI spec as I understand it. That said, I expect that as LRS products start to surface they will have sophisticated analytics layers built in as features. I would have thought that a learning analytics system within Moodle that sits on top of the Logging 2 (Tin Can compliant) data store would be the way to go, which I gather is in the pipeline anyway. Kings College London showed some interesting work at MootIE13 last month that they indicated has the potential to become a plugin. If Moodle had a basic analytics tool that would be great, but the key would be making that data store accessible to data scientists who can do more specialist stuff with Hadoop, Tableau or whatever more advanced tools they use themselves. But I don't think any of that needs to be within the scope of the Tin Can API implementation, except making the data accessible.

Martin, regarding your concern about grammar, there is some good info on verb definition here: http://tincanapi.co.uk/pages/verbs.html

Hi all,
Mark has suggested I join the conversation here. I don't know much about Moodle but I know a lot about Tin Can so hopefully I can be of help. There's a number of resources on my website http://www.tincanapi.co.uk including links to my Github and a statement generator that's a little more comprehensive than the Rustici one.

From having a quick skim over the conversation it looks like there are a number of tools that could be developed entirely independently and work together using Tin Can and Moodle. Take a look at the approach I've taken here: https://github.com/garemoko/TinRepo . We can take a similar approach with Moodle.

As Mark says this could be split up into:

1. Launching wrapped up content a la SCORM. This part should also implement CMI5. See https://github.com/AICC/CMI-5_Spec_Current

2. Tin Can reporting from Moodle e.g. discussion forums. See https://github.com/garemoko/PHPCan/blob/master/sendStatement.php

3. An open source PHP LRS designed to sit on the same server as a Moodle or stand alone. When integrated into Moodle it can share some of the user management features. The user management stuff could also be done without direct integration. See https://github.com/garemoko/xAPI-Spec/blob/permissionsProfile/permissions.md

4. Learning Analytics using the Tin Can data. Again, this could either be integrated into Moodle or stand alone tools or both.

These can be treated as four completely separate projects and there is value in developing each of these on their own even if the others do not exist yet. The first two need to be integrated into Moodle but the second two could work alongside Moodle or be integrated.

I hope that's helpful. I'm happy to answer any questions here about anything Tin Can related or what I've mentioned above.

Andrew

Oh also: 5. Adaptive release based on Tin Can statements.

There are lots of watchers and voters of this tracker item, does anyone have a view on the above regarding creating multiple items for the various strands? I'm not sure how to go about it if so, I think there is a META ticket that could be used?

1. Launching wrapped up content a la SCORM: This should probably be the first priority. Most of our instructor users understand Tin Can in the context of SCORM. And this functionality is what they will expect first because this is how they understand SCORM.

Regarding 2. Tin Can reporting from Moodle e.g. discussion forums, I don't see why that would need to be limited to only discussion forums. Pretty much every resource and activity in Moodle facilitates an action that can be reported/recorded via Tin Can. But that is way outside of the scope of SCORM. It seems like what we would want to do in that case is establish a set method, a subset of editing controls for setting where the data is sent and what is sent, and that is implemented on a per-module basis. But lots of decisions would have to be made with regard to that. Is the data aggregated in some way from the gradebook? Is it aggregated from individual activities and resources? It would be the kind of tool, like outcomes and completion tracking, that would touch a lot of things.

An open source PHP LRS Not a new idea. Dan & I discussed it in Perth. The real question is not how we implement it but how we get that data into useful places in Moodle. Where does the TinCan info from the LRS go? To the user profile? To class gradebooks? How will we know?

With regard to analytics, we then have another quandary: do we attempt to get this data in to existing Moodle formats, like the gradebook, thus developing analytics to benefit all of Moodle; or do we develop analytics solely for TinCan received via the LRS, which will not benefit all of Moodle or provide comprehensive analysis of a student's work both within Moodle and without. Do we translate all gradebook data into 'Tin-Can-like' data in order to add it to the analysis? Would the result be useful?

2) Amy, this is what I said about logs above, and is part of the scope for our logging rewrite (using events) in 2.6.

4) I don't see why tincan needs to get between our own logs and our own analytics. We need that to be super fast, and it will be quite specific to things in Moodle. Or course our analytics will generate another activity stream of their own, and that can be published to an LRS via TinCan easily if required.

Hi all,
Has anybody made anymore progress on this? I'm considering doing a bit of open source work around Tin Can and Moodle. Specifically I'm considering:

1. Outputting Moodle user logs as Tin Can statements.

2. Launching externally hosted Tin Can e-learning from Moodle, initially using the Rustici launch method but possibly incorporating a CMI5 option later.

Has anybody already done any work in this area? Is anybody interested in helping out? PHP developers with a knowledge of Moodle are most welcome. Everyone else is just welcome. :-p

I've also posted on the Tin Can forums.

Andrew

Hi Andrew,
what has been coded by Jamie Smith cover part of your (2): it could be nice if you could start reviewing his code as your first starting point when working at (2). About (1): I'll be happy to help you with some code review: unfortunately spare time is limited so this is what I can offer now.

Note: CMI-5 will be IMHO the way to go, when it will be officially proposed.

Hi Andrew,
For (1) , are you planning to build those on top of our new events/logging?
http://docs.moodle.org/dev/Talk:Logging_2#Can_we_support_Tincan_Experience_API_via_a_retrieval_plugin.2Freporting_tool
http://docs.moodle.org/dev/Event_2

If so, I would be happy to help in anyway I can.
Thanks

There has been some talk about this in the Moodle forums. E.g. https://moodle.org/mod/forum/discuss.php?d=230866

Thanks Matteo, I had a quick look at Jamie's code and it looks like he has a different focus. From what I can see, Jamie is launching Tin Can courses hosted within Moodle and then tracking those using Moodle' s SCORM tracking features.

What I'm hoping to do is launch Tin Can experiences hosted outside of Moodle and track those to an LRS (which may or may not be part of Moodle).

Ankit, I had not got as far as planning anything but I think that makes sense. Do you see Tin Can reporting as an observer looking at the events process or would it be integrated into the events code? What's the difference between the events and logging projects?

Tim, thanks I'll take a look!

I'm hoping to be able to announce some plans related to this in the next month or so - I'm still on the fence a bit on whether to include the work Jamie has done in the core SCORM module or if we will want to develop a separate clean module but hopefully I should be able to announce some solid plans soon.

Great stuff Dan. I'll keep an eye out for your announcement. I've managed to recruit a php developer volunteer from the Tin Can forums so we'll make a start with scoping out what's involved in the two items I mentioned above. Hopefully there'll be some cross over with what you're planning to do.

Andrew

I've decided to start by looking at launching externally hosted Tin Can e-learning from Moodle. I've put down some initial thoughts here: https://github.com/garemoko/MoodleLaunch

I think this will be slightly different from what Jamie's already produced as it will deal with externally hosted content rather than uploaded packages.

Jamie - I'd be interested in hearing from you if you think there's anything we can re-use for this project from what you've done already? I also notice from your Github that you've been looking at oauth - that could be very handy for this project once we've sorted out the basics.

Andrew

Andrew Downes, I think you should also have a look at what AICC is finalizing with their CMI-5 specs (https://github.com/AICC/CMI-5_Spec_Current). Since we already have some support to AICC (and HACP) in SCORM.

And also checkout Catalonia (Spain) special Marsupial project (https://github.com/projectestac/marsupial)

“Marsupial” is a set of protocols defined by the Ministry of Education of Catalonia in the context of the 1-to-1 program “educat1x1/eduCAT 2.0”.
The target of “Marsupial” is to facilitate the communication between Virtual Learning Environments (VLE) and on-line commercial textbooks provided by publishers.
The “Marsupial” protocol defines three main functions:

1. An internal structure of digital textbooks, usually as a tree of chapters or topics, thus facilitating direct references from the VLE to specific contents of the book.
2. To manage credentials and silently authenticate students on textbook platforms, so after a single login into the VLE, students can work with their digital textbooks (even from different publishers) without having to log-in again in each platform.
3. To report to the VLE the results of exercises and activities made by students inside the digital textbooks. This allows teachers to have the results of all exercises collected in a single place, thus facilitating a global assessment.

Thanks. I'll take a look!

Hi Andrew,
a small note about licensing: you can't derivate a GPL-ed work and licensed it as Apache 2.0, you need to keep your derivate work under the GPL umbrella.

Besides, here is a trivial note about PHP Docs in Moodle:

* @package mod

* @subpackage tincanlaunch

should be:

* @package mod_tincanlaunch

Found right now that https://github.com/moodlehq/moodle-mod_newmodule/blob/master/lib.php#L28 misses the update to the new PHP Docs coding style: MDLSITE-2362.

HTH,
Matteo

Thanks, that's helpful. I'll make those documentation fixes.

Whilst you were reviewing, did you notice anything wrong with the actual code? When I drop it into my mod folder, it crashes moodle so I just get a white screen until I delete that mod.

Andrew

Fixed it. The trick was to update version.php with this new line:

$module->requires  = 2013050100

in place of:

$module->requires  = 2010031900;      

and then delete and re-add the plugin.

Hi Andrew,
that's strange: BTW I'll extensively look at the code one of the next (my) evenings, I'm already watching your repo so I'll be notified of any change.
What about opening a new thread in the Developers Community to let these comments be posted there? We'll be able to post several messages/comments w/o bothering the watchers of this issue with the ongoing dev updates (this is the way other people uses to create discussions during the development).

Thanks. I've created a thread here: https://moodle.org/mod/forum/discuss.php?d=233707

I've got an initial release that seems to work now. I'm going to leave it for a week or two for others to try it out and review and I'll possibly start working on another part of the plugin collection.

Andrew

Sorry for my absence of late. However, our company has taken a different path and shifted focus from the use of Moodle as an LMS.
Based on the recent posts, it seems that much of the interest is not necessarily on Moodle as an LRS but simply being able to interface with an external LRS in the way of launching content, be it external or internal, and report on the collected streams of data.

My primary focus was always on providing a simple interface to facilitate the upload and tracking of content that would live outside of Moodle, as in the Articulate Mobile Player. The built in LRS seemed to be the most appropriate way to collect streams from 'known' content and users. Simply converting those streams into reportable data in the form of SCO tracks eliminated the need for an additional reporting tool. Effectively, the administrator really doesn't have to do anything different in order to take advantage of Tin Can in the way that it allows content to live outside of the LMS.

I realize that the end result does not fully celebrate the complete intent or potential of Tin Can. However, I do think it helps to fulfill an immediate need for those wishing to take advantage of the newer mobile device deployment methods and maintain the ability to track user interactions and completion.

Feel free to re-use any code included in my project and call on me with questions. However, with our change in direction, it's not likely that I'll be furthering any efforts on this front in the near term.

Cheers Jamie, thanks for the update.

Thanks Jamie!

Thanks heaps for your work Jamie! - I'm still hoping to get some time to spend on this so the work you have already done is really useful - thanks!

I've started to look at this again with the hope of getting something into Moodle 2.7 - I've convinced myself that it makes sense to extend the existing SCORM plugin to include support for importing Tin Can packages for storage/playing in Moodle. I've started by looking at the work Jamie has already done and am currently working on porting that/tidying it up - for those that want to watch the progress keep an eye on my github repo - here's the current in-progress work: https://github.com/danmarsden/moodle/compare/moodle:master...master_MDL-35433

That's great to hear Dan. Hopefully, my work is beneficial to you. If you have any questions, please don't hesitate to ask. I'm sure some cleaning up and alignment with the latest Tin Can specs are in order. I do think the community will put it to use and make your efforts worthwhile.
Thanks for continuing work on this.

Great news Dan!

Hi all, I did a bit more work on my launch plugin today and also started to implement Tin Can tracking as part of the quiz module:

https://github.com/garemoko/moodle_tincan_quiz/commit/a62ee517c59696fc8164ddf850711a375b50fb32

Any thoughts always welcome.

Andrew

Andrew, I think xAPI (TINCAN) statements should be generated by events, globally, and not specifically in each module. (i.e. Quiz).

Or, it might be event better to develop a local plugin that wrap the logging framework and expose it as an LRS. Which will convert Moodle log entries to xAPI statements, as far as possible. And maybe add the missing events in Moodle for major missing statements.

What do you think?

Hi Nadav,
I agree with you, xAPI as a local plug-in was my first thought before Jamie Smith proposed a nice SCORM module enh to allow xAPI packages (at his time, pending the new CMI5 work available in https://github.com/AICC/CMI-5_Spec_Current/blob/master/cmi5_coursestructure.md) to be deployed and tracked i.e. the CMI5 Launch feature.
BTW, for Trackers' ref: https://moodle.org/mod/forum/discuss.php?d=256381#p1111891.

HTH,
Matteo

Hi,
I did agree that logging would be the way to do this, but having looked at logging and thinking about this more, actually the match isn't quite right and I think we can get better data by designing the Tin Can tracking for each module rather than relying on the logging design to work. Logging tracks a lot more less meaningful events than we'd want with Tin Can and doesn't provide all the data we'd want, for question type or correct answers pattern are two examples of this.

That said, a lot of the code could certainly be centralised for use by multiple activity modules, in particular the settings (bar activity id which could be calculated by Moodle) and the functions I put in locallib.php. If you agree, do you have time to provide some direction on how to set this up and call it from the quiz module or even put something together based on my code?

Thanks for your input!

Andrew

Andrew, have you been looking at the new logging in Moodle 2.7 or the previous simple logs? I urge you to look at the new logging and events again. The docs are still being worked on but see http://docs.moodle.org/dev/Event_2 for example.

Having glanced at your patch to extend quiz, I really think designing yet another set of callbacks and database fields that every module would have to implement is really a non-starter...

Andrew,
looking at your Quiz code patch and althought it would probably work with the standalone LRS LearningLocker I am not sure Tim Hunt would like the way it was implemented. Let's join Tim to the discussion. Though I do not think it should be confined to the Quiz module alone.

It should be part of a much low level infrastructure. Teachers should not turn "xAPI logging" for specific activities. An Administrator should control it. It should be transparent for Teachers.

I think, their should be a versatile logging infrastructure that has an external LRS interface that transform the internal logging to xAPI statements that can be used by Moodle's internal (and 3rd party) report plugins or for standalone 3rd party analysis and reporting tools that connect to Moodle LRS interface and read (or write) some data from it.

Looking at the current Event_2 verb list and comparing it with ADL's verb vocabulary or Rustici's verb list or AICC's short verb list we can see a clear differance.
First we should add the missing relevant ones to our list.

Then, probably, set some requirement or suggestions for developers as to how should "Pedagogical" events triggers be implement, which will result in xAPI statements. (I think it was considered as "Level property" of the event)

Obviously, some modules should implement more statements than others. All should have xAPI "started", "updated" (with progress) ,"completed". Which should probably handled by core Moodle "Technical" events ("viewed", "updated", "ended").

A Quiz or a SCORM module should implement more specific xAPI statements (pedagogical events) : "attempted","suspended", "passed", "failed".

One more point to consider, is that the taxonomy used in the "activity completion" and "conditional activity" mechanisms we use in Moodle, have slightly different naming conventions in comparison to xAPI statements. And if Teachers are presented with both "xAPI course analytics" (based on student's xAPI statements triggered by Moodle events) and Moodle's internal course completion logging or Moodle internal log reports, there could be some confusion and misrepresentation of the data displayed.

Hi Martin,
I think we can dispatch with the extra database fields pretty quickly be centralising the settings as Nadav and Matteo suggest.

Replacing the extra callbacks needs more though, but thanks for encouraging me to look at events again - I hadn't looked at this for a while and did have the current system in mind. I've got a client who specifically needs to tin can track the quiz and likely won't be using 2.7 (and certainly won't be before it's released!) Still, I need to think future proof and bigger picture, particularly for my out-of-work work so thanks for pointing me at that.

My initial concern with using events/logging is that they don't provide the right events, they provide to many events or they don't provide enough information. Actually looking at the documentation it looks like events should be fairly comprehensive so the first item is less of a worry. The second and third concerns are valid however, and unless we were to adopt Tin Can syntax (not data transfer mechanism) for the events API, I can't see a way around having some designed system that looks for specific events in specific modules, pulls out additional data from that module's database and generates a Tin Can statement. let me know if some examples would help here. I guess we're looking at something similar to the recent activities block, except without the functions in each module that supports it. Where does this leave new modules that the Tin can plugin isn't aware of though?

How would you feel about a local plugin that hooks into events for specific modules and then sends Tin Can statements to an external LRS? If that's the way forwards, what state is the events API in now and how can I get started on a prototype? Can somebody point me to a good local plugin example or tutorial as a start?

Nadav, on the topic of an LRS embedded in Moodle, that would be great, but I don't have the resources for that or really see the need for it, particularly as Learning Locker is so far on in development. It's the same for an e-portfolio embedded in Moodle - just use Mahara!

I know very little about Moodle, but we've released TinCanPHP FWIW.

http://rusticisoftware.github.io/TinCanPHP/

Andrew's start is a really good one, we had a different focus so put out the whole thing. If there is something that would make it easier to use from Moodle (core or a plugin) let me know via a GitHub issue and we'll take a look.

Thanks Brian! (Fancy seeing you here?)

I really appreciate you putting the work into a PHP library.

I'll definitely take a look with a view to at replacing my code with that at some point, particularly for tracking Moodle activity if you get OAuth sorted. With PHP being server side there's not really any excuse to use basic authentication.

I wonder if composer will cause any problems with including the library in a plugin for people who may not have composer installed? I'll try it out and let you know if there's any issues.

I assume the difference in license (Apache 2 vs Moodle's GPL) won't cause any problems as the library is a self contained bundle. If anybody else has more insight on that, please shout up!

Andrew

Apache 2 is no problem. https://www.gnu.org/licenses/license-list.html#apache2

You most likely will not be parsing logs, but capturing events.

I can see it best working roughly like this:

1. You write this as a /report plugin that listens for specific events and converts them to whatever TinCan needs on the fly. It can collect data locally in it's own tables in TinCan format if you need that. The plugin also provides the interface points for LRS. The plugin contains settings to control access and the flow of information, turn certain events on or off etc, as the admin requires.
2. If new events are needed, then create them under new issues in this tracker and we can look at getting them into core as necessary.

Thanks Martin that sounds like a good direction. I like the idea of storing statements in a database to be sent in batches; hopefully that should improve performance. 

it's great to see all the new projects developing open-source options for Tin Can - with the amount of work involved it makes sense for Moodle to adopt some of these options instead of rolling our own - Thanks Brian for the pointer to the Rustici PHP library. Do you know if anyone else has adopted your API yet? (I presume you're using it internally for something?)

Not sure who else might be using it at this point, that's a problem with OSS . We aren't using it directly in house, but we built it specifically for a client who will start to use it very soon. Having said that, the API is modeled after TinCanJS and TinCanJava which are pretty well used. As the third iteration I think it is a bit tighter in the return values from the LRS calls, and a couple other areas.

Hi Brian,
I tried to get this working in a Moodle plugin this evening. I installed it via composer fine and added the require code, but it's not finding the classes when it comes to run the code. Any ideas for what I should try?

Andrew

Hi Martin,
Why do you suggest a report plugin rather than a local plugin? It looks like report plugins need to have an index.php which this one won't, at least not initially, or am I missing something?

Andrew

Hi all,
I am following this conversation with interest. I am experimenting with Outcome Sets in the beta version of Moodle and hope that these too would be part of any reporting to an LRS.

I am happy to assist with any scoping, scenario building or testing of what is being produced.

Hi Natalie!

Thanks for getting involved! What are Outcome sets and how are they related?

Andrew

/local plugins are the catchall type of plugins when no other type makes sense, usually for plugins that are local to a specific installation.

To me /report is both a good fit for this and a better option for this to get into core later on. It's not to hard to image index.php providing some sort of overview status report (for admins, teachers and users) so that people can see what data has been sent through out, as well as possibly some way for users to specify their own LRS etc.

Details of Outcome Sets to be released in Moodle 2.7 , links to Sam's version on bitbucket, and sample csv files of Outcome Sets are available on this page: http://docs.moodle.org/dev/2.7_Outcomes_scope.

With the more detailed event reporting and the ability to map activities against outcomes Moodle becomes the ideal platform for implementing gamification in education (along with badges and rubrics). One of the fundamental principles of game design is short feedback loops to the players, so I am interested in how Moodle reporting can provide fast, detailed reports back to the learners, and also to teachers/assessors.

I am working on another project using a Learning Record Store, which I intend to link up to my Moodle site. I imagine that as a Moodle course creator I would create a few activities and resources and then map these to learning outcomes in Moodle. In my design I give people a few options on how to meet a certain outcome. So the data sent to the Learning Record store may say:

PersonA 'completed' ActivityX.

And this statement could also be sent:

PersonA 'completed' OutcomeX.

The person may have met that Outcome in some other offline way, eg observation in the workplace, which is recorded directly in to the LRS. I would then filter the LRS based on the user and see if they had met OutcomeX - either within Moodle choosing one of my options, or in another situation. From this perspective reporting on activity completion is less important than if the outcomes have been met as yet.

I am also wondering if this is two-way communication so that Moodle can read data entered in to the LRS?

Natalie

Interesting stuff Natalie.

The Tin Can launch module (currently only really a prototype) does allow you to pull back statements from the LRS and set Moodle completion based in a particular statement, which I think is a step towards what you described. The main challenge here is that the Moodle has to check for the statement, but if the activity happened entirely offline, how does the Moodle know to go check? We need to design in some kind of trigger for this check to happen - a 'claim outcome' button or something perhaps.

Andrew

(Outcomes will not be landing in 2.7, unfortunately)

Andrew,

Composer creates an 'autoload.php' file that can be used to load all the classes provided by a module installed by Composer. AFAIK that is the best way to go. Otherwise you would need to issue a `require_once(<file>);` on each of the PHP files. Moodle may have a preferred method for doing this with Composer but I didn't have a chance to look yet.

The repo has a sample 1 page "app" that shows this at work. You can see it here: https://github.com/RusticiSoftware/TinCanPHP/tree/master/sample once `composer` install has been run there is a `vendor/autoload.php` generated.

Brian

Thanks Brian. I got it working but I had to make a couple of changes.

1. Change my namespace - we were both using the 'tincan' namespace (D'oh!).

2. Amend the example code to look in the global namespace by adding a slash e.g. '$lrs = new \TinCan\RemoteLRS'

3. Use the saveStatement method rather than sendStatement. You've got sendStatement in yoru examples, and that's what we use in TinCanJS, but it looks like you've (accidentally?) used a different name in TinCanPHP? I'll raise an issue on Github for this one.

Hope that's helpful to anybody else implementing TinCanPHP in Moodle.

Andrew

Just a quick note to say that with over 70 votes, this ticket has now made it into the Top 10 of the New Features and Improvements list in the Moodle Tracker
https://tracker.moodle.org/issues/?filter=10512

Question: Should the 'Affected Version' field in this ticket be set to 'Future Dev' instead of tying it to M2.4, which is simply when it was raised? Would make more sense to me. Can someone closer to HQ advise if this is the right thing to do, please?

Natalie Denmeade asked:

I am also wondering if this is two-way communication so that Moodle can read data entered in to the LRS?

In the current Outcomes proposal, the instructor decides whether the student has met or has not met the Outcome, so it's not necessarily writing it to Moodle it is communicating it to the instructor. There are a couple of ways I can think of to implement this, depending on whether you need to explicitly track the achievement within Moodle, but it would involve the use of custom plugins.

(Mark, the "affected versions" on new features is not really important. New features only go in the latest new major releases anyway.)

Dan, I'm using your branch to add TCAPI support, which worked great in my initial testing.

Through an integration with SCORM Engine I'm conditionally forwarding users to the SCORM Engine player in mod/scorm/player.php, but I don't want to do this for TC packages. The problem is, even for TC packages, the $scorm->version reports as "4" (SCORM 1.2) in mod/player.php

Is $scorm->version intentionally misreporting itself as SCORM 1.2 to make mod/scorm integration easier, or this a bug (not saving version as TCAPI)?

(disregard) $scorm->version indeed has the value "scorm_12". How would I distinguish TCAPI packages from regular SCORM 1.2 packages?

Will we also see the integration of LRS functionality, or will we still need to use a 3rd party LRS?

Hi Steve, good to hear it's been useful - the code parses Tin can statements and stores score/completion status in the same way as SCORM 1.2 so in some ways it impersonates SCORM 1.2. I don't think the current code will end up in core the way it is currently designed but has been really useful as a prototype. I had some initial funding to look into Tin Can from a client but unfortunately they have gone in a different direction so I don't have any funding dedicated to Tin Can at this stage.

I think it would be better to make all Tin Can statments into Moodle generate a new event and then implement an LRS store as an event handler.

Paul - I'm not sure on the answer to that one at this stage, I think there are benefits to having a native Tin Can LRS but there are some very good arguments against it as well. It would be influenced a lot by any funding that was found to implement further support. We can also already use tin can in Moodle with an external LRS using Andrew's mod_tincanlaunch plugin. I do like the idea of supporting Tin Can directly within the SCORM plugin though as it simplifies the user interface a lot for teachers - they shouldn't really care if a zip file is a SCORM or Tin Can - it should just work.

Hi Dan, I am not sure if this is the right forum or too sensitive to share publicly but I am curious to know how much funding is needed to produce these sorts of plugins. There is obviously a demand for Tin can support in Moodle. How much should I be hitting the boss up for to help this project along?

Hi Shay - it's hard to give a real figure on it as it depends a lot on what you want Tin can to do for you that SCORM doesn't currently already do - it would depend on your internal requirements and how you were planning to use Tin Can. A lot of people I talk to are thinking about using it as a direct SCORM replacement so it's really hard to justify a business case for development. Drop me an e-mail if you want to discuss more details.

On this topic I'm talking with some folks not on this issue who are interested in adding this functionality to Moodle, and we're planning to knock up a small spec for Moodle as a LRS as well as a provider, then we'll know more about the size of the project. Moodle HQ is always up for funding on such things if anyone is interested.

thanks Martin - great to hear!

Hi all,
Good to see this discussion picking up again. I'm hoping to have some news on the launcher and Tin Can as a provider for quiz tracking possibly as early as next week so watch this space! There's been things going on under the surface that I'm very excited about!

On the topic of an LRS within Moodle, I don't think this is a good idea. It'd be a lot of work to do well and if done badly could actually harm Tin Can as a standard given the popularity of Moodle. There's also no advantage of putting an LRS inside Moodle. There's plenty of great commercial and open source LRS available to be used alongside Moodle. We wouldn't put an e-portfolio into Moodle - we'd just use Mahara.

If there is any funding for putting Tin Can into Moodle, I'd love to see some investment in reviewing and integrating the launcher (after my news mentioned above - there's no point looking at the current code) and then looking at Moodle as a data provider, tracking the various activities and resources.

Anybody looking for pricing for Tin Can work is welcome to mail me andrew.downes@leolearning.com with clear requirements and I'll see what I can do.

On merging the Tin Can launcher and SCORM package player, I can see the argument in theory, but in practice if you look at the settings of the two modules, there's very little overlap and combining the two could be much more confusing to the user. I think anybody uploading a SCORM package or pointing at a Tin Can activity will need to know what they're doing to some extent in order to use the modules anyway. Note that there's no need to have zip package with Tin Can - the content just sits somewhere on the internet.

Hi Dan

I've been using your branch, and it works fine. We deploy TinCan packages built with Articulate, and we're happy to have tracking available, especially on their iPad player.

One little bug we have: when the student just complete a course, the activity completion checkbox is not ticked. It's not a matter of cron, because it works fine with a SCORM 1.2 package of the same course.
What is weird is that the successful attempt is visible in the teacher's report. But the student has to log off and log in again to see the activity checked.
Do you have any idea of what could cause this problem ?

If you need more information, I'll be happy to help and provide a test case.

Thanks again for your priceless contributions

Thanks Cedric - good to hear it's been useful - just a shame I haven't got ongoing funding myself to work on this further.

I saw your posts on moodle.org which suggest you might have sorted this? - related to a cache?

Hi Dan. Well yes and no, I could narrow down the key elements but I did not fix it.

The issue is definitely related to the course completion cache. It is correctly updated when a SCORM 1.2 package is completed. When using a TinCan package, only the database is updated, but not the cache. As a result, the completion reports are correct, but the reader has to wait for the delay defined as COMPLETION_CACHE_EXPIRY before getting the checkbox ticked. Surprinsingly, this cache is not cleaned when running "Purge all caches" as an administrator (which I would also call a bug.).

My programming skills are a bit rusted, but my understanding is the only missing thing is an update of the completion cache used in completionlib.php when storing the activity completion.
This is very similar to the issue discussed here : https://moodle.org/mod/forum/discuss.php?d=255351

Hi all,
There will be a fuller announcement at some point, but just letting people watching this thread know that LEO (http://leolearning.com/ ) have released a major update to the Tin Can Launch plugin at https://moodle.org/plugins/view.php?plugin=mod_tincanlaunch . This is the plugin that allows you to launch Tin Can packages to be tracked in an external LRS. The update makes the plugin much more robust, adds additional features and includes language translations in 10 languages for the learner facing strings. I've updated the maturity from beta to 'release candidate' and would really appreciate any comments as GitHub issues: https://github.com/garemoko/moodle-mod_tincanlaunch/issues

I'd really like to move towards getting this launch plugin included in core.

LEO have also published a code sample (this is not a fully functional plugin) that may be of interest to anybody looking to add Tin Can tracking to a Moodle activity module such as the quiz: https://github.com/leo-platforms/moodle-quiz-tincan This is based around https://docs.moodle.org/dev/Tin_Can though it doesn't match exactly.

Let me know if you have questions. I'm expecting a fuller announcement on the LEO website at some point soon.

Andrew

It's exciting to see all of this work moving forward with TinCan. I'd like to thank everybody for their work. I wanted to say that I would prefer a well implemented LRS within Moodle. Andrew, I can see your point that if it was done poorly, it could harm TinCan, but if it was done well it could help Tin Can with a popular product fully supporting it. It would also help Moodle making it a more competitive LMS.

Hi Rick,
What do you see as the advatange of an LRS in Moodle vs an LRS installed alongisde Moodle?
I don't think we can say that just because Moodle requires an LRS alongside it that it doesn't support Tin Can. Has Moodle's lack of e portfolio features ever caused an issue in the past?

Dan,
I have been testing several LRS Systems, GrassBlade, Wax and ScormCloud, but None of These gives a satisfactory outcome. The results and data collection is hellishly hit and miss, and above all the reporting is not directly in Moodle itself.
I for one would favour LRS Integration into Moodle itself where this is at all possible.

Hi Paul!

There's no reason why we couldn't have reports in Moodle with an external LRS, for example my launch plugin gets data from the LRS to feed onto Moodle's completion tracking. We just need resources to build the reports. In fact that's one argument for not having an LRS in Moodle: time spent building the LRS could be better spent building reports.

I'm interested to hear more details about the issues you've been having with data collection. What kinds of problems have you been running into?

Andrew

Should be better to open a discussion in the Moodle Community about having an LRS in Moodle vs having integrated reports using an external LRS? E.g. here, https://moodle.org/mod/forum/view.php?id=8044, or in https://moodle.org/mod/forum/view.php?id=50. It would be nice to discuss about it outside the Tracker, where, usually, conclusions should be reported including anything related with the current implementation or the ongoing one.
If you agree, please post here the link to the discussion thread too.

TIA,
Matteo

Andrew,
Problem is two fold:
1) I'm using your plugin, but getting no results back.
2) Universities won't allow us, for Data Protection reasons, to use external resources such as GrassBlade, WAX or ScormCloud.
Re point (1) above, I have talked to Grass Blade and WAX, and they can't see why I don't get results back, but I can extplain the Situation off list if that's better.

Hi Paul,

On #1:Do you mind logging you issue with the plugin here: https://github.com/garemoko/moodle-mod_tincanlaunch/issues ? Please make sure you're using the latest version of the plugin and let me know the site level and instance level settings you're using (screenshots are ideal) plus give me a link to your content so I can test myself.

On #2: You could consider SCORM Engine as an internally hosted alternative to SCORM Cloud or self host Learning Locker. I'm not sure if grassblade and wax have similar products you can host yourself.

Matteo - thanks for suggesting the Moodle forums, but I don't find them practical as it's impossible to subscribe only to a thread and I simply don't see the relevant replies in amongst all the others. If people do want to post questions on the forum and then email me a link to those questions separately that might work?

I've been lurking on this issue with great interest. My organization is preparing for Tin Can and I'd like to share with you some reasons for an internal LRS in Moodle:

• Ease of installation: if the Moodle devs choose what LRS comes out-of-the-box with Moodle, then the organizations that use Moodle don't have to - unless they want to.
• Simpler security: for organizations not able/interested/permitted to share data about their learners' experiences, an external LRS is a security liability. If the LRS is internal to the LMS, security is simpler.

I understand developing an LRS is a huge undertaking. Would it be possible to integrate an existing open source LRS into Moodle?

Andrew,
GrassBlade can be purchased for a one off Price, Upgrades Need to be bought. Learning Locker, by their own admission is not the easiest to install nor maintain.

I agree with François. One stop shop. One Installation, one database and one set of records. Moodle with integrated LRS is the simplest, cleanest and easiest to administer.

Re #1, I'm on it and will get back to you very shortly. May even give you a Login to the site so you can play and see what's happening.

FYI: when https://moodle.org will be updated to 2.8 - i.e. shortly - you'll be able to subscribe on a per-discussion basis. Refs.: https://docs.moodle.org/28/en/Forum_settings#Subscribe_to_individual_forum_discussions, MDL-1626.

Before this goes cold, I would like to ask: what are the chances that we see a Moodle with an LRS incorporated into it? I truly feel this is by far the best solution for all of us who work in institutions where the use of outside services is not an option.
As mentioned above, learning locker is complicated and fussy to install, and GrassBlade is relies on the user purchasing it and then buying upgrades when ever a bug occurs.
Moodle plus built in LRS with its open source flexibility and adaptability is by far the best approach.

Paul - I think that will depend on someone with funding that has a need for recording experiences that occur external to Moodle or someone with a need for offline learning packages - Martin has been talking with someone (see comment above on 15 sep 14) that may facilitate this but I'm not aware of any updates since last sept. I think there's general acceptance from the core Moodle team that implementing an LRS would be useful and people could choose to use an external LRS instead of whatever gets built into Moodle core - but whoever funds the initial effort will obviously influence the initial features.

Dan, I took a look at Martin's comments, and I'll certainly ask here. Just as a guide, what sort of sums would one be looking at?

that would depend on the project size and requirements which would be influenced by the needs of the person with the funding - you're not going to get any sums out of me publicly here

Tin Can is quite a wide and varied spec - there are a number of areas that we could implement in Moodle and some that are already supported with the use of 3rd party plugins like the great work Andrew has been doing.

Dan,
As I said I'll ask here at the University, I know that the IT department are keen on developing Moodle plugins, and are working on a Corpus plugin for me.
They are also looking at Mobile learning, and perhaps some sort of development on Andrews plugin would be worth a look.
Let's keep this channel open.