JEDIUM EDUCATION

MODERN TRENDS IN E-LEARNING

The need for high-quality online training is constantly increasing, and, apparently, that is a long-term trend. Many big companies (e.g. Microsoft, Google) already foresee the future education as remote training only, and technological trends make lifelong learning is almost a necessity. However, a situation with the means of support of online learning is far from ideal.

MAIN AREAS

Historically, the development of e-learning happened in two areas:

The most famous and widely used is TRAINING. There is a number of specific standards and standard applications that—for a long time—covered all organization’s necessary requirements for training. First of all, these are the standards AICC/SCORM, and based on them Learning Management Systems (LMS); LMS Moodle is a classic example. Usually, such product is a website where students can take courses (in the format of presentations/documents/video), take tests, and communicate; it offers a variety of opportunities to manage the learning process.

The second is LEARNING, arising from a series of learning environments at various universities. There were no uniform standards, but constructivist, connectionist approaches and, partially, social learning have been applied. Knowledge Forum is one of the early versions of the e-environment to support project/constructivist/connectionist learning.

CURRENT SITUATION

However, all those variants excluded real-time interactions just because the technology was not good enough. With the advent of various means of real-time communication, new products (e.g. webinars) emerged. The question how to integrate real-time communication and chats within the same framework was still not settled. One of the existing paradigms is BLENDED LEARNING.

PROBLEMS

The question about the combination of social constructivist learning was even more difficult. To date, there is no a product that covers such implementation (the impact of mentoring/hidden knowledge of individual learning trajectory).

In addition, variants of simulations and serious games were not integrated into the learning process. This was partly due to the fact that there was no any standard for a statistical recording of actions in a simulation. xAPI standard appeared relatively recently.

CHARACTERISTICS OF A LEARNING ENVIRONMENT

Such environment should:

  • Be network-centric that is based on the concept of social networking;
  • Support all modern forms of communication in real time;
  • Include all the tools to work with courses of modern LMS;
  • Support options for a dynamic/adaptive course and individual learning trajectory.

However, that is just a traditional part of the learning environment upgraded to the modern version of the traditional concept of the portal such as Moodle. We believe that the second part of the learning environment should be a virtual environment.


In terms of a successful integration between virtual and learning environments, what characteristics VR should have?

OUR VISION

Firstly, it must be a multi-user experience. Many companies have created single-user virtual learning environments. Although such realization provides more benefits compared to a classic presentation or a video with a set of tests, the conceptual difference is not so big. In our case, that is not appropriate, since—at the early beginning—we chose the social interaction as one of the key concepts of our system.

Secondly, it should be easily integrated with all other aspects of the system at various levels. In addition to obvious integrations with social networks (login, status, instant messaging etc.), theoretically, any piece of content in the system should have a virtual representation. For example, if we have a common presentation, we should be able to display it in the virtual reality; if someone started the live video, we have an opportunity to see it; if someone is being presented in the learning environment in the mode of a regular webinar (voice communication + video + whiteboard), all of that we need to see in the virtual reality. Furthermore, interaction with various objects in the virtual course should be visible on the social network.

Third, the virtual environment must be dynamic. Students and teachers should have an ability to create virtual reality content and make it interactive: write their own program, responsible for the behavior of the object in VR.

Until relatively recently, the implementation of such virtual environment has been associated with a number of difficulties.

HISTORY OF THE VIRTUAL ENVIRONMENT

The development of virtual environments proceeded in the same way as the development of the World Wide Web (WWW) The first sufficient common embodiments of such environments (e.g. World of Warcraft) were client-server systems where the server was used to synchronize client actions in a virtual world and trigger a variety of scenarios. That involved the implementation of a network protocol and other elements of the client-server system. The difference with Web 1.0 was in the process of delivering content: the content was downloaded when the user had been installed the client program. The similarity was that the content was created by the authors of the system, the user role was only in an interaction with the content.

In place of the Web 1.0 came Web 2.0. The main difference was that the content was created by users. That required a number of new technologies (it is worth mentioning scripting on the client side). From the perspective of training, the major change was that Web 2.0 allowed using several techniques (like social learning) online.

Virtual environments followed the trend in some degree. Universal Transfer Protocol of 3D content—similar to the WWW—did not exist (as it does not exist now; although VRML claimed that role). The important thing was that a separation of protocols on transport and representation began appearing in some systems. Without that separation, users were not able to create VR content.

Second Life

One of the well-known virtual environments implementing that approach is the virtual world of Second Life. It was originally designed as a "Web 2.0" for virtual worlds, enabled users to create new content, and program (create firmware scripts) on the server side. That is why they were multi-user by definition. The results of work of such program were the same for all users in VR. At the same time, from developer’s point of view, the program itself was written as a regular single-player.

Second Life was the revolutionary project for its time but had a number of shortcomings that were partially a consequence of the chosen architecture:

  • Resource intensive scheme of delivery of the content. Second Life used a "web-scheme", in which all content was stored on the server side, and was downloaded by the user when user’s avatar appeared in a certain segment of the virtual environment. Although it gave a very great flexibility in the means available to the user, it imposed serious restrictions on the Internet channel: what worked well for the hypertext and simple images worked much worse on "heavy" 3D content.

  • Limitations of the scripting language. LSL language was designed specifically for Second Life, and provided a lot of opportunities for the manipulation of 3D objects, the world. However, it was not suited to write any complex systems. Suffice it to note that LSL is not an object-oriented language and does not support modularity in any form.

  • Complex scaling. A standard element of the space ("region," as a Second Life term) has been severely restricted by the number of objects, and most importantly by the number of simultaneously being in VR users. Moreover, that limit was low: no more than 40 members in the same region. Apparently, that was due to architectural decisions that were taken when developers wrote back-end.

However, Second Life has established a number of concepts, which, in our opinion, deserve development.

First of all, the concept of custom scripting (writing software). If you develop it, you can come to the conclusion that the object in virtual reality—with an embedded program—can be compared with an ordinary program in a modern operating system:

  • It is independent of other programs (but can interact with them);

  • It may have a specific interface (in our case, that is a 3D environment and elements of the user interface on the client side);

  • It must be based on a standard API, a set of basic features offered by the system. At the same time, from developer’s point of view, it is a conventional "single-user" program without anything related to networking.

Features of our implementation of a dynamic virtual environment

We call such object "ENTITY". A virtual environment created with Jedium Platform is a set of entities. As a scripting language, we use full C#/.NET. That provides all features of the language, as well as the necessary modularity.

Another problem is the scalability. On the Jedium Platform, any entity on the server side is implemented as an Akka.NET agent. Akka.NET is an agent-oriented programming environment allowing developers to scale entity with no restrictions.

Also, we chose a hybrid method of content delivery. While being used, the content is downloaded (similar to Second Life), but some content can be delivered one-time (similar to World of Warcraft). That is quite justified approach for use in training because the initial content of the course is possible to be determined at the stage of its creation, and the ability to work with user-generated content provides everything you need for modifications alongside the learning process is continuing. In that case, the load on the Internet channel depends on the amount of changes.

It should also be noted that, unlike others, we initially focused on the application for training existing implementations of dynamic virtual environments. Second Life was also used (and it is still used) for training, but that raises a number of specific problems related to integrations with other means and systems of training and organization of the working process.

We originally designed Jedium Platform with embedded all necessary properties mentioned above. For example:

  • Separated the development process of complex scenarios—that include interactions between entities—from the development of entities per se. We made the development of scenarios flexible without requirements to have skills in programming;

  • We provided a number of tools for the analysis of the learning process and and made the platform ready for implementations of new paradigms like constructivism and connectionism. For us, the social component of the training is one of the key elements, and it was implemented within multi-user VR experiences.

OUR SOLUTION

We have created Jedium Platform that allows representations of any entity in the form of an Akka.NET. agent.

Our solution combines simultaneous work of the people:

  • In virtual reality;

  • At screens of conventional monitors (a third-person view; like in games);

  • From mobile devices.

Based on platform, we developed industry-specific solutions:

Need more information or a demo?

Want useful & interesting updates?