The use of analytics has gained a relevant level of importance in current learning environments. Due to its life-cycle of observation, analysis and intervention, it is important to make learning analytics available to all the participants of a learning process. A Learning Management System (LMS) is a very suitable platform to present results in the form of visualizations, but the development of custom modules usually requires programming and administrative work. This paper presents a system architecture to embed learning analytics visualizations without having to develop a custom LMS module. Our approach is based on the modi cation of the LMS' web pages through a browser extension. The details of the implementation are presented, as well as issues that might arise and how to address them.
The life-cycle of a learning analytics process can be described in three stages:
observation, analysis and intervention [
A common approach taken to intervene is the provision of awareness by
displaying visualizations to the participants of the learning activity. Learners
are provided with self-awareness of their performance and comparisons with the
group performance. Meanwhile, instructors are provided with awareness of the
learners performance at individual and collective levels. Among the examples of
application of visualizations in learning contexts we can nd CAMera [
A Learning Management Systems (LMS) is a common channel of communication to all the participants of the course; this is a main reason to use them as the channel to display visualizations. The most common approach to achieve this is through the development of a custom module to be installed in the LMS. However, given that the LMS is commonly managed at an institutional level and it must support several courses, installing a customized module becomes a complicated procedure both technically and administratively.
In this paper, we propose an architecture to embed learning analytics visualizations and reports into a LMS without having to install modules in the LMS. This solution follows a client-server pattern and is based on a learning analytics service that provides the visualizations in combination with a web browser extension used by the participants of the course. Thus, we simplify the task of providing visualizations to participants of the course, valuable for the execution pilot studies or the evaluation of visualizations.
The rest of the article is structured as follows, Section 2 describes the architecture, its components and the communication among them. Section 3 explains an implementation based on this architecture. Finally, section 4 presents some points of discussion such as problems to address and future work regarding the architecture. 2
The architecture proposed involves two main components: a visualization that is dynamically generated by a learning analytics service and a web browser extension on the client side. Both components and the method to interconnect them are described as follows. 2.1
The analytics service is in charge of generating the visualizations that will be embedded in the LMS web page by the browser extension. The visualizations can be generated as a single image or as an independent web page depending on whether the visualization will be interactive.
A visualization might present di erent information to the same participant, depending on the context where the visualization is being shown. This requires the service to accept parameters that indicate the current context of the viewer. For instance, the visualization of a learner performance could be displayed to both instructor and learner, but the latter could be provided with a comparison of her performance and the performance of the whole class group. In other situations, such as a general dashboard, the learning analytics service provides information about the individual user only when the visualization is seen by a learner but not when seen by an instructor. 2.2
The browser extension includes a special type of script known as a content script, which consists of a JavaScript code executed in the context of a page whose URL matches a given pattern. It must be noted that the URL pattern does not accept a query string; thus, the veri cation of the query string must be done within the logic of the content script.
In the architecture, there are two sites where the content script must be run: the course home page and the course participant list. The content script modi es the home page and the page that lists the course members. The structure and design of the elements that are included into these pages follow the style of the complete LMS in order to maintain it consistent.
The modi cation on the course home page consists of the inclusion of an element commonly known as widget, module or portlet. This element is shown to every participant of the course, be it a learner or an instructor. The content presented is a visualization obtained from the analytics service which will be personalized for each viewer. Because of this personalization, the content script must obtain a user identi er within the content of the page, and usually available at explicit links referring to the user pro le or session status.
In the list of participants the content script adds a visualization element next to each learner's portrait or full name. In order to maintain the privacy of the learners' academic information, the list of participants should be modi ed only if the viewer is an instructor. Thus, the content script needs to be aware of the role that the viewer plays within the course which can be achieved through mechanisms like analyzing the options available on the web page or fetching the content of the viewer's pro le and analyzing the user description. As in the home page modi cation, the user identi er for each learner can be obtained from a link pointing to her user pro le in the LMS. 2.3
Visualizations must be available for the browser extension to embed them into the web page of the LMS when seen by a course participant. This is usually achieved by o ering the visualizations through a web server and requiring authentication in order to respect the privacy of the learner data.
The communication process follows a client-server architecture, where the browser extension plays the role of the client and the visualization service is the server. The extension initiates the communication process by requesting the appropriate visualization given the current context in the LMS, which includes the web page and the user's current pro le. The request includes information about the identity of the user and current context.
The proposed architecture and the exchange of information among its components are represented in Fig. 1.
In our scenario, the LMS where the visualizations are embedded is Moodle and
the course participants use Google Chrome and Mozzilla Firefox as their web
browsers. The visualization service is provided by LearnGLASS [
Regarding the browser extensions, we have used Kango Extensions [
Although the web page that generates the visualization does not require a session, it does require an authentication token as a parameter. The token is generated by a hash function of the user identi er, the current timestamp and a password known by both client and server. Fig. 2 presents a screen capture of the home page of a Moodle course as seen by a student; the red selection shows the visualization that has been inserted. 4
Using a decentralized architecture also implies the appearance of problems that need to be addressed such as a fragmentation of client software, dependency on structure, account association and security.
User identity issues include the uni cation of user accounts in the two
systems, the LMS and the visualization service. These problems are explained with
more detail in [
A second possible issue to take into account is that by using a client-server architecture, users might have di erent versions of the client. This problem is approached in our implementation through the provision of an update URL. This URL is accessed by the web browser to check whether there is a new version of the extension and, when this is the case, the user has the option to upgrade.
By modifying the structure of the LMS' web pages, the correct behaviour of the presented architecture depends on keeping the same structure and visual design of the web pages. This issue is addressed through a constant monitoring of the LMS look-and-feel and the appropriate modi cation of the extension to adapt to change. Another mechanism to consider is the development of an alert system in the extension that informs the visualization service about any mismatch in the structure of the page.
One of the main disadvantages of the development of a client application with JavaScript is the availability and openness of its source code. Thus, the development of an authentication protocol that is password-protected becomes di cult. A possible way to overcome this problem is through the implementation of the OAuth protocol to allow the browser extension to fetch information from the visualization service. This option presents the disadvantage of requiring an initial intervention by the user.
Regarding the proposed future work, we are currently working on the deployment of a learning analytics scenario that is supported by the presented architecture. This deployment has many objectives: evaluate its viability, analyze the reaction of users to the presentation of analytics, and analyze whether the e ects of embedded visualizations in the LMS during the learning process of the participants.
Finally, another line of technical work is the generalization of the browser extension. Currently, the extension is dependant on the structure of the pages in the LMS and on the visualization service speci cation. By abstracting both of these characteristics, we would improve the modularity and re-usability of the extension.
Work partially funded by the EEE project, \Plan Nacional de I+D+I TIN201128308-C03-01" and the \Emadrid: Investigacion y desarrollo de tecnolog as para el e-learning en la Comunidad de Madrid" project (S2009/TIC-1650).