Keywords

Motivation and Research Methodology

The primary role of any teacher, is to stimulate learning activities that will gradually result in the attainment of certain learning outcomes (Koper and Bennett 2008). As a consequence, the design of learning activities—in short learning design—has always been of a particular interest to the educational domain. The work of iTEC is no exception, and in this chapter we consider both the progress made by the project in furthering the state of the art in learning design, and the way in which learning design activities can be conducted within the infrastructure created by the project.

Attempts to provide computer-based support for this process have had some success, but have not been widely adopted by teachers. A number of projects have developed learning design authoring software that aims to simplify the design process, and the work described here can be situated in that context. An overview of related work is provided by Derntl et al. (2011), while Neumann and Oberhuemer (2009) describe a graphical user interface for designing learning activities based on IMS Learning Design. Evaluation of the latter revealed the disconnection between the design tool and the run-time system as one major problem with respect to user acceptance. To date tools supporting educational modelling languages have not reached wide adoption (see Derntl et al. 2011; Durand et al. 2010; Durand and Downes 2009). In the work reported here ‘learning design’ is understood as the preparation of a unit-of-learning (e.g. course, lesson) and includes the definition of learning outcomes, the selection of learning resources, and the sequencing of measures (see Koper and Bennett 2008; Durand 2010).

In our work we focused on blended learning environments in the school sector. This is because the infrastructure for information and communication technology (ICT) in schools remains weak, despite the evidence suggesting that ICT can have a positive impact on the expansion of learning opportunities (Core ICT Indicators 2010; ITU 2013). There is still a significant number of schools in Europe that lack sufficient ICT (ITU 2013), and at the same time the adoption of ICT also varies between subjects (OECD 2009). Consequently fully ICT driven approach is not feasible in the present school system (leaving on one side the question of whether such an approach would be desirable).

In line with the overall approach of the iTEC project (see Chap. 4), we addressed the need to support learning design activities by applying a design science research methodology (DSRM) to the problem. DSRM identifies six activities (Peffers et al. 2007), i.e. problem identification and motivation, objectives for a solution, design and development, demonstration, evaluation, and communication. Though the activities in the DSRM are represented sequentially and start with “identify problem …”, one may start at any of the first four steps. The entry point depends on the nature of the problem and triggering factors. In our case we combined problem identification and the definition of the objectives of the solution in one phase and documented the results of both steps in section “Problem Identification and Requirements” of this chapter. Based on the requirements identified a solution was designed and developed that is documented in section “Implementation of a Widget-Based Solution”. Finally, several evaluations were conducted. In section “Evaluation and Outlook” this chapter concludes with summing up the findings of these evaluations.

Problem Identification and Requirements

This section starts from an initial idea, and a typical user story, followed by the basic concepts and user roles derived from it, in order to come to functional and non-functional requirements, taking into account the school context.

From an Initial Idea to an Agreed User Story

The user requirements that the proposed solution needed to satisfy where initially described in the description of work of the grant agreement. We started off with the idea of allowing users to describe teaching situations and attach learning resources to those descriptions. A few internal meetings later the following user story was developed:

Livia is a Teacher in a secondary school in Izmir, Turkey. She is very enthusiastic about applying new teaching methods and tools. One day, Livia decides to investigate a tool called the Composer by starting to search for learning designs created to support collaborative learning. Since she needs to teach about air pollution in a couple of weeks she looks for learning stories that address this subject.

She finds a very interesting one that combines the puzzle method with the participation of external experts and the attendance at events related to the subject being taught. The next step is to select all the learning resources needed to implement this Learning Story in Livia’s school.

The Composer proposes a list of tools that could be used from those available in Livia’s school. The first recommendation to cope with file sharing is the file sharing functionality of Livia’s learning management system. In terms of content the Composer provides a video on the effects of air pollution plus some online tests that she can use for a formative assessment of the intended learning outcomes. When it comes to searching for Events the Composer returns a list of eight events. The first one is an online event on ‘All you need to know about air pollution’. This event is part of a series of webinars supported by a European project.

Finally, she needs to select an external expert that she aims to bring in. This time she goes to the ‘Recommend Contributors’ option of the Composer. Unfortunately there are no experts on air pollution available that are fluent in Turkish. It seems that only English speaking contributors with the required knowledge on that topic are available. Well, the head of Livia’s department is pushing his staff to progressively introduce English in their lectures. So, this could be a good opportunity for Livia’s pupils to practice their English. She selects Dr. Knopfler, a professor from the Vienna University, Austria, who is an expert in air pollution and kindly offered himself to participate in such kind of activities.

After having sufficiently prepared her personal Learning Design on teaching about air pollutions, she makes it available in her learning management system of choice. Now she feels ready to deliver high quality education on her chosen subject.

Conceptual Foundations and User Roles

Driven by the user story mentioned above, we started to layout its conceptual foundations. Our proposed solution is centred on the design and facilitation of Learning Designs. These, and related key concepts describing our key artefacts are defined as follows:

  • Learning Activity Design: describes a discrete session of Learner interactions, including potential Learning Resources to be used, in order to achieve a set of educational outcomes.

  • Learning Story Design: Learning Activity Designs are “packaged together” to provide a description of a possible context for the delivery of several Learning Activities.

  • Learning Design: refers to both Learning Activity Design and Learning Story Design.

  • Learning Resource: We opt for a broad view of the term “Learning Resource” and distinguish the following types of Learning Resources:

    • Content: Any information resource that can be used for teaching and learning.

    • Contributor: is a person who agreed to make personal contact information available, so that a teacher is able to include her as a contributing participant in the context of a Learning Activity.

    • Event: something that takes place at a determinable place and time, and which can be used within a Learning Activity.

    • Tool: An Application (software) or Device (hardware) that can be used for educational purposes by end users.

Our approach assumes, that all artefacts that are meant to become part of the final learning experience are represented as—or delivered through—appropriate (or appropriately configured) widgets.

In line with the user story described above the stakeholder roles (see Chap. 4, section “The iTEC Technical Architecture”) of Learner, Teacher, and Learning Designer are confirmed.

Schools as Educational Context

Our work focuses on learning environments of the school sector. Hence, we primarily assumed blended learning environments as the context for the uptake of technology. Although evidence suggests that ICT can have a positive impact on the expansion of learning opportunities (Core ICT Indicators 2010; ITU 2013), there is still a significant number of schools in Europe that lack sufficient computer equipment when it comes down to the student per computer ratio (ITU 2013). At the same time the adoption of ICT also varies between subjects: 26 % of students use computers in language lessons while only 16 % of OECD students use computers in mathematics lessons (OECD 2009). As a consequence we could not assume a learning environment that fully relies on the availability and usage of ICT when it comes to supporting the definition and exchange of learning activities.

Functional and Non-functional Requirements

Based on our user story as well as an analysis of the educational context led us to the identification of the following requirements. Although somewhat controversial (Glinz 2007), we distinguish them between functional and non-functional requirements.

The identified problem was translated into high-level functional requirements using the user story format (Cohn 2004): “As a <role>, I want <goal/desire> so that <benefit>”:

  • As a Learning Designer, I want to create new Learning Designs and publish these so that they can give inspiration to Teachers.

  • As a Learning Designer or Teacher, I want to find innovative Learning Designs and create a personal copy so that I can edit them to suit my needs.

  • As a Learning Designer, I want to publish Learning Designs I have adapted or created to a shared space so that I can share my best practices.

  • As a Teacher, I want to easily find a Learning Activity Design and together with its required Learning Resources at a central place, so that I can make these Learning Resources available to my Learners when conducting the Learning Activity.

  • As a Teacher, I want to take advantage of other Teacher’s assessment of Learning Designs so that I can easier find highly relevant ones that actually work in practice.

Beyond the functional requirements the key non-functional requirement Interoperability was identified. In order to support the exchange of Learning Designs beyond system boundaries the systems involved need to be interoperable. Interoperability indicates the ability of two or more systems or components to exchange information and to use the information that has been exchanged (IEEE 1991). Interoperability research distinguishes between interoperability on the object, referring to a proper use of the information provided—and interoperability in the communication, referring to an agreed communication protocol between systems (Van Assche et al.). These two aspects of interoperability translated into the requirement to make learning designs—including their resources—re-useable in different technical contexts as well as the requirement to agree on communication protocols between the various system components.

Implementation of a Widget-Based Solution

When designing the Composer we opted for a widget-based approach that consists of the following components: A Widget is a packaged web application (W3C 2012) that is designed to be easily distributed and embedded within varying contexts (e.g. within a portal-style mashup, on a mobile phone, etc.). Widgets rely on open standards with respect to both their representation format and their communication protocols.

A Widget-Based Authoring Environment is used to create widgets. This supports our technical assumption that all artefacts that are meant to become part of the final learning experience are represented as, or delivered through, widgets. Hence, a Learning Design as well as the Learning Resources included are represented as Widgets.

The Widget Store is a software component that is built on the Apache Wookie and EDUKApp technologies (Griffiths et al. 2012). It supports the uploading, tagging, and searching for Learning Resources and learning designs in the form of Widgets. The Composer supports Learning Designers and Teachers in designing Learning Activities, and augmenting them with Learning Resources.

A Widget Run-time Environment (RTE) acts as the “entry point” for end users and is a configurable software container that provides an environment allowing users to identify and add their Widgets and to integrate them in order to meet the educational objectives of a Learning Activity. Typically, a Widget RTE connects to a Widget Store to provide users with an integrated experience when selecting and instantiating widgets (Soylu et al. 2012). Examples include mashup engines like Apache RAVE as well as Widget-enabled learning management systems like Moodle and DotLRN.

Representing Learning Designs via Widgets

We now describe our layered approach to representing Learning Designs, which follows the “web best practices” of progressive enhancement and the rule of least power (Soylu et al. 2012). Consequently, when entering a higher level, interoperability decreases, while functionality increases. At the lowest layer we render a Learning Design as HTML. Hence, the fundamental (narrative) information of such a guide is represented as a web document, thus can be viewed in any standard web browser, or processed otherwise by third-party applications.

Packaging this Learning Design as a W3C Widget represents the second layer, which gives teachers easier control of the Learning Design in various manners, e.g. by instantiating it in their Widget RTE, viewing it offline on a phone, or publishing it in a Widget Store. At these two levels the Learning Design already provides added value to the teacher, both when preparing the learning activity and when it takes place.

However, many useful Learning Designs will go beyond mere textual descriptions and will require particular resources to be used by teachers and learners (e.g. Applications, Content). Hence, the technology supports the Teacher in augmenting the (virtual) learning environment with these resources. We therefore progress further in functional enhancement by “transforming” the instantiated Learning Design Widget into a mashup. Technically, to this end our approach utilizes a client side cross-context communication channel-based on PMRPCFootnote 1 (Soylu et al. 2012). To transmit a description of the additional Learning Resources required. As we consider all resources to be delivered via Widgets, we represent the resources required by the Learning Design in the form of a mashup description based on the Open Mashup Description Language.Footnote 2 Finally, the RTE instantiates all the Widgets required for conducting the learning activity that is described by the Learning Design Widget.

Authoring Widget-Based Learning Designs with the Composer

From a user’s point of view, the Composer is intended to provide Learning Designers and Teachers with the means to compose and re-use Learning Activities and augment them with Learning Resources. We interpreted this process as a Widget aggregation. A typical usage scenario of the Composer can be given alongside the “typical usage scenario for learning resources” (see Van Assche et al. 2006):

  • Discovering: A Teacher who wants to create a Learning Design for use in the classroom uses the Composer to search for existing Learning Designs, which seem to fit the particular learning outcomes she has in mind. Having discovered an interesting Learning Design, she evaluates it both according to her personal criteria. Before Teacher begins with augmenting the Learning Design, she creates a personalized copy within the Composer.

  • Repurpose and Re-use: This is the central step, where a Teacher modifies the Learning Design according to her personal needs. In doing so, the Teacher aggregates (references to) Widgets from the Widget Store. For example, the Teacher enriches the Learning Activity with concrete Learning Resources. The result of this mashup process is a personalized Learning Design that is augmented with concrete resources.

  • Publishing: In case the Teacher decides to publish this Learning Design, the Composer makes it available to others in a public area, so that it can be reused in other “development cycles”. Moreover, a Learning Design Widget—representing the interoperable output representation—is generatedFootnote 3 and published into the Widget Store.

Technically, driven by the non-functional requirement for interoperability, the Composer was implemented as a highly embeddable web application. To this end, the Composer seamless integration via the emerging IMS Learning Tools InteroperabilityFootnote 4 (LTI) protocol and implements a responsive user interface.Footnote 5

LTI enables a seamless integration into for example in the DotLrn learning management system as far as identity management is concerned. Hence, a DotLrn user can directly access the Composer via DotLrn using her DotLrn user account. Once logged into the Composer the user can start to compose a Learning Design. A user can start composing also by reusing other Learning Designs. This is supported by a browse functionality and a copy feature that allows her to copy an existing Learning Design into her personal workspace. At the personal workspace a user can create new and alter existing Learning Designs. Users are also encouraged to publish their private Learning Designs to the public space, where they can again be found by other users.

The metadata used for describing Learning Designs is limited to the a few elements in order to simplify the authoring process and include title, summary, and descriptions of the activities recommend to be carried out. Once the authoring of the Learning Design is finalised the Learning Design can be pushed to the Widget Store where it can be discovered and reused.

Sharing Learning Designs via the Widget Store

As explained above, Learning Resources are highly relevant during both the design-time and run-time of a Learning Design. In this context, we consider that an educational Widget Store plays a key role. On the one hand, it acts as a repository of Learning Resources, in particular Content and Applications. On the other hand, the Store also provides the user with means to “widgetize” arbitrary web resources. Hence, the Widget Store has the potential to evolve into a living, collaboratively curated repository of user-selected and user-generated Learning Resources. These Learning Resources can be added to a Learning Design during the authoring process mentioned above (see Fig. 5.1). In order to find appropriate Learning Resources the Scenario Development Environment was introduced as an additional system component providing recommendations for learning resources based on the user profile as well as the educational context of the author composing the Learning Design.

Fig. 5.1
figure 1

The iTEC Widget Store as part of DotLrn

Full size image

Technically, the Widget Store (see Chap. 8) consists of three layers. Firstly, it builds on the Apache Wookie server. Secondly, management of data relating to the description of Widgets and their use, is handled making use of the EDUKApp Educational Widget Store initiative (Griffiths et al. 2012). Thirdly, its front-end is delivered to the user as a Widget.

Facilitating Learning Designs with a Widget Run-Time Environment

The software component that acts as the “entry point” for the end user—in particular the Learner—is referred to as a Widget RTE. Examples include, but are not limited to, mashup engines such as Apache RaveFootnote 6 and Widget-enabled learning management systems such as MoodleFootnote 7 and DotLRN.Footnote 8

In the DotLrn-instantiated Widget Store a Teacher can select her Widget of-choice, like for example a Widget represented a Learning Design for teaching children about air pollution (see Fig. 5.2). Once this Learning Design is identified in the Widget Store, the Teacher can simply configure the DotLrn by pressing an “Install” Button. As a next step the Teacher is asked to confirm the population of her DotLrn course with all the widgets required to conduct this Learning Activity. Once the Teacher has confirmed, additional widgets are added to the Teacher’s course. Hereby the Widget RTE becomes ready to support the Learning Design about teaching “Air Pollution”.

Fig. 5.2
figure 2

DotLrn configured with Widgets of the Learning Design “Air Pollution”

Full size image

Evaluation and Outlook

At the end 19 small-scale evaluation activities of the proposed solution were carried out. Early evaluation activities mainly consisted of open expert interviews from which a better understanding of the problem definition was derived. At a later stage these activities were used to iteratively revise the requirements. The evaluation events mostly involved pedagogical experts. The evaluations were documented in the form of action logs resulting in concrete changes to requirements. In the case of the Composer the main findings relate to: (a) provide an even more simplified user interface, (b) support private areas within the collaborative, wiki-style tool, and (c) improve support of mobile devices like tablet computers.

Finally the Composer formed part of the Edukata process in two of the iTEC case study countries. When using the Composer in this deployment phase, teachers looked at existing Learning Designs for inspiration and used the Composer to ‘present’ the Learning Designs they had devised during the workshop. In the context of this evaluation activity the main improvement requests were related to enhancing the metadata model used for describing the Learning Desings. Extending the metadata model for example by suggested elements such as typical age range or level of difficulty would subsequently allow for an improved search mechanism.

Overall, we concluded from our evaluations and deployment experiences that the idea of the Composer was generally well received, but it looked like that the idea of sharing Learning Designs cannot create critical mass as a standalone component. As a consequence we transferred the ideas of the Composer to the learning management system DotLrn and introduced a new learning resource type called “teaching idea” there. Teaching ideas are Learning Designs created to inspire other teachers in use of technologies in the classroom. A project initiated by the Austrian ministry of education called “App-o-thek” was launched, where this new learning resource type is already used in order to provide teachers with hands-on guidance when it comes to using Apps in the context of their classroom teaching.