Requirements and Design

Data about user activities and status is stored in the form of logs and tracking data inside the LMS to provide a first elementary user profile and activity report (regardless of whether other systems already memorised it in the learner model, at a higher level of aggregation and abstraction). The user profile is then created on the basis of their activities and interactions in the learning environment. Although many Learning Management Systems already provide the possibility to explore this user tracking data, in many cases the visual presentation of the information is not well suited to the users’ specific needs. The exposed data is generally

3.1 The Infrastructure

provided as a simple list of user activities – or access to course contents – without the possibility to explore it from an aggregated didactic point of view. For this reason, adding a didactic oriented view requires an effort that normally requires interactions between different skills, to cope the objectives of the activities with the technical way of implementing it and interpreting its logs. This means that the didactic interpretation of the logs, i.e. the meaning to be given to this data in the educational experience, has to be added by the ID/teacher (in cooperation with the technicians) each and every time. In case where the learning experience was developed in a team oriented flavor (teacher, Instructional Designer, tutor, technician are different persons) this effort can become demanding if multiple refinement recursions are required to reach the expected results and carries the risk of generating inconsistencies in successive improvement iterations. In fact, this events exploration feature was originally thought for technicians in charge of solving technical issues, rather than for instructors or tutors interested in improving pedagogical aspects.

In other works, the presentation of the data is either limited to a data subset or predefined by developers and therefore fixed (Mazza and Milani 2004), (Mazza and Milani 2005), and (Mazzola, Eynard, and Mazza 2010). Notable exceptions in the field of OLM are OLMlets (Bull, Gardner, Ahmad, Ting, and Clarke 2009), in which the learner can choose autonomously between seven different representations. Nevertheless they still rely on data coming from a single system, normally the one on top of which they were developed.

GVIS provides an easy way to create effective graphical presentations of arbitrary data from different and heterogeneous sources through the three-tier architecture consisting of a data extractor, a data aggregator and a builder, as shown in Fig. 3.1.

All these levels rely on a configuration file that the instructional designer can amend or expand to add graphical indicators (in the form of widgets) of one or more interesting charac- teristics of the user profile. The infrastructure can connect to any data source with different connection types (e.g. databases, Web services, connection bus) simply through the creation of a small adapter. The output produced by the tool, as seen by a final user, is a flash based interface that represents, using one of the available graphical metaphors, the information that is considered relevant for the user itself aggregated according to a didactic model, which is the interpretation of elementary actions such as opening a web-page, posting on as forum or answering a quiz.

In order to achieve this result, it relies on a highly configurable infrastructure based on layers, each one implementing a level in the model: extraction, aggregation and widget creation.

Figure 3.2: The GVIS requirements for the general user.

Figure 3.3: The GVIS requirements for the server-related part.

Furthermore, this schema follows a common data processing pattern: retrieve raw data, extract or derive, and present it in the most suitable way (Mazzola and Mazza 2009a), (Mazzola and Mazza 2009b). This approach allows the tool to create a sort of educational mash-up1.

1_{It is called mash-up the software or service that relies mainly on different and not naturally interconnected}

sources for providing a higher value service, based on the integration and enrichments of the single data source adopted; i.e. the fusion of awareness data with representational facility (map), such as in the case of data

3.1 The Infrastructure

Figure 3.4: The GVIS requirements for the browser-related part.

The requirements are presented in the UML schema included in this section. Fig. 3.2 shows the basics functionalities: the end user can perform three operations (select and view chart, move chart in the dashboard, and hide chart ), whereas an admin user can work with the configuration, defining rules for the three levels of the tool. Figure 3.3 presents the operational view, as seen by the core system, offering the capability for request extractions, aggregations and chart creation based on requests received from an end user. On the other side, Fig. 3.4 offers a view of the dashboard one, which provides a list of all the available widgets and allows to change their visibility status in order to support the final user interactions.

Finally, Fig. 3.5 represents the logical flow of information for the widget generation phase. It begins with a request (formulated by the user in the dashboard interface and encoded in an AJAX1_{) request that is intercepted by the core-system to invoke the relevant Builder. The}

Builder object then takes the control and checks the configuration which, if successfully vali- dated, invokes the set of Aggregators required one at a time. Each individual Aggregator re- quests the set of Extractors it requires. Eventually the data is turned into information through composition and computation and is returned to the builder that, in the final step, maps it to the chart and returns the newly created object to the dashboard.

regarding current locations of a list of friends provided in textual way, enriched by its representation on a map with distance (Km) and time required to reach them by car given the current state of the traffic in the area

1_{The acronym AJAX stands for Asynchronous JavaScript And XML and is a de-facto standard for the}

request of a segment of information to be inserted in a answer or in a segment of a web-page once the page is already loaded in the client browser. It works through the capabilities of the JavaScript implementation in the browser to react to asynchronous events and to manipulate the Data Object Model (DOM) of the document rendered and the method HttpRequest for requesting an informative element through the normal http connection.

Figure 3.5: Data flow in the widget generation.