Description of the approach
We previously mention that we propose MS as a didactical approach which brings two online collaboration approaches (outside-of-class-Multiscript (OMS) and inside-of-class-Multiscript (IMS)) into a single platform. The basis of MS is the didactical aspect i.e. more own initiative of the students and more chances for student peer interaction, which eventually motivates the design of our MS platform. We refer MS as a platform rather than an application because it combines the tasks of different applications (e.g. recording the audio lectures, maintaining student’s annotations and feedbacks on the slides, supporting audio and text chats on the lecture contents, fetching content feedback from a classroom response system called Tweedback (Vetterick et al., 2013) to deliver the final task. A lecture content typically contains a set of slides, optionally extended by private annotations of the student and public audio annotations of the teacher. The teacher can provide the audio annotations to explain a specific topic in detail. The teacher has the option to record the audio during the lecture presentation; the audio will be automatically attached to the relevant slide set. Besides this, if the teacher feels appropriate, s/he can add audio snippets and recording of the discussions of the students (in case they agree).
Below, we present the main features which MS contains to support the online collaboration. There are two main categories of features – one is for the teachers and the other is for the students which we refer here as shared features.
Features for teacher only
-
Upload and manage slide sets
-
Attach audio files to a single slide
-
Present the slides on Multiscript
-
-
Automatically sync the projected slides to the screens of the listeners
-
-
Different information, e.g. the number of listeners
-
-
Integration of the class room response system Tweedback (Vetterick et al., 2013)
Shared features
-
Listen to audio files for more information
-
Annotate the slides with text and mark them with predefined tags to group them
-
Text chat (in every situation)
-
Audio chat (in outside of class)
-
-
Synchronize the slides between other audio chat users (like a small “in-class” situation among learners)
Besides these, the following features are currently in development:
-
Consultation hour (see “Consultation hour” section)
-
Notes directly on the slides
-
Audio stream of a live session
-
Public annotations for a slide to group similar questions/notes, that can also be answered/approved by the teacher
-
Record a live session (in class) and automatically assign the recording to the presented slides (with a possible replay of the complete session)
Here, we respectively describe the idea behind devising OMS and IMS and the functional requirements to support their working process.
In OMS, the students are able to seamlessly collaborate, via web connection, with their peers on the lecture slides uploaded by the teacher. Here, a teacher, after delivering a lecture, can share the lecture slides by uploading them to the MS server. The students can access the lecture slides on any available PCs, tablets, notebooks or mobile devices at any time just by using a web browser. While sharing the lecture slides, a teacher can attach audio annotations for each of the slides and/or attach a single audio for the whole lecture. So, the students can listen to the audio annotations for each slide while studying the slides and/or go through all the slides while listening to the entire lecture audio in the background. Figure 1 shows an illustration of OMS mode. In OMS mode, the students are offered four different kinds of features, they can:
-
Perform text chats with their peers
-
Participate in audio chats with their peers
-
Annotate the slide for their own purpose
-
Post feedback about the slides and ask questions to the teacher
For the last case, the feedback and the questions are sent to the teacher as a ‘newsletter’ and the teacher, along with providing appropriate response, can also rate the feedback/questions. The teacher is also able to provide reason for his/her voting.
In IMS, the students can collaborate on the lecture content while being in the classroom. Here, the students can create annotations on the slides for themselves and post feedback about the slides which is read by the teacher later. The teacher can respond to the feedback and rate it similar to OMS mode. This mode is illustrated in Fig. 1. While the teacher delivers a lecture in IMS, the slides are shown in three different modes:
-
via the projector in the classroom
-
on the browser of a student’s device
-
on his own computer’s screen
In the second case, the slide displayed on a student’s device is synchronized with the projector’s current slide. In the third case, the teacher’s screen shows a few additional features along with the slides. S/he can see the currently selected slide, a preview of the other slides and some notes for herself. The teacher can also control, from his/her machine, the number of collaborating options which will be available on the students’ devices.
Apart from the functional features described above, Multiscript (MS) has a few other features which are designed for providing the best possible user experience. One of such features is the fast interaction experience of the users with MS. We develop a robust communication platform within MS so that the interaction with MS is fast and responsive enough to meet user’s satisfaction. Besides, since the users consider a communication platform as a comfortable one only when the user-interface is easy to use and has a minimalist design, we preserve these qualities within MS. We also consider the fact that the interface of a robust communication platform like MS should have a flexible interface which fits on different screen sizes of different devices (e.g., PCs, Tablets, mobile phones). We develop the MS platform in such a way that it can be displayed intuitively on various screen sizes on a range of devices.
Besides this, while designing the MS platform, we have considered the age of the users. We kept the design simple enough so that people with minimum knowledge about Internet can familiarize themselves with MS with minimum effort. Moreover, MS has the capability to handle quite a large number of users at a time. In future, it might be used by a large number of users, so we have considered the access peak of the system when many users start to use MS at once. The scalability of MS allows large number of connections simultaneously. Besides this, we keep the identity of the students anonymous in MS, so that they can avoid the account creation process and collaborate autonomously with their peers. We have designed MS to be modular so that, in future, new features can be integrated easily into it.
Form of collaboration in Multiscript
We have designed MS to be a collaboration platform for the learners and the teachers. Here, we explain which type of collaboration we consider while designing the MS platform. We consider the following three different situations about how the collaboration can occur.
Planned meeting among students
This situation can be described by a group of students, that made an actual appointment on MS. Using other communication services (email, messengers etc) all students made an appointment, e.g. at 3 p.m. to meet on MS Slide Set “Lecture01” by Prof. X. The students don’t have to find each other because they already have a specific meeting point.
Spontaneous meeting among students
Here, we consider a spontaneous learning situation. It might happen that some students are learning on MS and one has a question regarding a difficult topic. So, the students can take advantage of MS and resolve their respective queries.
Consultation hour
Here, the teacher provides a consultation hour for the students. Now, we can think of two scenarios – either the teacher provides a fixed time (e.g. 1 p.m. to 3 p.m.) or a more spontaneous approach is taken. The first scenario allows for a remote version of the usual consultation, but allows all participants to operate from their current location, removing the need for traveling. In the second scenario, the teacher is working on MS and notices that some students are learning on a specific slideset. Due to the text chat or some other form of notification, the teacher notices that there is an interesting discussion going on. Therefore, the teacher decides to join the discussion and invites the student to an audio session to discuss the problem in detail. Additionally, to the existing features like the slides and the text/audio chat, the teacher will get the possibility to draw on a blackboard-like element to write down formula, explanations etc. in an easy way.
Feedback from the participants
As stated in the related work section, IC feedback can be gathered in two ways: learners post messages to the audience and multiple choice questions answered by learners. While the first one is covered by the previous chapter, the second one adds a huge benefit to the teachers’ use of Multiscript.
As used in Classroom Response Systems, Multiscript (MS) also offers a function for the teachers to ask multiple choice questions (“quiz”). Teachers are able to spontaneously create a quiz whenever they intend to get a picture of the overall understanding level of the students. Within MS, teachers can create this “bigger picture” by asking a set of questions with predefined answers to the students and then, judging the responses of those questions upon receiving from the students; here, the students have to map their knowledge and understanding into the given answers. Multiscript, after collecting all the students’ answers, summarizes and present them to the teacher.
Furthermore, Multiscript preserves these summaries (quiz results), so the teachers, on the one hand, can revise their teaching material and methods afterwards to improve their teaching. On the other hand, students can revise their knowledge, understanding and pitfalls afterwards to prepare better for the exam.
Architecture of the Multiscript platform
Since we plan to support a wide range of devices (with varying screen size and operating system), rather than developing individual app for each cases, we develop a web application, which serves HTML, for the MS platform. Since most of the devices (stationary or mobile) possess the capability to render HTML5, Javascript and CSS (Kamboj & Gupta, 2012), we develop one browser-based client interface which intuitively fits on these devices. This removes the necessity to maintain different repositories for different versions (mobile phone, desktop, iOS, Android etc.) of the proposed MS platform. Moreover, we also consider an easy and minimal design for the user interface. Hence, to achieve a unique development platform and user friendly interface design, we choose to use established frameworks for the web-based user interface. We use Express and SocketIO framework, Node.js, Jade and AngularJS for building the web application of MS.
While designing the user interface of MS platform, we decide to subdivide the interface into different views in such a way that every feature has a separate view of its own. The teacher’s view on the MS interface contains a number of controlling options by means of which s/he can control which feature the students are able to see on their own machines. Figure 2 outlines the technology stack of MS. In MS, we allow anonymous participation of the students so that the peers and the teacher cannot trace back to the user. To achieve this, we remove the necessity to register an individual with a university account, rather we allow everyone. Nevertheless, we define certain thresholds to prevent any misuse of the MS platform with an anonymous account.
Performance, scalability and responsiveness are the factors which matter most for a good web application, and yet, these are the requirements which are quite difficult to achieve. To develop a stable and fast web application for MS, we looked into numerous solutions for asynchronous web servers which would work with two-way communication channel in tandem. We decide to use the Node.js as our web server. It uses V8, the Google Chromes JavaScript engine. It is event-driven, stable and has the capability to perform thousands of concurrent connections. For MS, a two-way communication channel is necessary, because both, the server and the client, send messages to each other. In MS, the client is the browser of both the students and the teacher. We use the SocketIO library as the two-way communication layer which is well implemented for Javascript and for the Node.js web server. To support audio chat in MS, we use WebRTC. We choose to use MongoDB, a non-relational database which possesses flexible scheme to store all permanent data.
Data flow
In MS, the users are assigned hash values as UserID and a lecture content is assigned a unique LessonID. The data flow in MS are initiated – either by the teacher or by the students. Figure 3 shows the data flow diagram within MS platform. When the teacher uploads lecture content (called a Slideset) with audio annotations, an upload command is executed within MS. As a result, a corresponding LessonID is generated for the Slideset, and subsequently, the Slideset with audio annotations and LessonID are sent to the MS server to be stored.
When a student selects a Slideset from the list of displayed Slidesets, a request is sent to the MS server to fetch the Slideset. Upon getting the request, the MS server fetch the Slideset and associated annotations (if already existed) for that particular student and send them to the students browser. When the students create new annotations and/or feedback for a particular slide, those are sent (along with UserID and LessonID) to the MS server to be stored.
Development status
Currently, as of April 2017, we have completed the development of most of the features for both OMS and IMS mode, except the feedback feature (currently under development) for the students. The current version of MS is accessible at https://ms.twbk.de/. An overview of the OMS and the IMS modes, and the outlook of teacher’s window when the lecture is being presented via the projector is depicted in Figs. 4, 5 and 6 respectively. Figure 4 depicts that the students can look into the slide contents while listening to the audio annotations, collaborate anonymously with their peers via audio and text chat, and annotate the slides for themselves. Figure 5 shows that the teacher can start the presentation on the projector from his/her device while his/her screen shows different options (e.g., preview of current and other slides, audio annotation area). S/he can write notes about the slides or the lecture for him while s/he is presenting the slide to the students. Figure 6 depicts the teacher’s window when s/he has started the lecture and the slides are being displayed on the projector. It shows different real-time statistics such as how many users have joined the lecture via MS, running time of the lecture slides etc.