Development of a Classroom Response System

Entwicklung eines Classroom Response Systems Development of a Classroom Response System Dominik Ferber

BACHELORARBEIT

Betreuer: Prof. Dr. Axel Böttcher eingereicht am Bachelorstudiengang Informatik der Hochschule München, Fakultät für Informatik und Mathematik im Juni 2014

Inhaltsverzeichnis Kurzfassung

iv

Abstract

v

1 Einleitung

1

1.1

Aufgabenstellung . . . . . . . . . . . . . . . . . . . . . . . . .

1

1.2

Motivation . . . . . . . . . . . . . . . . . . . . . . . . . . . . .

2

1.3

Gliederung . . . . . . . . . . . . . . . . . . . . . . . . . . . . .

3

2 Peer Instruction

4

2.1

Konzept . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .

5

2.2

ConcepTest . . . . . . . . . . . . . . . . . . . . . . . . . . . .

6

2.3

Fragen . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .

8

2.4

Aufgaben des CRS . . . . . . . . . . . . . . . . . . . . . . . . 10

3 Classroom Response Systems 3.1

12

Kategorien . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 12 3.1.1

Nicht-Technisch . . . . . . . . . . . . . . . . . . . . . . 13

3.1.2

Elektronisch . . . . . . . . . . . . . . . . . . . . . . . . 13

3.1.3

Softwarebasiert . . . . . . . . . . . . . . . . . . . . . . 14

3.1.4

Hybride Lösungen . . . . . . . . . . . . . . . . . . . . . 16

3.2

Marktübersicht . . . . . . . . . . . . . . . . . . . . . . . . . . 16

3.3

Gängige Fragetypen . . . . . . . . . . . . . . . . . . . . . . . . 19 3.3.1

Single Choice . . . . . . . . . . . . . . . . . . . . . . . 19

i

Inhaltsverzeichnis

3.4

ii

3.3.2

Multiple Choice . . . . . . . . . . . . . . . . . . . . . . 20

3.3.3

Freitext . . . . . . . . . . . . . . . . . . . . . . . . . . 20

3.3.4

Numerisch . . . . . . . . . . . . . . . . . . . . . . . . . 20

Architektur webbasierter Lösungen . . . . . . . . . . . . . . . 20

4 Geplantes System

23

4.1

Konzeption . . . . . . . . . . . . . . . . . . . . . . . . . . . . 23

4.2

Umgebung . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 25

4.3

Anforderungen . . . . . . . . . . . . . . . . . . . . . . . . . . 25

4.4

Fragetypen

5 Entwicklung 5.1

5.2

5.3

. . . . . . . . . . . . . . . . . . . . . . . . . . . . 28 33

Komposition der Werkzeuge . . . . . . . . . . . . . . . . . . . 34 5.1.1

Meteor . . . . . . . . . . . . . . . . . . . . . . . . . . . 35

5.1.2

MongoDB . . . . . . . . . . . . . . . . . . . . . . . . . 40

5.1.3

D3 . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 41

5.1.4

Bootstrap . . . . . . . . . . . . . . . . . . . . . . . . . 41

5.1.5

Technologie-Übersicht . . . . . . . . . . . . . . . . . . 41

Design . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 43 5.2.1

Struktur . . . . . . . . . . . . . . . . . . . . . . . . . . 43

5.2.2

Collections . . . . . . . . . . . . . . . . . . . . . . . . . 46

5.2.3

Seminare . . . . . . . . . . . . . . . . . . . . . . . . . . 51

Fragetypen

. . . . . . . . . . . . . . . . . . . . . . . . . . . . 54

5.3.1

Multiple Choice . . . . . . . . . . . . . . . . . . . . . . 58

5.3.2

Number . . . . . . . . . . . . . . . . . . . . . . . . . . 60

5.3.3

Point-And-Click . . . . . . . . . . . . . . . . . . . . . . 60

5.3.4

Smiley Reports . . . . . . . . . . . . . . . . . . . . . . 61

5.3.5

Likert Scale . . . . . . . . . . . . . . . . . . . . . . . . 62

5.3.6

Zusammenfassung . . . . . . . . . . . . . . . . . . . . . 64

5.4

Testen . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 64

5.5

Continuous Integration . . . . . . . . . . . . . . . . . . . . . . 66

5.6

Deployment . . . . . . . . . . . . . . . . . . . . . . . . . . . . 66

Inhaltsverzeichnis

iii

5.7

Skalierung . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 68

5.8

Konformitätsbewertung . . . . . . . . . . . . . . . . . . . . . . 70

6 Schluss

73

6.1

Zusammenfassung . . . . . . . . . . . . . . . . . . . . . . . . . 73

6.2

Fazit . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 74

6.3

Ausblick . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 75

A Erstellung eines Frageformats

76

A.1 Geplantes Frageformat . . . . . . . . . . . . . . . . . . . . . . 76 A.2 Voraussetzungen . . . . . . . . . . . . . . . . . . . . . . . . . 76 A.3 Umsetzung . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 77 A.3.1 Definition des Packages . . . . . . . . . . . . . . . . . . 77 A.3.2 Definition des Frageformats . . . . . . . . . . . . . . . 77 A.3.3 Integration des Frageformats . . . . . . . . . . . . . . . 84 Quellenverzeichnis

86

Literatur . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 86 Online-Quellen . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 87

Kurzfassung Viele Hochschulen verwenden Classroom Response Systeme (CRS) um Studierende aktiv in den Unterricht einzubinden. Neben den langjährig etablierten hardwarebasierten CRS gibt es immer mehr webbasierte Lösungen. Diese ermöglichen es Studierenden, ihre eigenen mobilen Endgeräte zum Abstimmen zu verwenden. Da so die Anschaffungskosten des CRS nicht von der Teilnehmerzahl abhängt, kann die häufig mit CR-Systemen genutzte Lehrmethode Peer Instruction auch für sehr große Gruppen (mehr als 1000 Teilnehmer) genutzt werden. Ein Nebeneffekt davon sind die erweiterten Eingabefunktionen der leistungsfähigeren mobilen Endgeräte der Teilnehmer, im Gegensatz zu den in hardwarebasierten CRS verwendeten Clickern. Dadurch ist es möglich, neuartige Frageformate umzusetzen. Eine für diese Arbeit durchgeführte Marktanalyse ergab, dass bisherige webbasierte CRS dieses Potential kaum nutzen. Deshalb wurde im Rahmen dieser Arbeit ein webbasiertes CRS entwickelt, das sehr einfach um neuartige Frageformate erweiterbar ist. Es enthält bereits einige Frageformate. Auf dem entstandenen CRS aufbauend können neue Fragetypen zukünftig mit wenig Aufwand erprobt werden, um die Lehre mit CRS langfristig zu verbessern.

iv

Abstract Many universities use Classroom Response Systems (CRS) to actively involve students during class. In addition to long-established hardware-based CRS, there are more and more web-based solutions being developed, which allow students to participate by using their own smart devices in order to vote. This way the final price of the system does not depend on the number of students, so even courses with more than 1000 participants may implement Peer Instruction, which is a teaching method that utilizes CRS. As a side effect, the functionality of the mobile devices exceeds the Clickers used in hardware-based CRS. The improved input capabilities enable developers to implement new types of questions. A market analysis, which was conducted as part of this thesis, shows that many existing web-based CRS fail to take advantage of this opportunity. Therefore, a web-based CRS was developed as part of this thesis, which is very easily extensible to include new question formats. The system already contains some question types. In the future even more question types may be tested effortlessly, based on this system. This will hopefully improve teaching with CRS in the long term.

v

Kapitel 1 Einleitung 1.1

Aufgabenstellung

Im Rahmen dieser Arbeit soll ein webbasiertes Classroom Response System (CRS) für den Einsatz an Hochschulen entwickelt werden. Das System soll auf die Lehrmethode Peer Instruction (PI) zugeschnitten sein [1]. Diese sieht vor, dass ein Dozierender pro Lehrstunde sequenziell mehrere Fragen stellt und pro Frage sofort eine Rückmeldung von den Studierenden erhält. Es gibt einige Systeme, die lediglich Single- und Multiple-Choice-Fragen unterstützen [9]. Ein wesentliches Teilziel dieser Arbeit ist deshalb die Erkundung neuartiger Frageformate. Dazu soll zunächst in einer Marktübersicht der gängige Funktionsumfang bestehender Lösungen ermittelt werden. Dabei sind speziell die derzeit verfügbaren Frageformate interessant. Anschließend ist ein CR-System zu entwickeln, mit dem neuartige Frageformate erkundet werden können. Für das CRS ist ein Mechanismus zu implementieren, der es den Teilnehmern ermöglicht die Fragen der Veranstaltung automatisch auf ihren eigenen Geräten anzuzeigen und von dort aus zu beantworten. Wechselt der Lehrende zur nächsten Frage, soll diese ohne Aktion der Studierenden automatisch in ihren Browsern erscheinen. Dieser Mechanismus wird als Fragestrom bezeichnet. 1

1. Einleitung

1.2

2

Motivation

“Man kann die Pferde zur Tränke führen, saufen müssen sie selbst.” – Sprichwort Dieses Sprichwort passt sehr gut auf die Lehre. Dozierende können ihren wissensdurstigen Hörern zwar das gesamte Skript vortragen, doch um die Inhalte tatsächlich aufzunehmen, müssen die Studierenden selbst aktiv werden. In traditionellen Lehrveranstaltungen ist den Studenten eine passive Rolle zugeordnet. Sie hören was der Lehrende vorträgt. Vorwiegend Zuhörer, die von sich aus aktiv werden – indem sie sich in die Thematik hineinversetzen – können von so einer Lehrstrategie profitieren. Eine Methode, welche die Studenten während des Unterrichts über das reine Zuhören hinaus fordert, wird als „aktives Lernen“ bezeichnet [14]. PI ist eine solche Methode. Durch regelmäßige ConcepTests sollen die Studenten mit in den Unterricht eingebunden werden. Dabei handelt es sich um Fragen der Lehrperson, welche die Kursteilnehmer diskutieren und beantworten sollen. Das Ergebnis jedes Tests entscheidet über den weiteren Verlauf der Lehrveranstaltung. Eric Mazur entwickelte PI vor über 20 Jahren an der Harvard University. Seither wurde die Lehrmethode oftmals positiv evaluiert, wie z. B. in [5]. Da es dem Dozierenden ohne Hilfsmittel nicht möglich ist, sich in angemessener Zeit ein korrektes Bild von der Meinung der Befragten zu machen, werden CRS eingesetzt. Indem jeder Student einen sogenannten Clicker zum Abstimmen verwendet, ist es dem Lehrenden möglich, das Voting der Hörer binnen Sekunden zu erhalten. Dadurch, dass jeder Teilnehmer einen eigenen Clicker benötigt ist die Anschaffung von hardwarebasierten CRS teuer. Alternativ gibt es softwarebasierte CRS, bei denen die Studierenden ihre persönlichen Endgeräte als Clicker verwenden können, indem sie eine App installieren. Da pro Betriebssystem eine spezielle App entwickelt werden muss, werden so Benutzer nicht unterstützter Betriebssysteme ausgeschlossen. Daher soll in dieser Arbeit ein webbasiertes CRS entwickelt werden, das auch

1. Einleitung

3

in großen Gruppen kostengünstig nutzbar ist und möglichst viele Teilnehmer unterstützt, indem es betriebssystemunabhängig eingesetzt werden kann.

1.3

Gliederung

Kapitel 2 erläutert die Lehrmethode Peer Instruction. Hier werden die grundlegenden Konzepte vorgestellt. Weiter wird auf die Abhängigkeit von einem guten Classroom Response System für eine erfolgreiche Lehrveranstaltung eingegangen. Das dritte Kapitel stellt CRS detailliert vor. Es beschreibt die unterschiedlichen Kategorien von CRS. Eine Marktübersicht zeigt gängige Lösungen. Aus ihr hervorgehende grundlegende Fragetypen werden vorgestellt. Letztlich folgt eine stichprobenartige Analyse der Architektur webbasierter CRS. In Kapitel 4 wird das geplante System erläutert, wobei auch auf dessen zukünftige Einsatzumgebung eingegangen wird. Es werden wichtige Anforderungen an das System herausgearbeitet. Ferner wird begründet, weshalb neuartige Fragetypen nützlich sein können. Das fünfte Kapitel thematisiert die Entwicklung des CRS. Dazu werden zunächst passende Werkzeuge ausgewählt und aufeinander abgestimmt. Weiter werden interessante Punkte des entworfenen Systems und die entstandenen Frageformate vorgestellt. Abschließend werden Tests und Continuous Integration zur Qualitätssicherung aufgezeigt und letztlich wird das Kapitel mit einem kurzen Einblick ins Deployment beendet. Im Anhang findet sich ein Beispiel für die Definition eines Frageformats für das im Rahmen dieser Arbeit entwickelte CRS. Anhand dieses Beispiels wird erklärt, welche Schritte notwendig sind, um dem entstandenen CRS einen Fragetyp hinzuzufügen.

Kapitel 2 Peer Instruction Wie der Physikprofessor Eric Mazur in seinem Buch [11] beschreibt, liegt ein Problem des konventionellen Unterrichts in der Präsentation des Materials. Häufig wird das zu behandelnde Thema direkt aus dem Skript oder aus Fachbüchern übernommen und während des Unterrichts vom Dozent in Form eines Monologs präsentiert. Dabei könnten sich die Teilnehmer auch selbständig in neue Themen einarbeiten, indem sie die Literatur lesen. Da die Hörer während der Lehrveranstaltung passive Rezipienten bleiben, profitieren sie folglich kaum davon, dass sie zu den Unterrichtsstunden kommen. Um die Zeit während des Unterrichts effizienter zu nutzen und so den Studierenden die Konzepte hinter den physikalischen Problemen einfacher begreifbar zu machen, überlegte sich Eric Mazur einen neuen Lehransatz: Peer Instruction. Dabei sollen die Studenten durch eine vom Dozenten gestellte Frage zu Diskussionen in kleinen Gruppen angeregt werden. In diesen Debatten versuchen die Teilnehmer die korrekte Antwort auf die Frage zu finden. Ähnlich der Mäeutik1 sollen die gestellten Fragen die Studierenden gezielt zu einer Erkenntnis – nämlich dem Verständnis des gelehrten Konzepts – führen. Da Studierende den Stoff selbst erst kürzlich erlernt haben, wissen diese noch wo eventuelle Schwierigkeiten lagen. Deshalb fällt es ihnen 1

Lehrmethode von Sokrates, bei dem der Unterrichtete durch gezielte Fragestellung zu

einer gewissen Erkenntnis geführt wird. Auch als „sokratische Methode“ bezeichnet [7].

4

2. Peer Instruction

5

leichter als dem Lehrenden, Verständnisprobleme bei ihren Kommilitonen zu erkennen und diese im Diskurs zu beseitigen. Die diversen Vor- und Nachteile der Lehrmethode sind bereits in zahlreichen Publikationen wie z. B. [5, 8, 11] erläutert, weshalb sich diese Arbeit auf das Konzept und geeignete Fragen für PI beschränkt.

2.1

Konzept

In der Regel werden in herkömmlichen Lehrveranstaltungen neue Themen erst während des Unterrichts angesprochen. Im Gegensatz dazu bereiten sich die Kursteilnehmer bei PI bereits vor der Lehrstunde auf die neuen Inhalte vor. Dazu lesen sie beispielsweise in Fachbüchern oder lernen vom Lehrenden erhaltenes Material. Die Unterrichtsstunden bestehen aus kurzen Wiederholungen der wichtigsten Punkte des Themas, auf die jeweils ein ConcepTest (s. 2.2) folgt. Dabei handelt es sich um eine konzeptionelle, zum Thema passende, kurze Frage, die durch jeden Hörer individuell zu beantworten ist. Anschließend sollen die Teilnehmer ihre Antworten untereinander diskutieren. Eine erneute Abstimmung nach dieser Diskussionszeit führt häufig zu verbesserten Ergebnissen [11]. Die pädagogischen Ziele erreicht eine solche Unterrichtsmethode auf unterschiedlichen „Kanälen“: durch das Fokussieren der Aufmerksamkeit der Studierenden auf die gestellte Frage; durch die Stimulation der kognitiven Prozesse der Teilnehmer während des Suchens nach der korrekten Antwort; durch das gemeinsame Betrachten und Besprechen der Umfrageergebnisse und durch Aussprache von eigenen Ideen und Konfrontation mit den Ideen anderer während des Kurses. Zusätzlich bewegt dieser Prozess die Studenten dazu, sich mit dem Material zu befassen. Er ermöglicht es ihnen dabei, das eigene Verständnis des behandelten Konzepts besser einzuschätzen. Auch dem Dozierenden fällt es dadurch leichter nachzuvollziehen, wie gut die Kursteilnehmer das Material verstehen. Dieses Wissen kann dann genutzt werden um das Lehren und Lernen in nachfolgenden Unterrichtsstunden zu verbessern [1].

2. Peer Instruction

2.2

6

ConcepTest

Der schematische Ablauf einer Lehrstunde im Sinne von PI ist in Abb. 2.1 dargestellt. Begonnen wird der Unterricht nach der PI Methode mit einem Impulsreferat2 des Dozenten, bei dem er das Thema – in das sich die Hörer bereits im Voraus eingearbeitet haben – zusammenfasst. Hier werden wichtige Inhalte wiederholt. Zusätzlich können Experimente vorgeführt werden. Nach diesem Resümee folgt ein ConcepTest. Dazu wird allen Teilnehmern dieselbe Frage gestellt. Für die folgenden zwei Minuten sorgt der Dozierende für absolute Stille um Teamarbeit zu vermeiden, während die Kursteilnehmer individuell versuchen, eine Antwort zu finden. Nun teilen die Studenten dem Lehrenden ihre Ergebnisse mit, wobei nicht festgelegt ist, wie dies geschieht. Hierfür werden in der Regel CRS eingesetzt. Die Verteilung der Stimmen wird allen Teilnehmern bekannt gemacht und kann kurz vom Dozierenden zusammengefasst und analysiert werden. Der weitere Verlauf des Unterrichts hängt von der Anzahl korrekter Antworten ab. Haben mehr als ca. 90 Prozent richtig gestimmt, wird zum nächsten Thema übergegangen. Da bereits genügend Teilnehmer das Konzept verstanden haben ist es nicht notwendig das aktuelle Thema weiter zu erklären. Für den Fall, dass weniger als 40 Prozent der Antworten korrekt waren wiederholt der Dozent die Inhalte nochmal ausgiebig – und kann dabei besonders auf die vorher festgestellten Probleme eingehen. Durch das zielgerichtete Erklären im Falle von Unklarheiten wird dem Auseinanderdriften der Erwartungen des Lehrenden und dem Verständnis der Lernenden vorgebeugt [11]. Im Idealfall sind in etwa 40 bis 90 Prozent der Antworten richtig. Jetzt sollen die Studenten versuchen ihre Kommilitonen von der eigenen Auffassung zu überzeugen – in sogenannten Convince-Your-Neighbour Diskussionen. Dazu erklären die Kommilitonen sich gegenseitig, wie sie zu ihrer Antwort gekommen sind. Die Erklärungen und Begründungen der Teilnehmer 2

Dies ist nach [19] eine Sonderform eines Referats, das die Kerndaten eines Themas

prägnant darstellt und somit eine Grundlage für eine Diskussion im Plenum bietet.

2. Peer Instruction

7

Abbildung 2.1: Ablauf einer Lehrstunde nach Peer Instruction. Basierend auf [15].

enthalten dann idealerweise die Prinzipien, die im Impulsreferat angesprochen wurden. Somit werden Studierende dazu bewegt, ihre Anschauungen, Wahrnehmungen, Annahmen, Erwartungen, Verständnisse und Denkweisen zu artikulieren. Dies ist für die Diskutierenden sehr wichtig, da dabei die wagen, vernebelten, inkonsistenten, teilweise falschen Gedanken zu konkreten Sätze formuliert werden müssen, wodurch Defizite aufgedeckt und beseitigt werden [1]. Der Schlüssel der Lehrmethode liegt folglich darin, dass sich die Studenten über das Thema unterhalten. Nach diesen Diskussionen wird die aktuelle Abstimmung noch einmal wiederholt. Bei der Analyse der Ergebnisse wird sich zeigen, dass die zweite Frage meistens von einer größeren Anzahl an Teilnehmern korrekt beantwortet wurde, als die Erste. Das liegt daran, dass es schwieriger ist die Meinung von jemandem zu ändern, der sich diese aus den richtigen Gründen gebildet hat, als von jemandem der aus den falschen Gründen auf eine falsche Antwort schloss [11]. Um eine möglichst gute Grundlage für Diskussionen zu bieten sind deshalb solche Fragen auszuwählen, bei denen die Anzahl korrekter Antworten typischerweise zwischen 40 und 90 Prozent fällt. Andernfalls wird sich die

2. Peer Instruction

8

korrekte Antwort nicht ausreichend verbreiten, da zu wenige Personen im Auditorium auf diese gekommen sind, oder das Konzept wurde bereits von so vielen Studierenden verstanden, dass von einer weiteren Vertiefung nur ein kleiner Teil profitieren würde.

2.3

Fragen

Diskussionen unter Studierenden sind bei PI, wie gezeigt, vital für den Lernerfolg. Um eine möglichst solide Basis für Diskussionen zu bieten sind „gute“ Fragen essenziell. Das Erstellen qualitativer Fragen ist schwierig und unterscheidet sich von dem Verfassen von Fragen für Prüfungen oder Hausaufgaben [1]. Um Nutzern des PI Ansatzes für physikbezogene Kurse den Einstieg zu erleichtern, erstellte Eric Mazur einen umfangreichen Fragenkatalog, der in dessen Buch Peer Instruction: A Users Manual [11] enthalten ist. Obwohl die Sammlung einen guten Ausgangspunkt bietet, ist diese laut [1] unzureichend, da die darin enthaltenen Fragen von den Lehrpersonen nicht effektiv angewandt werden können, solange diese die Ziele und das Design der Frage nicht kennen. Daher können Lehrende das verborgene Potential der Fragen häufig nicht nutzen oder sabotieren deren Effekt unwissentlich. Um CR-Systeme effektiv einsetzen zu können müssen Lehrende ein Verständnis dafür entwickeln, weshalb Fragen erfolgreich sind oder scheitern, wie Fragen zu evaluieren sind, wie sie selbst Fragen an ihre persönliche Situation und ihre eigenen Ziele anpassen und wie sie solche individuellen Fragen von Grund auf erstellen [1]. Pädagogische Ziele Verwendete Fragen sollten einem expliziten pädagogischen Ziel dienen, wobei damit nicht lediglich das Vermitteln des unterrichteten Materials gemeint ist. Vielmehr sollten Fragen drei Ziele erfüllen: Inhaltliche Ziele, Kognitive Ziele und Metakognitive Ziele [1]. Diese nachfolgend näher erklärten Ziele wurden in [1] für die darin vorgestellte Methode des Unterrichtens Question-

2. Peer Instruction

9

driven Instruction herausgearbeitet. Da diese Methode PI sehr ähnlich ist und ebenfalls CRS verwendet, können diese Ziele, sowie Mechanismen zum Erreichen dieser Ziele, aus [1] übernommen werden: Inhaltliche Ziele (content goals): Das inhaltliche Ziel einer Frage legt fest, welche Teile des unterrichteten Materials vertieft werden sollen. Hier sind speziell die Konzepte, Prinzipien und deren gegenseitige Abhängigkeiten des gelehrten Themas ein guter Ausgangspunkt für erfolgreiche Fragen. Kognitive Ziele (process goals): Diese Ziele bestimmen, welche kognitiven Fähigkeiten die Studierenden anwenden sollen, um die Frage beantworten zu können. Während die inhaltlichen Ziele die Frage „Was wird gelernt?“ beantworten, geben die kognitiven Ziele das „Wie wird gelernt?“ an. Metakognitive Ziele (metacognitive goals): Metakognitive Ziele geben an, welche didaktische Methode und welche Art der Anwendung gelernter Inhalte gefördert werden sollen. Je konstruktiver die metakognitive Perspektive der Studierenden ist, desto besser können diese begreifen was die Dozierenden zu Lehren versuchen. Daher ist es wichtig diese Perspektive zu formen, um so die Unterrichteten auf das anstehende und zukünftige Lernen vorzubereiten. Die aktuelle Auffassung der Wissensweitergabe legt sogar nahe, dass das „Vorbereiten auf zukünftiges Lernen“ das dauerhafteste Ergebnis der derzeitigen Lehre ist. Mechanismen, durch die Fragen ihre Ziele erreichen Allein durch das Stellen einer Frage erzielt diese einen starken Effekt bei den Befragten. So wird deren Aufmerksamkeit auf die Thematik der Frage gelenkt, wodurch beeinflusst wird, worüber die Teilnehmer nachdenken. Weiterhin kann durch gezieltes Design der Frage gesteuert werden, wie die Studierenden über die Thematik nachdenken. Keine Fragestellung kann die Teilnehmer dazu zwingen, einen bestimmten kognitiven Prozess einzuleiten, da mentales Engagement immer freiwillig ist. Jedoch kann das Design einer Frage die Verwendung bestimmter Denkprozesse nahelegen [1]. Ein weiterer und sehr offensichtlicher Mechanismus mit dem CRS ihren

2. Peer Instruction

10

pädagogischen Zweck erfüllen, ist das Verbreiten von Informationen über die Verteilung der studentischen Antworten auf die gestellte Frage. So lernen Studierende die Denkweisen ihrer Kommilitonen kennen und der Dozierende erfährt die Denkweisen seiner Studenten [1]. Die Diskussionen unter Studierenden bei der Erschließung einer Antwort, sowie die Diskussionen zwischen Studierenden und dem Lehrenden bei der Betrachtung der Ergebnisse sind ebenfalls Mechanismen von Fragen, mit dem sie ihre pädagogischen Ziele erreichen können. Bei den Debatten werden Studierende mit unterschiedlichen Auffassungen, Anschauungen, Analysen und Schlussfolgerungen konfrontiert. So müssen diese ihre eigene Meinung gegenüber ihren Diskussionspartnern verteidigen oder diese überdenken. Dadurch wird der Lernerfolg gefördert und das Verständnis des unterrichteten Materials bei den Studierenden gefestigt [1].

2.4

Aufgaben des Classroom Response Systems

Prinzipiell ist für den Einsatz der Lehrmethode Peer Instruction kein CRS notwendig. Der Verzicht auf ein solches System bringt aber Nachteile mit sich, wie z. B. die Begrenzung der Teilnehmerzahl. Daher folgt hier eine Aufzählung der Aufgaben eines CRS für den Einsatz mit PI, geordnet nach dem Zeitpunkt des Einsatzes während einer Unterrichtsstunde. Verbreiten der Frage Häufig ermöglichen webbasierte CRS dem Dozierenden, die Frage zu verbreiten. Andernfalls muss diese mit in die Präsentation eingebunden, an die Tafel geschrieben oder mit Hilfe eines Overheadprojektors verbreitet werden, um sie den Studierenden bekannt zu machen. Jede dieser Methoden hat eigene Nachteile. Das Anschreiben an die Tafel ist zeitaufwändig. Möchte der Dozent die Fragen über einen Overheadprojektor bekannt machen, ist dieser

2. Peer Instruction

11

extra dazu notwendig. Bindet er die Fragen mit in seine Präsentation ein ist er unflexibel gegenüber spontan entstehenden Fragen für ConcepTests. Durch die Verbreitung der Fragen über das CRS bleibt der Dozent flexibel und spart Zeit. Einsammeln und Abzählen der Stimmen Ohne elektronische CRS ist es nicht möglich in kurzer Zeit die Stimmen von vielen Teilnehmern einzusammeln und auszuzählen. Gerade bei Veranstaltungen mit mehreren hunderten Teilnehmern kann sich der Dozent unmöglich in einem angemessenen Zeitrahmen ein akkurates Bild der Meinung des Auditoriums machen. Weiterhin können die Abstimmenden nicht anonym bleiben, wenn per Handzeichen gewählt wird. Da sich manche Hörer weigern, öffentlich abzustimmen, würde der Verzicht auf ein CRS die Teilnehmerzahl weiter einschränken. Präsentation des Ergebnisses Der wohl größte Vorteil, den der Einsatz eines elektronischen CRS mit sich bringt, liegt in der Präsentation der Umfrageergebnisse. Dabei kann das Resultat unverzüglich durch Diagramme und weitere Darstellungsformen visualisiert werden. Der Dozent hat die Möglichkeit die Ergebnisse den Kursteilnehmern zu zeigen. Jeder Studierende ist somit besser dazu in der Lage das eigene Verständnis des unterrichteten Materials einzuschätzen, indem er seine Antwort mit dem Gesamtergebnis vergleicht.

Wie gezeigt sind CRS ein unverzichtbares Mittel, um die PI-Philosophie erfolgreich umzusetzen. Im folgenden Kapitel wird genauer auf die Systeme eingegangen.

Kapitel 3 Classroom Response Systems In den 1950er-Jahren entstanden elektronische CRS unabhängig von dem zu der Zeit noch nicht existierenden Lehransatz Peer Instruction. Sie wurden ursprünglich für die amerikanische Luftwaffe entwickelt und dort für Weiterbildungen der Rekruten eingesetzt. Damals wie heute bestand ihre Hauptaufgabe darin, die Stimmen für Single-Choice-Fragen einzusammeln und auszuwerten. Etwa 10 Jahre später wurden CRS zum ersten Mal in der Hochschullehre verwendet [9]. Neben PI gibt es heutzutage viele weitere Anwendungsgebiete für CRS, wie z. B. Class-wide Discussions [4].

3.1

Kategorien

Die Systeme durchliefen seit ihrer Entstehung einige technologische Entwicklungsschritte. Der Grundaufbau blieb dabei allerdings immer gleich. Die Teilnehmer verwenden ein Eingabegerät mit dem sie für eine Antwortmöglichkeit stimmen können. Diese Apparate bezeichnet man als „Clicker“. An einer zentralen Stelle werden die Stimmen gesammelt, ausgewertet und visualisiert. In modernen Systemen übernimmt diese Aufgabe beispielsweise ein Webserver, in elektronischen Systemen ein Empfänger am Laptop des Dozenten. Die konkrete Art der Umsetzung eines CRS kann in die Kategorien Nicht-Technisch 3.1.1, Elektronisch 3.1.2 und Softwarebasiert 3.1.3 eingeteilt werden.

12

3. Classroom Response Systems

3.1.1

13

Nicht-Technisch

Bei den nicht-technischen Systemen handelt es sich meiner Auffassung nach nicht um CRS im engeren Sinn. Die Teilnehmer stimmen hier durch Handzeichen oder farbige Flash Cards ab. Da es keine zentrale Auswertungseinheit gibt, muss der Dozent das Auszählen der Stimmen selbst übernehmen. Daher eignet sich diese Methode nur für sehr kleine Gruppen. Ein entscheidender Nachteil ist hier, dass die Abstimmenden nicht anonym bleiben können. Da manche Studenten ihre Antwort eventuell nicht öffentlich preisgeben wollen, bleibt diesen nichts anderes übrig, als sich zu enthalten. Folglich schränken Systeme dieser Kategorie die Teilnehmerzahl ein und schließen Studenten, die anonym bleiben möchten, von der Teilnahme aus. Deshalb wird diese Methode in der Praxis kaum eingesetzt.

3.1.2

Elektronisch (Hardwarebasiert)

Diese Kategorie zeichnet sich dadurch aus, dass die Kursteilnehmer zu Beginn einer Veranstaltung einen Clicker erhalten1 , den sie fortan zum Abstimmen verwenden. Ein solches Gerät ist in Abb. 3.1 dargestellt. 1985 wurde mit „ClassTalk“ ein einfach nutzbares elektronisches CRS vorgestellt. Hierbei waren alle Clicker mit einem zentralen Rechner im Hörsaal verkabelt [4]. Aufgrund der Tatsache, dass für kabelgebundene CRS eigens ein Saal präpariert werden muss, entwickelten sich dynamischere Systeme. Die Eingabegeräte in diesen fortgeschrittenen Lösungen verwenden entweder infrarot- oder funkbasierte Übertragungstechniken. Da der am Dozentenrechner angeschlossene Empfänger ebenfalls portabel ist, sind diese drahtlosen Systeme unabhängig vom eingesetzten Hörsaal. Ein Nachteil elektronischer CRS ist, dass jeder Student einen eigenen Clicker benötigt. Daraus ergeben sich für Lehrveranstaltung mit sehr vielen Teilnehmern hohe Anschaffungskosten und weitere Probleme, wie z. B. den Ausschluss von Abstimmungen 1

Studenten müssen an manchen Hochschulen selbst einen Clicker erwerben. Es ist eben-

falls möglich, dass ein Clicker pro Veranstaltung zu Beginn gegen ein Pfand ausgegeben wird, den die Studierenden das gesamte Semester über behalten.

3. Classroom Response Systems

14

Abbildung 3.1: Ein kabelloser Clicker bei dem eine aus sechs möglichen Antworten (A-E) ausgewählt werden kann. Bildquelle [16].

von Studierenden, deren Clicker nicht funktionsfähig ist, geklaut wurde oder nicht mitgebracht wurde [2]. Ebenfalls zu dieser Kategorie zählen manche Publikationen die softwarebasierten CRS, obwohl diese keine physikalischen Clicker erfordern. Um speziell elektronische CRS zu bezeichnen und dabei softwarebasierte Lösungen auszunehmen, wird dann der Begriff „hardwarebasierte CRS“ verwendet.

3.1.3

Softwarebasiert

Um diesen Problemen auszuweichen findet derzeit ein Übergang zu softwarebasierten CRS statt. Die Anschaffungskosten sind hier deutlich geringer, da den Teilnehmern ermöglicht wird, ihre privaten, mobilen, internetfähigen

3. Classroom Response Systems

15

Endgeräte als Clicker zu verwenden2 , wodurch die Hardwarekosten entfallen. Das Sammeln und Auswerten der Stimmen übernimmt ein Server. Die Ergebnisse kann der Dozent je nach System über einen Browser, ein Programm oder direkt in der Präsentation anzeigen. Die einzigen Voraussetzung bleiben so, dass der Raum über einen kabellosen Internetzugang verfügt und die Teilnehmer ihre geladenen Geräte mitbringen. Die softwarebasierten CRS teilen sich in weitere Unterkategorien auf. Es wird dabei unterschieden, wie die Systeme realisiert sind. Mobile Apps Um ein solches System einsetzen zu können, müssen zunächst alle Studenten eine Anwendung aus dem zu ihrem Gerät passenden App Store laden. Dies hat zur Folge, dass die Entwickler des CRS für jeden App Store ein eigenes Programm schreiben müssen (Native Apps), oder durch Multi-Plattform Apps versuchen möglichst viele verschiedene Marktplätze abzudecken. Um Laptops ebenfalls als Clicker verwenden zu können, muss zusätzlich ein eigenes Programm für jedes gängige Betriebssystem entwickelt werden. Alternativ kann es auch die Möglichkeit geben, über eine Internetseite abzustimmen. Solche Systeme erfordern folglich einen enormen Programmieraufwand, da dieselben Funktionen mehrfach implementiert werden müssen. Umständlich ist hier ebenfalls, dass alle Teilnehmer zunächst die App herunterladen und installieren müssen, bevor sie an Abstimmungen teilnehmen können. Ein in der Praxis häufig eingesetztes Beispiel für ein solches System ist eduVote3 . Webbasiert Webbasierte CRS vermeiden diesen hohen Programmieraufwand, da die Internetanwendung nur ein einziges Mal geschrieben werden muss und anschließend von allen Geräten mit Webbrowser verwendet werden kann. Die Brow2

Die Möglichkeit mobile, private Endgeräte in einem schulischen oder dienstlichen

System einzusetzen wird als „Bring-Your-Own-Device“ (BYOD) bezeichnet. 3 http://eduvote.de/

3. Classroom Response Systems

16

ser mobiler Geräte werden immer leistungsfähiger und benutzerfreundlicher. Durch die fortschreitende Standardisierung der Funktionen bieten diese eine gute Basis für die Nutzung als Eingabegeräte. Ebenfalls ist das System aufgrund des webbasierten Ansatzes installationslos nutzbar. Dies ermöglicht im Falle eines Ausfalls des Dozentenrechners den reibungslosen Umstieg auf ein anderes Gerät. Durch den webbasierten Charakter ist das System überall dort einsetzbar, wo kabelloser Internetzugang besteht. Spezielle Techniken des Webs ermöglichen es ebenfalls, einen barrierefreien Zugang bereitzustellen. Besonders große Gruppen (mehr als 1000 Teilnehmer) können durch webbasierte CR-Systeme kostengünstig und mit geringem Verwaltungsaufwand unterstützt werden.

3.1.4

Hybride Lösungen

In der Praxis treten auch hybride Lösungen auf. Diese passen in mehrere der genannten Kategorien oder ermöglichen den Studenten über zuvor nicht beschriebene Wege ihre Stimme einzureichen. So lässt sich bei Shakespeak 4 beispielsweise über SMS oder Twitter abstimmen. Systeme wie iclicker 5 kombinieren den elektronischen mit dem softwarebasierten Ansatz, wodurch mit hardwarebasierten Clickern und mit privaten mobilen Endgeräten an derselben Abstimmung teilgenommen werden kann.

3.2

Marktübersicht

In [10] wurde eine Marktanalyse durchgeführt, die softwarebasierte, hardwarebasierte und hybride Lösungen untersucht. Diese ergab, dass zum Zeitpunkt der Untersuchung kein System der 36 betrachteten Anbieter alle nachfolgend zusammengefassten Anforderungen erfüllte: 1. Nutzbarkeit Das System ist für Studierende und Lehrende intuitiv nutzbar. Um es zu bedienen ist es nicht notwendig eine Anleitung zu 4 5

https://www.shakespeak.com/ http://www1.iclicker.com/

3. Classroom Response Systems

17

lesen. Das System ermöglicht es zudem, problemlos auf Änderungen während der Lehrveranstaltung zu reagieren, indem z. B. eine Frage übersprungen wird. 2. Skalierbarkeit Da Lehrveranstaltungen mit mehr als 1000 Teilnehmern gängig sind, muss das System hoch skalierbar sein. 3. Kosten Das System ist für Dozenten und Studenten kostenlos nutzbar. 4. Installation Um das System zu nutzen ist es weder für Dozierende, noch für Studierende erforderlich, ein Programm auf ihren Geräten zu installieren. 5. Betriebssystem Das System ist für alle Anwender unabhängig vom genutzten Betriebssystem einsetzbar. Um eine Lösung zu schaffen, die allen Anforderungen gerecht wird, wurde PINGO an der Universität Paderborn entwickelt. Es gehört zur Kategorie der webbasierten CRS. Die Wahl eines webbasierten Ansatzes wurde getroffen, da solche Systeme die einzige Möglichkeit sind, alle der genannten Anforderungen zu erfüllen6 . Deshalb wurden für die Marktübersicht (Tab. 3.1) lediglich webbasierte CR-Systeme betrachtet und auf die folgenden Kriterien untersucht: 1. Mobile First / Responsive Webdesign (MF) Das Layout des Programms ist an die durch kleine Displays der mobilen Endgeräte gegebenen Herausforderungen angepasst. 2. Peer Instruction Kompatibilität (PIK) Das System kann problemlos für Peer Instruction verwendet werden. Insbesondere wurde geprüft, ob sich Fragen einfach wiederholen lassen und ob deren Reihenfolge und Ablauf durch den Lehrenden bestimmbar ist7 . Ebenfalls dürfen Umfrageergebnisse erst gezeigt werden, nachdem die Teilnehmer abgestimmt haben, da diese sonst in ihrem Abstimmungsverhalten beeinflusst werden könnten – indem sie sich beispielsweise der Mehrheit anschließen. 6

Hardwarebasierte Systeme sind aufgrund der Clicker immer mit Hardwarekosten ver-

bunden. Softwarebasierte CRS mit mobilen Apps sind immer betriebssystemabhängig. 7 In vielen Systemen wird diese Eigenschaft als „Teacher-paced“ bezeichnet.

3. Classroom Response Systems

18

3. Anonyme Teilnehmer (AT) Studenten können ohne vorhergehende Registrierung an Umfragen teilnehmen. Ihre Stimmen bleiben anonym. 4. Kommerziell (K) Das System ist kommerziell. 5. OpenSource (OS) Das System ist quelloffen. 6. Anzahl Fragetypen (#F) Gibt die Anzahl der möglichen, logisch unterschiedlichen Fragetypen an. Sind beispielsweise Single-Choice-Fragen möglich, wurden Ja-Nein-Fragen nicht als eigener Fragetyp gewertet, da sich diese ebenfalls durch eine Single-Choice-Frage realisieren lassen. Tabelle 3.1: Auswahl webbasierter CRS. Basierend auf [9, 10] und eigener Recherche. Abkürzungen in dieser Tabelle: Mobile First (MF), Peer Instruction Kompatibilität (PIK), Anonyme Teilnehmer (AT), Kommerziell (K), OpenSource (OS), Anzahl Fragetypen (#F). Produktname

MF

PIK

AT

K

OS

#F

ARSnova

Ja

Ja

Ja

Nein

Ja

3

GoSoapBox

Ja

Nein

Ja

Ja

Nein

1

inVote

Nein

Nein

Ja

Nein

Nein

3

Learning Catalytics

Ja

Ja

Nein

Ja

Nein

13

Let’s Feedback

Ja

Nein

Ja

Ja

Nein

3

PINGO

Ja

Ja

Ja

Nein

Ja

4

Poll Everywhere

Nein

Ja

Ja

Ja

Nein

3

QuestionPress

Ja

Ja

Ja

Ja

Nein

7

Socrative2

Ja

Nein

Ja

Geplant

Nein

3

Von den untersuchten neun Systemen entsprechen lediglich drei Systeme (ARSnova, PINGO, QuestionPress) den Kriterien Mobile First, Peer Instruction Kompatibilität und Anonyme Teilnehmer. Es zeigt sich weiterhin, dass die Anzahl an logisch unterschiedlichen Fragetypen insgesamt gering ausfällt. Das einzige System mit einer breiten Auswahl ist Learning Catalytics, das 13 differierende Formate bereitstellt. Der am häufigsten verfügbare Fragetyp ist Single Choice (s. Abschn. 3.3.1) – er ist in jedes System integriert8 . Bis 8

QuestionPress und Socrative2 unterstützen lediglich eine Sonderform des Fragetyps bei

dem die Antwortoptionen (Ja–Nein oder Wahr–Falsch) unveränderlich vorgegeben sind.

3. Classroom Response Systems

19

auf GoSoapBox unterstützen alle Systeme Freitext-Fragen (s.Abschn. 3.3.3), die somit der zweithäufigste Fragetyp sind. Fünf Systeme (ARSnova, Learning Catalytics, PINGO, QuestionPress, Socrative2) bieten Fragen des Typs Multiple Choice (s. Abschn. 3.3.2). Ebenfalls fünf Systeme (inVote, Learning Catalytics, Let’s Feedback, PINGO, QuestionPress) unterstützen numerische Fragen (s. Abschn. 3.3.4).

3.3

Gängige Fragetypen

Der Begriff Fragetyp (auch Frageformat) umfasst in dieser Arbeit: wie die Frage vom Dozierenden erstellt wird; durch Angabe welcher Informationen Teilnehmer die Frage beantworteten und in welchem Format die Abstimmungsergebnisse dem Dozierenden präsentiert werden. In den untersuchten CR-Systemen finden sich häufig dieselben Fragetypen. Das liegt einerseits vermutlich daran, dass sich webbasierte CRS aus hardwarebasierten Systemen entwickelten. Die Clicker der hardwarebasierten CRS lassen häufig nur simple Eingaben zu, weshalb deren Frageformate sehr eingeschränkt sind. Bestehende webbasierte CRS übernahmen großteils lediglich die bereits etablierten Fragetypen ohne die Möglichkeiten der funktionsreicheren Eingabegeräte auszuschöpfen. Andererseits sind die nachfolgend aufgezählten Fragetypen so häufig vertreten, da sie interdisziplinär einsetzbar sind. Es folgt nun eine kurze Erklärung gängiger Frageformate.

3.3.1

Single Choice

Für dieses Format legt der Dozent eine Frage fest und gibt eine Reihe von Antwortmöglichkeiten vor. Um abzustimmen wählen die Teilnehmer genau eine der vorgegebenen Optionen aus. Manche Systeme (z. B. Learning Catalytics) bezeichnen den Single-Choice-Fragetyp als „Multiple Choice“. Den tatsächlichen Multiple-Choice-Fragetyp nennen diese „Many Choice“.

3. Classroom Response Systems

3.3.2

20

Multiple Choice (Many Choice)

Dieser Fragetyp gleicht dem Single-Choice-Fragetyp. Unterschiedlich ist, dass die Studenten für eine oder mehrere Antwortoptionen stimmen können.

3.3.3

Freitext

Hier antworten die Teilnehmer in eigenen Worten auf eine Aufgabenstellung oder Frage des Dozenten. Dargestellt wird das Ergebnis oftmals durch Word Clouds oder eine Liste der häufigsten Wörter.

3.3.4

Numerisch

Bei diesem Fragetyp sind die Teilnehmer aufgefordert eine Zahl anzugeben. Dabei kann es sich beispielsweise um die Abschätzung eines Geldbetrags oder das Ergebnis einer mathematischen Aufgabe handeln.

3.4

Architektur webbasierter Lösungen

In diesem Abschnitt werden bestehende webbasierte CRS hinsichtlich ihrer Umsetzung untersucht. Von den in der Marktübersicht (3.2) gelisteten Systemen sind ARSnova und PINGO quelloffen. Zusätzlich existieren für beide Systeme Architekturbeschreibungen (s. [10, 12, 20]), weshalb deren Aufbau detailliert nachvollzogen werden kann. Diese eignen sich daher besonders gut, um einen Einblick in den Entwicklungsstand webbasierter CRS zu gewinnen. Von Vorteil ist ebenfalls, dass beide Systeme die Anforderungen Mobile First, Peer Instruction Kompatibilität und Anonyme Teilnehmer erfüllen, in der Praxis häufig eingesetzt werden und unterschiedliche Architekturen verwenden. ARSnova Das von der Technischen Hochschule Mittelhessen stammende ARSnova wurde zunächst als Rich Internet Application (RIA) entwickelt. Als Framework

3. Classroom Response Systems

21

wurde dabei Sencha Touch 9 eingesetzt, wodurch die Nutzer auf WebKitBrowser eingeschränkt wurden. Weiterhin gab es erhebliche Sicherheitslücken, da die Clients direkt mit der Datenbank kommunizierten. Somit war es Angreifern potenziell möglich unter Kenntnis einiger anwendungsspezifischer Interna das System gezielt zu manipulieren [20]. Aufgrund dieser Probleme wird für ARSnova 2 derzeit eine Reimplementierung durchgeführt, die im Nachfolgenden betrachtet wird. Für ARSnova 2 verlagerten die Entwickler die Geschäftslogik wieder auf den Server (Apache Webserver mit Apache Tomcat Servlet-Container). Zur Echzeitkommunikation zwischen Client und Server werden WebSockets (durch Socket.IO10 ) eingesetzt. Sämtliche Kommunikation mit der Server-Anwendung ist über das HTTP abwickelbar, da eine durchgängige und strukturierte REST-API bereitsteht. Es ist somit möglich beliebige Client-Anwendungen an den Server anzubinden, wodurch beispielsweise ein eigener barrierefreier Zugang entwickelt werden kann [20]. Clientseitig wird das Dojo Framework 11 genutzt, mit dessen Grafikfunktionen ebenfalls Umfrageergebnisse dargestellt werden. Als Datenbank dient die NoSQL-Lösung Apache CouchDB. PINGO PINGO wird an der Universität Paderborn entwickelt und ist wie in den aus dessen Entwicklung entstandenen Publikationen [9, 10, 12] beschrieben aufgebaut: Serverseitig verwendet es das Ruby on Rails 12 Framework auf einem nginx13 Webserver. Um möglichst viele echt gleichzeitige Benutzer zu ermöglichen wird zusätzlich Node.js 14 eingesetzt, das mit Hilfe von WebSockets (ebenfalls durch Socket.IO) mit den Clients kommuniziert. Als Datenbank 9 10 11 12 13 14

http://www.sencha.com/products/touch/ http://socket.io/ http://dojotoolkit.org/ http://www.rubyonrails.org http://nginx.org/ http://nodejs.org/

3. Classroom Response Systems

22

und Speicher dienen MongoDB 15 und redis 16 . Zur Visualisierung der Umfrageergebnisse wurde eine modifizierte Version von Chart.js 17 erstellt.

Es zeigt sich, dass beide Systeme unterschiedliche Architekturen verwenden. Während ARSnova 2 mehrere Apache-Produkte einsetzt, kombiniert PINGO eine Vielzahl von Frameworks unterschiedlicher Entwickler. Die beiden Systeme haben dennoch Gemeinsamkeiten: Socket.IO zur Realisierung der Echtzeit-Kommunikation und eine NoSQL-Datenbank zur Persistierung der Daten.

15 16 17

http://www.mongodb.org/ http://redis.io/ http://www.chartjs.org/

Kapitel 4 Geplantes System Das in dieser Arbeit entwickelte System soll sowohl zuvor nicht dagewesene Fragetypen bereitstellen und bestehende Frageformate erweitern, als auch intuitiv und unter hoher Last bedienbar sein. Genauer wird das unter dem Namen Merian 1 entstehende CRS in diesem Kapitel erklärt.

4.1

Konzeption

CR-Systeme können mit unterschiedlichen didaktischen Methoden (z. B. Peer Instruction [11], Question-driven Instruction [1]) genutzt werden. Merian soll speziell für den Einsatz von Peer Instruction ausgelegt sein. Geplant ist, dass der Dozierende die Web-Anwendung auf einem an einen Projektor angeschlossenen Laptop aufruft. Das System wird als Verteiler der Aufgabenstellung und der Antwortmöglichkeiten dienen. Diese werden auf der Allgemein als „Fragestrom“ bezeichneten Seite erscheinen, auf die Teilnehmer durch Scannen des auf dem Projektor von der Anwendung angezeigten QR-Codes oder durch manuelle Eingabe der URL gelangen. Sie erhalten automatisch die jeweils aktuelle Frage mit dem Antwortformular auf ihr Gerät, wozu ein Push-Mechanismus zu implementieren ist. Die Umfrageergebnisse werden ausschließlich auf dem Dozentenrechner angezeigt und sind 1

http://www.merian.io

23

4. Geplantes System

24

Trainer

Server

Student

Startet Seminar QR-Code & URL des Fragestroms

Zeigt URL den Studierenden Betritt Fragestrom loop

Beginnt Abstimmung Zeigt Frage & Antwort-Formular

Zeigt Frage über Projektor Antwortet Zeigt neue Anzahl Stimmen Versteckt Frage & Antwort-Formular Beendet Abstimmung Zeigt Warteseite Ergebnisse der Abstimmung

Zeigt Ergebnisse über Projektor Beendet Seminar Zeigt Seminarende

Abbildung 4.1: Geplanter Ablauf eines Seminars.

somit auf dessen Wunsch über den Projektor allen Studierenden ersichtlich. Genauer stellt Abb. 4.1 den Ablauf dar. Ein möglicher, aus dem Sequenzdiagramm nicht ersichtlicher Schritt ist die Anmeldung eines oder mehrerer Studierender am Fragestrom des Dozierenden während bereits eine Abstimmung stattfindet oder zu jedem anderen Zeitpunkt zwischen Start und Ende des Seminars. Die Umfrageergebnisse bereits abgeschlossener Lehrveranstaltungen sollen dauerhaft gespeichert für den Veranstalter einsehbar bleiben, damit dieser daraus Erkenntnisse ziehen kann, welche Fragen besonders gut geeignet waren und welche Fragen für künftige Veranstaltungen geändert werden sollten.

4. Geplantes System

4.2

25

Umgebung

Geplant ist, dass jede Bildungseinrichtung eine eigene Instanz des Systems einsetzt. Dies ermöglicht eine sehr individuelle Konfiguration pro Hochschule. Standardmäßig läuft jede Instanz des Systems auf einem eigenen Server der Amazon Elastic Compute Cloud (Amazon EC2)2 und verwendet eine Datenbank eines MongoDB-as-a-Service-Anbieters, wie z. B. MongoHQ3 . Sollte eine Hochschule wünschen, dass die Daten aus Datenschutzgründen nur auf Servern im Landesinneren oder auf hochschulinternen Servern verarbeitet werden, ist dies durch die variable Konfiguration umsetzbar. Ebenfalls garantiert dieser Ansatz den Hochschulen ihre eigenen Ressourcen, da diese nicht mit anderen Bildungseinrichtungen geteilt werden müssen. Durch den Einsatz strikt getrennter Datenbanken wird die Sicherheit erhöht, da die Daten unterschiedlicher Hochschulen nicht vermischt werden. Da das Einrichten einer eigenen Instanz pro Hochschule initialen Aufwand erfordert, kann für einen schnellen Start, zu Demonstrationszwecken oder für individuelle Personen die nicht an einer Hochschule arbeiten zusätzlich eine allgemein zugängliche Instanz betrieben werden, die sich diese dann teilen.

4.3

Anforderungen

Aus den in 3.2 und in [10] genannten Kriterien gehen einige Anforderungen hervor, denen das System entsprechen muss, um praxistauglich zu sein. Neben diesen sind nachfolgend weitere durch Brain-Storming erarbeitete Anforderungen genannt. Viele dieser Anforderungen erfüllt das System bereits durch die webbasierte Umsetzung. Es ist bei der Entwicklung in diesen Fällen darauf zu achten, dass die Erfüllung jener Anforderungen nicht gebrochen wird. 2 3

https://aws.amazon.com/de/ec2/ http://www.mongohq.com/

4. Geplantes System

26

Ohne Installation nutzbar Das System muss ohne Installation von Studierenden und Dozierenden verwendet werden können [10]. So ist das System bereits in der ersten Stunde ohne Vorbereitung der Studenten einsetzbar. Dies spart wertvolle Unterrichtszeit, da auch keine Installationsschritte erklärt werden müssen. Des Weiteren kann der Dozierende auf diese Art während der Lehrveranstaltung problemlos den eingesetzten Laptop wechseln (im Falle eines Ausfalls) und auf einem anderen Gerät an genau derselben Stelle weitermachen – auch die Teilnehmer müssen sich nicht erneut am Fragestrom anmelden. Geringer Konfigurationsaufwand Das System soll mit möglichst geringer vorhergehender Konfiguration einsetzbar sein [10]. Die verwendeten Clicker bzw. mobilen Endgeräte sollen nicht vorher den Studenten zugewiesen werden müssen. Diese sollen ohnehin anonym abstimmen können. Weiter sollen eventuell anfallende Lizenzgebühren die Studierenden nicht davon abhalten, das System unverzüglich einzusetzen, indem sie sich beispielsweise zunächst authentifizieren müssen. Kosten Das System darf nicht mit steigender Teilnehmerzahl teurer werden, da es sonst für Kurse mit sehr vielen Teilnehmern aufgrund zu hoher Anschaffungskosten nicht einsetzbar ist. Geringer Verwaltungsaufwand Bei der Verwendung hardwarebasierter CRS erhalten Studierende an manchen Hochschulen zu Beginn des Semesters die Clicker gegen ein Pfand. Es ist somit erforderlich zu protokollieren, welcher Studierende bereits einen Clicker erhalten hat. Die Instandhaltung der Geräte bedarf ebenfalls einem vermeidbaren Zusatzaufwand. Um diese zeitintensiven Tätigkeiten zu meiden, soll das System mit möglichst geringem Verwaltungsaufwand einsetzbar sein.

4. Geplantes System

27

Skalierbarkeit Da Seminare mit über 1000 Teilnehmern gerade in Einführungsveranstaltungen (bei denen PI besonders wirksam ist) vorkommen, soll das System sehr viele simultane Teilnehmer bedienen können [10]. Mobile First Da die Studierenden das entstehende CRS voraussichtlich hauptsächlich mit ihren Smartphones nutzen werden, muss dessen Design und Benutzung speziell an kleine Displays und niedrige Auflösungen angepasst sein. Andere Teilnehmer werden das System mit Geräten, die über größere Displays verfügen nutzen (Laptop, Tablet), weshalb das Design entsprechend skalieren muss. Unterbrechungsfreies Antworten Teilnehmer sollen sowohl die Fragestellung, als auch die Antwortoptionen auf ihrem Gerät sehen können. So ist es möglich das System gänzlich ohne Projektor zu verwenden. Ebenfalls soll die kompakte und ganzheitliche Darstellung der Frage zusammen mit den Antworten auf demselben Gerät die Ablenkung durch einen andernfalls notwendigen, ständigen Wechsel des Blicks zwischen der am Beamer präsentierten Frage und der lokal am eigenen Gerät angezeigten Antwortoptionen senken. Unterstützt Vielzahl an Geräten Hardwarebasierte CRS haben den Vorteil, dass jeder Student der über einen Clicker verfügt, an der Abstimmung teilnehmen kann. Um eine ähnlich hohe Abdeckung mit einem webbasierten Ansatz zu erreichen ist es einerseits notwendig, dass viele Studierende ein internetfähiges Gerät mitführen. Andererseits muss das System mit der Vielfalt an unterschiedlichen Browsern in diversen Versionen dieser Geräte zurechtkommen. Auch ältere Geräte müssen noch ausreichend unterstützt werden. Hier ist es wichtig ein angemessenes

4. Geplantes System

28

Verhältnis zu finden, bei dem genügend Endgeräte unterstützt werden und dennoch gängige Features der Webtechnik einsetzbar sind. Intuitive Bedienbarkeit Das System soll sowohl für Dozenten als auch für Studenten ohne Einweisung bedienbar sein. Es soll nicht notwendig sein, zunächst eine Anleitung zu lesen [10]. Interaktionsarme Bedienbarkeit Auf Smartphones ist die Bedienung von Webseiten häufig mühsam. Daher soll das System so viele Schritte wie möglich automatisch übernehmen. Beispielsweise kann die Eingabe der Internetadresse vermieden werden, indem ein QR-Code angezeigt wird. Neue Fragen des Dozentenstroms sollen nach der ursprünglichen Anmeldung automatisch auf den Geräten der Studierenden angezeigt werden. PI Kompatibilität Das System soll besonders auf die Anwendung von Peer Instruction zugeschnitten sein. Dazu ist es beispielsweise wichtig, dass Abstimmungen sehr leicht wiederholt werden können. Zusammenfassung Die sich ergebenden Anforderungen sind in Tab. 4.1 zusammengefasst.

4.4

Fragetypen

Die Effizienz von PI hängt maßgeblich von der Qualität der gestellten Fragen ab [1]. Diese sollten auf das grundlegende Verständnis abzielen, möglichst viele Teilnehmer ansprechen und eine gute Grundlage für Diskussionen im

4. Geplantes System

29

Tabelle 4.1: Zusammenfassung der Anforderungen. Anforderung Ohne Installation nutzbar Geringer Konfigurationsaufwand Kosten Geringer Verwaltungsaufwand Skalierbarkeit Mobile First Unterbrechungsfreies Antworten Unterstützt Vielzahl an Geräten Intuitive Bedienbarkeit Interaktionsarme Bedienbarkeit PI Kompatibilität

Plenum bieten. Wie bereits in 3.3 erwähnt und aus Tab. 3.1 ersichtlich beschränken sich gängige CRS häufig auf wenige, meist ähnliche Frageformate. Diese limitierte Auswahl an Fragetypen erschwert die Suche nach geeigneten Fragen weiter. Daher soll das entstehende System neuartige Frageformate bereitstellen um es Dozierenden zu erleichtern, geeignete Fragen zu finden. Als Nebeneffekt bietet eine Vielzahl an Frageformaten den Teilnehmern mehr Abwechslung. Die Fragetypen der in der Marktübersicht (s. 3.1) untersuchten CRS sind, abgesehen von den in Learning Catalytics 4 bereitgestellten Formaten, alle interdisziplinär einsetzbar. Durch die Schaffung von zusätzlichen domänengebundenen Frageformaten lassen sich bestimmte Konzepte der jeweiligen Disziplin besser beleuchten. Beispielsweise gibt es in Learning Catalytics das Frageformat „Direction“, bei dem Studierende den Richtungsvektor einer Kraft auf einer Zeichnung eintragen. Dieser ist besonders nützlich für die Physik. Die unter 2.3 gezeigten inhaltlichen, kognitiven und metakognitiven Ziele können die bei PI gestellten Fragen durch die ebenfalls in 2.3 erläuter4

https://learningcatalytics.com/

4. Geplantes System

30

ten Mechanismen erreichen. Präziser werden dafür in [1] einige Taktiken zur Umsetzung der Mechanismen genannt, die bei der Erstellung, Auswahl und Anpassung der Fragen zu beachten sind. Durch eine Vielzahl an verfügbaren Fragetypen können die jeweiligen Taktiken einfacher und effizienter umgesetzt werden. Eine nicht umfassende Auswahl der Taktiken die besonders durch neuartige Frageformate verbessert angewendet werden können, sind nachfolgend – zusammen mit kurzen Beispielen wie dies geschehen könnte – aufgelistet: Taktiken zur Fokussierung der Aufmerksamkeit und zur Erhöhung des Bewusstseins Removing nonessentials: Das Verzichten auf unnötige Informationen ist eine allgemeine, offensichtliche und häufig nicht befolgte Taktik um die studentische Aufmerksamkeit zu fokussieren [1]. Durch den Einsatz domänenspezifischer oder genau auf die Problemstellung angepasster Frageformate können potentielle Ablenkungen minimiert werden. Ein Beispiel hierfür ist das zuvor genannte „Direction“-Frageformat aus Learning Catalytics. Da Studierende direkt den Richtungsvektor der Kraft eintragen, wird die Aufmerksamkeit auf diesen gelenkt. Compare and contrast: Hier wird die Aufmerksamkeit der Teilnehmer speziell auf die Unterschiede zweier Situationen konzentriert, indem sie diese vergleichen sollen. Eine Möglichkeit diese Taktik umzusetzen ist es, den Teilnehmern eine Aufgabe zu stellen, bei der verschiedene Situationen beschrieben werden (z. B. unterschiedliche aber ähnliche Setups eines Experiments). Um die Aufgabe zu lösen sollen die Befragten die unterschiedlichen Situationen dann kategorisieren oder ordnen [1]. Somit sind Frageformate die das Ordnen und Kategorisieren von Dingen ermöglichen hilfreich, um diese Taktik umzusetzen.

4. Geplantes System

31

Taktiken zur Stimulierung kognitiver Prozesse Interpret representations: Viele Studierende hängen stark an den algebraischen Darstellungen physikalischer Konzepte, Abhängigkeiten und Situationen. Sie wissen den Mehrwert zusätzlicher „alternativer“ Darstellungen nicht zu schätzen [1]. Deshalb können Fragen dieser Taktik die Studierenden dazu bewegen, bereits bekanntes Wissen in anderen Darstellungsformen neu zu erfahren und sich somit vom notorischen Denken in Formeln zu lösen. Beispielsweise könnte eine Frage so gestellt sein, dass die Studierenden wichtige Informationen zur Lösung der Aufgabe aus einem Graphen auslesen müssen, anstatt diese textuell zu erhalten. Auch das Ergebnis könnten die Teilnehmer dann wieder in den Graph eintragen. Dies bringt die Lernenden dazu, auch andere Darstellungsformen derselben Informationen wertzuschätzen. Constrain the solution: Durch das Beschränken der Lösungsmöglichkeiten durch Verbieten oder Vorgeben spezieller Ansätze (z. B. „Lösen Sie geometrisch“) können die Studierenden zum Bedenken alternativer Lösungswege gebracht werden [1]. So könnte ein Frageformat, bei dem Studierende Graphen anfertigen können, dazu genutzt werden, um beispielsweise den Satz des Pythagoras anzuwenden, ohne auf dessen mathematische Formel zurückzugreifen. Reveal a better way: Bei dieser Taktik wird den Studierenden zunächst eine Aufgabe gestellt, die diese wahrscheinlich mit einer vorhersehbaren, korrekten aber dennoch suboptimalen Lösung beantworten. Anschließend kann der Dozierende eine kürzere, elegantere Lösungsmöglichkeit vorstellen. Diese Taktik ist mit standardmäßigen Single- bzw. Multiple-Choice-Fragen kaum zu realisieren, da dabei alle Antwortoptionen von Anfang an verbreitet werden müssen. Ein passendes Frageformat hierfür wäre beispielsweise, dass die Studierenden dazu aufgefordert werden einen Algorithmus zu vervollständigen indem Sie die Lücken eines vorgegebenen Code-Skeletts ausfüllen. Nach der Präsentation der Ergebnisse kann der Lehrende dann die elegantere Lösung bekannt geben.

4. Geplantes System

32

Taktiken zur prägenden Nutzung der erhaltenen Antworten Answer choices reveal likely student difficulties Wie in 2.3 bereits erläutert besteht ein Mechanismus, durch den Fragen ihre pädagogischen Ziele erreichen können, aus dem gemeinsamen Betrachten der Abstimmungsergebnisse durch die Teilnehmer und die Lehrperson. Die Frage soll so gestaltet sein, dass die Verteilung der Antworten Verständnisprobleme bei den Studierenden aufzeigt. Daher müssen die verwendeten Visualisierungen der Ergebnisse schnell und eindeutig erfassbar sein. Es müssen dabei in der Regel alle bei der Abstimmung erhaltenen Informationen dargestellt werden. Bei der Analyse bestehender Systeme für die Marktübersicht (s. 3.2) fiel auf, dass die meisten CRS bei der Darstellung der Ergebnisse nicht das volle Potential der erhaltenen Informationen ausschöpfen. Beispielsweise werden bei Multiple-Choice-Fragen lediglich Säulendiagramme zur Visualisierung der Ergebnisse verwendet, wobei jede Säule eine Antwortoption repräsentiert. Dabei werden einige Informationen nicht angezeigt, wie z. B. welche Kombination aus Antwortoptionen am häufigsten gewählt wurde. Merian soll daher auch bestehende Frageformate neu interpretieren und besonders die Visualisierung der Umfrageergebnisse verbessern.

Kapitel 5 Entwicklung Für die Entwicklung des Systems standen mehrere Strategien zur Auswahl: Einerseits konnte entweder ein bestehendes, quelloffenes System (z. B. PINGO) oder ein Prototyp1 , der auch die Hauptmotivation für die Durchführung der vorliegenden Arbeit war, um die gewünschten Features erweitert werden. Andererseits gab es die Möglichkeit ein gänzlich neues System zu erstellen. Ein bestehendes, quelloffenes System an die herausgearbeiteten Anforderungen anzupassen und um weitere Fragetypen zu erweitern, war eine reizvolle Strategie. Zunächst hätte hier ein passendes System ausgewählt werden müssen. Vermutlich wäre die Wahl auf PINGO gefallen, da das CRS bereits häufig eingesetzt wird und in sehr vielen Publikationen [9, 10, 12, 13] beschrieben ist. Ein Nachteil PINGOs ist, das dessen Frageformate ursprünglich nicht modular waren. Diese wurden an verschiedenen Stellen fest im Quelltext verankert. Hier wurde erst nach Beginn der Entwicklung Merians nachgebessert. Weiterhin eigneten sich Meteors Packages besonders gut um die Fragetypen umzusetzen, weshalb auf eine Modifikation PINGOs verzichtet wurde. Die in Merian erzielte Modularität der Frageformate übertrifft PINGO auch nach diesen Verbesserungen. Dies bestätigt den Entschluss, ein gänzlich neues System zu schaffen. 1

Erreichbar unter http://onlineresponse.org.

Quellcode unter https://github.com/axelb/clicker.

33

5. Entwicklung

34

Gegen die Erweiterung des Prototyps1 sprach, dass es der Software zum Zeitpunkt der Untersuchung an Echtzeit-Features und einer angemessenen Benutzerverwaltung (Registrierung, Administration, Passwort-Management, Speicherung benutzerspezifischer Daten) fehlte. Gerade diese Funktionen sind für CRS besonders wichtig. Letztendlich wurde, nach einiger Abwägung der Alternativen, der Weg der Reimplementierung gewählt. Ausschlaggebend war hier die mit wenig Aufwand umsetzbare Implementierung der dem Prototypen1 abgehenden Features. Gleichzeitig konnte die Komplexität des Systems im Gegensatz zu bestehenden Lösungen sehr niedrig gehalten werden. Genauer ist die Zusammenstellung der Werkzeuge im nächsten Abschnitt 5.1 beschrieben. Weiterhin kann die nötige Neuprogrammierung der bereits in anderen Systemen bestehenden Features durch die gute Zusammenstellung der Werkzeuge sehr schnell durchgeführt werden. Gerade durch das erneute Verfassen ist es möglich, an einigen Stellen von Anfang an speziell auf die gewünschten Anforderungen einzugehen. Ein weiterer Grund für die vollständige Neuprogrammierung des CRS war die gewünschte Erprobung Meteors. Dieses eignet sich ideal als Grundlage für die Entwicklung eines CR-Systems. Daher wurde die Gelegenheit genutzt, um die Plattform kennenzulernen. In diesem Fall ist somit, nach einer Beurteilung der Alternativen, eine Neuentwicklung der beste Weg ein CRS zu erstellen, das den gewünschten Anforderungen entspricht.

5.1

Komposition der Werkzeuge

Wie sich in diesem Kapitel zeigen wird, kann durch eine intelligente Auswahl der Werkzeuge (Plattform, Frameworks, Libraries, Tools) die Komplexität des entstehenden Systems minimiert werden. Ebenfalls verringert dies den Aufwand der Implementierung einiger Features (z. B. Echtzeit), da diese durch die eingesetzten Werkzeuge fast vollständig mitgeliefert werden.

5. Entwicklung

5.1.1

35

Meteor

Bei Meteor2 handelt es sich um eine quelloffene Plattform zur Erstellung von Web-Applikationen [3]. Meteor ist zusammengesetzt aus aufeinander abgestimmten serverseitigen und clientseitigen Modulen, geschrieben in JavaScript. Ebenfalls zu Meteor gehört dessen Kommandozeilen-Tool, das diverse Funktionen übernimmt, wie z. B. Bündeln (Unibuild) und Deployen der Anwendung und das Testen von Packages (TinyTest) [17]. Meteor besteht aus unterschiedlichen Packages, die je nach geplantem Einsatzzweck kombiniert werden können. In der Standardkonfiguration ist Meteor als Single-page Application (SPA) vorgesehen, in der neben einer serverseitigen, und einer clientseitigen Datenbank u. a. Module für Logging, Reaktivität, Echtzeit-Kommunikation und Templating enthalten sind. Neben den bestehenden Packages lassen sich Meteor-Anwendungen um selbst verfasste Packages erweitern. Serverseitig baut Meteor auf Node.js 3 auf, wobei dessen API durch Meteor abstrahiert ist. Eine typische Meteor-Anwendung besteht aus einem Mix aus JavaScript im Browser des Clients, JavaScript auf dem Meteor Server innerhalb eines Node-Containers, HTML Markup, CSS Regeln und statischen Dateien [17]. Prinzipien Anhand der in Meteors Dokumentation [17] erwähnten Prinzipien ist erkennbar, wie gut sich Meteor als Grundlage für ein webbasierten CRS eignet: Data on the Wire Beim initialen Laden der Anwendung sendet der Server dem Client alle Templates. Ab diesem Zeitpunkt werden zwischen Browser und Server nur noch Daten übertragen, nicht aber wie gewöhnlich deren Code zur Darstellung. Der Client füllt die Templates dann mit den erhaltenen Daten. Ändern sich die Daten, erfährt der Client dies und kann die Darstellung anpassen, da er die Templates bereits kennt. Somit ist die Anwendung unter2 3

https://www.meteor.com/ http://nodejs.org/

5. Entwicklung

36

brechungsfrei nutzbar, da die Seite nie neu geladen werden muss. Ebenfalls ist das Übertragen der Daten aufgrund des HTML-freien, kompakteren JSONFormats schneller, als das Übertragen derer Darstellung in HTML und CSS. U. a. ermöglicht dieses Prinzip den Fragestrom des Dozierenden in Merian. One Language Sowohl clientseitiger, als auch serverseitiger Quelltext wird in JavaScript geschrieben. Dies ermöglicht isomorphen Code, weshalb in beiden Kontexten bestehende Models und Funktionen nur ein einziges Mal definiert werden müssen. Weiterhin bleibt das System so simpel, da es durchgehend in derselben Programmiersprache verfasst ist. Database Everywhere Der Client verfügt ebenfalls über eine Datenbank (im Speicher), die Teile der serverseitigen Datenbank enthält. Der Server bestimmt welche Teile der Client sehen kann. Da beide Datenbanken dieselbe API verwenden, kann isomorpher Code problemlos geschrieben werden. Ferner vermeidet eine einheitliche API unnötige Komplexität. Durch das Halten von Daten auf dem Client kann dieser die lokale Datenbank durchsuchen ohne mit dem Server zu kommunizieren, wodurch die Anwendung schneller wird. Die clientseitige Datenbank ermöglicht den großen Vorteil der Latenzkompensierung, wie im nächsten Punkt beschrieben ist. Latency Compensation Der Client besitzt seine eigene Datenbank, die durch intelligentes Laden einiger Daten bereits vor deren Verwendung gefüllt werden kann. Ebenfalls kennt der Client nach dem initialen Laden der Anwendung bereits alle Templates. Ruft der Client gewisse Methoden des Servers auf, kann die Applikation deshalb das Resultat clientseitig simulieren (da die Daten bereits lokal vorliegen) und darstellen (da die Templates bereits bekannt sind) – ohne auf das Ergebnis des Servers zu warten. Sobald dessen Ergebnis vorliegt wird dieses mit der Simulation verglichen und im Bedarfsfall der Status des Clients angepasst. Für den Endanwender entsteht so das Gefühl einer latenzlosen Verbindung zum Server, da auf viele Eingaben ohne Verzögerung reagiert werden kann. Deshalb wird die Usability auch bei

5. Entwicklung

37

kurzzeitig hoher Last des Servers oder bei gelegentlichen Verbindungsverlusten nicht eingeschränkt. Dies ist aufgrund des eventuell instabilen WLAN in den Veranstaltungssälen für das CRS besonders vorteilhaft. Full Stack Reactivity In Meteor werden alle Änderungen an der Datenbank durch einen Client (oder den Server) in Echtzeit von allen anderen verbundenen Clients automatisch übernommen. Ermöglicht wird dies, da Reaktivität auf allen Schichten – von der Datenbank bis zu den Templates – implementiert wurde. Dies eignet sich speziell für den Fragestrom des Dozierenden. Schaltet dieser zur nächsten Frage, wird diese sofort den anderen Teilnehmern angezeigt – ohne dafür explizite Logik zu schreiben. Auch an weiteren Stellen profitiert Merian von Meteors reaktiver Natur. Embrace the Ecosystem Dieses Prinzip ist auf zwei Arten auszulegen. Einerseits kann Meteor problemlos mit anderen Libraries verbunden werden, ohne dass diese Meteors Interna kennen. Gerade durch Meteors Reaktivität könnte es hier zu Komplikationen kommen, da Meteor häufig Teile der Templates im Document-Object Model (DOM) manipuliert. Dabei könnten beispielsweise Event-Listener verloren gehen. Ältere Versionen Meteors hatten dieses Problem, weshalb die Template Engine neu geschrieben wurde. Seit deren Release unter dem Namen Blaze ist Meteor kompatibel zu zahlreichen Libraries. In Merian wird Meteor u. a. mit D34 und jQuery5 genutzt. Andererseits gibt es einen Package-Manager für Meteor. Meteors Packages können sowohl clientseitigen Code, als auch serverseitigen Code enthalten. Ebenfalls können sie in den Build-Prozess eingreifen. Ein für das CRS genutztes Package ist z. B. Iron-Router6 , das ebenfalls isomorphen Code enthält. Durch dieses Package ist es möglich die SPA-Restriktion von Meteor zu lösen und unterschiedliche Routen in der Anwendung zu erstellen. 4 5 6

http://d3js.org/ http://jquery.com/ https://github.com/EventedMind/iron-router

5. Entwicklung

38

Weitere Vorteile Neben diesen – in der Dokumentation [17] genannten – Prinzipien gibt es weitere Gründe, die für den Einsatz von Meteor sprechen: WebSockets Wie die Analyse von PINGO und ARSnova in Abschnitt 3.2 ergab, verwenden beide Systeme WebSockets für die Umsetzung der EchtzeitFeatures. Auch Meteor nutzt WebSockets zur Echtzeit-Kommunikation. Entgegen den anderen System wird hier auf SockJS 7 zurückgegriffen. Die WebSockets sind in Meteors Kern verwurzelt und durch die API transparent, weshalb in Meteor-Anwendungen Echtzeit der Standard ist. Daher lies sich Merian ohne Programmierung auf einer so niedrigen Ebene umsetzten. Fibers Meteor verwendet Fibers8 um die, sich manchmal in typische Node.js-Anwendungen9 einschleichende Callback-Hell 10 zu vermeiden, ohne den Event-Loop11 zu blockieren. Meteors API baut auf Fibers auf, wodurch Anwendungen performant bleiben und dennoch den komfortablen, linearen, imperativen Programmierstil ohne Callbacks verwenden können. Meteors Beliebtheit stammt sicherlich zu großen Teilen von dessen elegantem Einsatz der Fibers. Namespacing Meteor kapselt die Variablen pro Datei in einem eigenen Namespace, solange diese mit dem Schlüsselwort var versehen sind. Andernfalls werden die Variablen zu globalen Variablen. In Meteors Packages kann explizit festgelegt werden, welche Variablen in die Anwendung und andere Packages exportiert werden sollen. Dies ermöglicht einen sehr sauberen Quellcode, auch bei sehr großen Anwendungen [17]. 7 8 9 10

http://sockjs.org/ https://github.com/laverdet/node-fibers/ http://nodejs.org/ Der Begriff bezeichnet das Vernesten von Callbacks bis zur Unleserlichkeit des Quell-

texts. http://callbackhell.com/ 11 https://developer.mozilla.org/en-US/docs/Web/JavaScript/Guide/EventLoop

5. Entwicklung

39

Wie aus den Prinzipien ersichtlich lassen sich mit Meteor Anwendungen schreiben, die ab dem initialen Laden unterbrechungsfrei nutzbar sind. Die Anwendungen bleiben sehr schlicht, da sie komplett in JavaScript geschrieben werden können. Durch die Datenbank beim Client und das Vorausladen der Templates ist Latenzkompensierung möglich. Meteors Reaktivität sorgt für die sofortige Anpassung der Darstellung bei Änderungen an den zugrundeliegenden Daten und vereinfacht auch an weiteren Stellen die Programmierung. Neben den speziell für Meteor verfügbaren Packages, können die Funktionen bestehender Libraries dank der leichten Integration einfach genutzt werden. Die in Meteor eingebetteten Fibers sorgen für eine performante Anwendung ohne den Quelltext unnötig unleserlich zu machen. Dank dem automatischen Namespacing bleiben auch große Anwendungen übersichtlich. All diese Vorteile bilden eine optimale Grundlage um mit Meteor ein CRS zu entwickeln. Umgang mit Beta-Status Wie gezeigt ist Meteor hervorragend als Basis eines CRS geeignet. Allerdings befindet sich Meteor selbst noch in der Entwicklung – derzeit in Version 0.8.1.3. Deshalb war es während der Implementierung stets hilfreich einen möglichst klaren Überblick über anstehende Erneuerungen zu haben. Dazu konnte einerseits Meteors Roadmap12 verwendet werden. Andererseits ließen sich Änderungen durch Verfolgen der relevanten Neuigkeiten13 vorhersehen. Das CRS konnte auf Kompatibilität mit anstehenden Updates bereits vor deren offiziellem Release getestet werden, indem die entsprechende MeteorVersion aus zugehörigen Branches in GitHub14 verwendet wurde. Für den Fall, dass zukünftig ein Update ein enormes Kompatibilitätspro12 13

http://roadmap.meteor.com/ https://www.meteor.com/blog,

https://www.eventedmind.com/, http://meteorhacks.com/, https://www.youtube.com/user/MeteorVideos 14 https://github.com/meteor/meteor/branches

5. Entwicklung

40

blem verursachen würde, kann das Umsteigen auf die neuere Meteor-Version aufgeschoben werden, bis der Konflikt gelöst ist. Da das Entwicklerteam von Meteor nicht-finale Teile der API durch entsprechende Namensgebung kennzeichnet, konnte für diese ein spezieller Regressionstest geschrieben werden. Sollte sich die API ändern wird ein solches Problem frühzeitig erkannt und kann behoben werden. Meteors Beta-Status führte im Verlauf der bisherigen Implementierung zu keinen wesentlichen Problemen. Neue Features von Meteor konnten problemlos übernommen werden und halfen die Qualität des entstandenen CRS zu steigern.

5.1.2

MongoDB

MongoDB ist eine NoSQL-Datenbank15 . Es speichert Daten als Dokumente in einem JSON-ähnlichen Format in Kollektionen. In einer Kollektion können Dokumente mit unterschiedlichen Strukturen gespeichert werden. Da verschiedene Frageformate unterschiedlich strukturierte Dokumente erfordern, vereinfacht dies das Layout der Datenbank enorm. Da die Schemata flexibel sind bleibt das CRS auch zukünftig problemlos um neue Frageformate erweiterbar. Durch Denormalisierung beschränken sich Anfragen an die Datenbank in der entwickelten Anwendung häufig auf eine einzige Kollektion, wodurch die Anwendung performant bleibt. Meteor wird standardmäßig mit MongoDB ausgeliefert. Obwohl Meteor auch andere Datenbanken unterstützt ist es besonders auf MongoDB ausgelegt. Die in Meteor enthaltene clientseitige Datenbank umfasst einen Treiber namens minimongo, der die API von MongoDB zu großen Teilen unterstützt. Daher ist es möglich sowohl clientseitig, als auch serverseitig dieselbe API zu verwenden. Es können aus den für den Server definierten Methoden automatisch Stubs für den Client generiert werden. Dies ermöglicht die in 5.1 beschriebene Latenzkompensation. 15

http://www.mongodb.org/

5. Entwicklung

41

Um Meteor-Applikationen hochskalierbar zu machen und die Belastung der Datenbank zu senken wird MongoDBs Oplog von Meteor genutzt [18]. Genauer ist dies in 5.5 erklärt.

5.1.3

D3

D3 16 steht für „Data-Driven Documents“. Es ist eine JavaScript-Library zur datenbasierten Manipulation des DOM. In Kombination mit HTML und SVG17 können so eindrucksvolle Visualisierungen erzeugt werden. Durch die Nutzung von Web-Standards sind diese unabhängig vom Browser des Clients darstellbar18 . D3 ist sehr vielseitig einsetzbar, da es lediglich mit dem DOM interagiert. Somit lassen sich die Resultate der Fragetypen auf bisher nicht genutzte Arten darstellen, wie z. B. als Box-Whisker-Plot im Number-Fragetyp (s. 5.3).

5.1.4

Bootstrap

Eine wesentliche Anforderung ist, dass sich das Layout des CRS an unterschiedliche Bildschirmgrößen anpasst (s. 4.3). Bootstrap19 ist ein Framework, das nach dem Ansatz Mobile First geschrieben ist. Deshalb sind enthaltene Komponenten auf mobile Geräte ausgelegt, skalieren aber gut für größere Displays. Bootstrap bildet eine solide Grundlage um ein Responsive Design zu erstellen, das sich an die unterschiedlichen Bildschirmgrößen anpasst. Ebenfalls konnte Implementierungsaufwand gespart werden, indem manche der bereits in Bootstrap enthaltenen Komponenten im CRS genutzt wurden.

5.1.5

Technologie-Übersicht

Eine Übersicht der eingesetzten Technologien und Libraries bietet 5.1. Der Server ist mit einer MongoDB Datenbank verbunden, wobei die Interakti16 17 18 19

http://d3js.org/ http://www.w3.org/TR/SVG/intro.html Abgesehen von stark veralteten Versionen einiger Browser. http://getbootstrap.com/

5. Entwicklung

42

Abbildung 5.1: Übersicht der eingesetzten Werkzeuge.

on mit dieser über das serverseitige Meteor abläuft. Möchte der Client eine Änderung bewirken, muss er einen Methodenaufruf zum Server starten. Dieser kontrolliert die Zugangsberechtigung und führt dann gegebenenfalls die Anfrage am Server aus. Die clientseitige Datenbank minimongo wird sofort geändert. Zum Speichern von Bildern für die Fragen wird Amazon S3 verwendet, wozu der Server den Client Knox 20 einsetzt. Somit muss zum Upload eines Bildes dieses zunächst vom Browser zum Server übertragen werden, und anschließend vom Server über Knox zu Amazon S3. Der Zugriff zur Anzeige der Bilder erfolgt dann direkt vom Browser auf Amazon S3 (dies ist in der Grafik nicht dargestellt). Initial wird die Anwendung über HTTP auf den Client geladen. Dabei erhält er alle Templates und den für ihn bestimmten Programmcode, der u. a. Meteor, jQuery, Bootstrap, D3 und Underscore 21 enthält. Der clientseitige Teil Meteors baut dann eine DDP-Verbindung 22 zum serverseitigen Teil Meteors auf. Der Client erhält vom Server die notwendigen Daten der aktuellen Seite. Er fügt diese nun in die Templates ein, wodurch die initiale 20 21 22

https://github.com/LearnBoost/knox http://underscorejs.org/ DDP (Distributed Data Protocol) ist Meteors Protokoll zur Übertragung von Daten

und entfernten Methodenaufrufen. https://github.com/meteor/meteor/blob/master/packages/livedata/DDP.md

5. Entwicklung

43

Seite angezeigt wird. Navigiert der Anwender nun zu einer anderen Seite innerhalb der Anwendung, so reagiert der clientseitige Router. Er unterbindet das Stellen einer erneuten HTTP-Anfrage und nutzt stattdessen die HTML5History-API 23 um die neue Seite in die Browser-History aufzunehmen und den Status der Adressleiste anzupassen. Ebenfalls fordert der Router die Daten der neuen Seite an, woraufhin der Client diese vom Server erhält (s. Publish & Subscribe, Abs. 5.2.2) und die View der neuen Route rendert. Folglich werden ab dem initialen Laden nur noch Daten übertragen. Somit bleibt die Anwendung sehr schnell, da keine HTTP-Anfragen mehr übertragen werden müssen und die Daten in kompakter Form ausgeliefert werden können. Clientseitig wird jQuery und Underscore genutzt, um die unterschiedlichen APIs der Browser zu abstrahieren und die Programmierung zu erleichtern. Das jQuery QR-Code Plugin wird eingesetzt, um den QR-Code zu generieren, der die URL des Fragestroms des Dozierenden enthält. Aufgrund der passenden Auswahl und guten Abstimmung der Werkzeuge lässt sich das CRS sehr komfortabel umsetzen. Durch die Komposition der Werkzeuge sind somit bereits einige Anforderungen erfüllt, die in Tab. 5.1 aufgelisteten sind.

5.2 5.2.1

Design Struktur

Da Meteor sowohl clientseitig, als auch serverseitig läuft ist eine spezielle Programmstruktur erforderlich. Prinzipiell könnte die gesamte Anwendung in einer einzigen Datei geschrieben werden. Mit speziellen Meteor.isServerund Meteor.isClient-Abfragen könnte darin geprüft werden, ob der Programmcode gerade auf dem Client oder auf dem Server ausgeführt wird. Dieser strukturlose Ansatz führt aber schon bei kleinen Projekten sehr schnell 23

http://www.w3.org/TR/2011/WD-html5-20110113/history.html

5. Entwicklung

44

Tabelle 5.1: Durch die Komposition der Werkzeuge erfüllte Anforderungen. Anforderung

Erfüllt durch

Ohne Installation nutzbar

webbasierter Ansatz

Geringer Konfigurationsaufwand

-

Kosten

webbasierter Ansatz

Geringer Verwaltungsaufwand

webbasierter Ansatz

Skalierbarkeit

Meteor mit Skalierungstaktiken (s. 5.6)

Mobile First

Bootstrap

Unterbrechungsfreies Antworten

Meteor

Unterstützt Vielzahl an Geräten

Meteor, jQuery

Intuitive Bedienbarkeit

-

Interaktionsarme Bedienbarkeit

-

PI Kompatibilität

-

zur Unübersichtlichkeit. Zudem hat dieser Ansatz das Problem, dass eventuell sicherheitskritische Programmteile dem Client ebenfalls mitgeteilt werden. Bei der Bekanntmachung von Programmteilen, sowohl an den Server, als auch an den Client, handelt es sich um Isomorphismus. Umgesetzt wird dies, indem Meteor beim Bündeln die isomorphen Programmteile sowohl in die Anwendung des Servers, als auch in die des Browsers einfügt. Isomorpher Quelltext eignet sich daher besonders gut, um Models nur ein einziges Mal definieren zu müssen und diese dennoch in beiden Kontexten nutzen zu können – wie dies auch in Merian geschieht. Allgemein ist der gesamte Quelltext in Meteor isomorph. Um bestimmte Teile der Anwendung ausschließlich dem Server oder ausschließlich dem Client bekannt zu machen sind deshalb Verzeichnisse mit bestimmten Eigenschaften definiert. Diese sind in [17] gelistet. Interessant ist dabei das Verzeichnis /client. Darin befindlicher Quelltext wird ausschließlich im Browser ausgeführt und ist dem Server nicht bekannt. In Merian liegt der Großteil der clientseitigen Anwendung in diesem Verzeichnis. Analog dazu sind Dateien im Verzeichnis /server nur dem Server bekannt. Ein weiteres wichtiges Verzeichnis ist /packages, das Packages

5. Entwicklung

45

enthält, die Programmteile für den Server, den Client oder beide liefern24 . In Merian wurden abgeschlossene Funktionseinheiten in eigenen Packages definiert. So gibt es die folgenden Packages: • crs-app • crs-accounts • crs-seminars • crs-history • crs-uploads • crs-courses • crs-remote-admin • crs-dashboard • crs-ui-helpers Im Package crs-seminars befindet sich beispielsweise das Modell für Seminare. Ebenfalls sind darin Methoden zur Steuerung (Starten, zur nächsten Frage schalten, Stoppen, usw.) des Seminars deklariert. Jedes Package verfügt über eine Datei namens package.js, die vorgibt wo die sonstigen im Package enthaltenen Dateien ausgeführt werden sollen (isomorph, auf dem Client oder auf dem Server). Diese bestimmt ebenfalls, von welchen anderen Packages dieses Package abhängig ist und welche Variablen aus diesem Package in den Namensraum der Anwendung exportiert werden sollen. Ein gekürztes Beispiel für das Package crs-seminars zeigt Programm 5.1. Die zu den jeweiligen Packages passenden Views wurden im Verzeichnis /client/pages angelegt. Eine ausführliche Auflistung der in Merian existierenden Verzeichnisse bietet Tab. 5.2. 24

Diese anwendungsspezifischen Packages sind von den Packages aus denen Meteor

selbst besteht zu unterscheiden. Leider verwendet Meteor für beide Arten von Packages dieselbe Bezeichnung, obwohl es sich dabei um unterschiedliche Dinge handelt.

5. Entwicklung

46

Programm 5.1: Gekürztes Beispiel für die in jedem Package enthaltene Datei package.js. 1

Package.on_use(function (api) {

2

// Dieses Package benutzt die folgenden anderen Packages

3

api.use(['standard-app-packages', .. ]);

4 5

// Dieses Package nutzt die folgenden Packages auf dem Client

6

api.use(['localstorage', 'reactive-cookie'], 'client');

7 8

// Im Package enthaltene isomorphe Dateien,

9

// die für den Client und den Server bestimmt sind.

10

api.add_files([ 'models/seminars.js', .. ]);

11 12

// Dateien die ausschließlich für den Client bestimmt sind

13

api.add_files(['controller.js', .. ], 'client');

14 15

// Dateien die ausschließlich für den Server bestimmt sind

16

api.add_files(['server/seminarMethods.js', .. ], 'server');

17 18

// Variablen, die in den Namensraum der Anwendung

19

// exportiert werden sollen

20

api.export(['Seminars', .. ]);

21

});

5.2.2

Collections

Meteor speichert Daten in Collections. Das Erzeugen einer Collection entspricht dem Deklarieren eines Models in traditionellen Frameworks, die Objekt-Relationale Mapper (ORM) verwenden. In Kollektionen verwaltete Dokumente werden von Meteor im Normalfall automatisch persistiert25 [17]. Auftretende Änderungen in isomorph deklarierten Collections propagiert Meteor an Client und Server. Da sowohl das Frontend, als auch das Backend die 25

Eine Ausnahme sind namenlose Collections, die dann auch nicht zwischen Client und

Browser synchronisiert werden.

5. Entwicklung

47

Tabelle 5.2: Merians Verzeichnisstruktur. Verzeichnis

Enthaltene Dateien

/client

Templates, Stylesheets und Skripte für den Client.

/client/css

Stylesheets.

/client/fragments

In unterschiedlichen Views verwendete Elemente.

/client/lib

Eigene Libraries.

/client/lib/3rd-party

Externe Libraries.

/client/pages

Templates und zugehöriger Code unterschiedlicher Views.

/client/router

Routen und Templates z. B. für „Seite nicht gefunden“.

/isomorphic

Code für Client und Server.

/packages

Externe und interne Packages.

/packages/crs-*

Interne Packages, speziell für Merian.

/public

Statische Inhalte.

/public/img

Bilder.

/public/js/3rd-party

Skripte, die nur in bestimmten Browsern geladen werden.

/server

Serverseitiger Code (Publikationen und Suche).

/tests

Unterschiedliche Tests und eigenes Test-Framework.

Kollektionen über die API manipulieren können, sind serverseitig Regeln zur Zugangskontrolle des Clients deklarierbar. Weiterhin bestimmt der Server pro Client, welche Teile der Collections dieser sehen kann [17]. Durch das Festlegen einer transform-Funktion können die aus der Datenbank ausgelesenen Dokumente vor dem weiteren Verwenden in der Applikation umgewandelt werden [17]. So lassen sich Dokumente wieder in echte Objekte des gewünschten Typs wandeln, wie Programm 5.2 zeigt. Dies erleichtert die Programmierung, da so die Logik in die zugehörigen Typen verpackt werden kann. In der Anwendung gibt es die folgenden Collections: • Courses Diese Kollektion stellt Kurse dar. Sie enthält u. a. Informationen über den Namen des Kurses und dessen Veranstalter. Eingebettet in die Kurse sind die Lehrveranstaltungen, in denen der Name der Veranstaltung und deren Fragen gespeichert sind. • Seminars Diese Collection bildet die tatsächlichen Seminare ab. Ein

5. Entwicklung

48

Programm 5.2: Wandlung eines Dokuments aus der Datenbank in ein Objekt vom Typ Course. // Legt die Collection „courses“ an. // Wandelt jedes Dokument beim Auslesen in ein Objekt vom Typ „Course“ Courses = new Meteor.Collection('courses', { transform: function (doc) { return new Course(doc); } });

Seminar besteht aus Informationen über den Trainer, den Status des Seminars, Beginn und Ende des Seminars, Kurz-Id26 , bereits gestellte Fragen, anstehende Fragen und Informationen zum Kurs und zur Lehrveranstaltung zu der das Seminar gehört. • SeminarHistory Wurde ein Seminar beendet wird es in diese Collection verschoben. Dadurch bleibt die Suche nach derzeit aktiven Seminaren sehr schnell, da sich die Dokumente abgeschlossener Seminare nicht mehr in derselben Kollektion befinden. Die Abstimmungsergebnisse der Seminare lassen sich auch nach deren Beendigung noch betrachten, da diese in dieser Kollektion gespeichert werden. • Meteor.users Die Collection der Benutzer wird mit Meteors AccountsSystem mitgeliefert. Sie enthält die an der Anwendung registrierten Benutzer. Die Kollektion wurde nur an einer einzigen Stelle erweitert, wobei diese Änderung für vorliegende Arbeit nicht weiter relevant ist27 . 26

Dabei handelt es sich um einen vier Zeichen langen, für aktive Seminare eindeutigen

Identifier, bestehend aus Buchstaben. Durch ihn können Teilnehmer das Seminar auffinden – ohne viele Buchstaben eingeben zu müssen. 27 Es wurde ein Feld zum Speichern der Starthöhe eines Countdowns hinzugefügt. Beendet ein Trainer eine Abstimmung, wird zunächst ein mit diesem Startwert initialisierter Countdown herunter gezählt, bevor die Frage tatsächlich beendet wird. Somit erhalten die Studierenden noch genügend Zeit, um ihre Antworten abzusenden und werden nicht vom plötzlichen Ende der Frage überrascht.

5. Entwicklung

49

Publish & Subscribe Dieser Mechanismus Meteors wird genutzt, um die clientseitige Datenbank mit Teilen der Datenbank des Backends zu füllen. Zunächst werden auf dem Server verschiedene Publikationen mit unterschiedlichen Namen eingerichtet. Dabei handelt es sich um Funktionen, die optionale Parameter entgegennehmen können und basierend darauf Daten in Form eines oder mehrerer Cursor zurückgeben. Ein Cursor ist generell das Ergebnis einer Datenbankabfrage, mit der Besonderheit, dass die Abfrage betreffende Änderungen auch nach dem ursprünglichen Aufruf noch durch den Cursor propagiert werden28 . Ein Cursor enthält in der Regel Teile der Daten einer Collection. Eine Publikation liefert einen oder mehrere Cursor. Unterschiedliche Publikationen können auch Cursor für verschiedene Teile derselben Collection ausgeben. Clientseitig lassen sich die Publikationen anhand ihres Namens abonnieren. Die in den Cursorn enthaltenen Daten werden dann in die Datenbank des Frontends übernommen. Nachträgliche serverseitige Änderungen an den Daten werden während des Abonnements dem Client gesendet. Der Client hat auch die Möglichkeit das Abonnement zu stoppen. Dieses Prinzip wird in Merian überall dort eingesetzt, wo der Client Daten des Servers erhält. Auch zum Befüllen der clientseitigen Datenbank mit Teilen der Daten des Servers wird dieses Modell genutzt. Unter anderem ist der Fragestrom des Dozierenden mit diesem Mechanismus umgesetzt. Die Studierenden abonnieren eine Publikation, die einen Cursor zurückgibt, der Teile der Daten des Seminars enthält. Ihnen ist beispielsweise die aktuelle Frage ersichtlich, nicht aber die noch anstehenden oder bereits abgeschlossenen Fragen. Schaltet der Trainer zur nächsten Frage, so ändert sich das Seminar. Die Publikation bemerkt dies und teilt die Änderungen über den Cursor den Abonnenten mit. Somit erfahren die Clients die neue Frage und können diese anzeigen. Dieser Ablauf ist schematisch in Abb. 5.2 veranschaulicht. 28

Alternativ lassen sich auch Cursor definieren, die ihre Daten nicht aus der Datenbank

erhalten, sondern diese selbst festlegen – wie beispielsweise ein Zähler der Benutzer die gerade auf der Seite sind.

5. Entwicklung

50

Trainer

Server

Student

Publication Publikationen für Seminare, anhand von deren Kurz-Id

Subscription Abonniert Seminar anhand Kurz-Id Erstellt Cursor durch Publikation, der die für diesen User sichtbaren Daten des abonnierten Seminars enthält Cursor mit Daten des Seminars Ändert Seminar Publikation bemerkt Änderung, verbreitet diese über Cursor Änderungen an Seminar

Abbildung 5.2: Publish & Subscribe anhand des Fragestroms eines Dozierenden.

Auch der Trainer erhält die Daten des aktuellen Seminars, allerdings anhand einer anderen Publikation. Diese kann nur der Veranstalter des jeweiligen Seminars abonnieren. Er hat dabei Zugang zu anderen Teilen des Seminars. Er sieht beispielsweise die Anzahl bereits abgegebener Antworten auf die aktuelle Frage. Stimmt ein Teilnehmer ab, so erhöht der Server den Stimmzähler im Seminar. Auch hier erfährt der Trainer anhand des von der Publikation erhaltenen Cursors von dieser Änderung. Der Browser zeigt daraufhin die neue Anzahl bereits abgegebener Stimmen an. Die jeweiligen Subscriptions verwaltet der clientseitige Router. Wechselt der Nutzer zu einer anderen Route, so abonniert der Router die dafür notwendigen Publikationen selbständig. Ebenfalls beendet er über den Cursor die Subscriptions der zuvor aktiven Route.

5. Entwicklung

51

Abbildung 5.3: Beziehung zwischen Kurs, Lehrveranstaltung und Fragen.

5.2.3

Seminare

Ein Seminar in Merian entspricht einem oder mehreren ConcepTests zu einem gewissen Thema, die innerhalb einer Unterrichtsstunde gestellt werden. Sie sind somit die Grundlage für den Fragestrom des Dozierenden, da dieser Strom die Fragen eines Seminars nach und nach ausliefert. Zunächst muss der Dozierende einen Kurs in Merian erstellen. Diesem kann er dann die unterschiedliche Lehrveranstaltungen hinzufügen, die selbst aus einer oder mehreren Fragen bestehen. Diese Abhängigkeiten zeigt Abb. 5.3. Zu Beginn einer realen Lehrveranstaltung startet der Dozierende das Seminar im CR-System. Dabei werden die Fragen aus der zuvor erstellten Lehrveranstaltung in das Seminar kopiert. Im Lauf des Unterrichts werden die Fragen dann nacheinander durch Abstimmungen mit den Antworten der Teilnehmer gefüllt. Ein Seminar ist folglich die konkrete Instanz einer Lehrveranstaltung. Der Lebenszyklus eines Seminars ist aus Abb. 5.4 ersichtlich. In der Datenbank sind die Seminare in der Kollektion Seminars angelegt (s. 5.2.2). Jedes Seminar enthält ein state-Feld, auf dessen Wert sich die Beschriftung in der Abbildung bezieht29 . Nach dem Start eines Seminars steht der Wert des state-Felds auf start. Der Browser des Trainers zeigt in diesem Zustand die URL, unter der sich die Studierenden am Fragestrom des Dozierenden anmelden können. Anschließend werden die im Seminar anstehenden Fragen sequenziell abgearbeitet. Zunächst wechselt das Seminar in den Status question. Dabei zeigt der Browser des Dozierenden ebenfalls die URL des Fragestroms und 29

In der Datenbank sind die hier genannten Werte für das state-Feld als Integer kodiert.

Zur besseren Lesbarkeit wurden für den Text entsprechende Namen für die Werte vergeben.

5. Entwicklung

52

einen zugehörigen QR-Code, damit sich auch verspätet zur Lehrveranstaltung erscheinende Teilnehmer noch am Fragestrom anmelden können. Die Teilnehmer sehen hier das Antwortformular für die aktuelle Frage. Wechselt der Trainer zu den Abstimmungsergebnissen, so wird das Feld state in den Zustand result geändert. Der Browser des Trainers zeigt dann die Ergebnisse der aktuellen Umfrage. Den Clients wird dabei eine Warteseite angezeigt. Nun kann der Trainer zu einer beliebigen nächsten Frage des Seminars schalten, wodurch die Abstimmungsphase erneut beginnt. Der Dozierende kann so alle Fragen des Seminars in beliebiger Reihenfolge abarbeiten. Möchte der Trainer das Seminar beenden, so würde dieses in den Endzustand complete wechseln. Tatsächlich wird dabei das Seminar in die SeminarHistory-Collection verschoben und dort archiviert. Dem Client wird vorgegaukelt, dass sich das Seminar noch in der Collection seminars befindet und in den Zustand complete überging. Da dieses state-Feld allen Teilnehmern ersichtlich ist, passen diese die Darstellung des Seminars je nach Status reaktiv an. Den schematischen Aufbau des Dokuments eines Seminars in der Datenbank zeigt Programm 5.3. Beim Wechsel zu einer neuen Frage wird diese aus der Warteschlange in das current-Feld des Seminars übernommen. Nach Anzeige der Abstimmungsergebnisse wird beim Schalten zur nächsten Frage oder bei Beenden des Seminars die Frage aus dem current-Feld in die Liste gestellter Fragen verschoben. Da Clients das current-Feld und das stateFeld ebenfalls sehen, und auf Änderung derer Werte reagieren, ist somit der Fragestrom des Trainers realisierbar. Der Push-Mechanismus neuer Fragen lies sich durch Meteors implizite Synchronisation der Daten (durch Publish & Subscribe, s. 5.2.2) und die Reaktivität aller Clients auf Änderungen an den Daten wie gezeigt mit sehr geringem Aufwand lösen.

5. Entwicklung

53

Programm 5.3: Aufbau eines Seminars in der Datenbank in Pseudo-JSON. { _id: String, answeredBy: [ { connectionId: String // id der DDP-Connection. Identifiziert Client userId: String

// id des Nutzers, falls angemeldeter User

}, .. ], completed: [Object],

// Fragen, für die bereits abgestimmt wurde

current: Object,

// Aktuelle Frage

info: { course: { _id:

String,

name: String

// id des Kurses zu dem dieses Seminar gehört // Name des Kurses. Denormalisiert.

}, lecture: { _id:

String,

name: String

// id der Lehrveranstaltung dieses Seminars // Name der Lehrveranstaltung. Denormalisiert.

} }, queue: [Object],

// Noch anstehende Fragen des Seminars

shortId: Integer,

// Kurze, eindeutige Id des Fragestroms für URL

state: String,

// Status des Seminars

time: { start: ISODate,

// Startzeitpunkt des Seminars

stop:

// Endzeitpunkt des Seminars

ISODate

},

}

trainer: String,

// Id des Dozierenden

trainerMail: String

// Email-Adr. des Dozierenden. Denormalisiert.

5. Entwicklung

54

Abbildung 5.4: Lebenszyklus eines Seminars in Merian.

5.3

Fragetypen

Ein wesentliches Teilziel dieser Arbeit ist die Schaffung einer Grundlage zur Entwicklung neuartiger Fragetypen. Für einen neuen Fragetyp sind in der Regel folgende Dinge notwendig: • Formular zur Erstellung einer Frage • Methode zur Speicherung der erstellten Frage • Formular zur Beantwortung einer Frage • Methode zur Speicherung der Stimme • Visualisierung der Abstimmungsergebnisse • Methode zum Zurücksetzen der Abstimmungsergebnisse für Wiederholung der Abstimmung Individuelle Frageformate verlangen daher ihre eigenen Templates und Methoden. So ist für jedes Frageformat ein eigenes Template zur Erstellung der Frage, Beantwortung der Frage und Darstellung der Umfrageergebnisse notwendig. Ebenfalls ist für jede dieser Aktionen pro Frageformat eine spezielle Logik erforderlich. Während zum Beantworten von Single-Choice-Fragen beispielsweise nur Zähler inkrementiert werden müssen, ist es bei Freitext-Fragen notwendig, die Texte der Benutzer zu speichern. Merian ist so ausgelegt, dass sich auch zukünftig entstehende Frageformate leicht integrieren lassen, indem diese ihre jeweiligen Bestandteile selbst liefern. Diese Module werden dann von Merian nach dem Hollywood-Prinzip aufgerufen. Als Beispiel ist die Umsetzung des Frageformats Number in Anhang A beschrieben.

5. Entwicklung

55

Da unterschiedliche Frageformate zudem eine individuelle Struktur der Dokumente in der Datenbank erfordern, ist ein flexibles Schema notwendig. Durch die Verwendung einer NoSQL-Datenbank ist Meteor für spezielle Schemata zukünftiger Fragetypen gerüstet, da Dokumente unterschiedlicher Struktur in die Collections einbindbar sind (s. 5.1). Meteors Packages sind abgeschlossene Funktionseinheiten, die Programmteile sowohl für den Client, als auch für den Server bereitstellen können (s. 5.1). Merians Frageformate bestehen sowohl aus Templates und Logik auf dem Client, als auch aus serverseitigen Methoden. Deshalb eignen sich Packages hervorragend, um darin die Frageformate umzusetzen. Jedes Frageformat ist in Merian durch ein eigenes Package abgebildet. Dieses enthält eine Datei namens type.js, die Informationen zum Fragetyp angibt. Darin sind in der Regel die Methoden zum Erstellen einer Frage (process), Zurücksetzen der Stimmen einer Frage (reset) und zum Abgeben einer Stimme für dieses Frageformat (answer) definiert. Weiterhin enthält das Package ein Template zum Erstellen einer Frage dieses Formats (createTemplate), ein Template mit dem Antwortformular für Teilnehmer (answerTemplate) und ein Template für die Visualisierung der Umfrageergebnisse (resultTemplate). Die konkreten Namen der zu verwendenden Templates aus dem Package sind ebenfalls in der Datei type.js festgelegt. Abb. 5.5 (a) zeigt, wie eine Frage für eine Lehrveranstaltung in Merian erstellt wird. Zunächst wird dabei das createTemplate der Frage aufgerufen. Der Trainer füllt das darin enthaltene Formular aus, wodurch ein die Frage repräsentierendes Objekt erzeugt wird. Dieses wird an die Methode process weitergegeben und dabei serverseitig auf Korrektheit geprüft und in ein für die Datenbank angemessenes Format gebracht. Anschließend wird die Frage von Merian weiter bearbeitet und daraufhin persistiert. Den Ablauf der Beantwortung einer Frage zeigt Abb. 5.5 (b). Jedem Teilnehmer wird das answerTemplate des Frageformats angezeigt. Durch beantworten der Frage anhand des enthaltenen Formulars wird ein answer-Objekt erstellt. Dieses wird von der Methode answer serverseitig geprüft und in eine

5. Entwicklung

56

(a)

(b) Abbildung 5.5: Schematischer Ablauf bei Erstellung (a) und Beantwortung (b) einer Frage.

Operation übersetzt. Die Operation entspricht beispielsweise dem Inkrementieren des Zählers für die gewählte Antwortoption einer Single-Choice-Frage. Diese Operation wird vom CRS weiter verfeinert und anschließend auf die Datenbank angewendet, wodurch die Stimme abgegeben wird. Da sich manche Frageformate ähnlich sind, wurde ein System geschaffen, mit dem duplizierter Code vermieden wird, indem Frageformate verschiedene Eigenschaften und Templates voneinander übernehmen können. Dazu wird die bereits erwähnte type.js-Datei in Kombination mit der in 5.2.1 genannten Datei package.js genutzt, um gegenseitige Abhängigkeiten zwischen den Frageformaten herzustellen. Somit kann ein Frageformat die Einbindung eines zweiten Frageformats implizieren. Dies ist beispielsweise nützlich, wenn ein konkretes Frageformat auf einem anderen, abstrakten Frageformat aufbaut. Hier würde das konkrete Frageformat die Verwendung des abstrakten Frageformats anhand der Datei package.js implizieren. Zum Beispiel ist in Programm 5.4 die Definition des Single-Choice-Frageformats angegeben. Die Methode Question.Types.extend erwartet drei Argumente, die angeben, von welchem Fragetyp geerbt wird (1. Parameter, hier text-base), wie

5. Entwicklung

57

Programm 5.4: Beispiel für die Definition eines Frageformats in type.js. 1 2

Question.Types.extend('text-base', 'sc', { name: 'Single Choice',

3 4

answer:

function (answerId) {

check(answerId, String);

5 6

return {

7

selector: {'current.answers.id': answerId},

8

operation: {$inc: {'current.answers.$.votes': 1}}

9

};

10 11

},

12 13

reset: function (question) { _.each(question.answers, function (answer) {

14

answer.votes = 0;

15

});

16 17

return question;

18 19

},

20 21

answerTemplate: 'answerSingleChoiceQuestion',

22

resultTemplate: 'resultSingleChoiceQuestion'

23

});

der Schlüssel des neuen Fragetyp lautet (2. Parameter, hier sc) und welche Eigenschaften der neue Fragetyp hat (3. Parameter). Somit liefert jedes Frageformat in einem Package alle notwendigen Puzzleteile, um in Merian eingebunden werden zu können. Im Beispiel nicht angegebene Eigenschaften (process, createTemplate) wurden von text-base geerbt. Bei text-base handelt es sich um einen abstrakten Typ, der selbst kein echter Fragetyp ist. Er ist in einem eigenen Package definiert und dient als Grundgerüst für diverse andere Frageformate, die dessen Module wiederverwenden. Weitere abstrakte Typen lassen sich in eigenen

5. Entwicklung

58

Packages definieren. Sie können häufig verwendete Funktionen oder Templates enthalten. Konkrete Fragetypen können diese dann erben und verwenden. Mit dem entwickelten System lassen sich neue Fragetypen durch das simple Hinzufügen eines entsprechenden Packages definieren. Es ist dabei nicht erforderlich, bestehenden Quelltext zu verändern. Meteors Tools zur Verwaltung der Packages können dann genutzt werden, um die Liste verfügbarer Fragetypen je nach Wunsch der Hochschule anzupassen. Somit bildet das System eine optimale Grundlage zur Erforschung neuartiger Frageformate. In den nun folgenden Abschnitten werden bereits für Merian definierte Frageformate vorgestellt.

5.3.1

Multiple Choice

Bestehenden CRS mangelt es häufig an ausführlicher Darstellung der Abstimmungsergebnisse von Multiple-Choice-Fragen. Es werden dabei Informationen zurückgehalten, da viele CR-Systeme die Anzahl der Stimmen pro Antwortoption summieren und das Ergebnis als Säulendiagramm darstellen. Gegenseitige Abhängigkeiten der gewählten Antwortoptionen werden dabei nicht visualisiert. Auch die Reihenfolge der am häufigsten gewählten Kombinationen aus Antwortoptionen ist so nicht ersichtlich. Durch eine interaktive Anzeige lässt Merian eine sehr detaillierte Untersuchung der Ergebnisse zu. Abb. 5.6 (a) zeigt, wie in Merian durch ein Chord-Diagramm die Abhängigkeiten zwischen gewählten Antwortoptionen dargestellt wird. Abb. 5.6 (b) zeigt die meistgewählten Kombinationen aus Antwortoptionen. Durch diese erweiterten Visualisierungen der Ergebnissen können Studierende einen besseren Eindruck der Meinungen ihrer Kommilitonen erhalten, da auch die am häufigsten gewählten Kombinationen aus Antwortoptionen ersichtlich sind.

5. Entwicklung

59

(a)

(b) Abbildung 5.6: Merians Darstellung der Abstimmungsergebnisse einer Multiple-Choice-Frage unter Verwendung eines Chord-Diagramms (a) und als Anzeige der meistgewählten Kombinationen aus Antwortoptionen (b). Grafik (b) gekürzt.

5. Entwicklung

5.3.2

60

Number

Bei diesem gängigen Frageformat (s. 3.3) geben die Teilnehmer eine ganze Zahl an. Dabei kann es sich um die Abschätzung eines Geldbetrags oder das Ergebnis einer mathematischen Aufgabe handeln. Der Dozierende sieht die angegebenen Zahlen der Teilnehmer. Häufig nutzen CRS hier nicht das volle Potential der Darstellung der Resultate. Auch bei diesem Frageformat gab es daher Verbesserungspotential. Für Nutzer mobiler Endgeräte wurde die Eingabe erleichtert, indem das Input-Feld auf den Typ „number“ gesetzt wurde. Dadurch zeigen mobile Geräte direkt eine Tastatur an, welche nur Zahlen enthält. Dies erleichtert die Eingabe und verringert die notwendige Interaktion mit dem Eingabegerät. Andernfalls würde zunächst die Tastatur für Buchstaben auftauchen, und die Nutzer müssten manuell zur Zahlentastatur wechseln. Dieser unnötiger Zwischenschritt wurde somit umgangen. Dies ist ein Beispiel für die Erfüllung der Anforderungen Interaktionsarme Bedienbarkeit und Intuitive Bedienbarkeit (s. 4.3). Bei der Darstellung des Resultats lässt sich der Box-Whisker-Plot nutzen, um die Ergebnisse passend zu visualisieren, da dieser Minimum, Durchschnitt, Median und Maximum enthält. Dies zeigt Abb. 5.7. Sollten sich bei einer Frage viele Stimmen auf wenige Zahlen verteilen, eignet sich die Häufigkeitsverteilung besser zur Darstellung. Die Ansicht kann daher entsprechend gewechselt werden.

5.3.3

Point-And-Click

Zwei der neun für die Marktübersicht (s. 3.2) untersuchten Systeme boten den Point-And-Click-Fragetyp an. Dabei antworten die Studierenden auf eine Aufgabenstellung des Trainers, indem sie eine gewisse Stelle eines vorgegebenen Bildes auswählen. Dieses Frageformat ist interdisziplinär einsetzbar und bietet viele Anwendungsmöglichkeiten, wie z. B. das Identifizieren der maximalen Steigung einer Kurve oder das Auffinden eines Fehlers in einem

5. Entwicklung

61

Abbildung 5.7: Merians Darstellung der Abstimmungsergebnisse einer Number-Frage unter Verwendung des Box-Whisker-Plots.

UML-Diagramm. Somit lassen sich die Mechanismen zur Konzentration der Aufmerksamkeit auf einen bestimmten Aspekt sehr gut umsetzen. In Merian stehen zwei unterschiedliche Ansichten des Ergebnisses zur Verfügung: Einerseits die reinen Antworten, wie in Abb. 5.8 (a), andererseits eine daraus generierte Heatmap, wie in Abb. 5.8 (b) dargestellt.

5.3.4

Smiley Reports

Bei diesem Frageformat handelt es sich um ein Hilfsmittel zum Einsammeln von Feedback der Studierenden für den Lehrenden. Es erweitert damit den Funktionsumfang typischer CRS. Der Lehrende erhält durch dieses Frageformat nach jedem Seminar die Möglichkeit, die Zufriedenheit der Studierenden mit der Lehrveranstaltung zu erfahren. Dazu können die Teilnehmer ihre Zufriedenheit angeben, indem diese zwischen drei Smileys auswählen, die ihre jeweilige Einstellung repräsentieren. Dies zeigt Abb. 5.9 (a). Der Dozierende erhält daraufhin die Verteilung der Stimmen zwischen „Zufrieden“, „Neutral“ und „Unzufrieden“. Somit erkennt er, ob Verbesserungsbedarf besteht. Dies ist in Abb. 5.9 (b) dargestellt. Alternativ kann mit diesem Frageformat auch die Einstellung von Studierenden zu anderen Themen ermittelt werden. Der Fragetyp ist somit sowohl zur Evaluation der Lehrveranstaltung, als auch als didaktisches Mittel einsetzbar.

5. Entwicklung

62

(a)

(b) Abbildung 5.8: Merians Darstellung der Abstimmungsergebnisse einer Point-and-Click-Frage als Rohdaten (a) oder Heatmap (b).

5.3.5

Likert Scale

Bei der Likert Skala handelt es sich um ein Verfahren zur Einstellungsmessung, wobei unter Einstellung die gefühlsmäßige, gedankliche und handlungsgemäße Disposition gegenüber einem Umweltaspekt verstanden wird. Die Einstellung wird anhand von mehreren Aussagen (Items) gemessen, die von den Befragten auf einer kontinuierlichen Skala von sehr positiv (starke Zustimmung) bis sehr negativ (starke Ablehnung) bewertet werden. Es gibt

5. Entwicklung

63

(a)

(b) Abbildung 5.9: Merians Smiley-Reports-Frageformat. (a) zeigt das Antwortformular aus Sicht der Teilnehmer und (b) die Abstimmungsergebnisse aus Sicht des Trainers.

dabei das Konzept, eine Einstellung anhand mehrerer Items zu messen, um Messfehler zu minimieren. Deshalb sollen die Items einer Skala in der Theorie parallele Tests darstellen, die jeweils dasselbe messen [6]. Von den in der Marktübersicht (s. 3.2) untersuchten CRS bot lediglich ARSnova dieses Frageformat an. Es ließen sich hier nur Skalen mit einem einzigen Item erstellen, weshalb eine Minimierung der Messfehler nicht möglich ist. Daher wurde dieses Frageformat für Merian so überarbeitet, dass die Skalen aus mehreren Items bestehen können.

5. Entwicklung

5.3.6

64

Zusammenfassung

Die erstellten Frageformate erlauben es den Dozierenden in gewissen Situationen einfacher Fragen zu finden, welche die verschiedenen didaktischen Ziele erreichen. Obwohl einzelne CRS häufig nur über wenige Frageformate verfügen, bieten die Systeme im Verbund bereits eine große Auswahl an Fragetypen, weshalb sich die Erkundung gänzlich neuartiger, fächerübergreifend einsetzbarer Frageformate als sehr schwierig entpuppte. Manche Frageformate fanden sich lediglich in veralteten, nicht mehr einsetzbaren CR-Systemen. Mit Merian entsteht ein CRS, das diese vielen unterschiedlichen Frageformate in ein einziges System zusammenfassen wird. Bisher wurden dabei hauptsächlich interdisziplinär einsetzbare, bereits existierende Frageformate umgesetzt. Manche Typen konnten erweitert werden, wovon häufig hauptsächlich die Visualisierung der Resultate profitierte. Noch offen steht die Erkundung von fachgebundenen Frageformaten. Diese wird sich voraussichtlich einfacher gestalten, als die Erfindung neuartiger, interdisziplinärer Fragetypen, da dabei die in den jeweiligen Fachbereichen üblichen Notationen, Diagramme, Skizzierungsarten und Darstellungsformen verwendet werden können. Von den in der Marktübersicht (s. 3.2) untersuchten Systemen bot lediglich Learning Catalytics fachgebundene Fragetypen. Deshalb liegt in der Erschaffung neuer, interdisziplinär einsetzbarer Frageformate vermutlich noch großes Potential. Wie gut sich die entwickelten Frageformate in der Realität einsetzen lassen, gilt es noch zu erforschen. Dies wurde bislang noch nicht getestet.

5.4

Testen

Der wohl größte Nachteil Meteors ist, dass es bisher keine integrierte Methode gibt, entwickelte Anwendungen vollständig zu testen. Zwar lassen sich Tests für erstellte Packages ausführen (durch TinyTest), allerdings ist dessen API nicht dokumentiert. Ferner kann die eigentliche Logik der Anwendung da-

5. Entwicklung

65

durch nicht geprüft werden – da sich TinyTest nur auf Packages beschränkt. Weiterhin gibt es bisher nur ein einziges, unfertiges Buch30 , das sich mit dem Testen von Meteor-Anwendungen auseinandersetzt. Dieses hat derzeit lediglich drei Kapitel. Wie aus der Roadmap Meteors31 ersichtlich, ist ein offizielles Test-Frameworks aktuell das zweitmeist gewünschte Feature und für Meteor Version 1.1 vorgesehen. Aus diversen Versuchen unterschiedliche Test-Frameworks mit Meteor zu verbinden, kristallisierte sich bei der Entwicklung Merians heraus, dass diese an Meteors Reaktivität scheitern. Weiterhin sind die vorhandenen Test-Frameworks entweder für das Frontend oder für das Backend ausgelegt. Für Meteor-Anwendungen ist es allerdings notwendig, beides zu testen und insbesondere deren Zusammenspiel. Daher gibt es zwei explizit auf Meteor ausgelegte Test-Frameworks: Laika32 und RTD33 . Beide befinden sich noch in der Entwicklung und konnten nicht zufriedenstellend mit Merian verbunden werden. Deshalb wurde eine eigene Teststrategie entworfen: Während der Entwicklung ist es hilfreich, wenn potentielle Fehler so frühzeitig wie möglich gemeldet werden. Daher wurde JSHint34 mit einer speziell auf Meteor ausgelegten Konfiguration in den verwendeten Editor eingebunden. Somit konnten Fehler bereits beim Verfassen des Quelltexts erkannt werden. Für die ausführlicheren Tests in Merian ergab sich folgender Ansatz: Die Logik Merians ist ohnehin großteils in Packages unterteilt. Daher lässt sich TinyTest hier gut für Unit-Tests einsetzten. Weiterhin wurde Nightwatch.js 35 für End-To-EndTests eingebunden. Dieses führt in JavaScript geschriebene Selenium-Tests auf der Maschine des Entwicklers aus, wodurch die nicht durch TinyTest erreichbaren Programmteile abgedeckt werden können. Für Load-Tests wird 30 31 32 33 34 35

http://testingmeteor.com/ http://roadmap.meteor.com/ http://arunoda.github.io/laika/ http://rtd.xolv.io/ http://www.jshint.com/ http://nightwatchjs.org/

5. Entwicklung

66

PhantomJS36 eingesetzt. Diese Test-Strategie ist zugegebenermaßen nicht optimal, da es ihr z. B. an Code-Coverage Analyse fehlt. Allerdings ist abzuwägen, ob es sich auszahlt eine ausführlichere Lösung zu erstellen, wenn diese bei Release des offiziellen Test-Frameworks vermutlich hinfällig wird.

5.5

Continuous Integration

Für die Tests in Merian wurde derzeit noch kein Test-Environment eingerichtet, da noch kein entsprechender Server bereitsteht. Alle Tests werden bisher direkt im Development-Environment ausgeführt. Um dennoch minimale Continuous Integration (CI) zu bieten, wurde ein eigenes System geschrieben. Vor jedem Einchecken in die Versionsverwaltung wird dieses durch eine Pre-Commit-Hook von Git37 aus gestartet. Es führt dann die vorhandenen Tests aus und lehnt den Commit im Fehlerfall ab. Das System generiert dabei eine HTML-Datei, anhand derer sich die fehlgeschlagenen Tests identifizieren lassen. Sollten alle Tests fehlerfrei sein, wird der Commit ausgeführt und es werden durch Plato38 Metriken erzeugt. Zudem wird automatisch die Versionsnummer der Anwendung erhöht. Teile der erzeugten Metriken sind in Abb. 5.10 dargestellt. Das Deployment wird derzeit nicht von der CI übernommen, da dieses trivial von der Kommandozeile aus geschehen kann – wie im nachfolgenden Kapitel erklärt.

5.6

Deployment

Meteor bietet die Möglichkeit Anwendungen auf deren Server zu deployen. Dazu muss lediglich der Befehl meteor deploy von dem ProjektVerzeichnis aus auf der Kommandozeile eingegeben werden. Meteor bündelt 36 37 38

http://phantomjs.org/ http://git-scm.com/ https://github.com/es-analysis/plato

5. Entwicklung

67

Abbildung 5.10: Teile der durch Plato erzeugten Metriken Merians.

dann automatisch, lädt das Bündel zu Meteors Servern und stellt eine Datenbank bereit. Allerdings sind Meteors Server derzeit nur für Testzwecke (interne Beta-Versionen, Demos, usw.), nicht aber für den produktiven Einsatz gedacht. In Zukunft wird Meteor unter dem Namen Galaxy einen Service bereitstellen, der speziell für das Hosting von Meteor-Anwendungen ausgelegt ist. Alternativ gibt es die Möglichkeit Merian zu bündeln und dieses dann auf

5. Entwicklung

68

einem eigenen Server zu betreiben. Dabei kann eine eigene Datenbank und ein eigener Mailservice genutzt werden. Ebenfalls lassen sich wieder Service Provider für diese Dienste verwenden. Um mehr Kontrolle über den eingesetzten Server zu haben wurde für Merian eine Instanz bei Amazon Elastic Compute Cloud (Amazon EC2)39 verwendet. Das hervorragende Meteor Up40 wird dabei genutzt um die MeteorAnwendung zu Bündeln, zum Server zu laden und diesen initial zu konfigurieren. Die Datenbank wird von dem Service Provider MongoHQ41 geliefert. Sie ist so bei Bedarf problemlos vergrößerbar und es werden regelmäßige Backups erstellt. Für das Versenden von Emails nutzt Merian den Service Provider Mailgun42 .

5.7

Skalierung

Meteor ist noch sehr jung. Deshalb haben sich hinsichtlich der Skalierung von Anwendungen noch kaum Erfahrungswerte entwickelt. Sicher ist, dass neben Meteors eigenen Problemen auch einige aus anderen Frameworks bekannte Probleme zu lösen sind. Um die Meteor-Anwendung zu entlasten kann dieser das Ausliefern statischer Dateien abgenommen werden. Deshalb werden für Fragen notwendige Bilder von Merian direkt in einem Amazon S3 43 Bucket gespeichert. Der Browser der Anwender ruft die Dateien direkt von dort ab, wodurch der Server entlastet wird. Um die in der Anwendung enthaltenen statischen Dateien auszuliefern, wurde Meteor ein nginx 44 Server als Reverse Proxy vorgeschaltet. Damit wird auch hier die Anwendung entlastet, da die Dateien nicht über Meteor ausgeliefert werden. Ferner können die Dateien so verkleinert übertragen werden. Dazu wurde ein Cronjob eingerichtet, der aus den sta39 40 41 42 43 44

https://aws.amazon.com/de/ec2/ https://github.com/arunoda/meteor-up http://www.mongohq.com/ http://www.mailgun.com/ http://aws.amazon.com/de/s3/ http://nginx.org/

5. Entwicklung

69

tischen Dateien eine gzip-Version erstellt. Somit konnten weit über 50% der Gesamtgröße der Dateien eingespart werden, wodurch die Ladezeit deutlich verbessert wird. Um Echtzeit-Fähigkeiten liefern zu können, müssen für jeden verbundenen Client serverseitig spezielle Informationen gespeichert werden, wie z. B. die aktuellen Subscriptions des Clients (s. 5.2.2). Werden mehrere parallele Server mit Load Balancing betrieben, so enthält nur der zuletzt genutzte Server diese Informationen, weshalb es notwendig ist, dass die weitere Kommunikation mit diesem Server stattfindet und daher der Load Balancer den Client wieder demselben Server zuteilen muss – man spricht hier von „Sticky Sessions“. Der in nginx enthaltene Load Balancer unterstützt dies. Da nginx zum Ausliefern der statischen Dateien ohnehin Meteor vorgeschaltet ist, kann es zukünftig problemlos auch zur Lastverteilung eingesetzt werden. Ein weiterer Vorteil des Einsatzes des Webservers nginx ist, dass dieser als Reverse Proxy und zur SSL Termination verwendet werden kann. Für Merian wurde somit die Sicherheit durch Verschlüsselung erhöht, ohne dabei die Meteor-Anwendung mit der Verwaltung der Verschlüsselung zu belasten. Werden mehrere Instanzen der Anwendung auf unterschiedlichen Servern betrieben, und verwenden diese dieselbe Datenbank, so ist es für die EchtzeitFeatures von Meteor notwendig, dass Änderungen, die von einer Instanz ausgehen, unverzüglich auch in den anderen Instanzen sichtbar sind. In früheren Versionen Meteors wurde dazu ein aufwändiger Poll-And-Diff -Algorithmus verwendet, der alle 10 Sekunden prüft ob die Daten in der Datenbank geändert wurden und dementsprechend die Clients benachrichtigt. Dieser rechenintensive Vorgang kann dank dem von MongoDB bereitgestellten Operations Log45 (Oplog) eingespart werden. Alle die Datenbank modifizierenden Operationen sind im Oplog enthalten. Aus diesen berechnen neuere Versionen Meteors wesentlich schneller, welche Änderungen sich ergeben. Da die Änderungen direkt im Oplog enthalten sind, entfällt so auch die Abfrage der Datenbank bei auftretenden Modifikationen. Somit kann das regelmäßige 45

https://github.com/meteor/meteor/wiki/Oplog-Observe-Driver

5. Entwicklung

70

Polling der Datenbank vermieden werden, wodurch diese entlastet wird. Die Performanz von MongoDB wurde durch passendes Setzen der Indizes erhöht. Dies ermöglicht sehr schnelle Lese-Operationen für bestimmte Teile der Daten, wovon die Anwendung insgesamt profitiert. Zudem wird ein Index der Kurz-Id der Seminare eingesetzt, um Duplikate zu vermeiden (s. 5.2.2). Somit wird sichergestellt, dass es nie zwei aktive Seminare mit derselben Kurz-Id gibt. Dies ist notwendig, da sonst durch die Kurz-Id nicht eindeutig bestimmbar wäre, am Fragestrom welches Dozenten sich die Teilnehmer anmelden wollen. MongoDB ist selbst gut skalierbar. Es können die allgemein etablierten Methoden verwendet werden, ohne speziell auf Meteor zu achten.

5.8

Konformitätsbewertung

Das entstandene System erfüllt alle bisher getesteten Anforderungen. Spezielle Anforderungen (z. B. Intuitive Bedienbarkeit, Skalierbarkeit) konnten noch nicht auf Erfüllung getestet werden, da diese tatsächliche Teilnehmer erfordern. Das System wurde bislang aber noch nicht produktiv eingesetzt. Die Anforderungen sind in Tab. 5.3 aufgelistet. Aufgrund des webbasierten Ansatzes ist das System installationslos nutzbar. Durch das Absehen von Lizenzgebühren gegenüber den Studierenden können diese das System ohne vorhergehende Konfiguration nutzen. Die Kosten des CRS hängen nicht von der Anzahl der Teilnehmer ab, da die Studierenden ihre eigenen Geräte verwenden können. Es ist somit nicht notwendig für jeden Teilnehmer einen eigenen Clicker anzuschaffen, wodurch der Preis linear mit der Teilnehmerzahl steigen würde. Da die Teilnehmer ihre eigenen Geräte verwenden entfällt der Verwaltungsaufwand der Clicker komplett. Das entstandene System wird dank Load Balancing sehr gut skalieren. Dies gilt es in der Realität allerdings noch nachzuweisen. Bootstraps Ansatz Mobile First hilft durch Responsive Design das Layout an Displays unterschiedlicher Größen anzupassen. Das unterbrechungsfreie Antworten konnte durch Meteor sehr

5. Entwicklung

71

leicht realisiert werden. Ebenfalls hilft Meteor das System mit vielen Geräten nutzbar zu machen. Zur Abstraktion der unterschiedlichen Eigenschaften der Browser wird jQuery genutzt, das häufig einen einheitlichen Weg bietet mit den Browsern zu interagieren ohne speziell auf deren Eigenheiten einzugehen. Ob die intuitive Bedienbarkeit tatsächlich erreicht wurde steht noch offen. Durch die kurzen Identifier der Seminare können die Studierenden diese mit nur wenigen Eingaben erreichen. Alternativ können Sie auch den QRCode scannen. Nahm ein Studierender bereits an einem Seminar einer gewissen Veranstaltung teil, werden zukünftige Seminare derselben Veranstaltung auf dessen Startseite automatisch angezeigt. Auch hier werden den Teilnehmern unnötige Eingaben erspart. Letztlich wurde das System so gestaltet, dass es auf Peer Instruction zugeschnitten ist. Hier wurde besonderer Wert darauf gelegt, dass sich bereits gestellte Fragen trivial wiederholen lassen. Auch werden keine weiteren Stimmen zu einer Abstimmung angenommen, nachdem der Dozierende das Ergebnis verbreitet hat. Auch einige nicht in den Anforderungen bestimmten Funktionen wurden mit in das System verbaut. So wird beispielsweise durch eine gesicherte Verbindung die Vertraulichkeit der übertragenen Informationen gewährleistet. Die Erstellung von Frageformaten für Merian ist modular, weshalb das System eine gute Grundlage zum Experimentieren mit neuen Formaten bietet. Es wurden bereits einige interdisziplinär einsetzbare Frageformate geschaffen. Offen steht weiterhin die Implementierung von fachgebundenen Fragetypen. Allgemein gilt es noch zu erkunden, ob sich die neuen Frageformate in der Realität als nützlich erweisen und das Lernen der Studierenden entsprechend fördern.

5. Entwicklung

72

Tabelle 5.3: Erfüllte Anforderungen. Anforderung

Erfüllt durch

Ohne Installation nutzbar

webbasierter Ansatz

Geringer Konfigurationsaufwand

Programmierung

Kosten

webbasierter Ansatz

Geringer Verwaltungsaufwand

webbasierter Ansatz

Skalierbarkeit

Meteor mit Skalierungstaktiken (s. 5.6)

Mobile First

Bootstrap

Unterbrechungsfreies Antworten

Meteor

Unterstützt Vielzahl an Geräten

Meteor, jQuery

Intuitive Bedienbarkeit

-

Interaktionsarme Bedienbarkeit

Programmierung

PI Kompatibilität

Programmierung

Kapitel 6 Schluss 6.1

Zusammenfassung

Für diese Arbeit wurde eine Marktübersicht bestehender webbasierter CRS geschaffen. Diese ergab, dass aktuelle Lösungen häufig nur wenige Fragetypen bieten, denen es oft an einer ausführlichen Darstellung der Abstimmungsergebnisse fehlt. Weiterhin boten lediglich drei der neun untersuchten Systeme anonyme Teilnehmer, Peer Instruction Kompatibilität und ein zugängliches Layout (Responsive Design / Mobile First). Viele der Systeme waren unnötig kompliziert zu bedienen. Es wurde daher ein eigenes System entwickelt, das die Probleme aktueller CRS meidet. Das System ist sehr einfach um zusätzliche Frageformate erweiterbar und visualisiert Abstimmungsergebnisse in zuvor nicht dagewesener Form. Durch viele unterschiedliche Frageformate erlaubt es den Trainern Fragen zu erstellen, die zuvor nicht möglich waren. So können Dozierende leichter Fragen kreieren, die ihren Studierenden dabei helfen die inhaltlichen, kognitiven und metakognitiven Lernziele zu erreichen. Die Entwicklung des Systems war aufgrund optimal abgestimmter Werkzeuge schnell umsetzbar. Das entstandene System ist sehr schlicht, da es in einer einzigen Programmiersprache geschrieben ist und nur sehr wenige Bibliotheken verwendet. Neue Frageformate sind mit nur geringer Kenntnis 73

6. Schluss

74

der Interna des Systems erstellbar und trivial durch Meteors bereitgestellte Package Management Tools verwaltbar. Das entwickelte CRS meidet Probleme bestehender Lösungen und liefert eine gute Grundlage für die weitere Erforschung neuartiger Frageformate.

6.2

Fazit

Besonders leicht umsetzbar war der Push Mechanismus, der für den Fragestrom des Dozierenden benötigt wurde. Dank Meteor musste für die EchtzeitFeatures kaum eigene Programmierarbeit geleistet werden. Weiterhin bot Meteors mitgeliefertes Accounts-System eine optimale Grundlage. Es konnte sich bei der Entwicklung von Merian auf die tatsächlich notwendigen Features konzentriert werden. Auch das häufig zur Visualisierung der Abstimmungsergebnisse genutzte D3 erleichterte die Programmierung enorm. Entgegen ursprünglichen Befürchtungen ergaben sich aus Meteors BetaStatus keine Komplikationen. Nach und nach erscheinende Features Meteors konnten genutzt werden, um die Anwendung weiter zu verbessern. Insbesondere die neue Rendering Engine, Blaze, vereinfachte den Code immens, da so externe Libraries verwendet werden konnten, ohne dass diese speziell an Meteor angepasst werden mussten. Auch das in Meteor Version 0.7.0 eingeführte Oplog Tailing legte einen guten Grundstein um Anwendungen besser skalierbar zu machen, wovon auch Merian profitiert. Problematisch ist, dass es noch an kompatiblen, ausgereiften Test-Frameworks mangelt, die auf die speziellen Anforderungen Meteors zugeschnitten sind. Es mussten hier viele unterschiedliche Ansätze ausprobiert werden, um zu einer vorläufig akzeptablen Lösung zu gelangen. Die Meteor Development Group plant bereits ein offizielles Test-Framework zu entwickeln. Dieses wird voraussichtlich viele der derzeit bestehenden Probleme lösen, wie z. B. die Ausführung von Tests, welche das Zusammenwirken von Client und Server prüfen. Bis dahin wird die provisorisch erstellte Lösung die Code-Qualität entsprechend sichern.

6. Schluss

75

Im Augenblick wird beim initialen Laden die gesamte clientseitige Logik geladen. Auch Kursteilnehmer laden unnötigerweise die Skriptteile für die Logik der Trainer mit. Verbesserungspotential wäre hier das modulare Laden unterschiedlicher Funktionen, basierend auf der Rolle des Benutzers. Dadurch würde sich die Ladezeit der Anwendung für Studierende verkürzen. Auch durch das für Meteor angekündigte serverseitige Rendering ließe sich die Wartezeit bis zur Anzeige der initial aufgerufenen Seite verringern.

6.3

Ausblick

Offen steht noch die Evaluation der Features, sowie der Benutzbarkeit und der Akzeptanz des Systems. Hier bieten sich die in [10] genannten Methoden (System Usability Scale, Technology Acceptance Model) an, die ebenfalls zur Evaluation von PINGO eingesetzt wurden. Die Implementierung von noch mehr neuen Fragetypen für Merian steht ebenfalls aus. Während in dieser Arbeit geschaffene Frageformate sehr interdisziplinär einsetzbar gehalten wurden, können nun noch weitere für spezifische Fachbereiche geschaffen werden. Durch das kontinuierliche Integrieren der Updates für Meteor wird sich das CRS zukünftig weiter verbessern können. Insbesondere das offizielle TestFramework wird von großem Nutzen sein. Doch auch von kleineren Neuerungen in Meteor wird Merian profitieren können, wie z. B. dem angekündigten einheitlichen Weg zur Internationalisierung geschriebener Anwendungen. Interessant wäre die Entwicklung eines Systems zum Austausch von etablierten Fragen. Das System könnte sowohl als Archiv für Fragen dienen, als auch zum Austausch der Fragen zwischen unterschiedlichen CRS. Somit könnte die Schwelle neue CR-Systeme auszuprobieren gesenkt werden, da sich dadurch bereits in ein System integrierte Fragen problemlos in ein anderes System übertragen ließen.

Anhang A Erstellung eines Frageformats Anhand des Beispiels Number (s. 5.3) wird in diesem Anhang gezeigt, wie die Erweiterung Merians um ein neues Frageformat abläuft.

A.1

Geplantes Frageformat

Wie bereits in 3.3 und 5.3 erwähnt, geben im Frageformat Number die Studierenden eine ganze Zahl als Antwort an. Der Trainer soll bei der Erstellung der Frage einen Bereich für akzeptierte Werte vorgeben können. Somit kann er im Kontext der Frage ungültige Antworten ausschließen. Nach der Abstimmung werden dem Dozierenden die Resultate als Box-Whisker-Plot und als Häufigkeitsverteilung dargestellt.

A.2

Voraussetzungen

Für die folgende Erklärung muss die Anwendung Merian bereits in einem Verzeichnis vorliegen. Alle nachfolgenden Anweisungen auf der Kommandozeile sind von diesem Verzeichnis aus durchzuführen. Weiterhin muss Meteor auf dem Rechner des Entwicklers installiert sein. Meteor muss Merian im Entwicklungsmodus ausführen. Dies ist durch die Eingabe der Anweisung meteor run auf der Kommandozeile möglich. 76

A. Erstellung eines Frageformats

A.3 A.3.1

77

Umsetzung Definition des Packages

Zunächst ist ein neues Package anzulegen. Dazu muss im Verzeichnis packages ein Ordner namens crs-questions-number erstellt werden1 . In diesem Verzeichnis ist die Datei package.js anzulegen. Diese liefert Informationen über das Package. Genauer ist dies in 5.2.1 erklärt. Deren Inhalt zeigt Programm A.1.

A.3.2

Definition des Frageformats

Wie ein neues Frageformat definiert wird ist in 5.3 beschrieben. In der im Package anzulegenden Datei type.js sind alle Informationen zum neuen Frageformat enthalten. Diese zeigt Programm A.4. Erstellung einer Frage Um eine neue Frage zu Erstellen wird dem Nutzer das Template createNumberQuestion angezeigt. Dieses zeigt Programm A.2. Die zu diesem Template gehörende Logik enthält Programm A.3. Sendet der Dozierende das Formular des Templates ab, wird auf dem Client ein die Frage repräsentierendes Objekt question erstellt. Dieses prüft das CRS anhand der im Frageformat definierten Methode process serverseitig auf Korrektheit. Insbesondere erfolgt hier eine Validierung des angegebenen Bereichs für gültige Zahlen der Antworten. Die Frage wird weiterhin durch question.pick auf die wesentlichen Eigenschaften beschränkt. Die Methode process ist in Programm A.4 dargestellt. Anschließend wird das Objekt vom CRS weiter modifiziert und in die Datenbank übernommen. 1

Die Namen der Packages der Frageformate beginnen in Merian mit dem Präfix

crs-questions-. Dies ist nicht zwingend erforderlich, verhilft aber zu einer besseren Struktur.

A. Erstellung eines Frageformats

Programm A.1: Datei package.js für das Frageformat Number. 1 2 3

Package.describe({ summary: 'CRS: Number question' // beschreibt das Package });

4 5

Package.on_use(function (api) {

6 7

// Andere Packages, die von diesem Package genutzt werden

8

api.use([ 'standard-app-packages',

9 10

'underscore',

11

'iron-router',

12

'BSAlerts',

13

'd3',

14

'crs-questions-base',

15

'less',

16

'reactive-vars',

17

'notifications'

18

]);

19 20

// Datei dem Package hinzufügen, die isomorph genutzt wird

21

api.add_files([ 'type.js'

22 23

]);

24 25

// Von Package ausschließlich auf Client genutzte Dateien

26

api.add_files([

27

'answer/answer.html', 'answer/answer.js',

28

'create/create.html', 'create/create.js',

29

'result/result.html', 'result/result.js',

30

'result/boxplot.js',

31

'result/frequency.js',

32

'result/result.less'

33 34

], 'client'); });

78

A. Erstellung eines Frageformats

Programm A.2: Template zur Erstellung einer Frage des Typs Number in create/create.html. 1 2



3

{{> questionWarnings}}

4

{{> questionTextBox}}

5 6

{{#content}}

7

Optional input range

8



9



10

Minimum

11 12



13



14



15 16



17



18

Maximum

19 20



21



22



23 24 25



26 27

Optional image

28

{{> imageUpload}}

29

{{/content}}

30 31

{{> questionCreateButton}}

32



33



79

A. Erstellung eines Frageformats

80

Programm A.3: Logik zur Erstellung einer Frage des Typs Number in create/create.js. 1 2

Template.createNumberQuestion.events({ 'submit form': function (event, template) { event.preventDefault();

3 4 5

var question = new Question({type: 'number'});

6

question.setText(template.find('#question-text').value)

7

question.setImage(Session.get('S3data'));

8

// input range

9 10

var min = template.find('#minimum').value,

11

max = template.find('#maximum').value;

12

question.range = {

13 14

'min': min.length ? parseInt(min, 10) : -Infinity,

15

'max': max.length ? parseInt(max, 10) :

Infinity

};

16 17 18

var bsAlerts = new BSAlerts(event.target);

19

bsAlerts.reset();

20

this.lecture.addQuestion(question, function (error) {

21

if (error) {

22

bsAlerts.warning(error.reason);

23 24

}

25

});

26

}

27

});

Beantwortung einer Frage Das CRS zeigt den Teilnehmern zur Beantwortung einer Frage des Formats Number das Template answerNumberQuestion. Dieses ist in Programm A.5 enthalten. Die zugehörige Logik ist in Programm A.6 dargestellt.

A. Erstellung eines Frageformats

Programm A.4: Definition des Frageformats Number in type.js. 1 2

Question.Types.extend('response-base', 'number', { name: 'Number',

3 4

process: function (question) { check(question.range, { min: Number, max: Number });

5 6 7

var min = question.range.min, max = question.range.max;

8

if (isNaN(min) || isNaN(max) || min >= max) { throw new Meteor.Error(406, 'Invalid range.');

9

}

10 11 12

question.pick('text', 'type', 'image', 'range');

13

question.responses = [];

14

return question;

15

},

16 17

answer: function (response, question) { check(response, Number);

18 19

if (isNaN(response)) {

20

throw new Meteor.Error(400, 'No valid answer provided');

21

}

22 23 24

var range = question.range;

25

if (response < range.min || response > range.max) { throw new Meteor.Error(406, 'Number not within valid range.');

26 27

}

28

return { $push: {'current.responses': response} };

29

},

30 31

createTemplate: 'createNumberQuestion',

32

answerTemplate: 'answerNumberQuestion',

33

resultTemplate: 'resultNumberQuestion'

34

});

81

A. Erstellung eines Frageformats

82

Programm A.5: Template zur Beantwortung einer Frage des Typs Number in answer/answer.html. 1



2 3 4



5 6

{{question.text}}

7 8

{{> image question.image}}

9 10 11 12

Enter your answer here

13 14



15



16 17



18 19 20

Submit

21 22



Sendet ein Teilnehmer das Antwortformular aus answerNumberQuestion ab, wird aus der Antwort des Teilnehmers ein Objekt erzeugt. Dieses wird an die Methode answer aus Programm A.4 weitergegeben. Dort wird die Antwort serverseitig auf Korrektheit geprüft. Die angegebene Zahl muss ganzzahlig sein und innerhalb des vorgegebenen Bereichs liegen. Danach wird die Antwort in eine Datenbankoperation umgewandelt. Die Operation wird an das CRS übergeben und von diesem weiter verfeinert. Durch das Anwenden der Operation auf die Datenbank wird die Stimme abgegeben.

A. Erstellung eines Frageformats

83

Programm A.6: Logik zur Beantwortung einer Frage des Typs Number in answer/answer.js. 1

Template.answerNumberQuestion.events({ 'submit form': function (event, template) {

2

event.preventDefault();

3 4

var answer = template.find('#answer').valueAsNumber;

5 6 7

var bsAlerts = new BSAlerts(event.target);

8

bsAlerts.reset();

9

this.seminar.answer(this.question._id, answer, function (error) {

10

if (error) {

11

bsAlerts.warning(error.reason);

12 13

}

14

});

15

return false;

16 17

}

18

});

Darstellung der Abstimmungsergebnisse Nach der Abstimmung wird dem Dozierenden das Resultat dargestellt. Dazu ruft Merian das Template resultNumberQuestion auf. Teile davon zeigt Programm A.7. Durch die zugehörige Logik in Programm A.8 werden die Ergebnisse der Abstimmung visuell aufbereitet. Für die Visualisierungen werden bei jedem Rendern des Templates die Funktionen renderBoxplot und renderFrequency aufgerufen2 . Diese zeichnen mit Hilfe von D3 den BoxWhisker-Plot und das Diagramm der Häufigkeitsverteilung in die im Template enthaltenen SVG-Elemente. 2

Da beide Funktionen viele Anweisungen enthalten, sind diese aufgrund ihrer ho-

hen Zeilenanzahl hier nicht dargestellt. Die Funktionen sind innerhalb des Packages in result/renderBoxplot.js und result/renderFrequency.js implementiert.

A. Erstellung eines Frageformats

84

Programm A.7: Ausschnitt des Templates zur Darstellung der Abstimmungsergebnisse für eine Frage des Typs Number in result/result.html. 1



2



3



4



5 6

{{min}}

7

Minimum

8



9



10

{{mean}}

11

Mean

12



13



14

{{median}}

15

Median

16



17



18

{{max}}

19

Maximum

20 21



22



23



A.3.3

Integration des Frageformats

Letztlich muss das entstandene Package dem CRS bekannt gemacht werden. Dies ist durch Eingabe von meteor add crs-questions-number auf der Kommandozeile möglich. Meteor bindet daraufhin das Package in die Anwendung ein, wodurch das neue Frageformat verwendet werden kann.

A. Erstellung eines Frageformats

Programm A.8: Logik zur Visualisierung der Abstimmungsergebnisse einer Frage des Typs Number in result/result.js. 1

Template.resultNumberQuestion.created = function () {

2 3

// sort votes

4

this.data.responses.sort(function (a, b) { return a - b;

5

});

6 7

};

8 9

Template.resultNumberQuestion.helpers({ max: function () {

10

return _.last(this.responses);

11

},

12 13

min: function () {

14

return this.responses[0];

15

},

16 17

mean: function () {

18

return Math.round(d3.mean(this.responses) * 10 || 0) / 10;

19

},

20 21

median: function () {

22

return d3.median(this.responses);

23 24

}

25

});

26 27

Template.resultNumberQuestion.rendered = function () {

28

renderBoxplot.call(this);

29

renderFrequency.call(this);

30

};

85

Quellenverzeichnis Literatur [1] Ian Beatty u. a. „Designing effective questions for classroom response system teaching“. In: American Journal of Physics 74.1 (Jan. 2006), S. 31–39 (siehe S. 1, 5, 7–10, 23, 28, 30, 31). [2] Manuel Caeiro-Rodríguez, Juan Gonzalez-Tato und Martín LlamasNistal. „Experiencing a Web-based Audience Response System in engineering lectures“. In: Global Engineering Education Conference. IEEE. 2013, S. 513–519 (siehe S. 14). [3] Tom Coleman und Sacha Greif. Discover Meteor: Building Real Time JavaScript Web Apps. url: https://www.discovermeteor.com/ (siehe S. 35). [4] Robert J Dufresne u. a. „Classtalk: A classroom communication system for active learning“. In: Journal of computing in higher education 7.2 (1996), S. 3–47 (siehe S. 12, 13). [5] Tolga Gok. „The impact of Peer Instruction on collge student’ beliefs about Physics and concpetual understanding of Electricity and Magnetism“. In: International Journal of Science and Mathematics Education 10.2 (2012), S. 417–436 (siehe S. 2, 5). [6] Bert Greving. „Messen und Skalieren von Sachverhalten“. In: Methodik der empirischen Forschung. Hrsg. von Sönke Albers u. a. Gabler, 2007, S. 65–78 (siehe S. 63). 86

Quellenverzeichnis

87

[7] Ioannis Kanakis. „Die sokratische Lehrstrategie und ihre Relevanz für die heutige Didaktik“. In: International Review of Education 43.2-3 (1997), S. 225–240 (siehe S. 4). [8] Robin Kay und Ann LeSage. „Examining the benefits and challenges of using audience response systems: A review of the literature“. In: Computers & Education 53.3 (2009), S. 819–827 (siehe S. 5). [9] Dennis Kundisch u. a. „Classroom Response Systems“. In: InformatikSpektrum 36.4 (2013), S. 389–393 (siehe S. 1, 12, 18, 21, 33). [10] Dennis Kundisch u. a. „Designing a web-based application to support Peer Instruction for very large Groups“. In: International Conference on Information Systems (2012) (siehe S. 16, 18, 20, 21, 25–28, 33, 75). [11] Eric Mazur. Peer Instruction: A User’s Manual. 1997 (siehe S. 4–8, 23). [12] Wolfgang Reinhardt u. a. „PINGO: peer instruction for very large groups“. In: 21st Century Learning for 21st Century Skills. Springer, 2012, S. 507–512 (siehe S. 20, 21, 33). [13] Michael Sievers u. a. „Developing Electronic Classroom Response Apps for a Wide Variety of Mobile Devices: Lessons Learned from the PINGO project.“ In: mLearn. Bd. 955. 2012, S. 248–251 (siehe S. 33). [14] Adi Winteler. „Lehrstrategien, die das aktive Lernen fördern“. In: Workshop I: Aktives und kooperatives Lernen als Förderung des LernEngagements. (Kiel, FH Kiel). 2009. url: http : / / www . fh - kiel . de / fileadmin / data / praesidium / Hochschule _ mit _ Zukunft / Symposium _ Anreize _ in _ Lehre _ und _ Studium / Workshops / Winteler / Workshop _ Aktives_Lernen_Handout_Winteler.pdf (siehe S. 2).

Online-Quellen [15] url: http://www.hd-mint.de/lehrkonzepte/verstehen/peer-instruction/ (besucht am 22. 05. 2014) (siehe S. 7).

Quellenverzeichnis

88

[16] url: http://www1.iclicker.com/student- remote- iclicker- plus (besucht am 25. 06. 2014) (siehe S. 14). [17] url: http://docs.meteor.com/ (besucht am 25. 05. 2014) (siehe S. 35, 38, 44, 46, 47). [18] url: https : / / www . meteor . com / blog / 2013 / 12 / 18 / david - glasser on- scaling- meteor- with- the- mongodb- oplog (besucht am 25. 05. 2014) (siehe S. 41). [19] Tanja Brühl. Hinweise zum Impulsreferat. url: http : / / www . fb03 . uni-frankfurt.de/46036769/impulsreferat.pdf (besucht am 25. 06. 2014) (siehe S. 6). [20] Christoph Thelen. Günther Jauch im Hörsaal oder: Implementierung des Echtzeit-Feedback-Systems ARSnova. url: https : / / dl . dropboxusercontent.com/u/87040050/Guenther_Jauch_im_Hoersaal_ oder_Implementierung_des_Echtzeit-Feedback-Systems_ARSnova-1.pdf (besucht am 25. 06. 2014) (siehe S. 20, 21).