Ciclovía calle Ulloa

The dashboard is instantiated once for each client –the browser of the user that connects to the platform for accessing the GVIS generated widgets– when the service is started. The actions and flow of information connected with the Builder invocation is presented in Fig. 3.8, where the check settings function verifies the configuration and creates all the instances of the Aggregator needed for the correct execution of the module Builder. The module provides two types of functionalities. It is a container for all the widgets and it collects all the user interactions and feedbacks, such as data filtering or widget visibility change. As a container, it provides a common place for the different widgets, each of which is specialised to represent a specific aspect; on the other side, by managing the interactions with the user, it acts as a sort of control panel of the learner situation. The interaction functionality is important because this is the only level at which the final user can express preferences or partially change the behavior of the

Figure 3.8: Actions involved in the Building execution step.

whole system. This is particularly relevant for the learner category, that can use this capability to better target the amount of information received. This approach allows the learner to fulfill its specific needs in term of richness of the personal feedback channel.

The active widgets are dynamically created at the top of the dashboard: every widget, based on a graphical template – mainly defined by the builder classes and specialised through the XML configuration – that defines its main aspects, represents an encoding of a single indicator (i.e. a piece information that can be relevant for the user activity) for each of the characteristics (one or more) of the learner profile. Each characteristic follows the presented path, from extraction to aggregation to being ready and usable for encoding into an indicator. This way, these widgets are the final outputs of the application.

3.1 The Infrastructure

3.1.7

Adaptivity

In the current implementation, the two upper layers (aggregator and builder) can be enhanced with adaptive features. As already mentioned, after the extractor layer has retrieved raw data from the sources the aggregator takes charge of merging and filtering the data in order to extract more refined information. This aggregation is based on the model that the instructional designer wants to provide to the learners and reflects the didactic approach adopted in the course.

With such an architecture, the support to the learning process based on adaptive profile externalisation can be achieved by adapting the visualisation to the specific didactic model.

The adaptivity is modeled in the configuration files for the two levels (aggregator and builder) through a simple XML. Its XML schema supports the conditional construct ”IF ... THEN ... ELSE ... ” which allows the GVIS visualisation to produce a different behavior with different properties. Furthermore, the schema allows each branch to be a leaf or another conditional, supporting in this way even a multilevel logic. The next example shows the usage of two levels. The properties can be any combination of source data values, on which a set of mathematical and logical operators can be applied. For instance, it can be decided that a particular widget may show a comparison of the level of knowledge of a student among the class only if his current knowledge level is greater than a threshold value; or we may want to show a particular widget only to the course instructor and not to the learners. This is implemented by including conditional instructions in the XML configuration files of the aggregator and the builder. The configuration files may contain variables, logical and arithmetical operators i.e. we have implemented the common comparison operators (more than, less than, equal and different) and the logical operators AND, OR, XOR (exclusive or), NOT (!).

The following example shows a possible condition: <cond>

<op>(v1 AND ((A &gt; 3) OR !(z)))</op> // FIRST LEVEL CONDITION <operands> <val id="v1">CourseX.Concepts.list</val> <val id="z">CourseX.Student.count</val> <val id="A">CourseX.ConceptA.mean.knowledge</val> </operands> <true>...</true> <false>

<op>(h &lt; t)</op> // SECOND LEVEL CONDITION <operands>

<val id="t">CourseX.ConceptA.mean.knowledge</val> <val id="h">CourseX.ConceptA.userH.knowledge</val> </operands> <true>...</true> <false>...</false> </false> </cond>

In the code above there are two conditions, and their interpretation is the following: COND1 => If the list of concepts in course X is not empty and either the average knowledge of concept A is greater than 3 or there are no students subscribed to the course, then display a particular widget, otherwise check another condition.

The second condition is related to the knowledge level of the current learner, implemented in the false branch of the first one, and states the following:

COND2 => If the knowledge level of the current learner is lower compared to the average level for course X, ...

The construct shown allows for the creation of conditions of varying complexity and can therefore be used to specify a number of different behaviors at the level of granularity required. In the conditional expression any variable that was associated in the extractor with an input of the user model can be used, as well as variables that represent user preferences and user device configurations, if available and retrieved by the extractor layer.

As a case study, the GVIS software was fed data from different LMSes used in a controlled experiment, to support a distance learning course.

The following examples show possible configurations enhanced through adaptive segments. The adaptive behavior can be achieved by the aggregator and the builder, and is driven by course data (i.e. data not directly related to a single user, such as the number of concepts in a course) and/or user data (i.e. data about the learner e.g. the activities performed, the knowledge acquired or preferences expressed). All this data is either collected by the extractor or it can be explicitly declared by the learner through his/her preferences and personal settings which are stored in the DB of the educational platform.

The first example, based on user data (see Fig. 3.9), adapts at the aggregation level. It presents the knowledge achieved by a student over the concepts of the course.

In Fig. 3.9 on the left is a compact view, where the average knowledge level of the learner (first column) over the concepts of the course is compared to the average knowledge level of the class (second column).

3.1 The Infrastructure

Figure 3.9: Example of the produced widgets: different aggregation level of the same data.

Figure 3.10: Example of the produced widgets: different graphical representation of the same base data, aggregated in different ways.

The right side of Fig. 3.9, on the other end, presents detailed information for each concept of the course (namely, Star, Planet, Sun, and Earth; each concept is followed by the [it] suffix to indicate that the content provided was adapted to the user’s preferred language i.e. Italian). The choice around which of these two widgets should be presented to the user is made by the GVIS engine on the basis of the number of concepts to display: if the number of concepts is too large to be represented in the detailed visualisation, GVIS will present the aggregated view. It is important to notice that GVIS will only present data related to the concepts visited by the learner. This means that the adaptation rule can change the presented object automatically as the learner subsequently visits more concepts of the course. The threshold based on which one of the two alternative visualisations is chosen can be either a constant value in the XML configuration file or a value that is calculated on the basis of one or more characteristics of the class or activities done on the LMS, or even based on the device type currently used by the learner.

Another visualisation we developed, presented in Fig. 3.10, adapts the type of graph to the user preferences and to the number of concepts, in order to optimize the readability of the widget. It shows the information in two different formats: on the left hand side, a bar chart represents the knowledge levels of a learner over the concepts of the course, comparing

Figure 3.11: Example of the produced widgets: graphical versus textual representation.

these values with the expected knowledge level. On the right hand side, a pie chart offers a representation of the knowledge for every concept along with their relative weight in the total knowledge achieved on the course.

The next example, based on course data, is presented in Fig. 3.11 with an adaptation condition included at builder layer. This means that the data represented – like in the previous cases – is exactly the same, but here the encoding changes: in this case the adaptation is driven by either the type of hardware used by the learner or by the connection speed. A textual list is well suited for mobile phone devices or hand-held based platform, while a graphical widget (on the left) is more suitable for larger displays and broadband access.

Figure 3.12: Examples of the produced widgets: differential versus absolute representation.

As previously stated, providing a way to open the profile to user inspection is important in the domain of Life Long Learning: the presentation of information about user activities and status as an indicator of the learning process is widely accepted as one of the key points to improve participation and increase the participants’ satisfaction (Shneiderman and Plaisant 2004) and (Shneiderman and Plaisant 2005).