Ausarbeitung - Goethe

Transcription

Fachbereich 12 Informatik und Mathematik
Institut für Informatik
Diplomarbeit
Kooperative Drehbuch-Produktion
von eLearning-Inhalten
Vasyl Kenyuk
Studiengang: Informatik
Frankfurt am Main
7. Oktober 2010
Prüfer: Prof. Dr.-Ing. Detlef Krömker
Eidesstattliche Erklärung
Hiermit erkläre ich an Eides statt, dass ich die vorliegende Diplomarbeit ohne fremde
Hilfe und nur unter Verwendung der zulässigen Mittel sowie der angegebenen Literatur angefertigt habe.
Die Arbeit wurde bisher keiner anderen Prüfungsbehörde vorgelegt und auch noch
nicht veröentlicht.
Frankfurt am Main, den 7. Oktober 2010,
Vasyl Kenyuk
Zusammenfassung
eLearning Kurse sind ein fester Bestandteil im Lernangebot von verschiedensten Institutionen und nden immer mehr Verbreitung. Ihre Beliebtheit liegt vor allem in
der leichten Zugänglichkeit der Kurse und deren nützlichen Funktionalitäten bei deren Benutzung.
Die Erstellung der Inhalte für eLearning Kurse ist ein aufwändiger Prozess, der oft eine Kooperation mit mehreren Fachleuten verlangt. Die Autorenprogramme sind leider
meistens auf die Arbeit mit einem Autor ausgerichtet und bieten kaum Werkzeuge,
die eine Kooperation bei der Erstellung von eLearning Inhalten erleichtern. Für viele
Autoren ist die Verwendung von einem Textbearbeitungsprogramm vorteilhaft, denn
dort sind oft die Funktionalitäten verfügbar, die in den Autorenprogrammen entweder fehlen oder nur teilweise implementiert sind. Diesem Wunsch folgend können die
eLearning Inhalte zunächst in einem Drehbuch erfasst werden, welches eine abstrakte
Beschreibung des geplanten Kurses darstellt. Das Drehbuch bietet dem Autor die
Möglichkeit, sich auf die Inhalte zu konzentrieren, ohne auf die technischen Details
der Implementierung des Kurses achten zu müssen. Des Weiteren können die Inhalte
in einem Textbearbeitungsprogramm erstellt werden und die dort nützlichen Funktionalitäten genutzt werden, sowohl im Bezug auf die Kooperation als auch auf die
Textbearbeitung.
In meiner Diplomarbeit werden die Möglichkeiten der Kooperation bei der Erstellung
von Drehbüchern untersucht und ein Konzept zur automatischen Transformation eines Drehbuches zu einem eLearning Kurs entwickelt. Das Konzept beinhaltet eine
Denition, wie die Inhalte im Drehbuch erfasst werden können, so dass eine anschlieÿende automatische Transformation zu einem Kurs durchgeführt werden kann.
Das Konzept eines Programms, das diese Transformation durchführt, wird ebenfalls
im Lösungskonzept vorgestellt. Da sich eine Kooperation in bestimmten Situationen
durch verschiedene Mittel erreichen lässt, wird in meinem Konzept die Unterstützung
von mehreren Editoren angestrebt. Die erstellten Kurse sollten nach Möglichkeit wiederverwendbar sein und nicht nur auf eine Lernplattform beschränkt bleiben. Deshalb
sieht mein Konzept vor, dass Kurse in einen eLearning Standard überführt werden.
Inhaltsverzeichnis
Abkürzungsverzeichnis
iii
Abbildungsverzeichnis
v
Tabellenverzeichnis
vii
1 Einführung
1
1.1
Zielsetzung und Motivation
. . . . . . . . . . . . . . . . . . . . . . .
1
1.2
Aktuelle Arbeiten . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
2
2 Analyse
5
2.1
Drehbuch
. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
5
2.2
eLearning Inhalte . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
6
2.3
2.4
2.5
2.2.1
HTML . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
7
2.2.2
JavaScript . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
8
2.2.3
Plug-Ins . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
9
Kooperation bei der Erstellung von eLearning-Inhalten
. . . . . . . .
10
. . . . . . . . . . . . . . . . . . . . . . . . . . . . .
10
2.3.1
Übersicht
2.3.2
Computer Supported Cooperative Work
. . . . . . . . . . . .
10
2.3.3
Editoren zur Drehbucherstellung . . . . . . . . . . . . . . . . .
13
2.3.4
Versionskontrollsysteme für Oce-Suiten . . . . . . . . . . . .
17
2.3.5
Koopertative Bearbeitung von Medien
. . . . . . . . . . . . .
18
Autorenwerkzeuge . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
20
E-Learning Standards . . . . . . . . . . . . . . . . . . . . . . . . . . .
24
2.5.1
Übersicht
. . . . . . . . . . . . . . . . . . . . . . . . . . . . .
24
2.5.2
AICC
. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
24
2.5.3
IMS
. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
25
2.5.4
SCORM . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
29
3 Lösungskonzept
35
3.1
Übersicht
. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
3.2
Erfassen der Inhalte über Drehbuchvorlagen
. . . . . . . . . . . . . .
35
35
3.2.1
Kursstruktur
. . . . . . . . . . . . . . . . . . . . . . . . . . .
39
3.2.2
Erfassen der Seiten . . . . . . . . . . . . . . . . . . . . . . . .
40
3.2.3
Verknüpfungen von Inhalten . . . . . . . . . . . . . . . . . . .
41
3.2.4
Integration von Medien . . . . . . . . . . . . . . . . . . . . . .
42
3.2.5
Interaktive Seiten . . . . . . . . . . . . . . . . . . . . . . . . .
43
3.3
Ausgabeformat der Editoren . . . . . . . . . . . . . . . . . . . . . . .
43
3.4
Transformieren des Drehbuches zu einem eLearning Kurs . . . . . . .
44
i
Inhaltsverzeichnis
3.5
3.4.1
Parsen . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
45
3.4.2
Validieren und Filtern
. . . . . . . . . . . . . . . . . . . . . .
47
3.4.3
Ausgabe des Kurses . . . . . . . . . . . . . . . . . . . . . . . .
48
Zusammenfassung . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
49
4 Implementierung
51
4.1
Übersicht
. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
51
4.2
Vorlagen . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
51
4.2.1
MS Word und OO Writer
. . . . . . . . . . . . . . . . . . . .
51
4.2.2
MediaWiki . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
52
4.3
Konvertieren zu HTML . . . . . . . . . . . . . . . . . . . . . . . . . .
54
4.4
Parsen und Interpretieren
. . . . . . . . . . . . . . . . . . . . . . . .
54
4.5
Validieren und Bereinigen
. . . . . . . . . . . . . . . . . . . . . . . .
56
4.6
Ausgabe der Dateien
4.7
Überführung in einen eLearning Standard
. . . . . . . . . . . . . . . . . . . . . . . . . . .
. . . . . . . . . . . . . . .
57
58
5 Zusammenfassung und Ausblick
59
Literaturverzeichnis
61
A Software
63
ii
A.1
Lernplattformen . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
63
A.2
Autorenprogramme . . . . . . . . . . . . . . . . . . . . . . . . . . . .
63
AICC . . . . . . . .
Aviation Industry Computer-Based Training Committee
AJAX . . . . . . . . Asynchronous JavaScript and XML
API . . . . . . . . . .
Application Programming Interface
CAM . . . . . . . . . Content Aggregation Model
CBT . . . . . . . . .
Computer-based Training
CMI . . . . . . . . . . Computer Managed Instruction
CP . . . . . . . . . . .
Content Packaging
CSCW . . . . . . .
Computer Supported Cooperative Work
CSS . . . . . . . . . .
Cascading Style Sheet
ECMA . . . . . . .
European Computer Manufacturers Association
GLC . . . . . . . . .
Global Learning Consortium
HACP . . . . . . . . HTTP AICC Communication Protocol
HTML . . . . . . .
Hypertext Markup Language
IEEE . . . . . . . . . Institute of Electrical and Electronics Engineers
IMS . . . . . . . . . .
Instructional Management Systems
JSP . . . . . . . . . .
JavaServer Pages
LD . . . . . . . . . . .
Learning Design
LOM . . . . . . . . . Learning Object Metadata
MS . . . . . . . . . . . Microsoft
OO . . . . . . . . . . . Open Oce
PIF . . . . . . . . . .
Package Interchange File
PSD . . . . . . . . . . Photoshop Document
QTI . . . . . . . . . .
Question and Test Interoperability
iii
RTE . . . . . . . . .
Run Time Enviroment
SCO . . . . . . . . .
Sharable Content Object
SCORM . . . . . . Sharable Content Object Reference Model
SS . . . . . . . . . . . . Simple Sequencing
SVN . . . . . . . . .
Apache Subversion
UML . . . . . . . . .
Unied Modeling Language
VBA . . . . . . . . .
Visual Basic for Applications
WARP . . . . . . .
Wiki-based Authoring by Rapid Prototyping
WBT . . . . . . . . . Web-based Training
WebDAV . . . . .
Web-based Distributed Authoring and Versioning
WYSIWYG . .
What You See Is What You Get
XHTML . . . . . . Extensible Hypertext Markup Language
XML . . . . . . . . .
Extensible Markup Language
XSD . . . . . . . . .
XML Schema Document
iv
2.1
eXe Editor . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
21
2.2
Erstellung von einem Single Choice Quiz im LernBar Studio
23
2.3
IMS CP Paket . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
26
2.4
Unterschiede zwischen IMS CC und SCORM . . . . . . . . . . . . . .
29
2.5
Beispiel Content Organization . . . . . . . . . . . . . . . . . . . . . .
31
2.6
SCORM API: ein SCO kann die Methoden aufrufen . . . . . . . . . .
33
3.1
Aufteilung des Lösungskonzepts in zwei Bereiche . . . . . . . . . . . .
36
3.2
Eine Textvorlage im Drehbuch, eine HTML-Datei und die generierte
. . . . .
Kursseite . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
38
3.3
Kursstruktur in MediaWiki.
40
3.4
Technisches Konzept der automatischen Transformation von Drehbücher 46
4.1
Dialog zur Auswahl und zum Einfügen einer Vorlage in MediaWiki
4.2
4.3
. . . . . . . . . . . . . . . . . . . . . . .
.
53
Platzhalter für mathematische Formeln mit Angabe des TeX Syntax
im Tooltip . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
53
Validator Basisklasse mit Implementierungen für einzelne Seitentypen
57
v
vi
Tabellenverzeichnis
2.1
Bekannteste eLearning Standards im Vergleich . . . . . . . . . . . . .
24
2.2
Wichtigste Methoden der API . . . . . . . . . . . . . . . . . . . . . .
34
vii
1 Einführung
1.1 Zielsetzung und Motivation
Die Erstellung von qualitativ hohen eLearning Inhalten ist ein zeitaufwändiger und
schwieriger Prozess. Es gibt sowohl speziell für die Produktion von Lernmaterialien
entwickelte Software, als auch allgemeine Programme, mit denen Inhalte erstellt und
bearbeitet werden können. Viele Lernplattformen liefern eigene Werkzeuge für die
Erstellung von Kursen und können dann dadurch spezische Funktionalitäten abbilden.
Für eine Vereinfachung der Arbeit an Inhalten wird bei eLearning Autorenprogrammen meistens ein einfacher WYSISYG Editor eingesetzt. Editoren dieser Art verfügen im Vergleich zu Textbearbeitungsprogrammen nur über einige grundlegende
Funktionalitäten und insbesondere fehlen dort wichtige Hilfsmittel für eine kooperative Arbeit.
Als eine Alternative dazu, können die Inhalte in einem beliebigen Texteditor erfasst
und anschlieÿend in einen Kurs transformiert werden. Da ein eLearning Kurs auf
diese Weise nicht direkt erstellt wird und eine Entkoppelung der Inhalte vom Layout
stattndet, ist dieser Prozess einem Drehbuch ähnlich, in dem man die wichtigsten Konzepte für einen Kurs sammelt. Bei der Erstellung eines Drehbuches sind die
technischen Details der Implementierung zunächst nicht wichtig und der Autor konzentriert sich auf die Inhalte selbst.
Das Ziel dieser Arbeit besteht sowohl in einer Analyse der bestehenden Situation,
als auch im Vorschlag von möglichen Lösungen und der Suche nach neuen, besseren
Wegen bei der kooperativen Produktion von Drehbüchern. Unter Produktion wird
hier nicht nur die Erstellung eines Drehbuches verstanden, sondern auch ein anschlieÿendes Transformieren der Inhalte in einen eLearning Kurs.
1
1 Einführung
1.2 Aktuelle Arbeiten
Ein Versuch, kooperative Arbeit an eLearning Inhalten zu ermöglichen, wurde in
[QGN01] gemacht, wobei die Kooperation hier auf der Ebene eines gemeinsamen Zu-
1
gris auf Daten stattndet. Dabei wird auf den oenen Standard WebDAV
zurück-
gegrien. Die Struktur der Kurse wird in einer XML-Datei gespeichert. Anschlieÿend
werden XML-Dateien zusammen mit Inhalten mit Hilfe von JavaServer Pages, dargestellt. Es ist unklar, wie der Prozess von Erstellung eines Kurses abläuft und ob der
Autor über XML-Kenntnisse verfügen muss. WebDAV wird hierbei wegen Einfachheit
verwendet, da für ein Versionskontrollsystem zusätzliche Software und womöglich die
Einarbeitung der Autoren benötigt wird. Das Ziel dieser Lösung ist in erster Linie,
den Prozess der Aktualisierung der erstellten Kurse zu automatisieren, so dass sich
die Inhalte häug und unproblematisch ändern lassen. Gegenstand dieser Arbeit ist
nicht neue, noch nicht bestehende Kurse zu entwickeln.
In [Jon02] werden die eLearning Standards als Mittel zum Austausch von Kursen
gesehen und damit wird die Kooperation bei der Erstellung von Inhalten ermöglicht.
Diese Art von Kooperation ist vor allem im Sinne von Interoperabilität gemeint, die
eine Wiederverwendung von Kursen mit gleichen Inhalten zwischen unterschiedlichen
Lerninstitutionen erlaubt. Eine gemeinsame Bearbeitung der Inhalte wird dadurch
nicht erreicht.
Als ein Teil des WARP (Wiki-based Authoring by Rapid Prototyping) Systems
[STW09] dient ein Wiki als Autoren-Werkzeug, um die Autoren bei der kooperativen Bearbeitung des automatisch generierten Entwurfes eines eLearning Kurses zu
unterstützen. Dabei werden die Möglichkeiten der Diskussionsseiten und der Revisionskontrolle von MediaWiki Software genutzt. Jedoch eignet sich dieses System am
besten für bereits vorhandene eLearning Inhalte, die anschlieÿend von den Autoren
modiziert und zu neuen Kursen erweitert werden können. Auf die Erstellung von
Tests wird in der Beschreibung dieses Systems nicht eingegangen.
Um den Autoren die Erstellung der eLearning Inhalte zu vereinfachen, wird in [PTM07]
der Open Oce Writer als Editor vorgeschlagen. Die erstellten Inhalte werden dann
in XML Format transformiert und anschlieÿend der komplette Kurs in SCORM 2004
Standard generiert. Jedoch werden dabei die kooperativen Aspekte der Arbeit an
den Inhalten nicht betrachtet. Auch die derzeitige Beschränkung nur auf Open Oce
Writer ist ein groÿer Nachteil. Die Anbindung neuer Editoren ist laut der Autoren
zwar möglich, wurde bislang aber noch nicht entwickelt. Die Umsetzung der Vorlagen
im Editor ist auch umständlich. Der Autor muss hierbei einzelne Formatierungen mit
Hilfe von Makros vornehmen, von denen es aber nur wenige Vorlagen gibt.
In [DIFM 06] wird ein Wordprozessor (MS Word) mit einer speziell entwickelten Toolbar als Editor verwendet. Die Toolbar stellt einige Hilfsfunktionen, wie das Einfügen
1 http://www.webdav.org/specs/
2
1.2 Aktuelle Arbeiten
von Strukturbausteinen, bereit. Die Inhalte werden dann zunächst im HTML Format
gespeichert und danach in das XML-Format konvertiert (Immediate Site Activator),
wobei auch die Metadaten mitberücksichtigt werden. Backed e-Learning Software
produziert aus den XML-Dateien die Kurse nach SCORM Standard. Diese Lösung
leidet aber auch unter ähnlichen Problemen wie die Lösung in [PTM07]. Als Editor
wird nur MS Word unterstützt und die Erzeugung des Textes ist nicht intuitiv, da
man jeden Textbaustein mit Hilfe der Toolbar auszeichnen muss.
3
1 Einführung
4
2 Analyse
2.1 Drehbuch
Der Begri Drehbuch ist allgemein aus der Filmwelt bekannt und beschreibt Szenen, Handlungen und Dialoge in Textform. Michael Schaudig [Sch92] beschreibt das
Drehbuch als Grundlage der Produktionsentscheidung seitens des Filmproduzenten
und/oder Verleihers, mit exakt ausformulierter Handlungsführung, das heiÿt mit detaillierten Darstellungsanweisungen innerhalb der konkretisierten (auch durchnummerierten) Szenenfolge. Oft enthalten die Drehbücher auch andere Anweisungen und
Beschreibungen, so dass man unter einem Drehbuch auch einen Plan verstehen kann,
auf Grund dessen der Film dann gedreht und fertiggestellt werden kann. Ein Drehbuch bietet damit ein Szenario, nach dessen Anweisungen die Filmemacher ihre Arbeit
organisieren können.
Analog zu den Drehbüchern in der Filmindustrie, können auch die Drehbücher bei
eLearning ein Szenario darstellen, nach dem es möglich ist, einen eLearning Kurs zu
erstellen. Dieses Szenario ist eine Abstraktion eines Kurses, wo es erst einmal nicht
wichtig ist, wie die Inhalte letztendlich aussehen werden. Es sollen vor allem die wichtigsten Konzepte eines Kurses erfasst werden. Dazu zählen beispielsweise die Struktur
eines Kurses, die Inhalte selbst, die vermittelt werden sollen, aber auch welche Medien am günstigsten in diesem Kurs verwendet werden könnten.
Ein Drehbuch bietet dem Autor also die Möglichkeit, Kursinhalte selbst frei zu erstellen, bevor man mit der eigentlichen Produktion des Kurses in einem Autorenprogramm beginnt. Und da man an dieser Stelle nicht an genauen Details der Implementierung interessiert ist, kann das Drehbuch zum Beispiel in einem Texteditor erstellt
werden.
In Kapitel 2.2 werden typische eLearning Inhalte betrachtet. Aus der Sicht des Autors
kann man dabei zwischen dem Text und Medien wie Audio und Video unterscheiden.
Während die Erfassung eines Textes in einem Editor kein Problem darstellt, ist das
mit einem Medium vielfach kompliziert.
Zwar bieten die meisten Editoren (2.3.3) die Möglichkeit, Bilder einzufügen, verfügen aber nur über begrenzte Möglichkeiten, diese zu bearbeiten. Oft werden auch die
Medien nicht von den Drehbuch-Autoren selbst, sondern von anderen Personen bearbeitet, die über entsprechende fachliche Kenntnisse verfügen. In der Regel werden
Bilder in einem externen Bildbearbeitungsprogramm erstellt und im Drehbuch selbst
werden diese nur referenziert. Häug ist es günstig, einen gemeinsamen Ordner für
5
2 Analyse
alle Bilder eines Kurses vorzusehen. Andere Medien werden auch nach diesem Schema behandelt, zumal das Einfügen von Audio und Video von Editoren noch selten
unterstützt wird.
Ein weiterer Vorteil von Drehbüchern ist, dass die dort erstellten Inhalte wiederverwendbar sind. Dies kann insbesondere dann interessant werden, wenn die Kurse für
verschiedenen End-Plattformen angeboten werden, wie mobile Geräte (Smartphone,
Handy), Tablett-PC (iPad), klassische Lernplattformen in Web-Browsern.
2.2 eLearning Inhalte
In E-Learning, ein Wörterbuch [BBSS02] wird der Begri eLearning als Lernen, das
mit Informations- und Kommunikationstechnologien respektive mit darauf aufbauenden E-Learning-Systemen unterstützt bzw. ermöglicht wird deniert. Eine ähnliche
Denition ndet man im Fachlexikon e-le@rning [SM02] - E-Learning ndet statt,
wenn Lernprozesse in Szenarien ablaufen, in denen gezielt multimediale und (tele)kommunikative Technologien integriert sind.
Es wird zwischen dem Computer-based Training (CBT) und dem Web-based Training (WBT) unterschieden, wobei das WBT als Weiterentwicklung und Untermenge
von CBT angesehen werden kann. In [BBSS02] versteht man unter CBT solche Lernmaterialien, die am Computer bearbeitet werden können und keine Internetverbindung benötigen. Etwas ausführlicher wird CBT von Seufert und Mayr [SM02] erklärt:
CBT vermittelt Lerninhalte computerunterstützt und multimedial an den Lernenden,
wobei die Inhalte meistens Interaktionen (Fragen mit Feedback) enthalten. Bei WBT
werden Inhalte über einen Web-Server verteilt [BBSS02] und können dann mit Hilfe
des Internets überall verfügbar gemacht werden. Dank der Verfügbarkeit des Internets wird die Kommunikation zwischen den Lernenden und Tutoren vereinfacht und
immer mehr üblich [SM02].
Durch die Verbreitung von Netzwerktechnologien gerät nicht-Web-basiertes Lernen
immer mehr in Hintergrund, obwohl Lerninhalte, die auf Medien wie DVD oder CD
produziert werden, durchaus ihre Verwendung nden, aber hauptsächlich zum Selbststudium dienen. Dabei ist es ein entscheindender Vorteil von CBT, dass alle benötigten Dateien auch ohne Internetverbindung bereitgestellt werden. Oft sind die Inhalte
so umfangreich, dass die Zustellung selbst bei einer schnellen Verbindung zu erheblichen Verzögerungen führen kann.
In dieser Arbeit wird unter eLearning Kurs vor allem WBT verstanden und somit
entsprechen eLearning Inhalte den Formaten, die in einem Web-Browser wiedergegeben werden können. Dies ist übrigens auch im Sinne von eLearning-Standards wie
SCORM (2.5.4) oder IMS CC (2.5.3), wo nur diese Formate zugelassen werden.
Die eLearning Inhalte sind also Dateien, die in einem Web-Browser dargestellt werden
können. Ursprünglich wurden Web-Browser in erster Linie dafür entwickelt, um mit
6
Hypertext (HTML) umgehen zu können. Mit der Zeit erlaubten technische Entwicklungen immer mehr Formate, die auch von Web-Browsern dargestellt werden konnten.
So kamen zunächst die Graphiken dazu und später andere multimediale Formate wie
Audio und Video. Durch die Einführung von JavaScript wurde die Möglichkeit geschaen, die Inhalte direkt im Browser zu generieren, verändern und nachzuladen.
Die genaue Auistung aller möglicher Formate ist an dieser Stelle nicht weiter wichtig, zumal Web-Browser immer mehr Formate mit Hilfe von Plug-ins (Flash, Java)
aber auch ohne diese beherrschen.
Ein wichtiger Bestandteil von Trainingskursen sind Tests. Fragen zum Kurs lassen
zum einem ein besseres Verständnis des Inhaltes erzielen und zum anderen kann
überprüft werden, ob ein bestimmtes Wissens-Niveau erreicht worden ist. Es gibt
verschiedene Arten von Tests, die man bei eLearning Kursen häug vorndet: Single
Choice, Multiple Choice, Drag-n-Drop, Richtig/Falsch, Lückentext etc. Da die Tests
die Interaktionen mit dem Benutzer ausführen, werden sie häug mit Hilfe von Javascript oder Plugins wie Flash oder Java implementiert. IMS QTI (2.5.3) standardisiert
die meisten Testarten zum Austausch zwischen Lernplattformen und Werkzeugen.
Die Struktur und Navigation eines Kurses spielen ebenfalls eine groÿe Rolle. Die
Möglichkeiten der Strukturierung sind sehr vielfältig und reichen von einem einfachen linearen Ablauf (Seite für Seite) bis hin zu komplexeren Strukturen wie Stern
oder Netz. Die Navigation kann durch den Kurs-Entwickler restriktiv gestaltet werden. Das heiÿt, dass der Benutzer erst nach der Absolvierung von obligatorischen
Aufgaben weiter navigieren kann.
Die Möglichkeit der Verlinkung der Seiten in HTML wird ebenfalls in eLearning Kursen verwendet. Dabei unterscheidet man zwischen internen und externen Verweisen.
2.2.1 HTML
Von Web-Browsern dargestellte Seiten werden in den Formaten HTML oder XHTML
erstellt. Technisch gesehen ist XHTML eine restriktivere Fassung von HTML, die aber
aus der Sicht des Benutzers keine zusätzlichen Funktionalitäten anbietet und wird
hier aus diesem Grund nicht weiter betrachtet. HTML (Hypertext Markup Language) zeichnet Teile von Text mit Hilfe von Tags aus. Die typischen Text-Elemente, die
von HTML dargestellt werden können, sind schon aus der Textbearbeitung bekannt.
Es handelt sich dabei um Überschriften, Listen, Tabellen und Text-Formatierungen.
Die Formatierungen (Schriftart, Gröÿe, Farbe) und das Layout (Position, Abstände)
werden mit Hilfe von CSS (Cascading Style Sheet) erreicht. HTML beschränkt sich
auf die Formatierung des Textes, wohingegen geometrische Figuren (Kreis, Dreieck)
oder komplexe mathematische Formeln beispielsweise nicht dargestellt werden können. Solche Elemente werden in Form von Graphiken erstellt. Für Formeln wurde
MathML (Mathematical Markup Language) entwickelt, das von immer mehr WebBrowsern unterstützt wird.
7
2 Analyse
1
2
Der Benutzer kann mit Hilfe von Web-Formularen, die Radiobuttons , Checkboxes ,
Dropdown-Menüs, Eingabefelder, Submitbuttons beinhalten, Daten an den WebServer, der die Seite serviert hat, zurücksenden. Dort wird die Anfrage in der Regel
von einer serverseitigen Scriptsprache (PHP, Python oder andere) verarbeitet und
anhand der übergebenen Parameter eine Antwort ausgegeben. Diese Form von Interaktivität kann bei vielen Anfragen seitens des Browsers umständlich werden - die
Seite muss vom Browser komplett neu geladen werden, was für den Benutzer längere
Wartezeiten bedeutet. Immer häuger wird dieses Problem mit Hilfe von JavaScript
gelöst, wobei die Anfragen an den Server mittels AJAX
3
ausgeführt werden.
Die derzeit (2010) aktuelle Version von HTML ist 4.01 (veröentlicht 1999), die aber
4
in Zukunft von HTML5 abgelöst werden soll. HTML5 bringt viele Neuerungen , die
die Entwicklung von modernen Web-Applikationen erleichtern, beziehungsweise erst
5
ermöglichen. Unter anderem wurde das Konzept von Cookies (kleine
Text-Dateien
die auf der Klientenseite von Web-Servern abgelegt werden) weiter entwickelt. Grö-
6
ÿere Datenmengen können dabei gespeichert werden (Web Storage ), ohne diese bei
jedem Aufruf der Seite neu an den Server übertragen zu müssen, wie das bislang
der Fall war. Ein weiteres Problem der Verfügbarkeit von Internetverbindung, das
vor allem die Web-Applikationen wie E-Mail betrit, wird in HTML5 durch Zwi-
7
schenspeicherung der Daten gelöst (Oine Web applications ). Zahlreiche weitere
Änderungen und Verbesserungen werden mit HTML5 eingeführt, wie zum Beispiel
neue Eingabefeldertypen (suche, farbe, zahlen, bereich, datum, email etc.), die Unterstützung von Videos ohne Plug-Ins (<video>) und die Generierung von Graphiken
mit Hilfe von Javascript (<canvas>), um hier nur einige zu nennen.
2.2.2 JavaScript
Die Programmiersprache JavaScript, die in Web-Browsern ausgeführt wird, bietet die
Möglichkeit, Inhalte auf der HTML-Seiten zu verändern und somit die Interaktionen
mit dem Benutzer zu erlauben, ohne eine Seite vom Server neu laden zu müssen. Mit
Hilfe von JavaScript wurden bereits komplexe Web-Applikationen wie E-Mail Programme, Text-Editoren, Bildbearbeitungsprogramme implementiert. eLearning Standard SCORM (2.5.4) verwendet Javascript für die Denition einer API, die Kommunikation zwischen den Lernenden und einer Lernplattform ermöglicht.
1 Optionsfeld
2 Auswahlkasten
3 Asynchronous JavaScript and XML
4 http://dev.w3.org/html5/spec/
5 Bis zu 4 Kilobyte
6 http://dev.w3.org/html5/webstorage/
7 http://www.w3.org/TR/html5/offline.html
8
2.2.3 Plug-Ins
Die Möglichkeiten von Browsern können durch Einbinden von Plug-Ins erwe,itert werden. Die am häugsten verwendeten Technologien hierbei sind unter anderen Flash,
Java und SilverLight. Die Plug-Ins ermöglichen zum einen von Browsern nicht unterstützte Formate darzustellen und zum anderen auch Applikationen auszuführen, die
sich mit Hilfe von anderen Technologien nur schwer oder gar nicht implementieren
lassen.
Doch die Verwendung von Plug-Ins birgt auch Nachteile, die die Zugänglichkeit der
Inhalte erschweren können. Erstens müssen die Plug-Ins vom Benutzer installiert
werden, zweitens hängen die in Plug-Ins ausgeführten Anwendungen oft von der verwendeten Version des jeweiligen Plug-Ins ab. Der Benutzer muss sich also auch um
die Aktualisierung kümmern. Allein diese zwei Umstände können für Benutzer aus
meiner persönlichen Erfahrung eine Hürde sein, diese Technologien zu verwenden. Ein
weiteres Problem ist die Unterstützung der Plug-Ins in der verwendeten Hardware.
Die meisten Mobilen Geräten wie Smartphones oder Tablet-PC beschränken sich oft
nur auf HTML, CSS und Javascript.
9
2 Analyse
2.3 Kooperation bei der Erstellung von
eLearning-Inhalten
2.3.1 Übersicht
In Kapitel 2.2 wurden eLearning Inhalte analysiert und es wurde festgestellt, dass die
Inhalte hauptsächlich aus Text (HTML) und Medien bestehen. Nun wird betrachtet
wie der Text und verschiedene Medien kooperativ bearbeitet werden können.
2.3.2 Computer Supported Cooperative Work
Kooperatives Bearbeiten von Dokumenten ist eine Form der Zusammenarbeit an verschiedenen Projekten. Abgesehen von den Schwierigkeiten, groÿe Projekte als Einzelnpersonen zu bewältigen [Koc97], ist es besonders wichtig, so zu arbeiten, so dass
auch andere Personen kontrollierend und korrigierend beteiligt sein können. Folgende Beispiele beinhalten dieses Konzept: Code-Review bei der Softwareentwicklung,
Entwicklung von Prüfungsfragen von mehreren Lehrenden.
Kooperative Arbeit mit Computern wird als Computer Supported Cooperative Work
(CSCW) bezeichnet und wird in [BBSS02] als Gruppenarbeit, die durch Informationsund Kommunikationstechnologien unterstützt beziehungsweise ermöglicht wird deniert. Es wird zwischen synchroner (also gleichzeitiger) und asynchroner (zeitunabhängig) kooperativer Arbeit unterschieden. Die synchrone Arbeit an den TextDokumenten erlaubt einen gleichzeitigen Zugri auf das zu bearbeitende Dokument
von mehreren Benutzern. Dabei können die Benutzer die von Co-Autoren vorgenommenen Änderungen sofort oder mit kleinen Verzögerungen sehen. Google Docs (2.3.3)
ist ein prominentes Beispiel für ein synchrones Textbearbeitungsprogramm. Die asynchrone Bearbeitung von Dokumenten erfolgt entweder iterativ (Benutzer arbeiten an
dem selben Dokument) oder jeder Benutzer bearbeitet eine Kopie des Dokumentes
und die Änderungen können dann manuell oder automatisch zusammengeführt werden.
Die Hauptanforderungen an die kooperativen Eigenschaften der Software und Arbeitsumgebung lassen sich folgendermaÿen denieren:

Zusammenführung von verschiedenen Dokumentenversionen

Auösung von Editierkonikten

Versionskontrolle

Vergleichen von verschiedener Versionen
Des Weiteren sind auch interessant:
10

Kommentare (insbesondere position- und zeitabhängige)

Kommunikationsmitteln wie Chat oder Videochat
2.3 Kooperation bei der Erstellung von eLearning-Inhalten

Gemeinsames Editieren in Echtzeit

Auszeichnung besonders wichtiger Stellen im Dokument

Kennzeichnung von häug bearbeiteten Abschnitten
Die kooperative Bearbeitung von Dokumenten ist seit Jahren ein gewöhnlicher Arbeitsvorgang bei Software Engineering geworden. An Quelltexten eines Programms
arbeiten sehr oft mehrere Programmierer zusammen. Dabei übernimmt ein Versionskontrollsystem die Verwaltung der einzelnen Dokumente und speichert jede Version
in seinem Repository. Des Weiteren kann ein Versionskontrollsystem die Änderungen
in einem Dokument zusammenführen, Editierkonikte entdecken, Änderungen protokollieren, Dokumente wiederherstellen, Verzweigungen in Versionierung anbieten
etc. Ein zuverlässiges Versionskontrollsystem ist eine der wichtigsten Voraussetzungen, um Software erfolgreich zu implementieren und warten zu können. Es existieren
zahlreiche Versionskontrollsysteme auf dem Markt, die auf zwei verschiedenen Architekturen aufbauen.
Verteilte Architektur:

Git

Bazaar

Mercurial

Darcs
Zentrale Architektur:

CVS

Subversion
Die zentrale Architektur sieht vor, dass die Dateien in einem gemeinsamen Repository abgelegt werden. Dabei hat der Benutzer lokal auf seinem Rechner nur eine Kopie
von dem aktuellsten Dokumenten in Repository. Diese Kopie wird wiederum für die
Bearbeitung des Dokumenten kopiert, so dass der Benutzer jederzeit die vorgenommenen Änderungen mit der aktuell vorhandenen Kopie vergleichen kann oder auch
die Änderungen verwerfen kann.
Im Gegensatz zu der zentralen Architektur hat jeder Benutzer die ganze Repository
auf seinem Rechner vorhanden und kann seine Änderungen mit beliebigen anderen
Benutzer austauschen. Die Bearbeitung von Dokumenten geschieht ähnlich wie in
zentralen Architekturen.
Alle diese Systeme haben eines gemeinsam - sie wurden entworfen um den Quellcode
der Software zu verwalten. Der Quellcode eines Programms in jeder Programmiersprache ist eine Text-Datei, die von einem Versionskontrollsystem auf Änderungen
11
2 Analyse
analysiert werden kann. Dabei werden mögliche Editierkonikte erkannt, die vom
Benutzer aufgelöst werden müssen. Dies kann natürlich nicht automatisch erfolgen.
Versionskontrollsysteme sichern auÿerdem auch die Konsistenz der Daten zu, indem
sie, bevor eine Datei in Repository hochgeladen wird, die Zusammenführung und
Koniktauösung erzwingen, falls die Datei in der Zwischenzeit von anderen Benutzern geändert und hochgeladen worden ist.
Als Konsequenz können zwar binäre Dateien in die Repositorien aufgenommen werden, die Zusammenführung und ein Vergleich der Dokumente werden aber von Versionskontrollsystemen nur für Text-Dateien unterstützt. Es ist also unmöglich binäre
Dateien zu vergleichen. Möchte man nun die Dokumente in Formaten aus bekannten
Oce Anwendungen unter einer Versionskontrolle verwalten, muss die Zusammenführung der Dokumente manuell in einem entsprechenden Programm vorgenommen
werden. Natürlich lassen sich die Dateien auch in anderen für eine Versionskontrolle
geeigneten Formate (z.B. HTML) speichern. Dadurch gehen aber unter Umständen
die programmspezischen Daten verloren. Im Fall von HTML können zum Beispiel
keine Kommentare, die in einem MS Word Dokument vorhanden sind, dargestellt
werden. Auch die Auösung von Konikten muss dann in diesem Format erfolgen,
was bedeutet, dass der Autor über sehr gute Kenntnisse des jeweiligen Formats verfügen muss. Wenn also binäre Dateien in Repositorien aufgenommen werden, ist es
erforderlich, dass der jeweilige Editor dem Benutzer bereits interpretierte Daten präsentiert und dort die Konikte aufgelöst werden.
Glücklicherweise gibt es in den Versionskontrollsystemen die Möglichkeit, ein externes
Programm zu denieren, von dem die Funktionen Vergleichen und Zusammenführen übernommen werden können (siehe 2.3.4). So würde beispielsweise für eine .doc
Datei-Erweiterung die Word Zusammenführungsfunktion aufgerufen werden, und der
Benutzer kann dann dort die Änderungen akzeptieren oder verwerfen.
12
2.3.3 Editoren zur Drehbucherstellung
Bezogen auf die Funktionalitätenvielfalt und die Kooperationsmöglichkeiten lassen
sich die Text-Editoren in zwei Kategorien aufteilen: die Browserbasierten und die
Desktopbasierten. In diesem Kapitel werden die Vor- und Nachteile verschiedener
Editoren aufgezeigt.
Microsoft Word
Angesichts der groÿen Verbreitung und des Funktionsumfangs von Microsoft Oce,
ist MS Word eine gute Wahl als Text-Bearbeitungsprogramm. Viele Benutzer sind
wegen des täglichen Umgangs an diese Software gewöhnt und mit deren Funktionalitäten vertraut. Würde diese Software für Produktion der Drehbücher verwendet
werden, würde auch die Einarbeitung der Autoren sehr einfach sein. Auÿerdem liegen bereits viele Inhalte in den entsprechenden Formaten vor - häug werden die
Entwürfe von eLearning Kursen zunächst in MS Word erfasst.
Es ist unumstritten, dass MS Word über gute Textbearbeitung Eigenschaften verfügt.
Die Text-Bausteine, die man in eLearning Inhalten ndet, lassen sich in Word problemlos erstellen. Auch grundlegende Funktionalitäten für das Anpassen und Einbinden der Bilder ist in Microsoft Word gut gelöst. Diese lassen sich genau positionieren
und in der Gröÿe anpassen. Die Möglichkeit, einfache Zeichnungen und geometrische Figuren zu erstellen, ist ebenfalls vorhanden. Des Weiteren verfügt MS Word
über einen guten Formeleditor, der sich intuitiv benutzten lässt. Die Symbole sind
in verschiedene Kategorien aufgeteilt und werden durch das Anklicken eingefügt. Die
Positionierung der Elementen in Formeln geschieht mit Hilfe von Platzhaltern. Video
und Audio Dateien kann man in ein Dokument zwar nicht einbinden, was aber bei der
Produktion von Drehbüchern kein groÿes Problem darstellt, da ja in einem Drehbuch
nicht das genaue Aussehen des Kurses angestrebt wird (2.1).
Eine der beliebtesten Funktionalitäten im Word ist die Outliner Funktion. Damit lässt
sich ein beliebiger Abschnitt im Dokument auf eine andere Stelle verschieben, ohne es
ausschneiden und einfügen zu müssen. Der Vorgang geschieht in einem gesondertem
Fenster, wo man eine Übersicht über das ganze Dokument hat. Diese Möglichkeit ist
bei der Erstellung von eLearning Inhalten besonders nützlich, denn damit kann die
Struktur des Kurses sehr schnell und fehlerfrei umgestaltet werden.
Darüber hinaus verfügt Word über die Möglichkeiten der Automatisierung von Arbeitsvorgängen mittels Makros und VBA (Visual Basic for Applications). Es können
zum Beispiel Vorlagen und Bausteine erzeugt werden: eine Grundstruktur der Seite
oder eine Tabelle zum Eintragen der Kurseinstellungen.
In Hinblick auf die Kooperation bietet MS Oce Word die Funktionen der Zusammenführung, des Vergleichen beziehungsweise des Änderungen verfolgen. Doch alle
diese Funktionalitäten reichen nicht aus, um den Workow mit mehr als zwei Autoren
ezient zu gestalten. Zurzeit ist es häuge Praxis, die Dateien einfach per Email zu
13
2 Analyse
tauschen. Dabei bearbeitet ein Autor eine Datei und versendet sie an den Co-Autor,
der dann die Möglichkeit hat, sie mit seiner Kopie zu vergleichen. Diese Methode hat
viele Nachteile und eignet sich zur eektiven Kooperation wohl kaum. Es ist aufwändig und fehlerträchtig zu bestimmen, welche Version des Dokumentes die Aktuellste
ist. Mit steigender Anzahl der Autoren wird es kaum möglich einen Überblick zu
behalten und eine Zusammenführung korrekt auszuführen.
Dennoch hat MS Word wertvolle Funktionalitäten, die die Kooperation erleichtern
und insgesamt eektiv machen. Dies sind insbesondere die Kommentare, Änderungen
verfolgen. Der markierte Abschnitt des Dokuments lässt sich mit einem Kommentar versehen, der auch nach der Verschiebung des Abschnitts bestehen bleibt. Um
die vorhandene Kommentare erkennen zu können, sind die kommentierten Stellen
im Dokument farblich hervorgehoben, jedem Autor wird dabei eine andere Farbe
zugewiesen.
Aktiviert man die Funktion Änderungen verfolgen ist jederzeit zurückzuverfolgen,
was und von wem im Dokument geändert wurde. Diese Änderungen kann der Autor
entweder verwerfen oder akzeptieren, und über die entsprechende Schaltächen im
Menü vornehmen.
Microsoft PowerPoint
PowerPoint ist ebenfalls ein verbreitetes und umfangreiches Programm aus der Microsoft Oce Suite. Sehr viele Lernmaterialien existieren in Form einer PowerPoint
Präsentation und können als Quelle für die Erstellung von eLearning Kursen genutzt
werden. Es stellt sich nun die Frage, ob das Programm auch für die kooperative Erstellung von Drehbücher geeignet ist.
Wie auch in MS Word lassen sich in PowerPoint alle Text-Bausteine und Elemente erstellen und bearbeiten. Die kooperativen Funktionalitäten, die in MS Word betrachtet
wurden (2.3.3), sind in PowerPoint ebenfalls vorhanden (Kommentare, Vergleichen
und Zusammenführen etc.). Darüber hinaus können aber auch Medien wie Audio
und Video eingefügt werden. Im Hinblick auf den Umgang mit Medien scheint PowerPoint für die Erstellung der Drehbücher eine gute Alternative zu MS Word zu
sein. Da bei der Erstellung von Drehbüchern (2.1) hauptsächlich mit Text gearbeitet
wird, sind die Vorteile der Medienunterstützung zweitrangig. Die Besonderheiten des
Folien-Layouts in PowerPoint sind für die Bearbeitung des Textes eher störend - oft
passt das Programm die Formatierungen des Textes (zum Beispiel die Schriftgröÿe)
zu den Folien-Layout automatisch an. Zudem hat PowerPoint natürlich auch andere
Ausgabeformate, und so kann eine Präsentation nicht als HTML gespeichert werden
(ab MS Oce 2010), was aber für den Kontext dieser Arbeit wichtig ist.
Open Office
Da Open Oce frei verfügbar ist, ist die Oce Suite eine attraktive Alternative zu
Microsoft Oce und wird auch bei der Erstellung von eLearning Inhalten verwendet
14
(siehe [PTM07]). Der Umfang der Textbearbeitungsfunktionen des Editors Writer
ist vergleichbar mit dem von MS Word und wird an dieser Stelle nicht weiter betrachtet. Die Automatisierungsmöglichkeiten sind ebenfalls vorhanden und können
mit Hilfe von Scriptsprachen Python, BeanShell, JavaScript oder eigen entwickleten
StarBasic programmiert werden. Auch die kooperative Arbeit unterstützenden Funktionalitäten, die man in MS Word ndet, sind in Open Oce Writer implementiert.
Eine kooperative Plattform für OpenOce, wo die Dokumente ähnlich wie bei MS
SharePoint Services (2.3.4) verwaltet werden könnten, fehlt jedoch. Möchte man kooperativ an OpenOce Dokumenten arbeiten, gibt es dann nur zwei Möglichkeiten
- Das Versenden der Dokumente über E-Mail oder über andere Kommunikationswege (zum Beispiel Instant Messaging) oder die Verwaltung der Dokumente in einem
Versionskontrollsystem mit ähnlichen Einschränkungen, die auch für MS Word gelten. Open Oce Writer speichert die Datei in .xml Format und packt sie dann zu
Archiv-Datei (Format .odt) und da die Archiv-Dateien binär sind, können die Zusammenführung und Vergleichen Funktionen eines Versionskontrollsystems nicht benutzt
werden (2.3.2).
Im Gegensatz zu MS Word lassen sich Video- und Audio- Dateien in ein Open Oce
Writer Dokument einfügen und abspielen. Die Gröÿe und Position eines Videos kann
geändert werden.
Google Docs
Als Texteditor bietet Google Docs im Vergleich zu Desktoptextprozessoren weniger
Funktionalitäten. Die Automatisierung der Arbeitsvorgänge beispielsweise wird zur
Zeit
8
nur in der Tabellenkalkulation unterstützt (für Dokumente wird demnächst
eine API veröentlicht). Dennoch dürften die vorhandenen Funktionen im Kontext
der Erstellung von eLearning Inhalten für die meisten Anwender ausreichend sein:

Layout: Überschriften, Tabellen, Kopf, Fuÿ, Listen

Formatierung des Schrift: Farbe, Gröÿe, Schriftart

Weitere: Formeleditor, Positionierung des Bildes mit Drag'n Drop
Google Docs bietet hervorragende Kooperationsmöglichkeiten und das dürfte für viele Anwender ein Kriterium für die Wahl der Software als ein Texteditor sein. Laut
Google können derzeit bis zu 50 Personen gleichzeitig an einem Dokument arbeiten.
Die vorgenommenen Änderungen von den Autoren werden sofort für ihre Partner
sichtbar. Als Kommunikationshilfsmittel steht ein Chat für angemeldete Autoren zur
Verfügung. Versionskontrolle der Dokumente sowie die Möglichkeit zum Vergleichen
von verschiedenen Revisionen und deren Wiederherstellung ist ebenfalls vorhanden,
wobei sowohl die Problematik der Zusammenführung von verschiedenen Dokumentenversionen als auch die Auösung von Editierkollisionen entfällt, weil das Dokument
in Echtzeit aktualisiert wird und jeder der Co-Autoren die Möglichkeit hat zu sehen,
8 Stand: Semptember 2010
15
2 Analyse
an welcher Stelle der Text vom Partner gerade geändert wird. Google Docs bietet
auch eine Kommentarfunktion, die ähnlich wie in den Textprozessoren wie MS Word
funktioniert. Die Dokumenten lassen sich in verschiedene Formate exportieren: MS
Word, Open, Oce PDF, RTF, HTML. Das Importieren der Dateien aus anderen
Editoren wird ebenfalls angeboten, wobei das nur für einfache Formatierungen gut
funktioniert. Als ein weiterer technischer Vorteil ist auch das gemeinsame Editieren
von Zeichnungen in Echtzeit zu nennen.
Die Kostenfreiheit und die sofortige Verfügbarkeit ist natürlich auch ein weiterer
wichtiger Aspekt. Es wird keinerlei Installation und Wartung benötigt. Für viele
Firmen ist jedoch Datenschutz ein entscheidender Grund, um Google Docs als einen
kooperativen Editor nicht zu benutzen, denn alle Daten und Arbeitsvorgänge (zum
Beispiel Inhalt der Zwischenablage bei einem Kopiervorgang) werden auf den GoogleServern gespeichert.
Etherpad, Titanpad und andere
Google Docs ist natürlich nicht der einzige Online-Texteditor. Viele andere Programme bieten ähnliche Textbearbeitung- und Kooperation- Funktionalitäten (Editieren
in Echtzeit, Versionskontrolle, Chat etc.). Obwohl die Unterschiede zu Google Docs
nicht sehr groÿ sind, sind sie eine gute Alternative für die Benutzer, die diese Produkte
bereits verwenden oder die Firmen, die aus Datenschutzgründen nicht ihre Inhalte bei
Google speichern wollen. Durch Googles Übernahme von Etherpad wurde der Quellcode des Programm Open-Source. Somit kann die Software in einem Firmennetzwerk
lokal installiert und benutzt werden.
Wikis
Wikis haben sich im Internet als ein kooperatives Werkzeug etabliert. Zahlreiche
Organisationen und Firmen nutzen Wiki als vielseitiges Werkzeug für verschiedene
Zwecke. Die Einsatzbereiche sind oft Dokumentationen, Wissensbasen, Nachschlagewerke etc. Die Einfachheit der Installation, der Benutzung und die freie Verfügbarkeit
sind oft entscheidende Kriterien für die Auswahl der Software.
Streng genommen ist ein Wiki kein Text-Editor und wurde für den Zweck von einfachen Erstellung der zusammengehörigen Seiten im Internet entwickelt. Doch die
guten kooperativen Eigenschaften können ein Kriterium für die Wahl eines Wikis als
Editor für die Drehbuchproduktion sein. Darüber hinaus sind Wiki-Inhalte durchsuchbar, so dass man die bereits erstellten Lernmateriallien leichter wiederverwenden
kann.
Die Software von Wikis ist Server-Seitig, ausgenommen von einigen Java-Script Funktionen und dem Wiki-Editor, die auf der Client-Seite ausgeführt werden. Die Bearbeitung und Erstellung der Seiten geschieht im Browser. Anders als bei Text-Editoren
sind bei Wikis nur bestimmte Formatierungen des Textes erlaubt, dabei wird kein
16
WYSISYG Editor in den meisten Wikis angeboten, sondern die Formatierungen werden mit speziellem Syntax Regeln erreicht, dem Wiki-Markup. Das Editieren des
Textes in einer Wiki bietet also keine Funktionalitäten, die man in Textbearbeitungsprogrammen ndet. Zwar lassen sich auch andere Editoren wie CKeditor als Alternative einbinden, jedoch können generell browserbasierte Editoren nicht alle Funktionalitäten der Text-Prozessoren anbieten. Auch Automatisierungsfunktionen fehlen
in Wikis, weil die Software natürlich nicht dafür konzipiert wurde. Wiki-Vorlagen
sind eine Hilfe bei der Formatierungen von Textabschnitten, die sich wiederholt auf
Wiki-Seiten wiedernden, werden aber mit steigender Anzahl von Parameter unübersichtlich und sind dann schwierig zu benutzen.
Bevor man Bilder und andere Medien in einer Wiki verwenden kann, müssen diese
erst auf den Wiki-Server hochgeladen werden und können erst dann im Text referenziert werden. Für die Erstellung der mathematischen Formeln wird TeX-Syntax
benutzt, wobei für die Darstellung einer Formel ein Bild generiert werden muss.
Kooperative Funktionen der Wikis Software beinhalten Diskussionsseiten, eine Versionskontrolle sowie Logbücher. Eine Diskussionsseite zu einem Artikel bietet den
Autoren die Möglichkeit alle Kommentare und Ideen zu dem Artikel auszutauschen.
Leider gibt es keine Möglichkeit, einen Kommentar zu der entsprechenden Stelle im
Text zu verknüpfen, wie das zum Beispiel in MS Word oder anderen Text-Editoren
der Fall ist. Bei gröÿeren Artikeln kann das möglicherweise zu Produktivitätseinbuÿen
führen, weil man nicht immer eindeutig feststellen kann, auf welche Stelle im Text
sich ein Kommentar bezieht. Selbstverständlich trit das nur auf gröÿere Artikel zu.
Ein besonderer Vorteil von Wiki ist, dass alle an einem Artikel vorgenommen Änderungen gespeichert werden und auf einer speziellen Seite übersichtlich dargestellt
werden. So können verschiedene Version verglichen werden und es ist jederzeit nachzuvollziehen was und warum an einem Artikel geändert wurde.
2.3.4 Versionskontrollsysteme für Office-Suiten
Microsoft SharePoint Services
Microsoft hat natürlich den Bedarf für die kooperative Arbeit erkannt und so entstand
ein neues Produkt Groove, das ab 2010 in Microsoft SharePoint umbenannt wurde.
SharePoint bietet eine Online Plattform zur gemeinsamen Verwaltung von Dokumenten. Neben einer Versionskontrolle, der Zusammenführungsfunktion und der Verwaltung von Nutzerrechten gibt es weitere Funktionalitäten, die eine kooperative Arbeit
erleichtern. Die Versionskontrolle basiert auf einem Modell von zentraler Architektur
der Versionskontrollsysteme (2.3.2). Gleichzeitiges Editieren von Dokumenten wurde
ermöglicht, indem ein zu bearbeitender Abschnitt des Dokuments gesperrt wird und
der Rest von anderen Autoren zur gleichen Zeit bearbeitet werden kann. SharePoint
ist auch erhältlich als Server Software, so dass die Dienste auch lokal im Intranet
17
2 Analyse
angeboten werden können.
SVN
Für Editoren, die über keine Versionskontrolle verfügen, bieten sich die schon vorhandenen Systeme an. Allerdings können diese Systeme das Zusammenführen von
binären Dateien nicht durchführen. Diese Aufgabe muss dann der Benutzer im jeweiligen Programm manuell vornehmen. Trotz dieses Nachteils bieten die Systeme
nützliche Funktionalitäten, die eine Kooperation an Dokumenten ermöglichen. Die
gespeicherten Versionen lassen sich bei Bedarf wiederherstellen und vergleichen. Des
Weiteren bietet die Versionskontrolle ein genaues Protokoll darüber, wann und wer
welche Änderungen vorgenommen hat und kurze Kommentare von den Autoren zu
diesen Änderungen.
Da die Versionskontrolle tatsächlich nicht nur von den Programmierern eingesetzt
wird, bietet SVN Windows-Klient TortoiseSVN eine nützliche Erweiterung für MS
Oce und Open Oce Benutzer an, die automatisch die entsprechende Zusammenführung oder Vergleichen Funktion des jeweiligen Programms aufruft und somit die
manuelle Zusammenführung der Dateien maximal vereinfacht. Diese Funktionalität
kann natürlich auch für andere Systeme implementiert werden, zumal die TortoiseSVN quelloen ist.
2.3.5 Koopertative Bearbeitung von Medien
Obwohl in einem Drehbuch grundsätzlich mit Text gearbeitet wird (2.1), sind Medien ein wichtiger Bestandteil der eLearning Kurse. Es ist erforderlich zu verstehen,
wie man die kooperative Arbeit an den Medien organisieren kann und inwieweit die
kooperative Bearbeitung möglich ist.
Die Versionskontrollsysteme (2.3.2) können leider ihre Hauptfunktionalitäten nur für
Text-Dateien anbieten. Das Problem trit insbesondere auf Medien wie Bilder, Audio und Video zu. Um die Medien kooperativ bearbeiten zu können, sind also andere
Wege und Programme nötig. Man kann natürlich auch Medien-Dateien in einer Repository speichern und verwalten. Die kooperative Bearbeitung kann dann aber nur
sequentiell erfolgen - gleichzeitige Arbeit an einer Medien-Datei ist wegen Schwierigkeiten bei der Zusammenführung der Änderungen und der Koniktauösung kaum
vorstellbar. Auch die Erkennung der Änderungen ist bei Medien-Dateien sehr schwierig - oft sind sie für das menschliche Auge kaum bis gar nicht sichtbar oder sind nur
sehr schwer aundbar (zum Beispiel ein Schnitt in einer groÿen Videodatei). Es sind
also Mechanismen erforderlich, die den Autoren, ähnlich wie bei Text-Dateien, die
Änderungen und Kommentare auch in Medien-Dateien ermöglichen.
Das Bildbearbeitungsprogramm Adobe Photoshop bietet die Speicherung aller vorgenommenen Änderungen in einer History, zumindest für Dateien in PSD Format.
So kann der Autor immer nachvollziehen was geändert wurde und kann diese Änderungen auch rückgängig machen. Ein Bild kann auch mit Notizen versehen werden,
18
die aber dann in der Produktion natürlich nicht sichtbar sein dürfen. Als Alternative kann man zu jeder Medien-Datei, die man kooperativ bearbeiten möchte, eine
zugehörige Text-Datei anlegen, in der man Kommentare speichern könnte.
Google Docs (2.3.3) bietet seit Mai 2010 die kooperative Bearbeitung von Graphiken
beinahe in Echtzeit an. Natürlich kann das Browser-basierte Programm nicht den
Umfang von Funktionalitäten von Desktop Programmen anbieten, aber für die kooperative Erstellung von einfachen Zeichnungen eignet sich die Lösung sehr gut.
Möchte man kooperativ Audio- oder Videodateien bearbeiten, bieten sich folgende
Möglichkeiten. Man kann trivialerweise die Datei iterativ bearbeiten, so dass keine
Zusammenführung der Dateien nötig ist. Dabei wird die Datei in einem für alle Autoren zugänglichen Ort gespeichert (FTP-Server, Samba- oder Windowsnetzwerkfreigabe etc.). Versionskontrollsysteme würden sich dabei nur für Dateien von kleineren
Gröÿen eignen, da dort jede Version gespeichert wird. Alleine aus Platzgründen kann
diese Lösung problematisch werden - hochauösende Dateien sind selbst für heutige
Verhältnisse enorm groÿ. Dazu kommen lange Übertragungszeiten bei der Speicherung im Repository.
Die Problematik bei der Speicherung auf einem Medium wie zum Beispiel einem
FTP-Server besteht hauptsächlich in der Absprache, wann und wer die Datei bearbeitet, weil ein gleichzeitiges Editieren nicht möglich ist. Es ist aus technischer Sicht
nicht schwierig eine Passwort geschützte Freigabe einzurichten, die nach dem Einloggen weitere Autoren sperrt, so dass keine Kollisionen entstehen. Jedoch ist dieser
Weg ohne Kommunikation und Planung unter den beteiligten Autoren nicht optimal.
Eine andere Möglichkeit, zumindest für die groÿe Dateien, besteht in der Aufteilung
dieser in kleinere Teile, so dass die Autoren gleichzeitig an ihren Abschnitten arbeiten
können und die nale Version erst zum Schluÿ zusammengefügt wird. Auch hier ist
eine intensive Kommunikation und Planung zwischen den Co-Autoren nötig.
Eine weitere Alternative, zumindest für Video-Dateien, ist die Ausnutzung der Tatsache, dass beim Editieren der Video-Dateien die Quell-Datei selbst nie geändert wird.
Stattdessen werden bei den meisten Videobearbeitungsprogrammen die Änderungen
(Schnitte, Eekte, Untertitel, etc.) zunächst in einer Projekt-Datei gegebenenfalls
einem Projekt-Ordner gespeichert und erst wenn die Editierung fertig ist, wird die
Ziel-Datei erzeugt. Die Projekt-Daten kann man dann natürlich unter einer Versionskontrolle verwalten, da die Gröÿe der Dateien akzeptabel ist. So kann eine beliebige
Version wiederherstellt werden und anhand der Quellvideodatei die Ziel-Datei generiert (gerendert) werden.
Folgende Software unterstützt eine kooperative Arbeit an Mediendateien.
9
Audiohive
bietet eine kooperative Bearbeitung von Audio-Dateien an, die für Film-
vertonung produziert werden. Dabei wird eine knotenbasierte Mehr-Benutzer Arbeitsumgebung mit Versionskontrolle und Zugangskontrolle angeboten. Die Kooperation
9 http://openstudionetworks.com
19
2 Analyse
wird dadurch erreicht, dass die Inhalte aufgeteilt werden und die Autoren unabhängig
voneinander daran arbeiten können.
Adobe Captivate
10
ermöglicht Kommentare bei der Videobearbeitung, indem man
die bearbeitete Datei auf den Server von Acrobat.com hochlädt und für Co-Autoren
freigibt. Diese können dann die Datei mit Kommentaren versehen, die positionsabhängig sind.
Kooperative Bearbeitung von Video-Dateien bietet auch Kaltura
11
Software. Es sind
Funktionen wie Kommentare, Annotationen und eine Versionskontrolle vorhanden.
Die Bearbeitung der Inhalte erfolgt direkt in Web-Browser und der Editor kann auch
in andere Web-Seiten eingebunden werden (zum Beispiel in eine Wiki). Final Cut
Pro 7
12
bietet kooperative Bearbeitung von Video an, indem der Co-Autor über
Video-Chat gemeinsam die Änderungen verfolgt und kommentiert. Dabei wird die
Zeitstempel in Video auch dem Co-Autor angezeigt und die vorgenommenen Änderungen werden sofort sichtbar.
2.4 Autorenwerkzeuge
In Kontrast zur Erfassung der eLearning Inhalte in einem Drehbuch können diese
auch mit Hilfe von Autorenprogramme erstellt werden. Dabei sind keine Programmierkenntnisse erforderlich und der Autor übernimmt die Rolle eines Kurs-Designers,
das heiÿt, er bestimmt Layout und Formatierungen der Seite selbst. Die für eine kooperative Bearbeitung der Inhalte wichtige Funktionalitäten werden in der Software
dieser Art in der Regel nicht implementiert. Es fehlt meistens die Möglichkeit den
Text mit Kommentaren zu versehen oder verschiedene Versionen eines Kurses zusammenzuführen. Als Ausgabe wird ein fertiger Kurs, oft auch in einem eLearning
Standard, erstellt. Am Beispiel zweier solcher Programme, möchte ich deren typische
Merkmale zeigen.
eXe
eXe
13
ist ein beliebtes freiverfügbares Programm zur Erstellung von eLearning In-
halten. Das Programm wurde mit dem Ziel entwickelt, die Erstellung von eLearning
Inhalten maximal zu vereinfachen.
Eine neue Seite wird mit Hilfe von bereitgestellten Vorlagen (iDevice) erstellt. Zur
Auswahl stehen beispielsweise Vorlagen zum Tests (Multiple-Choice, Richtig/Falsch
Fragen, Lückentext etc.), Text, Bildergalerie, Bild mit Lupe und andere. Dort werden
die für eine Seite benötigten Einstellungen und Inhalte eingegeben. Auch ein eigener
10 http://www.adobe.com/products/captivate/
11 http://corp.kaltura.com/video_platform/video_editing
12 http://www.apple.com/finalcutstudio/finalcutpro/collaboration.html
13 http://exelearning.org/wiki
20
iDevice kann mit Hilfe von eXe entwickelt werden.
Die Struktur des Kurses wird in einem separaten Fenster visualisiert, in dem auch
neue Seiten hinzugefügt oder die bestehenden umbenannt werden können. Für das
Verschieben der Seiten ist ein spezielles Auswahlmenü auf jeder Seite vorhanden. Die
internen und externen Verweise können ebenfalls problemlos im Editor erstellt werden. Die Eingabe des Textes erfolgt in einem WYSIWYG Editor, der grundlegende
Textbearbeitungfunktionalitäten und darüber hinaus die Funktionen zum Einfügen
von Medien, Formeln, Verknüpfungen etc. bereitstellt. Es fehlen jedoch beispielsweise
die Funktionen Suchen und Ersetzen oder die Rechtsschreibprüfung, die fast jeder
Texteditor beherrscht.
Der in eXe erstellte Kurs kann in einen eLearning Standard exportiert werden. Zur
Auswahl stehen IMS Content Package (2.5.3), IMS Common Cartridge (2.5.3) und
SCORM 1.2 (2.5.4).
Abbildung 2.1: eXe Editor
21
2 Analyse
LernBar Studio
LernBar wird von
studiumdigitale, der zentralen eLearning-Einrichtung der Goethe14
Universität Frankfurt am Main entwickelt
. Im Gegensatz zu eXe (2.4) ist LernBar
Studio auf die eLearning Kurse, die in dem LernBar Player wiedergegeben werden,
spezialisiert.
Für die Erstellung der Kurse sind keine Kenntnisse über HTML, CSS oder JavaScript
erforderlich. Einzelne Seiten werden ebenfalls mit Hilfe von bereitgestellten Vorlagen
erstellt, die zum einen unterschiedliche Layouts und zum anderen verschiedene Testtypen anbieten. Die Layout-Vorlagen erlauben die Wahl der Anzahl von Spalten auf
einer Seite und die genaue Platzierung von unterschiedlichen Medien. Als Fragen
werden beispielsweise Single Choice, Multiple Choice, Drag & Drop und andere
angeboten.
Die Erfassung des Textes erfolgt in einem WYSISWYG Editor, der auÿer grundlegenden Textformatierungen auch die internen und externen Verlinkungen, das Einfügen
von Bildern und anderen Ressourcen erlaubt. Tabellen und mathematische Formeln
können in dem Editor nicht erzeugt werden und eine Rechtsschreibprüfung fehlt ebenfalls.
Die Seiten lassen sich problemlos in einem Navigator Fenster per Drag & Drop auf
eine andere Stelle im Kurs verschieben.
14 http://www.studiumdigitale.uni-frankfurt.de
22
Abbildung 2.2: Erstellung von einem Single Choice Quiz im LernBar Studio
23
2 Analyse
2.5 E-Learning Standards
2.5.1 Übersicht
Mit wachsender Popularität von eLearning wurde auch die dazugehörige Problematik deutlich. Die Erstellung der Inhalte ist im allgemeinen teuer und zeitaufwändig
[Ost07, S.26] und somit ist das Interesse an einer Wiederverwendung und Interoperabilität sehr groÿ. Um diese Ziele erreichen zu können, sind allgemeingültige Standards
für eLearning Inhalte sowie für Lernplattformen nötig. Aus diesem Grund werden einige der aktuellen Standards in diesem Kapitel betrachtet.
Als Beispiel für den Bedarf einer Wiederverwendung der Inhalte sind hier die Lernprogramme an Hochschulen zu erwähnen. In vielen Fächern sind die Kurse ähnlich
und werden bis jetzt unabhängig voneinander erstellt. Dabei könnten die Hochschulen kooperieren und einmal erstellte Inhalte allen Beteiligten zur Verfügung stellen
[Jon02, S.3]. Ohne entsprechende Standards ist dieses Ziel kaum zu erreichen.
Zu beachten ist aber auch, dass obwohl man in der Regel von standardkonformen Inhalten protiert, das Implementieren solcher Inhalte mehr Aufwand und Einschränkungen in der Gestaltung bedeutet [NDH 08, S.604]. Vor allem für die Lernplattformen ist die Unterstützung eines Standards aufwändig zu implementieren, denn
während die Inhalte nur einige Aspekte des jeweiligen Standards verwenden, muss
eine Lernplattform einen Standard vollständig unterstützen.
15
Tabelle
2.1 zeigt die wichtigsten Standards, die im Folgenden näher betrachtet
werden.
Datum
Verbreitet
RTE
Packaging
Metadata
Sequencing
AICC
1998
Ja
Ja
Ja
Nein
Nein
SCORM 1.2
2001
Ja
Ja
Ja
Ja
Nein
SCORM 2004
2006
Ja
Ja
Ja
Ja
Ja
IMS CC
2006
Noch nicht
Nein
Ja
Ja
Nein
Tabelle 2.1: Bekannteste eLearning Standards im Vergleich
2.5.2 AICC
Das Aviation Industry Computer-Based Training Committee (AICC) war die erste
Organisation, die einen Standard für eLearning veröentlicht hat, in welchem deniert
wurde, wie eine Lernplattform Lernaktivitäten verfolgen und kontrollieren kann. So
wurde es beispielsweise möglich nachzuverfolgen, wie der Lernende bestimmte Tests
15 Quelle:
24
http://www.scorm.com/scorm-explained/business-of-scorm/scorm-versions/
absolviert hat und wie lange es gedauert hat [Ber04]. "CMI Guidelines for Interoperability", die Spezikation für Kommunikation zwischen eLearning-Inhalten und
Lernplattformen wurde weit verbreitet. AICC deniert einen web-basierten Interface
16
HACP
17
sowie JavaScript API
, das im später erschienen SCORM (2.5.4) Standard
verwendet wird.
2.5.3 IMS
18
eLearning Standards werden auch von dem IMS Global Learning Consortium
ent-
wickelt. Neben dem weit verbreiteten IMS Content Packaging Standard (IMS CP)
hat IMS GLC auch weitere Spezikationen veröentlicht, die verschiedene Aspekte
von eLearning angehen.
IMS Learning Design (IMS LD) speziziert eine Metasprache, die den geplanten Ablauf beziehungsweise die Abfolge von Lehr- und Lern-Handlungen als Prozess beschreibt [NDH 08, S.611]
IMS Simple Sequencing (IMS SS) deniert einen Standard für die Sequenzierung von
eLearning Inhalten. SCORM 2004 benutzt IMS SS für die Speziaktion der Navigation in den Kursen (siehe auch Kapitel 2.5.4).
IMS Question and Test Interoperability (IMS QTI) beschreibt ein Datenmodell für
die Repräsentation der üblichen Frage-Antwort Tests. Viele Werkzeuge für Generierung solcher Tests unterstützen bereits diesen Standard (siehe Anhang A.2 für einen
Überblick). Im Kontext dieser Arbeit ist dieser Standard besonders interessant. Die
in LernBar (2.4) verwendeten Fragendenitionen werden auch in XML-Format abgespeichert. Somit wäre IMS QTI geeignet, das momentan verwendete Format zu
ersetzen, um die Interoperabilitätseigenschaften weiter zu verbessern.
IMS Content Packaging
IMS Content Packaging (IMS CP) hat das Ziel, ein technisches Format für die Lernmaterialien zu denieren, so dass diese problemlos zwischen den verschiedenen Lernplattformen und Werkzeugen ausgetauscht, beziehungsweise ausgeliefert werden können. Der Standard ist in eine Spezikation des Informationsmodells und eine Denition, wie das Model mit Hilfe von XML beschrieben werden kann, unterteilt [Som04].
Ein nach dem IMS CP erstelltes eLearning Paket ist eine gepackte
19
Datei (Packa-
ge Interchange File), die alle zum einem Kurs dazugehörigen Dateien, sowie eine
Manifest-Datei beinhaltet (siehe Abbildung 2.3 [IGLC04]). Die Manifest-Datei beschreibt die Struktur des Kurses, enthält Meta-Daten und listet alle Dateien im
16 HTTP AICC Communication Protocol
17 Application Programming Interface
18 Obwohl IMS die Abkürzung für Instructional Management Systems ist, wird der Name IMS
verwendet
19 Ein bestimmtes Format ist nicht vorgegeben
25
2 Analyse
Kurs auf. Die Verzeichnisstruktur ist nicht vorgeschrieben. Lediglich die ManifestDatei (imsmanifest.xml ) muss sich in der Wurzel des Pakets benden, wobei auch
auf weitere Sub-Manifeste verwiesen werden kann, um bei umfangreichen Paketen
die Strukturierung übersichtlicher gestalten zu können. Für Meta-Daten kann ein eigenes Schema verwendet werden, andernfalls sieht IMS CP den IEEE LOM Standard
vor.
Abbildung 2.3: IMS CP Paket
IMS CP hat sich als eLearning Standard erfolgreich durchgesetzt. Er kann sowohl
alleinstehend sowie auch in Verbindung mit anderen Standards benutzt werden.
SCORM 1.2 und 2004, IMS Common Cartridge benutzen diese Spezikation zum
Austausch ihrer Inhalte zwischen Lernplattformen.
IMS QTI
IMS QTI unterstützt einen Austausch von Fragen, Tests und Testergebnissen zwischen Lernplattformen, Autorentools und anderen Werkzeugen. AssesmentTest, as-
sesmentItem, section, results report sind Hauptelemente in der QTI Spezikation. Ein
assesmentTest muss mindestens einen Abschnitt section haben, der wiederum keine,
eine oder mehrere Fragen assesmentItem sowie weitere Abschnitte beinhalten kann
(Version 1.2). Ein nach IMS QTI erstellter Test muss Metadaten beinhalten, um die
Tests in Fragekatalogen aundbar zu machen.
Einige Fragetypen aus der QTI Spezikation sind: True/False, Multiple Choice, Select text, Fill in the blank, Order objects, Drag object, Multiple response, Image hot
spot, Slide, Match items, Connect points.
Im Beispiel 2.1 [IGLC06] ist eine Frage im QTI 2.1 Standard dargestellt. Wie man
sieht, sind auch externe CSS möglich, sowie eine Untermenge von XHTML Elementen
zugelassen sind. Der Standard speziziert nicht, wie die Inhalte von Lernplattformen
26
interpretiert werden sollen. Ein Test kann also mit Hilfe von Flash oder Java-Applet
generiert werden.
<?
xml version=" 1 . 0 "
< !−−
e n c o d i n g="UTF−8" ?>
copyright University of Cambridge ESOL Examinations
<a s s e s s m e n t I t e m
−−>
x m l n s=" h t t p : / /www . i m s g l o b a l . o r g / x s d / i m s q t i _ v 2 p 1 "
x m l n s : x s i=" h t t p : / /www . w3 . o r g / 2 0 0 1 /XMLSchema− i n s t a n c e "
x s i : s c h e m a L o c a t i o n="
h t t p : / /www . i m s g l o b a l . o r g / x s d / i m s q t i _ v 2 p 1
h t t p : / /www . i m s g l o b a l . o r g / x s d / i m s q t i _ v 2 p 1 . x s d "
i d e n t i f i e r =" o r k n e y 1 "
t i t l e =" Orkney
1"
a d a p t i v e=" f a l s e "
t i m e D e p e n d e n t="
f a l s e ">
<r e s p o n s e D e c l a r a t i o n
i d e n t i f i e r ="RESPONSE"
c a r d i n a l i t y =" s i n g l e "
b a s e T y p e=" i d e n t i f i e r ">
<c o r r e c t R e s p o n s e>
<v a l u e>T</ v a l u e>
</ c o r r e c t R e s p o n s e>
</ r e s p o n s e D e c l a r a t i o n>
<o u t c o m e D e c l a r a t i o n
i d e n t i f i e r ="SCORE"
c a r d i n a l i t y =" s i n g l e "
b a s e T y p e=" i n t e g e r ">
< d e f a u l t V a l u e>
<v a l u e>0</ v a l u e>
</ d e f a u l t V a l u e>
</ o u t c o m e D e c l a r a t i o n>
<s t y l e s h e e t
h r e f=" s h a r e d / o r k n e y . c s s "
t y p e=" t e x t / c s s " />
<itemBody>
<d i v
c l a s s =" r i g h t p a n e ">
<o b j e c t
d a t a=" s h a r e d / o r k n e y . h t m l "
t y p e=" t e x t / h t m l " />
</ d i v>
<d i v
c l a s s =" l e f t p a n e ">
<p>
Read
if
the
the
text
about
following
the
Orkney
sentence
Islands
iscorrect
or
and
then
decide
incorrect .
</ p>
<c h o i c e I n t e r a c t i o n
r e s p o n s e I d e n t i f i e r ="RESPONSE"
s h u f f l e =" f a l s e "
m a x C h o i c e s=" 1 ">
<prompt>
Some
of
the
islands
are
home
to
animals
rather
than
people .
</ prompt>
<s i m p l e C h o i c e
i d e n t i f i e r ="T">C o r r e c t</ s i m p l e C h o i c e>
<s i m p l e C h o i c e
i d e n t i f i e r ="F"> I n c o r r e c t</ s i m p l e C h o i c e>
</ c h o i c e I n t e r a c t i o n>
</ d i v>
</ itemBody>
<r e s p o n s e P r o c e s s i n g
t e m p l a t e="
h t t p : / /www . i m s g l o b a l . o r g / q u e s t i o n / q t i _ v 2 p 1 / r p t e m p l a t e s /
m a t c h _ c o r r e c t " />
</ a s s e s s m e n t I t e m>
Beispiel 2.1: Eine Frage vom Type True/False im IMS QTI Standard
27
2 Analyse
Die Ergebnisse der von Lernenden durchgeführten Tests sind in QTI ebenfalls standardisiert, so dass eine Lernplattform bei Bedarf diese auswerten und auf eine eigene
Art und Weise darstellen kann.
IMS QTI ist derzeit
20
die einzige Spezikation, die Tests Format standardisiert hat.
Dennoch ist der Implementierungsaufwand seitens der Lernplattformen sehr hoch,
weil der Standard umfangreich und nicht fehlerfrei ist [PF07]. Piotrowski und Fenske kommen zu dem Ergebnis, dass QTI (in der Version 2.0) sogar ein ungeeignetes
Format zum Austausch von Tests ist, weil problematische Entscheidungen beim Entwurf des Standards getroen wurden und die Spezikation formale Schwächen und
Schwächen in der technischen Umsetzung in XML aufweist. Anderseits haben einige
Lernplattformen (ATutor, Dokeos, siehe Abschnitt A) und Softwareprogramme zum
Erstellen von Tests die Spezikation umgesetzt, so dass trotz festgestellter Mängel
dieser Standard benutzt werden kann.
IMS Common Cartridge
IMS CC ist ein neuer Standard, der einerseits die Interoperabilität zwischen Systemen ermöglicht und andererseits ein neues exibles Modell für modulare web-basierte
interaktive Kurse deniert. IMS CC unterstützt in erster Linie interaktive und kollaborative Kurse und Seminare.
Common Cartrige speziziert folgende Aspekte:

Format zum Austausch zwischen LMS - IMS CP

Zugrirechte für jeden Komponenten im Paket

Dublin-Core basierter Standard für Meta-Daten. Auch andere Standards dürfen
benutzt werden

Standard für Tests IMS QTI

Standard für das Ausführen und den Datenaustausch zwischen externen Applikationen

Standard für Diskussionsforen unter den Teilnehmern
Da sich auf den ersten Blick die Ziele von IMS CC und dem im folgenden betrachteten SCORM Standard überschneiden, erklärt IMS GLC die wichtigsten Unterschiede
21
(siehe Abbildung 2.4
).
IMS GLC betont, dass SCORM und IMS CC unterschiedliche Ziele verfolgen. SCORM
ist für das Training und hauptsächlich für einzelne Lernende entworfen worden, während IMS CC demgegenüber die Bedürfnisse vom kooperativen Lernen anspricht.
20 Stand: Juni 2010
21 http://www.imsglobal.org/cc/
28
Abbildung 2.4: Unterschiede zwischen IMS CC und SCORM
2.5.4 SCORM
Die Advanced Distributed Learning (ADL) Initiative ist eine Strategie des US Verteidigungsministeriums und wurde im Jahre 1997 gegründet. ADL hat das Shareable
Content Object Reference Model (SCORM) entwickelt, welches eine Sammlung von
Standards und Spezikationen für das web-basierte eLearning ist. SCORM ist ein Referenzmodell, das auf den existierenden Spezikationen von IMS, AICC, IEEE und
anderen aufbaut und primär den Anforderungen an web-basierte eLearning Inhalte
des US Verteidigungsministeriums entspricht.
Die wesentlichen Eigenschaften, denen SCORM entsprechen soll, sind:
Zugänglichkeit: Jederzeitige und ortsunabhängige Verfügbarkeit von Lernmaterialien
Interoperabilität: Benutzbarkeit der Inhalte, unabhängig von den für die Herstellung eingesetzten Werkzeugen
Dauerhaftigkeit:
Die erstellten Inhalte sollen auch nach Weiterentwicklung
von technischen Werkzeugen einsetzbar sein.
Wiederverwendbarkeit: Die Wiederbenutzung von Komponenten eines Kurses soll ermöglicht werden
SCORM 1.2 ist die meist verbreitete Version und wird in den meisten Lernplattformen unterstützt. Diese Version deniert im Wesentlichen, wie die Inhalte aggregiert
(Content Aggregation Model) werden können und wie sie mit Lernplattformen kommunizieren können (RTE). Darüber hinaus, deniert SCORM 1.2, wie die Inhalte mit
Hilfe von Metadaten beschrieben werden können.
29
2 Analyse
SCORM 2004
erweitert die Version 1.2 mit Sequenzing und Navigation Spezika-
tionen (IMS SS) und beseitigt Unklarheiten, die in früheren Versionen entstanden
sind. Eine weitere wichtige Neuerung von SCORM 2004 ist die Spezikation von
gemeinsamen Daten zwischen einzelnen Lerneinheiten.
Die relevanten Konzepte von SCORM werden im Folgenden betrachtet.
Content Aggregation Model
Content Aggregation Model (CAM) beschreibt einzelne Komponenten in eLearning
Kursen. Die Lernressourcen werden als Repräsentationen von beliebigen Informationen aufgefasst, die beim Lernen benutzt werden [Lea09a]. SCORM CAM besteht
aus

Content Model

Content Packaging

Meta-Daten

Sequenzierung und Navigation
Asset
Asset ist der kleinste Baustein eines Lernkurses. Asset kann eine beliebige Datei
sein, die dem Lernenden in einem Webbrowser dargestellt wird (eine HTML-, Flash-,
Audio-Datei oder ein Java-Applet). Ein Verschachtelung von Assets ist erlaubt. Die
einzelne Assets können auch mit Hilfe von Metadaten beschrieben werden, was die
Suche in Repositories ermöglicht und so den Wiederverwendungswert steigert.
Sharable Content Object
SCORM deniert Sharable Content Object (SCO) als eine Kollektion aus einem oder
mehreren Assets, die eine einzelne ausführbare Lernressource darstellt. Ein SCO kann
mit Hilfe von SCORM Laufzeitumgebung (RTE) mit einer Lernplattform kommunizieren, dabei ist ein SCO das kleinste Element, das von LMS angesprochen werden
kann. Im Idealfall, ist ein SCO unabhängig von anderen SCO's im Kurs und kann
wieder verwendet werden. LMS zeigt ein SCO als einen separaten Eintrag im Inhaltsverzeichnis und behandelt es getrennt von anderen SCO's. Ein SCO kann eigene
Lesezeichen, Auswertungen sowie den Fortschritt Status haben. Der Unterschied zwischen SCO und Asset besteht also darin, dass SCO mit LMS kommunizieren kann. Die
Kommunikation selbst erfolgt nach Institute for Electrical and Electronics Engineers
(IEEE) ECMAScript Application Programming Interface for Content to Runtime
Services Communication Standard [Lea09a].
ADL empehlt, die Gröÿe von SCOs relativ klein zu halten, so dass eine Wiederverwendbarkeit ermöglicht wird. Viele eLearning Entwickler und Lernplattformen fassen
30
einzelne Seiten im Kurs als ein SCO auf, was allerdings nicht immer die beste Möglichkeit ist. In [Ros09] wird gezeigt, dass ein SCO als Kapitel oft die bessere Wahl
wäre, denn oft würden nur einzelne Seiten aus dem Kontext gerissen.
Ein SCO muss den Anforderungen von SCORM RTE genügen, was bedeutet, dass zur
Laufzeit ein SCO eine Lernplattform API nden muss und mindestens die Initialize()
und Terminate() Methoden der API ausführen muss. Als Folge, jede Lernplattform,
die SCORM RTE implementiert hat, kann ein SCO ausführen und verfolgen. Dies ist
vor allem für diejenigen Tests wichtig, bei welchen beispielsweise die erreichte Anzahl
der Punkte gespeichert werden muss.
Content organization
Content Organisation bildet die Struktur der Inhalte ab und zeigt wie die Komponenten eines Kurses zueinander in Verbindung stehen (Abbildung 2.5 [Lea09a]). Die
einzelne SCOs und Assets enthalten also keine Navigations- oder SequenzierungsInformationen, andernfalls wäre die Wiederverwendbarkeit nicht gewährleistet, da
man sich nicht auf Verfügbarkeit anderer SCOs und Assets verlassen kann.
Abbildung 2.5: Beispiel Content Organization
Content Packaging
Das Ziel von Content Packaging ist, eine standardisierte Methode zum Austausch
zwischen Systemen und Werkzeugen zu denieren. Für Content Packaging benutzt
SCORM die IMS CP Spezikation, wobei SCORM noch explizit zusätzliche Anforderungen für SCOs und Assets deniert.
31
2 Analyse
Laufzeitumgebung
Die SCORM 2004 Laufzeitumgebung (Run Time Environment) Spezikation [Lea09b]
beschreibt, wie eine Kommunikation zwischen eLearning Inhalten und Lernplattformen stattnden kann. Auÿerdem wird ein Datenmodell für den Austausch der Informationen speziziert. Insbesondere werden die Anforderungen an die Lernplattformen
sowie an SCO deniert.
Nach SCORM Standard stellt eine Lernplattform die Inhalte dar, indem sie die Navigationsbefehle interpretiert und die entsprechenden Inhaltsobjekte ausführt. SCORM
deniert nicht, wie dieser Prozess in einer Lernplattform implementiert wird, sondern
es wird lediglich verlangt, dass die Inhalte (SCOs und Assets) zugestellt werden. Des
Weiteren wird beschrieben, wie eine Lernplattform mit den Lernsitzungen und Lernversuchen umgeht. Eine Lernsitzung ist nach SCORM ein ununterbrochener Zeitabschnitt, währenddessen ein Inhaltsobjekt bearbeitet wird. Ein Lernversuch ist eine
Aktivität des Lernenden, welche die Anforderungen des Inhaltsobjekts zu erfüllen
versucht. Dabei kann ein Lernversuch durchaus mehr als eine Lernsitzung dauern.
Der Kommunikationsmechanismus wird durch eine Programmierschnittstelle (API)
realisiert. Diese Schnittstelle ist die Standardisierung für Kommunikation zwischen
SCO und der Lernplattform. Wie die Lernplattform mit ihrer serverseitigen Komponente interagiert, wird hierbei nicht deniert und somit der Lernplattform selbst
überlassen. Auch die Implementierungsdetails der API Funktionen sind nicht speziziert und für den SCO Entwickler unwichtig.
Die API ist im Wesentlichen ein Satz von Funktionen, die von SCOs benutzt werden
können und erlaubt die Speicherung und Anforderungen der Werte von der Lernplattform. Die Kommunikation selbst kann nur von Seite SCO initiiert werden, es gibt für
eine Lernplattform keine Möglichkeit die Funktionen des SCOs aufzurufen.
SCORM unterteilt die API Funktionen in 3 Kategorien:
1. Sitzungsmethoden markieren Start und Terminierung der Kommunikation zwischen SCO und der Lernplattform
2. Datenübertragungmethoden ermöglichen den Datenaustausch
3. Support Methoden sind Hilfsmethoden wie z.B. Fehlerbehandlung
Die wichtigsten Methoden werden in der Tabelle 2.2 aufgelistet:
Eine Lernplattform muss zur Laufzeit eine API-Instanz bereitstellen, die von SCO gefunden werden kann und deren Funktionen dann benutzt werden können (Abbildung
2.6 [Lea09b]).
SCO ist verantwortlich, die von LMS bereitgestellte API-Instanz zu nden und als
Minimum die Funktionen Initialize() und Terminate() auszuführen. Sollten die
Daten zwischen der Lernplattform und SCO transferiert werden, geschieht das mit
32
Abbildung 2.6: SCORM API: ein SCO kann die Methoden aufrufen
33
2 Analyse
Name
Rückgabe
Typ
Initialize()
True/False
Sitzung
Terminate()
True/False
GetValue(name)
Wert/ Datenübertragung
SetValue(name, wert)
True/False
Datenübertragung
Commit()
True/False
Datenübertragung
GetLastError()
Fehlerkode
Support
GetErrorString(errorcode)
Fehlerinformationen
Support
GetDiagnostic()
Diagnoseinformationen
Support
Sitzung
Tabelle 2.2: Wichtigste Methoden der API
Hilfe der weiteren Funktionen sowie auch mit dem zugrundeliegenden Datenmodell.
Das Datenmodell sichert zu, dass bestimmte Informationen über SCO in der Lernplattform benutzt werden können. Ohne ein solches Datenmodell wäre es unmöglich
die Interoperabilität zu garantieren. Die Elemente des Datenmodells können z.B. den
Status oder die erzielten Punkte im Test repräsentieren.
Sequenzierung und Navigation
Eine der Neuerungen im SCORM 2004 ist die Einführung von Sequenzierung und
Navigation, die gröÿtenteils auf IMS Simple Sequencing basiert. Wie der Name schon
suggeriert, deniert SCORM in diesem Standard in welcher Reihenfolge die Inhaltsobjekte dem Lernenden präsentiert werden können. SCORM Sequenzierung hängt
von dem Lernaktivitätsbaum, der Sequenzierungsstrategie und verschiedenen Ereignissen ab [Lea09c]. Jede Lernaktivität hat ein zugehöriges Inhaltsobjekt, welches dem
Lernenden zugestellt werden soll. Die SCOs können nach diesem Standard auch selbst
die Navigationsanforderung der Lernplattform mitteilen.
Da die zugrundeliegende IMS SS Spezikation ein recht komplexer Standard ist (mit
simple sind hier einfache Navigationsmodelle gemeint), ist die Implementierung in
Lernplattformen eher selten zu nden. Aus diesem Grund bleibt SCORM 1.2 StateOf-The-Art mit seinem hierarchisch aufgebautem Menü und der Vor- und ZurückNavigation zwischen den Inhaltsobjekten [NG05].
34
3 Lösungskonzept
3.1 Übersicht
Nach der Analyse (2) der verschiedenen Werkzeuge und Programme (2.3.3), die für eine Erstellung von Drehbüchern verwendet werden können, wird deutlich, dass es kein
bestes Werkzeug für die kooperative Drehbuchproduktion gibt. Es ist eher so, dass
man ausgehend aus einer bestimmten Situation eine Wahl treen muss, die für eine
konkrete Situation zugeschnitten ist. Beispielsweise würde sich für eine kooperative
Erstellung eines Drehbuches in einer kleinen Gruppe von Autoren der Aufwand der
Installation und des Betriebs eines Wikis (2.3.3) oder SVN-Repository (2.3.4) nicht
lohnen. In dem Fall bietet sich Google Docs (2.3.3) oder ein anderer Online-Editor
(2.3.3) als eine gute Lösung an, denn dort ist eine Installation nicht erforderlich.
Steigt die Anzahl der Autoren und produzierter Kurse oder werden die Kurse in
einer Firmenumgebung erstellt, ist dagegen Mediawiki oder ein Desktop-Texteditor
wie MS Word (2.3.3) oder OO Writer (2.3.3) in Verbindung mit Versionskontrolle die
bessere Wahl. Man hat in dem Fall einen zentralen Ort für die erstellten Inhalte und
vermeidet mögliche Datenschutzbedenken, die sich im ersten Fall ergeben könnten. Es
ist also ein Konzept erforderlich, das nicht nur einen bestimmten Editor unterstützt,
wie das in bisherigen Lösungen (1.2) der Fall ist, sondern die Verwendung von gerade
geeigneter Software erlaubt.
Der hier vorgestellte Lösungsansatz ist in zwei Bereiche unterteilt (Abbildung 3.1):
eine Denition, wie die Inhalte im Drehbuch erfasst werden (3.2) und wie aus dem
erstellten Drehbuch ein eLearning Kurs erstellt wird (3.4). Bei der Erstellung werden
die im Drehbuch erfassten Inhalte analysiert, validiert und unter der Berücksichtigung der Einstellungen, zu einem Kurs transformiert. Damit der erstellte Kurs von
möglichst vielen Lernplattformen interpretiert werden kann, ist es erforderlich ein
eLearning Standard (2.5) als Format des Kurses zu verwenden.
3.2 Erfassen der Inhalte über Drehbuchvorlagen
Der Ausgangspunkt für den Entwurf des Lösungskonzeptes ist die Tatsache, dass die
Autoren die eLearning Inhalte in Drehbüchern erfassen, um die Vorteile von Textbearbeitungsprogrammen nutzen zu können. Die Drehbücher (2.1) bieten den Autoren
die Möglichkeit, sich auf die Inhalte zu konzentrieren, ohne auf die Implementierungsdetails wie das Layout der Seite oder die Gröÿe einer Schrift achten zu müssen. Hierbei
werden nur die nötigsten Informationen abgefragt, die später für die Umsetzung des
35
3 Lösungskonzept
Abbildung 3.1: Aufteilung des Lösungskonzepts in zwei Bereiche
Kurses notwendig sind.
Diese Entkoppelung der Inhalte von dem Layout und den Formatierungen ermöglicht
bei der kooperativen Bearbeitung der Drehbücher maximale Flexibilität bei der Wahl
der Editoren, sowohl für die Textbearbeitung als auch für die Produktion von Medien. Die Vertrautheit der Autoren mit einem gewählten Programm ist ein wichtiger
Vorteil, welcher bei der Produktivität eine groÿe Rolle spielt.
Die Transformation des Drehbuches zu einem Kurs setzt voraus, dass das Layout
und die Formatierungen des Kurses bereits von einem Designer entwickelt wurden
und die HTML-Dateien, in die die Drehbuchinhalte übertragen werden, zur Verfügung stehen. Für das Erstellen einer neuen Seite im Drehbuch wählt der Autor einen
gewünschten Seitentyp (zum Beispiel Textseite mit 2 Spalten) und beachtet dabei
die dort gültigen Einstellungen. Die Einstellungen denieren vor allem das Layout
(beispielsweise die Anzahl der Spalten oder Platzierung eines Mediums) und die obligatorischen Informationen, die erfasst werden müssen.
Die typischen Informationen, die bei der Erstellung eines eLearning Kurses benötigt
werden, sind folgende:
36

Kursstruktur (Unterteilung in Abschnitte)

Meta-Daten zum Kurs (Titel, Autor, Datum, Beschreibung etc.)

Titel der Seite

Meta-Daten zu einzelnen Seiten

interne und externe Verlinkungen

Pfade zu Medien, falls diese nicht direkt in Textkörper eingefügt werden

Fragen und die zugehörigen Antworten, Punkte, Feedbacks, Tipps, Reihenfolgen
der Antworten etc.
Eine bestimmte Lernplattform kann unter Umständen zusätzliche Daten benötigen,
um die dort verfügbaren technischen Funktionalitäten umzusetzen:

Glossareinträge

Fuÿnoten

Seiteneinstellungen:
Navigationsrestriktionen (darf die nächste Seite angesteuert werden, wenn
der Test nicht bestanden ist?)
Zeitbeschränkungen (wie lange darf eine Aufgabe bearbeitet werden)
Damit die erfassten Inhalte exibel wiederverwendbar sind und die Autoren nicht
zu sehr mit Einzelheiten der Implementierung belastet werden, ist es ratsam die Erhebung von den autorenprogrammspezischen Einstellungen im Drehbuch möglichst
minimal zu gestalten.
Es ist daher naheliegend, für jeden verfügbaren Seitentyp eine Vorlage im Drehbuch
anzubieten, in die die Kursinhalte eingegeben werden. Jedes Autorenprogramm deniert eigene Vorlagen, so dass die dort spezischen Informationen erfasst werden.
Damit die Unterstützung von mehreren Editoren implementiert werden kann, ist eine Vereinheitlichung der Vorlagenstruktur notwendig. Eine Vorlage im Drehbuch gilt
dann als eine Eingabemaske, in der ein Autor die oben betrachteten Informationen
eingibt. Somit ist eine Vorlage eine Abbildung einer Seite im Kurs mit dazugehörigen
Inhalten, Einstellungen und Meta-Daten.
In der Abbildung 3.2 ist eine Vorlage für das Erstellen einer Textseite mit zwei Spalten
und die entsprechende HTML-Datei dargestellt. In der HTML-Datei sind Platzhalter
deniert, die beim Generieren des Kurses durch die im Drehbuch erfassten Inhalte
ersetzt werden.
Bevor eine Seite im Drehbuch angelegt wird, muss dem Autor eine Auswahl an vorhandenen Vorlagen angeboten werden. Wie in dem Kapitel über die geeigneten Editoren für die Drehbucherstellung (2.3.3) festgestellt wurde, unterscheiden sich die
Programme in ihren Automatisierungsmöglichkeiten.
Im Falle MS Word (2.3.3) können entsprechende Schaltächen bereitgestellt werden, über die man VBA-Makros für das Einfügen einer Vorlage ausführt. Die gleichen Möglichkeiten sind auch für OO Writer (2.3.3) vorhanden, wobei dort mehrere
37
3 Lösungskonzept
Abbildung 3.2: Eine Textvorlage im Drehbuch, eine HTML-Datei und die generierte
Kursseite
38
Scriptsprachen zur Verfügung stehen. Eine Wiki-Software (2.3.3) bietet keine solchen
integrierten Automatisierungsmöglichkeiten. Die entsprechenden Funktionen müssen
dort mit Hilfe von JavaScript beziehungsweise mit Wiki-Erweiterungen implementiert werden. In Google Docs (2.3.3) ist es leider nicht möglich Arbeitsvorgänge zu
1
automatisieren, obwohl sich die Situation in naher Zukunft ändern wird . Eine Alter-
2
native für browserbasierte Editoren besteht in der Entwicklung einer Erweiterung
oder einer Toolbar, die die Vorlagen verwaltet und in den Editor einfügt.
3.2.1 Kursstruktur
eLearning Kurse werden in der Regel in mehrere Abschnitte untergliedert. Die Gliederung ist vor allem für die Navigation im Kurs wichtig und muss ebenfalls in einem
Drehbuch erfasst werden können. Eine Möglichkeit besteht darin, die Position der
Seite im Kurs in der Vorlage anzugeben. Dieser Weg ist jedoch problematisch, wenn
die Seite später an eine andere Position im Kurs verschoben werden muss. Denn in
diesem Fall müssen unter Umständen die Positionsangaben von sämtlichen Seiten
im Kurs entsprechend angepasst werden. Eine bessere und einfacher zu bedienende
Methode ist, eine Gliederung mit Hilfe von Überschriften abzubilden. Hierbei können die Gröÿen von Überschriften als Angabe der Ebene, in der sich ein Abschnitt
im Kurs bendet, verwendet werden. Eine Überschrift der Gröÿe 1 (also die gröÿte)
würde dann nach diesem Schema der ersten Ebene im Kurs zugeordnet (Kurs), eine
Überschrift 2 der zweiten Ebene (zum Beispiel einer Lektion) und so weiter. Eine
Seitenüberschrift dient zugleich auch als Name der Seite. Dadurch wird eindeutig
festgelegt, zu welchem Abschnitt im Kurs eine Seite gehört. Als Beispiel kann ein
Kurs in der LernBar (2.4) vier Ebenen beinhalten: Kurs, Lektion, Seite und optionale Unterseite, die nach diesem Verfahren mit Hilfe von Überschriften der Gröÿe 1, 2,
3 und 4 entsprechend gekennzeichnet werden können.
Dieser Ansatz hat einen weiteren Vorteil in Editoren wie MS Word oder OO Writer (2.3.3) - mit Hilfe von einer Outliner Funktion kann die Struktur eines Kurses
besonders komfortabel geändert werden. In der Outliner-Ansicht können die Inhalte
von Seiten bis auf die Überschriften ausgeblendet werden und die Position einer Seite
oder eines Kapitels geändert werden, indem man die Überschriften per Drag-n-Drop
auf eine gewünschte Stelle verschiebt. Diese Funktion eignet sich auch, um zunächst
die Struktur des Kurses zu entwerfen, bevor die Inhalte selbst erfasst werden. Die
Möglichkeit der komfortablen Strukturierung der Inhalte bieten nicht nur die Texteditoren an - am Beispiel (Abbildung 3.3) MediaWiki sieht man, dass auch in Wikis
die Struktur eines Kurses leicht erzeugbar und manipulierbar ist. Dafür wird eine
Wiki-Seite angelegt, in der mit Hilfe von Überschriften eine Kursstruktur festgelegt
3
wird und die Seiten selbst durch einen Verweis
eingebunden werden. Auf diese Weise
1 Eine Apps Script Engine wurde ohne einen genauen Veröentlichungstermin auf I/O Konferenz
Ende Mai 2010 angekündigt
2 iMacros ist ein Beispiel einer Automatisierungserweiterung für Firefox Browser
3 Die Syntax in Mediawiki: {{:Seitenname}}
39
3 Lösungskonzept
Abbildung 3.3: Kursstruktur in MediaWiki.
lassen sich mehrere Kurse erstellen, die zwar unterschiedliche Strukturen aufweisen,
verwenden aber die selben Seiten, ohne diese kopieren zu müssen, wie das in den
Texteditoren der Fall wäre.
3.2.2 Erfassen der Seiten
Die Gestaltung der Eingabe von Seiten ist wohl die wichtigste Aufgabe beim Konzept
der Drehbücher. Zum einen sollten die Inhalte dort intuitiv und einfach eingegeben
werden können, zum anderen müssen sie später von der Software maschinell verarbeitet werden können. Die Verwendung von Tabellen ist meiner Meinung nach der
richtige Ansatz für die Lösung dieser Ziele. Der Vorteil von Tabellen liegt in ihrer
klaren Strukturierung - eine Zelle entspricht einer Informationseinheit und da eine
Tabelle selbst eine geschlossene Einheit bildet, bietet das eine klare Abgrenzung der
Seiten voneinander. Diese Eigenschaften ermöglichen späteres automatisches eindeutiges Auslesen der eingegebenen Daten. Die erste Anforderung an einen Editor ist
also die Unterstützung von Tabellen.
Eine Vorlage entspricht also nun einer Tabelle, in der die benötigte Daten (3.2) vom
Autor eingegeben werden. Damit diese Informationen auch zugeordnet werden können, wird eine Zelle in der Tabelle entweder einen Schlüssel oder in der nächsten
Zelle den dazugehörigen Wert enthalten. Würde sich beispielsweise in der Zelle i der
Schlüssel Datum: benden, dann wird in der Zelle i+1 ein Wert 2010-11-01 vom
Autor eingegeben. Beim Auslesen des Drehbuches werden die einzelnen Werte ihren
Schlüsseln zugeordnet. Die Position eines Schlüssel-Wert Paares in der Tabelle spielt
40
hierbei keine Rolle, was eine exible Gestaltung von Vorlagen erlaubt.
Die Erfassung von Inhalten im Drehbuch bedeutet, dass die Text-Bausteine als solche auch erkannt werden können. Während Listen, Tabellen und Textformatierungen
vom Editor direkt, wie sie dort dargestellt werden, übernommen werden können, ist
das im Fall von Medien nicht trivial. Bei den Bildern bieten sich zwei Möglichkeiten
an: zum einen kann man in den meisten Editoren das Bild einfügen und die Gröÿe des
Bildes oder andere Eigenschaften entsprechend anpassen, zum anderen kann der Autor einfach auf ein Bild verweisen, indem er den Pfad zum Bild und die dazugehörige
Bezeichnung angibt. Dabei wird die Platzierung des Bildes und dessen Gröÿe vom
Designer der Seite festgelegt. Für andere Medien, die von Editor nicht unterstützt
werden, gibt es nur die letztere Möglichkeit. Dies ist allerdings keine Einschränkung schlieÿlich ist der Zweck eines Drehbuches das Sammeln der Inhalte und Einstellungen, und nicht deren genaue Darstellung im Drehbuch selbst (2.1).
Einige Informationen, die man in den Vorlagen erfassen möchte, dürfen nur bestimmte Werte annehmen (zum Beispiel richtig oder falsch bei Antworten in Tests). Damit
der Autor mit diesen Einschränkungen möglichst komfortabel arbeiten kann und die
Schreibfehler ausgeschlossen werden, können je nach Editor, Formulare benutzt werden, so dass der Autor die Werte nicht selbst eingeben muss, sondern nur einen der
vorgegebenen auswählt. Diese Einschränkungen erleichtern auch das spätere Extrahieren der Inhalte und macht die Lösung insgesamt robuster, denn keine unerwartete
Werte vorkommen können. Die Möglichkeiten der Editoren unterscheiden sich auch
bei dieser Funktion: in MS Word und OO Writer ist diese Funktionalität vorhanden,
4
Google Docs bietet dies zunächst nur in Tabellenkalkulation . In einer Wiki-Software
fehlt diese Möglichkeit, könnte jedoch in einem WYSIWYG Editor implementiert
werden.
3.2.3 Verknüpfungen von Inhalten
Neben Medien müssen auch Verlinkungen im Text als ein Sonderfall betrachtet werden. Externe Verlinkungen (in der Regel auf eine Webseite) können vom Editor einfach übernommen werden, denn eine URL ist eindeutig. Ganz anders sieht es mit
internen Verweisen - zum einem können sich die Seiten während der Arbeit am Drehbuch verschieben, zum anderen gehen verschiedene Editoren mit internen Verweisen
verschieden um. Zwar sind solche Verlinkungen von Standard SCORM nicht vorgesehen (vgl. Kapitel 2.5.4) zumindest nicht zu anderen SCOs, dennoch sind die Verknüpfungen durchaus erwünscht und erhöhen die Benutzerfreundlichkeit des Kurses.
Bei internen Verlinkungen muss sichergestellt werden, dass die Zielseite existiert.
Des Weiteren ist es wünschenswert, die Verlinkung so zu gestalten, dass die Seiten
austauschbar sind, das heiÿt, wenn die Zielseite mit anderen Inhalten oder Namen
4 Ab August 2010
41
3 Lösungskonzept
ersetzt wird, soll die Verknüpfung weiterhin bestehen und zum Ziel führen. Eine
mögliche Lösung dafür wäre, jeder Seitenvorlage eine eindeutige ID zu vergeben (die
zum Beispiel bei Einfügen der Vorlage automatisch generiert wird). Diese dient dann
als Verknüpfungangabe. Wird die Seite ersetzt oder verschoben, bleibt die ID erhalten. Das Verweisen auf eine Position im Kurs ist wegen möglichen Änderungen in
der Kursstruktur problematisch. Somit ist die erste Möglichkeit vorzuziehen. In MS
Word, OO Writer und einer Wiki können auch die dort verfügbaren internen Mechanismen für Verlinkungen benutzt werden, wobei ein Verweis in Editoren auf der
Ebene von Unterschriften implementiert ist (OO Writer erlaubt auch Verweise auf
Objekte wie Bilder, Zeichnungen etc.). Zu beachten ist hierbei, dass beim Verschieben und Umbenennen eines Abschnittes je nach Editor die Zuordnung zum Ziel nicht
mehr wie erwartet funktioniert. OO Writer benutzt für einen Verweis den Namen des
Zielabschnittes (Verschieben ohne Umbennen möglich) und MS Word verwendet die
Position einer Überschrift (Umbennen ohne Verschieben möglich), um einen Anker
für den Verweis zu setzen. In MediWiki ist das Verschieben und Umbenennen der
Seiten so gestaltet, dass die Verknüpfung bestehen bleibt. Obwohl Google Docs noch
keine Funktionalität für interne Links anbietet, können dafür aber die dort verfügbaren Lesezeichen benutzt werden, was für den Benutzer natürlich aber etwas mehr
Aufwand bedeutet, denn jede Seite, auf die verwiesen wird, muss zuerst als ein Lesezeichen gekennzeichnet werden.
3.2.4 Integration von Medien
Wie in Kapitel 3.2.2 bereits beschrieben, werden Medien entweder in das Textbearbeitungsprogramm eingefügt oder es wird ein Verweis auf diese angegeben. Für die
Implementierung von Verweisen auf Medien gibt es folgende Möglichkeiten. Die Position eines Mediums wird in manchen Vorlagen vom Designer fest vorgegeben. In dem
Fall ist eine Angabe des Pfades und der Bildunterschrift in der Tabelle ausreichend.
Dafür werden in der Vorlage die entsprechenden Eingabefelder vorgesehen.
Möchte der Autor dagegen ein Medium im Textkörper frei platzieren, muss der Verweis an dieser Stelle auf eine bestimmte Weise ausgezeichnet werden, so dass dieser
als solcher erkannt wird und nicht als Inhalt des Kurses interpretiert wird. Dies kann
durch Verwendung von Trennzeichen, Zeichenketten oder anderen Merkmalen erreicht
5
werden. Zum Beispiel , [[Image:Hydrangeas.jpg|Bildunterschrift]]. Das Einfügen von
solchen Auszeichnungen kann ebenfalls mit Hilfe von verfügbaren Automatisierungsmöglichkeiten erreicht werden, so dass der Autor nur den Namen und die Unterschrift
des Bildes angeben muss.
Matematische Formeln werden in vielen Editoren (2.3.3) unterstützt und können dort
in der Regel mit Hilfe eines eingebauten Formeleditors eingegeben werden. Falls diese
Funktionalität in einem Editor fehlt oder die Qualität der erstellten Formeln nicht
5 Hier wurde Wiki Syntax verwendet
42
3.3 Ausgabeformat der Editoren
ausreichend ist, können die Formeln in einem anderen Editor erstellt werden und im
Drehbuch als ein Medium behandelt werden.
3.2.5 Interaktive Seiten
Das Konzept von Tabellen mit Schlüssel-Werte Paaren eignet sich ebenfalls für die
Erfassung von interaktiven Seiten. Für jeden Testtyp wird eine entsprechende Vorlage angeboten, in der die Testeinstellungen abgefragt werden. Da bei manchen Fragen
(zum Beispiel Single Choice oder Multiple Choice) mehrere Antworten angegeben
werden müssen, wird die entsprechende Anzahl von Antwortfelder in der Vorlage vordeniert. Dadurch wird sichergestellt, dass die maximale Anzahl der Antworten nicht
überschritten wird und der Autor die Tabelle nicht verändern muss, um eine neue
Antwort hinzuzufügen.
Es ist von Vorteil den Schlüssel für eine Antwort in einer Kongurationsdatei zu denieren, so dass beim Transformieren des Kurses die Software die Antworten als solche
erkennen kann. Dies ermöglicht die Speicherung von Reihenfolge der Antworten und
erleichtert die Zuordnungen von zugehörigen Punktezahlen, Feedback etc.
Mit steigender Komplexität einer interaktiven Seite wird es möglicherweise nicht gelingen, diese im Drehbuch zu erfassen. In dem Fall muss die Seite in dem verwendeten
Autorenprogramm erfasst werden.
3.3 Ausgabeformat der Editoren
Fast jedes Textbearbeitungsprogramm verwendet für die Ausgabe der Inhalte ein eigenes spezisches Format. Für das Auslesen der Inhalte aus den Dateien ist also die
Implementierung von einem entsprechenden Parser erforderlich. Dies bedeutet vor
allem einen nicht unerheblichen Aufwand, da die Spezikationen von den Formaten
6
umfangreich
und komplex sind. Es muss dort jedes Merkmal des Editors abgebildet
werden, so dass beim erneutem Önen eines Dokumentes, der interne Zustand wiederhergestellt werden kann. Dies betrit vor allem die fortgeschrittenen Funktionen
wie beispielsweise Änderungen verfolgen oder Kommentare im MS Word. Um die
Unterstützung von mehreren Editoren dennoch zu ermöglichen, ist ein gemeinsames
Format erforderlich, in das die Editoren beziehungsweise externe Konvertierungsprogramme die Inhalte exportieren können.
In der Regel bieten Texteditoren eine Auswahl an Ausgabeformate: als Beispiel können die Dateien in Open Oce Writer auÿer eigenem Format auch in einem für
Microsoft Word geeigneten Format und in weiteren wie HTML, XML oder RTF
gespeichert werden. Bei allen der betrachteten Editoren besteht die Möglichkeit der
6 Die Spezikation von Microsoft entwickeltem Oce Open XML Format beträgt beispielsweise
über 5000 Seiten
43
3 Lösungskonzept
Ausgabe als HTML, was ein erster Grund für die Auswahl des Formates ist. Des Weiteren ist HTML auch das Format in dem WBT-Kurse (2.2) dem Benutzer schlieÿlich
vorliegen. Diese Verbindung zum Zielformat macht HTML aus meiner Sicht als eine natürliche Wahl des Ausgabeformates. Der Browser kann die Inhalte aus dem
Editor sofort darstellen, ohne dass diese vorher transformiert werden müssen. Es sei
denn, eine Filterung (3.4.2) bestimmter Formatierungen erwünscht ist, die wiederum viel einfacher in HTML vorzunehmen ist. Die wichtigsten Konzepte, die für das
Erfassen der Inhalte benötigt werden, (Überschriften, Tabellen und Verknüpfungen),
werden in HTML durch entsprechende Elemente repräsentiert (h1, table und a) und
können durch Software leicht identiziert werden. Für das Verarbeiten von HTML
sind in vielen Programmiersprachen entsprechende Parser bereits programmiert, so
dass dies ein weiterer Vorteil für die Wahl ist. Zu bemerken ist dabei, dass es während
der Bearbeitung des Drehbuches das vom Editor interne Format verwendet wird und
erst bevor man die Inhalte in einen Kurs transformieren möchte, ist eine Speicherung
beziehungsweise Konvertierung zu HTML notwendig. Dadurch können die editorspezischen Funktionalitäten im vollen Umfang genutzt werden.
Als Alternative zu HTML kann XML als Ausgabeformat verwendet werden. XML
gilt als restriktiveres Format als HTML (keine fehlende Tags erlaubt, etc.) und kann
Editor-Inhalte genauer beschreiben als HTML, schlieÿlich ist HTML nicht für solche Zwecke konzipiert worden und stellt in dem Sinne eher eine Untermenge von
XML dar. Dementsprechend ist aber auch der Aufwand höher, die XML-Ausgaben
zu parsen. Ein weiterer Grund gegen XML ist, dass die XML-Ausgaben der Editoren unterschiedlich sind, denn anders als bei HTML sind die einzelnen Elementen
in XML nicht speziziert. Dazu kommt auch noch, dass sich die Spezikationen der
XML-Ausgaben mit verschiedenen Versionen der Software ändern können, was für
HTML nicht passieren dürfte (abgesehen von Umstieg auf HTML-5).
3.4 Transformieren des Drehbuches zu einem
eLearning Kurs
In vorangegangenen Kapiteln wurde deniert, wie die Inhalte in einem Drehbuch erfasst werden, so dass deren Auslesen auch von verschiedenen Editoren möglich ist. Im
Folgenden wird ein Konzept für ein Programm vorgestellt, das als Eingabe ein Drehbuch erhält und als Ausgabe den daraus resultierenden Kurs in einem gewünschten
Format ausgibt. Des Weiteren soll das Programm die Anbindung von neuen Autorenprogrammen unterstützen.
Um diese Ziele zu erreichen ist in erster Linie eine modulare Architektur des Programms notwendig. Es ist erforderlich Schnittstellen zu denieren, die beim Anbinden von neuen Autorenprogrammen implementiert werden müssen.
44
3.4 Transformieren des Drehbuches zu einem eLearning Kurs
Für die Architektur des Programms schlage ich folgende Hauptkomponenten:

Im ersten Schritt wird das Drehbuch zu HTML konvertiert. Dies kann teilweise
vom Benutzer vorgenommen werden (Speichern als HTML), oder auch automatisch von der Software übernommen werden. Dabei müssen eventuell die
Korrekturen von Ausgabe des Konverters vorgenommen werden. Denn jeder
Editor hat seine Besonderheiten beim Generieren von HTML, die man sonst
im nächsten Schritt gesondert behandelt werden müsste. Beispielsweise wird
die Inhalt eines Open Oce Writer Dokuments wie erwartet in HTML direkt
innerhalb von <body> Elements ausgegeben, MS Word dagegen umrandet die
Inhalte noch mit einem <div> Element. Dieses Modul hat also auch die Aufgabe, die HTML-Ausgaben aus verschiedenen Quellen in eine einheitliche Form
zu bringen.

Parsen von HTML in eine Datenstruktur

Die in Editor erfassten Inhalte können unerwünschte Formatierungen des Textes oder Text-Bausteine enthalten, die von dem verwendeten Autorenprogramm
nicht unterstützt werden. In diesem Schritt können solche Formatierungen entfernt oder durch die vordenierten ersetzt werden.

Nun gilt es die gewonnenen Daten in HTML-Dateien zu speichern, die den eigentlichen Kurs bilden. Dafür werden vom Designer des Kurses HTML-Vorlagen
bereitgestellt, in die die Daten aus dem Drehbuch eingefügt werden. Die bereitgestellte Vorlagen enthalten zu diesem Zweck spezielle Platzhalter, deren
Denitionen in einer Kongurationsdatei abgelegt werden.

Nachdem der Kurs generiert wurde, kann dieser in einen eLearning Standard
(2.5) umgewandelt werden. Für jeden unterstützten eLearning Standard muss
es also in diesem Modul eine Implementierung geben.
Wie der Abbildung 3.4 zu entnehmen ist, ist es vorgesehen, dass jedes unterstütze
Autorenprogramm die Schritte des Validieren und des Schreibens des Kurses auf eine eigene Art und Weise implementiert. Die Konvertierung zu HTML, das Parsen
und das Erzeugen eines Kurses in einem eLearning Standard ist dagegen unabhängig
von dem verwendeten Autorenprogramm. Hier bietet sich Abstract Factory als Entwurfsmuster an, in dem die konkreten Klassen dem Hauptmodul (hier coursecreator )
erst zur Laufzeit bereitgestellt werden. Möchte man also ein neues Autorenprogramm
einbinden, müssen die in den abstrakten Klassen denierten Methoden implementiert
werden.
3.4.1 Parsen
Die Aufgabe dieses Moduls ist das Parsen von HTML-Datei, dabei werden die dort
enthaltene Daten extrahiert. Die Überschriften, die die Struktur des Kurses denieren
und die Tabellen, die einzelne Seiten des Kurses beinhalten werden analysiert und in
45
3 Lösungskonzept
Abbildung 3.4: Technisches Konzept der automatischen Transformation von Drehbücher
eine Datenstruktur gespeichert. Da es vorausgesetzt wird, dass im ersten Schritt (3.4)
die Unterschiede in HTML-Ausgabe von den Editoren beseitigt wurden, verläuft das
Parsen einheitlich für alle Quellen. In Tabellen, in denen die einzelne Seiten erfasst
wurden, soll der Parser in der Lage sein, die Schlüssel-Werte Paare zu erkennen und
entsprechend in einer Datenstruktur zu speichern. Bei Bedarf kann der Parser, anhand der Anweisungen in einer Kongurationsdatei das HTML-Markup komplett aus
den gefundenen Werten entfernen (zum Beispiel für die erfassten Kurseinstellungen).
Dafür können für die zugehörigen Schlüssel spezielle Präxe (zum Beispiel HTML_)
verwendet werden, so dass der Parser erkennen kann, wann HTML-Markup nicht entfernt werden soll.
Der Parser ist anhand der Überschriften in der Lage, die Positionen der Seiten im
Kurs festzustellen. Aus diesem Grund ist dieses Modul auch eine geeignete Stelle, um
die Struktur des Kurses (3.2.1) zu erfassen. Da die Kurse meistens eine hierarchische
Anordnung von Lektionen und Seiten aufweisen, kann dies hier in einer geeigneten
Datenstruktur (zum Beispiel ein Baum) gespeichert werden. Damit die einzelnen Seiten leichter identiziert werden können, ist an dieser Stelle auch eine eindeutige ID
jeder Seite zu vergeben. Dies erleichtert vor allem eine spätere Implementierung von
den internen Verlinkungen (3.2.3).
Da man an der Reihenfolge der Antworten für Tests interessiert ist (3.2.5) und Tests
oft eine gesonderte Behandlung erfordern, ist es ratsam schon beim Parsen zwischen
den Tests und anderen Seitentypen zu unterscheiden. Hierbei können entweder die
Angabe des Seitentyps oder auch ein Präx in Schlüsseln für Antworten verwendet
werden.
46
3.4 Transformieren des Drehbuches zu einem eLearning Kurs
3.4.2 Validieren und Filtern
Die Erstellung der Kurse im Drehbuch bedeutet, dass die dort erfassten Inhalte später in einen Kurs umgewandelt werden müssen. Dabei werden die vom einem Designer vorbereitete HTML-Vorlagen mit den aus dem Drehbuch extrahierten Inhalten
befüllt. Die Gestaltung der Kurse vom Designer setzt voraus, dass die Inhalte im
Drehbuch nicht beliebig formatiert werden dürfen, denn diese müssen harmonisch in
die vorbereitete Vorlagen einieÿen. Die Wahl von Farbpallete, Schriftgröÿen und anderen Formatierungen wird von Designer getroen und die Formatierungen aus dem
Drehbuch dürfen dies nicht ändern. Da bei der Erstellung eines Drehbuches (2.1) der
Fokus auf den Inhalten und nicht auf den Formatierungen liegt, müssen also diese
entsprechend überprüft beziehungsweise bereinigt werden. Es ist also nicht erforderlich, dass der Autor die Formatierungen des Kurses beachten muss.
Einige Formatierungen des Textes können aber durchaus erwünscht sein (zum Beispiel
eine Hervorhebung eines Wortes) und aus diesem Grund muss der Vorgang der Bereinigung exibel kongurierbar sein. Mehrere Strategien können hierbei angewendet
werden: Die Filterung mit Blacklist, Whitelist oder deren Kombinationen mit entsprechenden Prioritäten. Bei der Whitelist-Strategie werden alle auÿer in der Liste
denierten Formatierungen aus den Inhalten entfernt. Die Blacklist-Strategie erlaubt
alle Formatierungen auÿer denen, die in dieser Liste angegeben sind. Da die Daten in
HMTL-Format (3.3) vorliegen, können die Listen von dem Designer des Kurses in einer Kongurationsdatei deniert werden, so dass keine Anpassungen des Programms
notwendig sind. Diese Idee wäre nur schwer umsetzbar, wenn als Datenformat XML
ausgewählt wäre. In dem Fall müssten die Zuordnungen von XML- zu den entsprechenden HTML-Formatierungen deniert werden.
Auch andere Szenarien bei der Validierung und Filterung der Daten sind vorstellbar:
möchte der Autor ein Text in einer anderen Farbe darstellen, die aber nicht in die
Farbpalette des Kurses passt, könnte die Software dies erkennen und die vom Designer bereitgestellte Alternativen anbieten.
Auf diese Weise können auÿer Formatierungen auch Text-Bausteine kontrolliert werden. Bei den unerwünschten Elementen (zum Beispiel eine Tabelle), muss dem Benutzer eine Fehlermeldung präsentiert werden, die die genauen Anweisungen angibt,
wie er die Inhalte anpassen kann.
Da das Layout einer Seite oder eines Seitenbereiches bestimmte Dimensionen hat und
die Menge des Textes dafür beschränkt ist, ist es auch wünschenswert die maximale
Anzahl der Wörter zu überprüfen. Darüberhinaus können vom Validator auch die Dimensionen und Verfügbarkeit der Bilder, Plausibilität von Daten, interne Verlinkungen und andere Eigenschaften des Kurses überprüft werden. So kann beispielsweise
die Struktur eines Kurses validiert werden, indem man die Verfügbarkeit von Seiten
in Lektionen testet.
47
3 Lösungskonzept
3.4.3 Ausgabe des Kurses
Nachdem alle Daten aus einem Drehbuch extrahiert, verarbeitet und validiert wurden, können sie in diesem Schritt als ein Kurs ausgegeben. Das heiÿt, die Daten
werden auf einen Datenträger geschrieben. Die Möglichkeiten der Organisierung der
Daten auf dem Datenträger sind vielfältig und reichen von einem einfachem Schreiben aller Dateien in nur einen Ordner
7
bis zu mehr komplexen Ordnerstrukturen,
die die hierarchische Anordnung der Lektionen und Seiten im Kurs wiederspiegeln.
Des Weiteren, sind unter Umständen auch zusätzliche Dateien erforderlich, damit
der Kurs in einem bestimmten Programm geladen und ausgeführt werden kann. Als
Beispiel möchte ich hier LernBar (2.4) angeben: dort wird vor allem eine XML-Datei
benötigt, in der die Struktur des Kurses mit Angaben von Pfaden zu den einzelnen
Seiten abgebildet ist. Auÿerdem werden die Denitionen von Fragen und Antworten
mit zugehörigen Einstellungen ebenfalls in XML-Dateien gespeichert. Dies zeigt, dass
es keinen universellen Weg gibt, die Daten auf einen Datenträger zu schreiben, was
bedeuten würde, dass nur sehr wenige Programme den generierten Kurs interpretieren könnten.
Die Lösung des Problems bieten die in dem Kapitel 2.5 betrachteten eLearning Standards. Diese denieren wie ein eLearning Kurs beschrieben werden kann, so dass er in
einem Programm, das diesen Standard unterstützt, interpretiert werden kann. Natürlich, müssen in manchen speziellen Fällen (wie am Beispiel LernBar oben gezeigt) einige zusätzlichen notwendigen Dateien generiert werden. Der Schritt der Generierung
des Kurses in einem eLearning Standard wird also erst erfolgen, wenn alle Dateien
bereits vom Programm ausgegeben wurden. Für eine Vorschau des Kurses ist jedoch
dieser Schritt nicht erforderlich und somit würde sich anbieten, diesen Vorgang in
einen separaten Modul auszulagern, das nur bei der endgültigen Ausgabe des Kurses
ausgeführt werden muss.
Es stellt sich heraus, dass die Entscheidung für oder gegen einen Standard sehr schwierig ist. Viele Autorenprogramme (A.2) sowie Lernplattformen (A.1) versuchen IMS
CP (2.5.3) und SCORM 1.2 (2.5.4) und weniger SCORM 2004 zu unterstützen. Der
vielversprechende IMS CC (2.5.3) ist leider noch nicht weit verbreitet und es ist abzuwarten, ob sich der Standard auf dem Markt durchsetzt. Die Implementierung der
Standards ist vor allem für Lernplattformen aufwendig, da die umfangreichen und
komplexen Spezikationen dort in vollem Umfang umgesetzt werden müssen. Für die
Wahl eines Standards ist es also maÿgebend nicht nur wie gut ein Standard ist, sondern auch ob die Lernplattformen und Werkzeuge den Standard verwenden.
Da die Unterstützung von mehreren existierenden Standards angestrebt wird, und die
Anbindung von neuen Standards prinzipiell ermöglichen möchte, ist es erforderlich
einheitliche Daten-Strukturen bereitzustellen, in denen ausführliche Informationen
über den Kurs abgelegt werden, die dann von dem jeweiligen Standard benötigt werden. Es ist natürlich schwer vorherzusagen, was für Daten in den neuen Standards
7 Beispiel eXe
48
3.5 Zusammenfassung
erforderlich sein werden, aber am Beispiel der analysierten Standards lässt sich herleiten, dass vor allem die folgenden Informationen wichtig sind:

Meta-Daten zum Kurs sowie zum einzelnen Seiten, falls vorhanden

Kursstruktur

Auistung der Dateien mit relativen Pfadangaben

eventuelle Abhängigkeiten (zum Beispiel interne Verweise)
Für das Erfassen der Meta-Daten können hierbei ebenfalls Vorlagen angeboten werden, in denen die Informationen eingegeben werden können. Die Kursstruktur und
die Pfade zu den Dateien müssen während der Verarbeitung des Drehbuches im Programm gesammelt und an dieses Modul übergeben werden.
Die erstellten und in einem eLearning Standard veröentlichten Kurse lassen sich
dann für den Autor im Allgemeinen nur schwer editieren. Es sind in dem Fall sowohl
die Kenntnisse des Standards, als auch der verwendeten Formate erforderlich und wegen möglicher Fehler ist vom diesen Weg abzuraten. Möchte man also eine Änderung
im Kurs vornehmen, muss dem Autor das original Drehbuch zur Verfügung haben,
aus dem der Kurs generiert wurde. Falls der zum Generierung eines Kurses verwendete eLearning Standard dies zulässt, kann die Drehbuchdatei dort miteingebunden
werden, so dass der generierte Kurs jederzeit editiert werden kann. Dabei soll unter
Umständen auf Datenschutz geachtet werden und persönliche Informationen aus dem
Drehbuch entfernt werden.
3.5 Zusammenfassung
Die Kooperation bei der Erstellung der Drehbücher wird zum einen durch die Verwendung von Online-Editoren ermöglicht, die entsprechende Funktionalitäten anbieten,
und zum anderen durch Kombination von Versionskontrollsystemen mit DesktopEditoren. Da die Wahl einer bestimmten Lösung von der gegebenen Ausgangssituation abhängt, wurde in dem hier vorgestellten Konzept die Unterstützung von
mehreren Editoren angestrebt und gezeigt, dass unter Erfüllung einer Reihe von einfachen Voraussetzungen, neue Editoren eingebunden werden können. Ein Editor soll
die Erzeugung der Tabellen, der Überschriften von verschiedenen Gröÿen, eine Ausgabe in HTML-Format beziehungsweise eine Konvertierung zu HTML unterstützen.
Des Weiteren sind auch Funktionen für das Einfügen von Bildern und Verlinkungen
erwünscht.
Die Wahl von Tabellen als Vorlagen und Überschriften für die Abbildung der Struktur
eines Kurses spielen eine zentrale Rolle im Konzept. Dadurch wird das Auslesen der
Daten aus dem Drehbuch vereinfacht und für alle Editoren vereinheitlicht. Es wird
HTML als gemeinsames Format verwendet, da die betrachteten Editoren (2.3.3) die
49
3 Lösungskonzept
Ausgabe der Daten als HTML bereits unterstützen beziehungsweise entsprechende
Konvertierungsmöglichkeiten anbieten. HTML als internes Format der Daten ermöglicht eine direkte Übernahme der Formatierungen aus dem Editor oder auch deren
Filterung, die über eine Kongurationsdatei gesteuert wird.
Die Anbindung eines neuen Autorenprogramms erfordert die Bereitstellung der Vorlagen für das Drehbuch und der HTML-Vorlagen, die für die Generierung des Kurses
verwendet werden. Da jede Lernplattform und jedes Autorenprogramm unterschiedliche Funktionalitäten anbieten und Kurse in einem eigenen Format ausgeben, müssen
die Schritte des Validierens, Filterns und Schreibens der Dateien auf einen Datenträger entsprechend implementiert werden.
Die Ausgabe eines Kurses in einem eLearning Standard ermöglicht die Verwendung
des Kurses in vielen Lernplattformen, die den ausgewählten Standard unterstützen.
Auch Nachbearbeitung der Inhalte in einem Autorenprogramm ist möglich, falls der
Kurs in dem entsprechenden Format ausgegeben werden kann.
50
4 Implementierung
4.1 Übersicht
Für das prototypische Implementieren des im Kapitel 3 vorgestellten Konzepts wollte
ich eine objektorientierte plattformunabhängige Programmiersprache verwenden und
habe mich für Python entschieden. Python verfügt über gute Eigenschaften, die für
Rapid-Prototyping wichtig sind und verfügt zudem über Bibliotheken, die für diese
Implementierung nötig sind.
In diesem Kapitel werde ich aufzeigen, wie das Konzept (3) am Beispiel von MS Word,
OO Writer und MediaWiki umgesetzt wurde. Dabei wird der Kurs in ein Format,
das derzeit von LernBar (2.4) verwendet wird, transformiert und in ein eLearning
Standard überführt.
4.2 Vorlagen
Die Implementierung der Vorlagen für LernBar ist in jedem Editor beinahe identisch,
denn das Eingeben der Tabellen und Überschriften ist ein einfacher Arbeitsvorgang.
Die Unterschiede liegen beispielsweise in der Möglichkeit der Editoren, die Eingabewerte einzuschränken (3.2.2). Während MS Word und OO Writer die Verwendung
von Formularen unterstützen, ist dies in MediWiki leider nicht möglich.
4.2.1 MS Word und OO Writer
Für das Laden der Vorlagen in einen Editor wurden in meinem Konzept die Automatisierungsmöglichkeiten der Editoren vorgeschlagen. Sowohl in MS Word als auch
in OO Writer lassen sich Makros für das Einfügen der Vorlagen aufzeichnen beziehungsweise programmieren. Die Möglichkeit des Schützens der Formularen gegen
ungewollte Änderungen in Tabellen einer Vorlage wurde zunächst hier angewendet,
um mögliche Editierfehler auszuschlieÿen. Allerdings können dann die Tabellen, die
die geschützten Felder enthalten, nicht auf einen anderen Ort im Dokument verschoben werden und die Umstrukturierung des Kurses wird somit erschwert.
Somit wird dem Autor eine Datei bereitgestellt, die bereits die aufgezeichneten Makros zum Einfügen der Vorlagen beinhaltet.
51
4 Implementierung
4.2.2 MediaWiki
Da eine Wiki (2.3.3) kein Textbearbeitungprogramm ist, muss an die Umsetzung der
Vorlagen entsprechend anders herangegangen werden. Die Texterstellung in Wikis
geschieht durch Auszeichnung des Textes mit Wiki-Syntax. Dies bedeutet, dass der
Autor die Syntax erst erlernen muss, damit er produktiv an einem Drehbuch arbeiten kann. Die Wiki-Syntax ist für die einheitliche Formatierung der Artikel in Wiki
entworfen und eher für das einfache Layout vorgesehen. Das Editieren von Tabellen,
die ich im Konzept als Vorlagen vorschlage, ist in Wikis zwar möglich, wird aber
bei gröÿeren Tabellen unübersichtlich. Fehler bei der Bearbeitung der Vorlagen sind
selbst bei sehr guten Kenntnissen von einer Wiki-Syntax nicht zu vermeiden. Für
mehr Komfort bei der Bearbeitung von Wikiseiten, sorgt ein WYSIWYG Editor, mit
dem man auÿer Tabellen auch andere Textformatierungen und Bausteine bearbeiten
1
kann. Für MediaWiki wurde eine Version des FCK-Editor
angepasst und als Erwei-
terung angeboten, die ich in der Implementierung verwende.
Während das Laden von Vorlagen in den Text-Editoren mit Hilfe von Makros durchgeführt wird, ist diese Möglichkeit in Wiki Software nicht gegeben. Um dieses Problem
zu lösen, habe ich ein Plug-In für den hier verwendeten FCK-Editor implementiert,
welches die Vorlagen aus einem Ordner in den Editor lädt. Der Benutzer kann über
eine Schaltäche im Editor den Dialog zum Einfügen einer Vorlage aufrufen, in dem
ihm dann auch eine Vorschau von der ausgewählten Vorlage angezeigt wird (siehe
Abbildung 4.1). Das Plug-In liest die vorhandenen Vorlagen aus einem dafür vorgesehenen Ordner dynamisch aus und bei der Auswahl zeigt es auch die Vorschau der
ausgewählten Vorlage an. Um eine neue Vorlage zur Auswahl hinzuzufügen, muss
diese einfach in den vorgesehenen Ordner kopiert werden. Die Anpassungen in MediaWiki Software sind nicht notwendig, vorausgesetzt, dass die Vorlage den eigenen
Namen im Feld Vorlage: beinhaltet und eine Bilddatei als Vorschau ebenfalls vorhanden ist.
Die Eingabe der mathematischen Formeln ist in dem FCK-Editor möglich, wobei
diese nicht sofort nach der Eingabe im Editor dargestellt werden, sondern erst nach
Speicherung der Seite, denn die Formeln werden mit Bildern dargestellt, die vom
Server erst generiert werden müssen. Die bereits erstellten Formeln werden im Editor
durch die Platzhalter (siehe Abbildung 3.1) repräsentiert, so dass man die Formel
selbst leider nicht ansehen kann. Mit einem Rechtsklick auf einen Platzhalter wird ein
Formelbearbeitungsfenster aufgerufen, in dem die erstellten Formeln editiert werden
können. Da der Platzhalter selbst ein Bild ist, würde sich hier die Lösung anbieten, für
jede Formel ein Bild zu verwenden, das die Formel darstellt und nicht den Platzhalter.
In dieser Implementierung habe ich mich nur auf einen Tooltip beschränkt (3.1), in
dem die Formel in TeX-Syntax dargestellt wird.
1 http://mediawiki.fckeditor.net/
52
4.2 Vorlagen
Abbildung 4.1: Dialog zur Auswahl und zum Einfügen einer Vorlage in MediaWiki
Abbildung 4.2: Platzhalter für mathematische Formeln mit Angabe des TeX Syntax
im Tooltip
53
4 Implementierung
4.3 Konvertieren zu HTML
Als Format der Daten die aus dem Editor extrahiert werden, wurde aus mehreren
Gründen HTML ausgewählt (3.3). Damit der Prozess der Konvertierung der Ausgabedatei vom Editor zu HTML für den Benutzer transparent bleibt, wird dieser Schritt
hier automatisiert. Der Vorteil der Automatisierung wird vor allem dann spürbar,
wenn der Benutzer den Kurs häuger generieren möchte, um eine Vorschau des Kurses zu betrachten.
Die Microsoft Word Dateien (.doc oder .docx) werden mit Hilfe von der im Python bereitgestellten Bibliothek win32com.client verwendet, die eine Instanz von MS Word
aufruft und die Datei als HTML speichert. Die Konvertierung zu HTML übernimmt
dabei MS Word. Da von MS Word ausgegebene HTML auch Microsoft spezische
Daten enthält, werden diese mit Hilfe von regulären Ausdrücken in diesem Schritt
entfernt.
Für das Konvertieren einer Open Oce Datei wurde in der Implementierung mit
einer portablen
2
Version von Open Oce Suite zurück gegrien. Hierbei wird ein
Python-Script in einem separaten Prozess ausgeführt, der eine Open Oce Instanz
startet und diese dann die Datei zu HTML konvertiert. Da die Kommunikation mit
Open Oce Instanz über Sockets durchgeführt wird, muss der entsprechende Port
3
vom System freigegeben werden . Der Vorteil dieser Lösung besteht darin, dass Open
Oce viele Formate als Eingabe akzeptiert und diese dann ebenfalls zu HTML konvertieren kann. So kann eine MS Word Datei mit Hilfe von Open Oce zu HTML
konvertiert werden, falls MS Word auf dem System nicht installiert ist.
Für die Ausgabe des Drehbuches in HTML-Format aus MediaWiki wurde eine Extension programmiert, die gröÿtenteils auf PDF-Export
4
von Thomas Hempel basiert.
Es wurden Anpassungen für Verlinkungen und Bild-Dateien vorgenommen und auf
eine Ausgabe als PDF wurde hier verzichtet. Der Aufruf der Extension wird über
einen Verweis in der Navigationsleiste von MediaWiki getätigt.
4.4 Parsen und Interpretieren
Das Parsen der zu HTML konvertierten Datei wird mit Hilfe von Bibliothek Beautiful Soup
5
durchgeführt. Der Parser bekommt als Eingabe eine HTML-Datei und
wandelt diese in eine Python Datenstruktur um, indem er alle gefundenen Tabellen
und Überschriften verarbeitet. Hierbei werden die Tabellen nicht rekursiv gesucht,
denn die Tabellen selbst können auch andere Tabellen enthalten, die als Inhalt der
2 Eine Installation des Programms ist nicht erforderlich
3 Standardeinstellung ist 8100
4 http://www.mediawiki.org/wiki/Extension:Pdf_Export
5 http://www.crummy.com/software/BeautifulSoup/
54
4.4 Parsen und Interpretieren
Seite erfasst wurden. Anhand der Überschriften ist dem Parser die Position der Seite
im Kurs bekannt und wird als ein Attribut der Seite gespeichert. An dieser Stelle
wird auch jeder gefundenen Seite eine eindeutige ID vergeben, die zur Navigation
und Implementierung der Verlinkungen der Seiten dienen kann.
Eine Tabelle im Drehbuch ist eine Vorlage, die in der Ausgabedatei einer HTMLTabelle entspricht. Die Tabellen eignen sich sehr gut zum Parsen, da diese geschlossene Einheiten bilden und klar voneinander getrennt sind.
table>
<tbody>
<th>
<td> Ü b e r s h r i f t S p a l t e 1</ td><td> Ü b e r s h r i f t
</ th>
< tr>
<td> Z e l l e 1</ td><td> Z e l l e 2</ td>
</ tr>
< tr>
<td> Z e l l e 1</ td><td> Z e l l e 2</ td>
</ tr>
</ tbody>
</ table>
<
Spalte
2</
td>
Beispiel 4.1: Struktur der HTML-Tabelle
Die Verwendung von <tbody> und <th> Tags ist optional.
Die Tabellen enthalten Schlüssel und die dazugehörigen Werte. Dabei setzt man voraus, dass die Zellen mit Schlüsseln von Autoren nicht editiert werden dürfen. Der
Parser soll an dieser Stelle erkennen, wann in einer Zelle ein Schlüsselwort vorliegt
und kann dann annehmen, dass in der nächsten nicht-leeren Zelle der dazugehörige
Wert vorzunden ist.
Der Algorithmus zum Abarbeiten der Tabellen:
1. Iteriere durch die HTML-Elemente auf der Ebene, wo sich die Überschriften
und Tabellen benden
2. In jeder Tabelle nde alle Zeilen (nicht rekursiv)
3. In jeder gefunden Zeile nde alle Zellen (nicht rekursiv)
4. Ist der Index der Zelle gerade (teile modulo 2), handelt sich um einen Schlüssel
5. Ist der Index der Zelle ungerade (teile modulo 2), handelt sich um einen Wert,
der zum im vorherigen Schritt entdeckten Schlüssel gehört.
6. Entferne bei Bedarf HTML-Markup und weise dem Schlüssel den gefundenen
Wert zu.
55
4 Implementierung
Dabei werden in der Kongurationsdatei gespeicherte Präxe benutzt, um zu erkennen, ob es sich um einen Test oder einen anderen Seitentyp handelt. Dies ist
erforderlich, um die Antworten zu einer Frage in einer Liste zu speichern.
Eine weitere Aufgabe des Parsers ist, die Struktur des Kurses zu analysieren und auf
eine entsprechende Datenstruktur abzubilden, was mit Hilfe von folgendem Algorithmus erreicht wird:
1. Initialisiere eine leere Liste für die Speicherung von Lektions-Objekten als Attribut des Course Objektes
2. Iteriere über die Elemente der HTML-Datei (h1, h2, h3 etc.)
3. Fall h2 (Lektion): Erzeuge ein neues Objekt Lesson, füge es der Liste von
Lektionen in Course Objekt hinzu. Initialisiere eine leere Liste für die Speicherung von Seiten-Objekten als Attribut von dem erzeugten Objekt.
4. Fall h3 (Seite): Erzeuge ein neues Objekt Page, füge es der Liste von Seiten
im zuletzt erzeugten Objekt Lesson hinzu. Initialisiere eine leere Liste für die
Speicherung von Unterseiten-Objekten als Attribut von dem erzeugten Objekt.
5. Fall h4 (Unterseite): Erzeuge ein neues Objekt Subpage, füge es der Liste
von Unterseiten im zuletzt erzeugten Page Objekt hinzu.
Als Ergebnis des Algorithmus enthält der Course Objekt eine Liste der Lektionen,
wobei jede Lektion eine Liste mit zugehörigen Seiten enthält, die wiederum Unterseiten enthalten können. Diese hierarchische Anordnung wird für die Erzeugung von
XML-Dateien benötigt, die die Struktur des Kurses beschreiben.
4.5 Validieren und Bereinigen
Wie im Konzept vorgeschlagen wurde, müssen die gewonnenen Daten validiert und
von den nicht gewünschten Formatierungen bereinigt werden (3.4.2). Bevor man jedoch mit der Validierung anfangen kann, erwies sich noch ein zusätzlicher Schritt
als erforderlich. Die Vorlagen im Drehbuch beinhalten die Schlüssel, zu denen der
Benutzer die Werte eingibt (so ist zum Beispiel 'Datum' ein Schlüsselwort). Damit
die Schlüsselnamen geändert werden können, ohne das Programm selbst anpassen
zu müssen, werden diese aus einer Kongurationsdatei ausgelesen. Dies ermöglicht
auch, die Vorlagen in verschiedenen Sprachen anzubieten. Das Programm arbeitet
also intern mit den Schlüsseln, die in der Kongurationsdatei den Schlüsseln in den
Drehbuchvorlagen entsprechen. Der Schlüssel Abweichende Seitendauer wird beispielsweise im Programm dem internen Schlüssel page_duration zugeordnet und in
diesem Schritt wird der Wert von Abweichende Seitendauer unter dem Schlüssel
page_duration gespeichert.
56
4.6 Ausgabe der Dateien
Nach dem nun eine endgültige Datenstruktur vorliegt, können die Daten weiterverarbeitet werden. Die Klasse Validator enthält nur eine Methode validate(), die validierte und bereinigte Daten zurückliefert. Die Implementierung dieser Methode wird für
verschiedene Vorlagentypen und Lernplattformen unterschiedlich sein und erst zur
Laufzeit des Programms bekannt. Aus diesem Grund wird nur diese eine allgemeine
Methode deniert.
Abbildung 4.3: Validator Basisklasse mit Implementierungen für einzelne Seitentypen
Für jede Vorlage wird in der Kongurationsdatei eine Liste von nicht zugelassenen
Formatierungen (font-famlily, font-size etc.) deniert. Diese werden aus den Inhalten
mit Hilfe von regulären Ausdrücken entfernt.
4.6 Ausgabe der Dateien
Dem Modul Writer stehen die validierten Daten zu Verfügung, die den einzelnen
Vorlagen entsprechen. In diesem Schritt werden die HTML-Seiten und die zugehörigen
57
4 Implementierung
Dateien erzeugt und entsprechend auf dem Datenträger organisiert. Da die Einzelheiten hierbei für jedes Autorenprogramm unterschiedlich sind, ist in jedem Fall eine
separate Implementierung erforderlich.
Der Writer kopiert die bereitgestellten Vorlagen und ersetzt die dort denierten Platzhalter durch die entsprechenden Inhalte aus dem Drehbuch. Die im Drehbuch referenzierten Medien werden ebenfalls vom Writer kopiert. Dabei wird dieser Schritt mit
Hilfe der Kongurationsdatei gesteuert. Dort werden die Platzhalter und die dazugehörigen Schlüssel im Drehbuch deniert, so dass zum einen das Layout der Seite leicht
änderbar ist und zum anderen neue Vorlagen hinzugefügt werden können. Möchte der
Designer beispielsweise einer Vorlage eine weitere Textspalte hinzufügen oder entfernen, müssen nur die Vorlage im Drehbuch sowie die Kongurationsdatei angepasst
werden.
Für LernBar werden hier zwei unterschiedliche Klassentypen erforderlich - Writer für
Textseiten mit Medien und Writer für Tests. Die Fragen, die Antworten und die Einstellungen zu einem Test werden hierbei in einer XML-Datei gespeichert. Da für jeden
Testtyp eine eigene Konguration vorliegt, wurden hier die gemeinsamen Funktionalitäten in eine Basisklasse ausgelagert. Eine Initialisierung erfolgt in den Subklassen,
die den einzelnen Fragetypen entsprechen. Möchte man einen neuen Testtyp im Program unterstützen, muss also hier eine neue Subklasse implementiert werden, die
mögliche Unterschiede des Schreibens von der XML-Datei behandelt.
Für das Erzeugen eines gültigen LernBar Kurses ist darüber hinaus eine course.xml
Datei notwendig, die vor allem die Struktur des Kurses beschreibt. Die Kursstruktur
kann an der Stelle von dem Objekt Course entnommen werden, in dem die Daten
über Lektionen und Seiten beim Parsen (4.4) gespeichert wurden. Das Schreiben von
course.xml habe ich von der Implementierung des Writers getrennt und in ein Modul
ausgelagert, in dem solche zusätzlichen Operationen ausgeführt werden können.
4.7 Überführung in einen eLearning Standard
Obwohl ein Kurs im vorherigen Schritt bereits erzeugt wurde, ist die Wiedergabe nicht
in jeder Lernplattform möglich, ohne den Kurs in ein Format zu transformieren, das
von der Lernplattform interpretiert werden kann. Die Aufgabe dieses Moduls ist die
Erzeugung des Kurses in einem eLearning Standard (2.5) Format. Im Wesentlichen
werden in diesem Schritt zusätzlich zu den generierten Kurs-Dateien unter anderem
formatspezische Dateien generiert (Manifest, XSD etc.). Nach der Generierung aller
erforderlichen Dateien werden alle Dateien in eine Archiv-Datei gepackt.
58
In erstem Teil der Arbeit wurde der Begri Drehbuch in Hinsicht auf die Erstellung
von eLearning Kursen erläutert und eLearning Inhalte auf ihre typischen Merkmale
untersucht. Dabei war es wichtig zu verstehen, ob und wie die kooperative Arbeit
an Inhalten in gängigen Textbearbeitungsprogrammen unterstützt wird und welche
Vor- und Nachteile der jeweilige Editor aufweist. Wie sich herausgestellt hat, setzen
bestehende Lösungen auf Auszeichnungen von Textbausteinen und der Kursstruktur
mit Hilfe von speziellen Makros, so dass beim Transformieren des Kurses diese wiedererkannt werden können. Leider sind diese Lösungen auf einen bestimmten Editor
spezialisiert und betrachten die kooperativen Aspekte der Arbeit an Inhalten nicht.
Da das Drehbuch in einem Textbearbeitungsprogramm erstellt wird, ist die Möglichkeit der Wahl von einem Editor für die Autoren vorteilhaft. Deshalb sieht der Lösungsansatz in meiner Arbeit vor, dass die Umsetzung des Drehbuches nicht auf einen
bestimmten Editor beschränkt ist und dass für jeden Editor kooperative Bearbeitung
ermöglicht wird. Dies wird zum einen durch Verwendung eines Versionskontrollesystems und zum anderen durch die kooperativen Eigenschaften der Editoren erreicht.
Das Transformieren eines Drehbuches zu einem eLearning Kurs wurde einheitlich gestaltet, da HTML als ein gemeinsames Format der Ausgabe von Editoren ausgewählt
wurde. In der Implementierung des Lösungsansatzes konnte am Beispiel des Autorensprogramms LernBar die Unterstützung von bereits drei Editoren erreicht werden.
Einige Einschränkungen sind bei der Verwendung dieser Lösung zu beachten. Bei den
Veränderungen in der HTML-Ausgabe der Editoren sind möglicherweise auch Anpassungen im Programm vorzunehmen. Die Verwendung von Tabellen impliziert, dass
ihre Struktur durch den Autor nicht geändert wird, was durchaus auch versehentlich
passieren kann. Bei der Erstellung von Tests ist eine umfassende Validierung empfehlenswert, damit die Tests wie erwartet durchgeführt werden können. Es wurden in
der Implementierung nur einige Testtypen umgesetzt und möglicherweise sind einige
Tests nicht für die Erfassung im Drehbuch geeignet. In dem Fall müssen sie in den
verwendeten Autorenprogramm direkt erstellt werden.
Die rasante Entwicklung von Internettechnologien wird sicherlich neue Möglichkeiten sowohl für die kooperative Arbeit, als auch für Textbearbeitungsfunktionalitäten anbieten. Allein im Jahr 2010 wurden mehrere Neuerungen auf dem Markt von
1
Online-Editoren eingeführt. Microsoft hat eine Online-Version von seiner Oce-Suite
veröentlicht und damit eine neue Alternative zu Google Docs angeboten. In Google
1 http://workspace.officelive.com
59
Docs werden nahezu im monatlichen Takt neue nützliche Funktionen implementiert,
die sowohl die Textverarbeitung als auch die Kooperation verbessern.
60
[BBSS02]
Back, A.; Bendel, O.; Stoller-Schai, D.: Encyclopedia of distributed
learning . Achertäler Velag, 2002
[Ber04]
Bersin, J.: The Blended Learning Book . Pfeier, 2004
[DIFM 06] Di Iorio, A.; Feliziani, A. A.; Mirri, S.; Salomoni, P.; Vitali, F.:
Automatically Producing Accessible Learning Objects. (2006)
[IGLC04]
IMS Global Learning Consortium, I.: IMS Content Packaging Information Model, Version 1.1.4. (2004)
[IGLC06]
IMS Global Learning Consortium, I.: IMS Question and Test Interoperability Implementation Guide, Version 2.1 Public Draft Specication.
(2006)
[Jon02]
Jones, E. R.: Implications of SCORM. and Emerging E-learning Standards On Engineering Education. (2002)
[Koc97]
Koch, M.:
Kooperation bei der Dokumentenbearbeitung .
Deutscher
Universitäts-Verlag, 1997
[Lea09a]
Learning, A. D.: SCORM 2004 4th Edition, Content Aggregation Model
(CAM), Version 1.1. (2009)
[Lea09b]
Learning, A. D.: SCORM 2004 4th Edition, Run Time Environment
(RTE), Version 1.1. (2009)
[Lea09c]
Learning, A. D.: SCORM 2004 4th Edition, Sequencing and Navigation
(SN), Version 1.1. (2009)
[NDH 08]
Niegemann, H.; Domagk, S.; Hessel, S.; Hein, A.; Hupfer, M.; Zobel, A.: Kompendium multimediales Lernen . Springer-Verlag Berlin Heidelberg, 2008
[NG05]
Neumann, F.; Geys, R.: SCORM and the Learning Grid. (2005)
[Ost07]
Ostyn, C.: In the Eye of the SCORM, An introduction to SCORM 2004
for Content Developers . Online Ressource, 2007
[PF07]
Piotrowski, M.; Fenske, W.:
Interoperabilität von elektronischen
Tests. (2007). Paper bei DeLFI 2005
61
[PTM07]
Pohl, H.-M.; Tulinska, P.; Milde, J.-T.: Ecient Creation of Multi
Media eLearning Modules.
In:
Human Interface and the Management of
Information. Interacting in Information Environments . 2007, S. 457465
[QGN01]
Qu, C.; Gamper, J.; Nejdl, W.: A Collaborative Courseware Generating
System Based on WebDAV, XML, and JSP. (2001)
[Ros09]
Rosen, A.: E-Learning 2.0: Proven Practices and Emerging Technologies
to Achieve Real Results . AMACOM, 2009
[Sch92]
Schaudig, M.: Literalität oder Poetizität.
In: Das Drehbuch. Geschichte,
Theorie, Praxis . 1992, S. 916
[SM02]
Seufert, S.; Mayr, P.: Fachlexikon e-le@rning . managerSeminare Gerhard May Verlags GmbH, 2002
[Som04]
Sommer,
D.:
Qualitätsinformationssysteme
für
E-Learning-
Anwendungen . Books on Demand GmbH, Norderstedt, 2004
[STW09]
Snih, W.-C.; Tseng, S.-S.; Weng, J.-F.: Web 2.0: The Business Model .
Springer, 2009
62
A Software
A.1 Lernplattformen

ATutor

Blackboard

Claroline

Dokeos

ComVironment

Dokeos

dotLRN

eStudy

ILIAS

Moodle

OLAT

W3L
A.2 Autorenprogramme