Application scenarios

In order to prove to what extend the proposed IBL interoperable components help to develop IBL solutions, two application scenarios are described. The first scenario illus- trates how the APIs were used in the weSPOT European project (Specht, Bedek, Duval, Held, et al., 2012) as a contract between project partners to connect their in- quiry products. This implementation demonstrates interoperability as through the API, existing IBL client/server artefacts such as the Inquiry Workflow Engine (IWE) were integrated. The second scenario addresses shortcomings of the first scenario and pre- sents DojoIBL, a redesign tool that relies on cloud-based artefacts. These two exam- ples illustrate the wide applicability of this framework for interoperability between IBL components.

5.5.1 weSPOT Personal inquiry manager

The weSPOT project was a 3-year European research project (Specht, Bedek, Duval, Held, et al., 2012) that focused on a) addressing the lack of inquiry skills in schools

with teacher and students, b) establishing an inquiry model applicable in schools, c) developing an open source toolkit for the use in schools, and d) evaluating the effects of inquiry-based mobile learning in school contexts with a variety of topics/domains in 7 European Countries and international research cooperation.

Using the proposed interoperable components, the Personal Inquiry Manager (PIM) was developed. The PIM is a mobile application developed for both Android and iOS and brings two important inquiry functions to the mobile user: communica- tion and data collection. The PIM communicates with the weSPOT Inquiry Workflow Engine (IWE) to store and to retrieve inquiry data. The IWE, an open source social engine built on Elgg, models inquiries as Elgg sites. In this Elgg model, an inquiry structure is strongly coupled to the users. This means that an ‘Inquiry’ (defined as an Inquiry design) and the ‘Inquiry Run’ (group of users for that Inquiry) have a one-to- one relationship. This limits the reuse of an inquiry design (Inquiry) with a different Inquiry Run (group of users). For this case, the data model was adapted to be more specific, constraining the cardinality of ‘Inquiry’ to ‘Inquiry Run’ to one, meaning that an IWE inquiry always has one corresponding ‘Inquiry Run’.

Figure 26 illustrates the seamless integration of the IWE and the PIM. Both tools make use of the Mobile Data Collection (MDC) artefact. The IWE (left side) displays a data collection task and a selection of data collection samples. Using the PIM (right side), a user can consult data collection tasks and upload new data samples (e.g. pic- tures) to the cloud-based implementation of the MDC.

Figure 26: Data Collection in IWE (left - desktop) and PIM (right – mobile app).

This scenario illustrates how the API, presented in section 5.4.2 enables interoperabil- ity with a third party IBL artefact, the IWE. In order to provide interoperability be- tween the PIM and the IWE, the IWE data model was mapped on the IBL data model (see Figure 23). Moreover, this case features three different artefacts building on dif- ferent technologies: the IWE, PIM and MDC respectively build on PHP/server, JAVA android SDK and JAVA/cloud-based technologies. Figure 27 shows the architecture for the weSPOT case.

Figure 27: weSPOT architecture.

Figure 28 demonstrates a simple use case of the IBL architecture components and its APIs. As a user captures and submits a data sample with the PIM, the data (1) and corresponding metadata (2) are sent to the MDC via the ‘postBlob’ and ‘cre- ateDataSample’ message. The MDC stores this data sample and binds it to the user that took the sample, the ‘Inquiry Run’ and the ‘Data Collection Task’. Next, the MDC publishes a notification (3) to all users that participate in the ‘Inquiry Run’ to make them aware of this new data sample and to update their UIs. The Mobile Notification Component queries the devices that are registered with each user in the ‘Inquiry Run’ and will select the corresponding protocol to notify the user. Via Google Cloud Mes- saging protocol, an Android user will receive this update, while the channel API is used to update the IWE browser based application. By doing so, the Android device is trig- gered to update the UI and will retrieve the new sample metadata and data (4). Similar- ly, the IWE will update its interface and will show the new data samples.

Figure 28: Software artefacts and APIs.

5.5.2 DojoIBL

DojoIBL17 _{(Suárez et al., 2016; Ternier et al., 2012)}18 _{is an open source and cloud-} based implementation for inquiry-based learning developed to structure inquiry pro- cesses. It is maintained on a non-project basis by the Welten Institute of the Open Universiteit and is currently being used in 10 national and international inquiry project across Spain, the Netherlands and Bulgaria. During its first year over 200 students have generated in DojoIBL more than 2000 contributions and sent around 4000 messages. It has been developed upon various software artefacts following a design-based re- search approach. Teachers, designers and researchers have given feedback on a contin- uous basis and contributed to an incremental developmental process.

The DojoIBL architecture (see Figure 29) is a follow up initiative of the weSPOT architecture. However, DojoIBL took into account lessons learned. The IWE in the weSPOT architecture suffered from performance issues when several groups of stu- dents used the tool at the same time. Hence, several components in different layers of the architecture were exchanged or redesigned. In the data and application layer, a schemaless database (GAE) and a redesigned IBL engine were implemented on a cloud-based infrastructure that scales very well with increasing student numbers. Moreover, the application layer now builds on the AngularJS19 _{framework for the} browser version and on the React Native20 _{framework for the mobile part.}

As a results of the redesign, DojoIBL offers more flexible support for inquiry de- signs. It provides a) freedom for teachers and students to create their own inquiry designs and b) inquiry templates based on existing inquiry models from literature like: the weSPOT IBL model (Specht, Bedek, Duval, & Held, 2012), the six-step model

17 _{http://dojo-ibl.appspot.com}

18 _{This publication is included as Chapter 7 in this thesis.} 19 _{https://angularjs.org}

(Llewellyn, 2005) or the seven-step inquiry cycle (Murdoch, 2007). Unlike the IWE IBL engine in the weSPOT project, the DojoIBL engine properly implements the relation between ‘Inquiry’ (inquiry design) and ‘Inquiry Run’ (inquiry groups). This solves the problem that an ‘Inquiry’ could not be reused by different ‘Inquiry Run’ (inquiry groups). Ultimately, this means that groups of students can work and generate content independently following the same ‘Inquiry’ (inquiry design).

The new DojoIBL engine benefits more from the other components than the IWE engine and offers special support for collaborative IBL approaches like the Communi- ty of Inquiry (CoI) framework. The CoI (Garrison, 2015) characterizes the inquiry process as a continuous collaborative exploration of a topic of student’s interest. Thus, DojoIBL features an implementation of the ‘Mobile Notification’ and the ‘Inquiry Messaging’ component and offers a communication channel per “Inquiry Run’. This helps students and teachers to interact even when they do not share the same location. As chats are embedded within each ‘Inquiry Run’, discussions are contextualized to the topic and structure of an inquiry. The inquiry timeline interfaces with the notification engine. Every student contribution (e.g. new data sample taken, a comment made on a hypothesis) leads to a new entry on the timeline, providing an easy overview of all recent events and the flow of activities in an inquiry process.