From Bodington Wiki

Jump to: navigation, search

Back to TReCX



This page represents the distillation of generic use cases that we intend to pursue. The links below refer to pages which contain the data from which these are derived and also use cases which were previously up for consideration, but are now regarded as out of scope.


There are two main actors in the tracking scenario:

  • tracker: the user who makes use of a reporting tool.
  • trackee: any user who is tracked. They are clearly an (indirect) actor in such a scenario, as they are only actors in this scenario as a result of being a direct participant in one or more instance of an e-Learning tool. (In practice it may be necessary for them to have consented to be tracked, as is the case with companies in the UK who will track people via their mobile phone - see here).

The following should capture the distinction between tracking and reporting.

  • tracking: is achieved through event capture which is the recording of events as they occur.
  • reporting: makes use of tracking information to a tracker. The following lists some typical examples of this:

  1. client application: a web-application could allow for the reporting of tracking information on the basis of time period, user(s), learning resource(s), etc. This represents a pull use of the technology where the timing of information delivery and locus of control is entirely within the hands of the person using the tool.
  2. notifications / alerts: a tracker can subscribe to a service delivered through mechanisms such as e-mail or RSS. The initial subscription will capture certain filtering criteria for the reports such as time period, user(s), learning resource(s), etc. This represents a push use of the technology; the timing of delivery is on the basis of events as they occur (although in practice the delivery itself may be batched to occur at pre-arranged intervals or be subject to when the notification service actually queries the tracking data provider).

Put another way, tracking / event capture represents the fundamental requirement, without which nothing else is possible. It is fine-grained and does not attempt to do anything clever based on whether other events have or have not occured. Reporting represents what you do with this information afterwards. This will definitely include filtering what tracking data gets reported against the basis of certain criteria and possibly perform operations such as consolidation of the information, e.g. just say that user 'X' visited a forum 5 times on Tuesday rather than report user 'X' visited a forum on Tuesday, five times(!).

The scope of what could realistically be reported on by a single instance of the reporting tool, would probably be limited to applications protected by the same single sign-on system.

Use cases to be captured by the system

'Tutor reviews the use of an e-Learning system by an individual tutee'

A tutor sets a sequence of learning activities for a student; they should read an online document, discuss it in a forum and then test their knowledge on it in a quiz. The tutor can view if and how much time they spent in each activity. The tutor is able to see all this from a central location rather than having to view each tool individually.

'Tutor reviews the use of an e-Learning system by a group of tutees'

As the above, but repeated for a group of individuals.

'Tutor reviews usage of e-Learning resource(s)'

A tutor uploads a number of documents for her students to read for a particular course. After a few weeks she decides to review the number of times the documents were accessed. She sees that certain documents were accessed far more frequently than others. In line with analysing document content she is able to obtain a clearer picture of the kinds of documents students like so that she can (if necessary) adjust the content she uses for the following time the course is run.

'Correlating resource usage against performance indicators'

After a course has run, a tutor wishes to correlate resource usage against performance indicators. The course specified that students should engage with a number of e-Learning resources, some of which may or may not have mandatory. By analyzing the reporting data the tutor is able to see that strong scores in a formative assessment correlated highly to engagement with particular e-Learning resources. Subsequently the tutor decides to either make these elements mandatory or to focus his attention on ensuring that students engage with these parts of the course.

We will collect the data to enable this to be done in a system such as Excel, but will not perform the processing as part of Trecx.

'User of an e-Learning system views their personal history'

A user would like to navigate around an e-Learning system using their own personal history (a reflexive case of where the trackee would become the tracker!). They may remember a resource they used earlier, being of interest to them, but can not remember where it physically (or virtually!) was. By using a history of where they have been they can return to this previously visited resource (It is true that most web browsers have a history function, but as this history would be captured by the system it would work even when the users had changed clients).

Possibly out of scope, but it will never have any of the resource access issues associated with other use cases!

'User can view their favourites'

An individual makes use of a VLE over a period of time. At some point they decide they wish to "bookmark" the resources that they actually use the most (either in their web-browser or some web-based bookmarking site). By querying a web-based application that makes use of tracking data provided by TReCX, they are able to be presented with the resources that they actually use the most.

Possibly out of scope, but it will never have any of the resource access issues associated with other use cases!

Derivation of use cases

These have been gathered from the following sources:

  • Bodington development team (Leeds, UHI, Oxford, and Phosphorix)
  • Members of the JISCMAIL VLE's list (have a look at JISC VLElist)
  • Members of Oxford University Computing Services
  • Weblearn (Bodington) users at Oxford

Back to TReCX