Future development plans for Koala LMS
The first version of Koala LMS wanted to set basic bricks and show our ambition: collaboration through educational, , and . We want to go further, and we scheduled several major projects.
Our goal is to design solutions to enhance student collaboration, to integrate them into the educative process led by the teachers.
Table of contents
Create a federation of educational resources
Known and identified resources
Koala LMS is not intended to be a monolithic whole that functions as a data silo. We want to be the opposite of current centralisation practices on the Web.
Koala LMS must adopt a decentralised paradigm. Below, a naive example of decentralisation as we envision it.
The process of accessing educational resources is then modified with respect to the centralised basic operation:
- The client located in A University sends a request to the Koala LMS platform on which it is connected.
- Koala LMS searches its database for educational resources matching the query.
- Koala LMS searches in its cache for other educational resources that match the query.
- Educational resources are usually provided with additional files. They are stored on the filesystem.
- University A has found a resource corresponding to the client’s need, located in another instance, Secondary School 2.
- The client A instance sends a request to this other instance to get the requested resource.
- The instance of Secondary School 2 searches in its database for the requested resource.
- The instance of Secondary School 2 retrieves the files attached to the Learning Resources.
Finally, the University instance retrieves the data from Secondary School 2 and stores it in its cache until the expiry as defined by Secondary School 2 .
The previous proposition poses a strong dependence constraint between all instances. This means that to retrieve a learning resource from a Koala LMS instance IB, the IA instance that originated the query must know IB. This is not possible in a context like ours where instances can be installed and removed.
We propose a solution based on a central index replicated on each running instance. This index stores attributes of educational resources (name, keywords, etc.) useful for the search and the URL to access them.
Here, each instance comes with an index. It is synchronised with one or more reference indexes that are addressed in the domain name system, for example
index2.koala-lms.org, and so on.
Adding a new instance
When adding a new instance in the federation, the operation might be:
- The new index connects to the reference indexes to report its existence.
- Reference indexes give instructions on how to synchronise in the future (frequency of synchronisations, etc.)
- The new index synchronises with the reference index (it might be useful to spread this synchronisation load with other existing indexes already up to date).
- The index updates (new instructions and data) according to the guidelines given by the reference indexes.
Now, what to do when a user from the University A instance of the previous schema runs a query to get an unknown resource?
- The Koala LMS instance on which the user is logged in queries his local index for a learning resource that matches his needs.
- After identifying the URL of the Learning Resource, it can apply the same method as described in Known and identified resources.
Communication between users
User discussions about learning resources are processed and stored by the instance that hosts the resource. The ActivityPub protocol can partially answer this problem. The XMPP protocol is also a valuable solution in this context.
Recommend adapted teaching resources
Koala LMS is a utility for recommending educational resources. We want to be able to identify the best moments for learning in the learner’s path and offer him/her appropriate resources.
The analysis of digital traces of learning makes it possible to understand users’ habits, their level of progress in the courses to offer them adapted teaching resources.
A simple use case is that of the course recommendation which comes to supplement the knowledge already acquired, or to fill in the gaps identified by the tests carried out. De facto, the proposed educational resources are specific to the student. It is through his interaction with the tool that he receives adapted recommendations. The recommendation comes from his profile and traces left during learning.
Two types of recommendations exist: teaching resource recommendations within courses and course recommendations. If a student begins a learning process with a thematic course, the assessment results may indicate that there are gaps in some areas. The referral system offers courses and content to solve these difficulties. The recommendations are made to the teachers when they build a new course: public educational resources are indexed and can be reused to build new courses.
To make learning more effective, students must be available. This means that they are able to acquire new knowledge. One of the goals of Koala LMS is to identify student availability. It is according to the actions of the user at a given moment that the resources are proposed to him. The ambient sensors on mobile devices can be used to determine contexts and propose appropriate resources.
For the user A, at the moment TA identified as suitable for learning, Koala LMS identifies the context, it tells us of A is in a transport. The resource RA is offered for learning. In this context RA is an interactive game that can be played quickly and with one hand.
For user B, at time TB, the context tells us that B trains for running. The resource RB is proposed. It’s a radio show so he can listen to it without any interaction with the device.