From Bodington Wiki
TReCX stands for Tracking and Reporting in e-Learning Contexts.
It is an open source toolkit that will help with the tracking of learners across distributed e-learning systems. The toolkit allows tracking data to be generated or collected from a variety of e-learning applications and then presented back as a coherent whole so that the actions of a learner can be followed across application boundaries.
Tracking the actions of learners through e-learning tools is important in many situations. If a system is not recording the actions of the users then it is not possible to tell what activities are being undertaken or which resources are being using.
Providing services to learners through a set of distinct applications and tools is already happening. It is now the case that as well as using a VLE, tools such as external discussion forums, assessment engines, blogs and wikis can become part of a loose collection of tools used to deliver a course. Although this allows institutions to pick the applications that best suits their needs, often these applications either each maintain their own store of information about the progress of users through the system, or do not store this information at all. This makes tracking the overall progress of students at any point in time difficult as the information is distributed though separate systems.
Here we present a toolkit that allows the easy addition of tracking to existing tools which can then be collated and reported upon via a central service.
The technology presented here is usable by other systems that integrate service-based tools in a similar fashion to that described above.
At the most abstract level TReCX is:
- an XML schema defining the format of an events.
- a REST-ian "publish" interface.
- a REST-ian "reporting" interface.
To assist real-world applications in realising the above, the toolkit consists of the following:
- a stand alone web-based tracking event store ('Tracking Application' on the diagram below) that can be used by e-learning applications to store the actions of learners. This implements both the publish and reporting interfaces from above.
- a "publish" library written in Java to enable an existing application to push events to a tracking store.
- a "reporting" library written in Java to faciliate the creation of reporting applications that can interrogate one or more tracking store instances.
With reference to the diagram below, imagine the following scenario.
- 'E-learning application A' is a VLE, for example, Bodington or Moodle. Each of these VLEs implement their own tracking store detailing what a learner has been doing in the system. These implement the REST-ian "reporting" interface which means that they can be queried by a reporting application.
- 'E-learning application B' is a discussion forum, for example, JForum or phpBB. For the sake of argument, let us assume neither of these applications store tracking data. These applications have been modified to publish events to the TReCX standalone tracking store. Most likely this would be done by modifying the source code directly. Another possibility with a Java application would be to use AOP (aspect-oriented programming). Events of interest could be intercepted via suitably defined pointcuts and joinpoints and then pushed to a tracking store by using the provided publish library.
- The 'tracking application' is the web-based TReCX Tracking Store. Clearly this also implements the REST-ian reporting interface. The store is persisting data sent to it via its implementation of the REST-ian publish interface from e-learning application B (plus any other applications which are also in the 'federation').
- The 'reporting application' will be a system that uses the TReCX "reporting" library to search the various tracking stores in the 'federation'. The reporting application may then transform the events returned by the search into, say, HTML or iCAL format data and then display in a browser or calendar.
- Toolkit (overview, downloads, using the toolkit, developing the toolkit , etc.)
- Project (documentation created during the early stages of development of the toolkit)