Migration eines Praktikums auf eine

eLearning-Plattform

Studienarbeit

Lehrstuhl f�ur Rechnernetze und InternetWilhelm-Schickard-Institut f�ur Informatik

Fakult�at f�ur Informations- und KognitionswissenschaftenUniversit�at T�ubingen

von

Marc-Oliver Pahl

Betreuer:

Prof. Dr.-Ing. Georg CarleDipl.-Inform. Heiko Niedermayer

Tag der Abgabe: 26. Juli 2007

Ich erkl�are hiermit, dass ich die vorliegende Arbeit selbstst�andig verfasst und keine anderenals die angegebenen Quellen und Hilfsmittel verwendet habe.

T�ubingen, den 26. Juli 2007

Kurzfassung:

Viele (universit�are) Praktika �nden noch in"traditioneller\ Weise

"mit Papier und Bleistift\

statt. Diese Arbeit zeigt M�oglichkeiten auf, die sich durch die Umstellung des komplettenArbeitsablaufes auf eine eLearning-Plattform ergeben.Neben grunds�atzlichen Erw�agungen wird als Beispiel das Internetpraktikum des Lehrstuhlsf�ur Rechnernetze und Internet an der Univerit�at T�ubingen angef�uhrt. Hier brachte die Um-stellung einen deutlichen R�uckgang des Betreuungs- und Korrekturaufwandes. Gleichzeitigwurde der Lerne�ekt f�ur die Teilnehmer vor allem bei der theoretischen Vorbereitung starkerh�oht und die Aufgabenstellung im Praxisteil klarer.Die Arbeit f�uhrt Kriterien zur Auswahl einer geeigneten eLearning-Plattform an. Ver-deutlicht werden diese durch �Uberlegungen, die zur Erstellung der Plattform hinter demInternetpraktikum { dem Labsystem { gef�uhrt haben. Diese �Uberlegungen k�onnen auchf�ur andere PHP/ MySQL-basierte Systeme von Nutzen sein.Der neue integrierte Arbeitsablauf durch das Systems wird aufgezeigt und die dabei ent-stehenden Ver�anderungen f�ur Autoren, Teilnehmer, Betreuer und Korrektoren er�ortert.

Inhaltsverzeichnis

1 Einleitung 1

1.1 Zielsetzung der Arbeit . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 2

1.2 Gliederung der Arbeit . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 3

2 M�oglichkeiten durch und Anforderungen an ein Lernsystem 5

2.1 In welche Teile gliedert sich ein Praktikum? . . . . . . . . . . . . . . . . . . 5

2.2 Der Theorieteil . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 5

2.2.1 Multiple-Choice-Fragen . . . . . . . . . . . . . . . . . . . . . . . . . 5

2.2.2 Information aufteilen . . . . . . . . . . . . . . . . . . . . . . . . . . . 7

2.2.3 Das Medium nutzen . . . . . . . . . . . . . . . . . . . . . . . . . . . 8

2.3 Der Praxisteil . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 8

2.3.1 Information aufteilen . . . . . . . . . . . . . . . . . . . . . . . . . . . 8

2.3.2 Keine zu detaillierte Instruktionen . . . . . . . . . . . . . . . . . . . 9

2.3.3 Verbesserungsvorschl�age erfragen . . . . . . . . . . . . . . . . . . . . 9

2.3.4 Musterl�osungen formulieren/ Hinweise f�ur Betreuer . . . . . . . . . . 9

2.3.5 Wichtigkeit der Punkte . . . . . . . . . . . . . . . . . . . . . . . . . 9

2.3.6 Gemeinsames anstelle parallelen Arbeitens . . . . . . . . . . . . . . . 10

2.4 Die Korrektur . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 10

3 Konzeption des Labsystems 11

3.1 Allgemeine Grundlagen . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 11

3.1.1 Was muss ein eLearning-System leisten? . . . . . . . . . . . . . . . . 11

3.1.2 Wahl der Plattform . . . . . . . . . . . . . . . . . . . . . . . . . . . 12

3.1.3 Kon�gurierbarkeit . . . . . . . . . . . . . . . . . . . . . . . . . . . . 12

3.1.4 Aufteilung der Daten . . . . . . . . . . . . . . . . . . . . . . . . . . . 13

3.1.5 Das Benutzerinterface . . . . . . . . . . . . . . . . . . . . . . . . . . 13

3.2 Spezielle Umsetzung . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 14

3.2.1 Rahmenwerk . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 14

ii Inhaltsverzeichnis

3.2.2 Klassen und Interfaces: Abstraktion . . . . . . . . . . . . . . . . . . 15

3.2.3 Modulstruktur . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 15

3.2.3.1 Kommunikation mit der Datenbank . . . . . . . . . . . . . 15

3.2.3.2 Kommunikation mit der Au�enwelt . . . . . . . . . . . . . 17

3.2.4 Die Lernobjekte . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 17

3.2.4.1 Die Element-Basisklasse . . . . . . . . . . . . . . . . . . . . 17

3.2.4.2 Das Seitenelement . . . . . . . . . . . . . . . . . . . . . . . 18

3.2.4.3 Das Multiple-Choice-Element . . . . . . . . . . . . . . . . . 18

3.2.4.4 Problem Interaktion in HTML . . . . . . . . . . . . . . . . 18

3.2.4.5 Die Freitextfrage . . . . . . . . . . . . . . . . . . . . . . . . 19

3.2.4.6 Das Sammelelement . . . . . . . . . . . . . . . . . . . . . . 19

3.2.4.7 Die Lerneinheit . . . . . . . . . . . . . . . . . . . . . . . . 20

3.2.4.8 Der Eintrag im Zeitplan . . . . . . . . . . . . . . . . . . . . 20

3.2.5 Fazit . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 20

4 Das Labsystem in der Praxis 21

4.1 Das Authoring . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 21

4.2 Praktikumsablauf im Wintersemester 2005/ 2006 . . . . . . . . . . . . . . . 23

4.3 Die Teilnehmersicht . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 25

4.4 Die Betreuung . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 28

4.5 Die Korrektur . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 28

4.6 Punkteverwaltung . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 29

5 Zusammenfassung und Ausblick 31

Literatur 33

1. Einleitung

Im Fach Informatik gibt es an der Universit�at T�ubingen diverse"Praktika\. In der Regel

l�auft solch ein Praktikum derart ab, dass man sich im ersten Teil theoretische Hintergr�undeaneignet und diese dann im zweiten Teil in praktischen �Ubungen anwendet. Das Lesen derGrundlagen erfolgt oft alleine. Der Praxisteil wird zumeist im Team bearbeitet. Das �ubtzum einen das kooperative Arbeiten ein und spart zum anderen Ressourcen: Im konkretenFall des

"Internetpraktikums\ [colm], das ich im Folgenden als Beispiel w�ahle, scha�en

wir es, bis zu zw�olf Teams pro Woche an zwei Testaufbauten mit jeweils sechs Rechnernarbeiten zu lassen. Wir k�onnen damit bis zu 24 Studenten pro Semester ausbilden.

Das Internetpraktikum ist das Praktikum des Lehrstuhls f�ur Rechnernetze und Internet[riwe]. Es besch�aftigt sich mit grundlegenden Mechanismen und Diensten in Rechnernetzenwie dem Internet1.Dieses Praktikum fand zum ersten Mal im Wintersemester 2003/ 2004 statt; damals nochauf Basis des Buches

"Mastering Networks: An Internet Lab Manual\ von J�org Liebeherr

und Magda El Zarki [LiZa04]. Ich selbst war Teilnehmer der Lehrveranstaltung. Die Auf-gaben des Buches sind f�ur die Lehre an amerikanischen Universit�aten konzipiert worden.Die Instruktionen sind sehr detailliert gegeben2. Als Antwort auf die Fragen m�ussen des�Ofteren Programmausgaben abgegeben werden. Insgesamt sind die Aufgaben interessantaber viel zum umfangreich und langwierig f�ur unser Internetpraktikum, das mit vier bzw.drei Semesterwochenstunden in einer Pr�ufung angerechnet werden kann. Daher wurde ichzusammen mit Uwe Bilger f�ur das darauf folgende Sommersemester angestellt, die Inhaltezu �uberarbeiten und neue Aufgaben, die in angemessenerer Zeit l�osbar sind, zu stellen.Der buchbasierte Ablauf des Praktikums fand so, wie aktuell die meisten Praktika in T�u-bingen, statt: Man bekommt { in unserem Fall kopierte { Aufgaben und Fragen, die mandann in Form eines

"Protokolls\ beantworten muss.

Ein Vorteil dieser Abgabepraxis ist, dass man lernt,"Protokolle\ zu schreiben. Ein gro�er

Nachteil solch eines Praxisteils f�ur einen Teilnehmer ist, dass viel Zeit f�ur die Form, alsodas Kenntlichmachen, auf welche Frage man sich bezieht (z.B. durch Abtippen derselben)verbraucht wird. Aus Sicht eines Korrektors ist die dadurch entstehende Verschiedenheitder Form der Abgaben ein Nachteil: Die Korrektur dauert deutlich l�anger, da man erstsuchen muss, worauf sich die Antworten beziehen. Selbst wenn diese ordentlich gekenn-

1Wir behandeln unter anderem die Themen Funktionsweise des Ethernet, statisches Routing, dynami-sches Routing, TCP/ UDP, DNS, NAT, DHCP, Firewalling mit iptables, Einbruchserkennung mit Snort,Aufsetzen eines Webservers, SSL, IPSEC, VPN, Multicast und WLAN.

2Meistens werden alle f�ur die Durchf�uhrung des Versuches relevanten Befehle als Listing abgedruckt.

2 1. Einleitung

zeichnet sind, fehlen auf der Abgabe in der Regel Aufgabenstellung und Instruktionen. Manmuss die Abfolge der Aufgaben im Kopf haben, um korrigieren zu k�onnen.Ein weiteres Problem betri�t den Theorieteil: Dort muss eine gro�e Menge an Informa-

tionen gelesen werden { ohne Kennzeichnung, was besonders relevant ist und was eherunwichtig ist. F�ur den Rezipienten ist es dabei schwer, zu gewichten. Wahrscheinlich feh-len ihm bei der sp�ateren praktischen �Ubung einige Grundlagen, die er beim Theroiestudiumf�ur unwichtiger erachtet hat, die sich dann aber als besonders relevant herausstellen.

Bei der Konzeption der Aufgaben und Auswahl der Texte hat man als Konzipierender vorAugen, was einem wichtig ist und was nicht. Auf den ersten Blick fehlt nur ein geeigneter

Weg, dies den Lernenden anzuzeigen. . .

1.1 Zielsetzung der Arbeit

Diese Arbeit soll aufzeigen, wie sich ein Praktikum durch den Einsatz eines computer-basierten Systems deutlich e�zienter durchf�uhren l�asst. Zur Anschauung f�uhre ich meineUmsetzung anhand des Labsystems [labs] f�ur das Intertnetpraktikum [colm] an.Um die in der Einleitung schon angedeuteten Verbesserungen anzugehen, h�atte ich aufein bestehendes System [BaHMH02] zur�uckgreifen und es adaptieren k�onnen. Die Haupt-gr�unde, warum ich mich entschied, ein neues System

"from scratch\ zu entwickeln, waren

hohe Lizenzkosten [KlWa04], mangelnde Erfahrung mit existierenden Systemen (Fr�uhjahr2004) und vor allem die Zeit. Da ich schon mehrere auf PHP/ MySQL basierende Web-portale programmiert hatte, erschien mir der Aufwand, ein komplett neues System zuerstellen, vertretbar. Im Nachhinein betrachtet, habe ich ihn erheblich untersch�atzt. Esh�atte wahrscheinlich nicht so lange gedauert, eine bestehende Plattform auf unsere Be-d�urfnisse umzukon�gurieren. Dennoch h�atte es vieler Anpassungen bedurft und am Endew�are nicht genau das entstanden, was mir vorschwebte.Insgesamt hat sich das Projekt f�ur alle Beteiligten gelohnt: Der Lehrstuhl hat ein passge-naues System und ich habe Erfahrung in der Umsetzung eines umfangreicheren Projektsgesammelt. Vielleicht �ndet die Arbeit dar�uber hinaus auch Einsatz bei anderen Lehrver-anstaltungen oder an anderen Lehreinrichtungen.

Eine erste Version des PHP/ MySQL-basierten Websystems entstand zum Sommersemes-ter 2004. Es kam umgehend mit unseren neuen Inhalten, die wir schon innerhalb derSofware erstellt hatten, zum Einsatz. Mit der ersten Version wurde im Sommersemester2004 und im Wintersemester 2004/ 2005 erfolgreich gearbeitet. Nur durch den Einsatz desSystems waren wir in der Lage, zu zweit die Studenten zu betreuen und gleichzeitig nochAufgaben zu erstellen3. Von Seiten der Studierenden gab es durchweg positives Echo aufdie neue Erfahrung des rechnergest�utzten Abgebens der Praktikumsaufgaben bis hin, dassdies das bestorganisierte Praktikum sei, an dem sie teilgenommen h�atten!Da das System in extrem kurzer Zeit entstand4, war der Code unsauber und faktisch nichtwartbar5. Das machte es nahezu unm�oglich, Verbesserungsvorschl�age, die den teilneh-menden Studenten6 und mir ein�elen sinnvoll umzusetzen. Der Konzeptionsteil 3 der Ar-beit kann daher auch als Leitfaden f�ur eine sinnvolle vor der Implementierung stehendePlanungsphase dienen.

3Ab der H�alfte des Semesters hat uns Johannes Riedel noch tatkr�aftig unterst�utzt. Die sp�ateren Prelabshat gro�teils Heiko Niedermayer erstellt.

4Da ich inkrementell nach unserem Bedarf entwickelte, standen kurz vor Beginn des Sommersemesters2004 nur die Komponenten zum Erstellen von Inhalten, da wir das im Rahmen unseres Hiwi-Jobs machten.Die Funktionalit�at f�ur Benutzer musste ich dann innerhalb von drei Wochen komplett schreiben, damitunsere Inhalte auch genutzt werden konnten.

5Ein weiteres Beispiel f�ur den unsch�atzbaren Wert einer Planungsphase vor Entwicklungsbeginn.6Allen Studenten sei hier f�ur ihre konstruktiven Hinweise gedankt!

1.2. Gliederung der Arbeit 3

Motiviert durch die positiven Erfahrungen und nicht zuletzt, da auch von anderen Hoch-schulen Interesse bestand, entschied ich mich im Dezember 2004, mit dem Entwurf einerzweiten Version zu beginnen.

1.2 Gliederung der Arbeit

Im anschlie�enden zweiten Teil der Arbeit werden M�oglichkeiten aufgezeigt, die sich durchden Einsatz eines eLearning-Systems f�ur den Theorie- und Praxisteil ergeben k�onnen. Diesek�onnen als Entscheidungshilfe f�ur ein eLearning-System herangezogen werden.Der dritte Teil zeigt Schl�usselaspekte bei der Konzeption eines solchen Systems auf.Im vierten Teil wird �uber die Erfahrungen bei der Durchf�uhrung des Internetlabs mit demLabsystem berichtet.Den Abschluss der Arbeit bilden Fazit und Ausblick.

4 1. Einleitung

2. M�oglichkeiten durch und

Anforderungen an ein Lernsystem

Dieser Abschnitt beinhaltet Verbesserungsm�oglichkeiten, die sich durch die Verwendungeines eLearning-Systems ergeben k�onnen.Dazu werden { wie schon in der Einleitung begonnen { ausgehend von einem

"tradi-

tionellen\ Praktikum, am Beispiel des Internetpraktikums vor der Umstellung, Verbesse-rungsvorschl�age angef�uhrt und motiviert. Dadurch werden zugleich Anforderungen an einLernsystem gestellt.Das Kapitel hilft somit bei der Auswahl einer geeigneten Lernplattform als Grundlage f�urein Praktikum.

2.1 In welche Teile gliedert sich ein Praktikum?

Universit�are Praktika { mindestens im Bereich Informatik { sind aus Sicht der Teilnehmerim Wesentlichen zweigeteilt: Ein erster Teil, in welchem die theoretischen Grundlagen(zumeist individuell) erworben werden sollen: der Theorieteil. Und ein zweiter Teil, in demdieses Wissen (zumeist im Team) praktisch angewandt werden soll: der Praxisteil.Aus der Gesamtsicht eines Praktikums kommt vor Phase eins die Erstellung der Aufgabenund der theoretischen Hintergr�unde. Nach Phase zwei m�ussen die L�osungen der Teilnehmerkorrigiert und die Ergebnisse verwaltet werden (siehe auch 4).

2.2 Der Theorieteil

2.2.1 Multiple-Choice-Fragen

Wie schon einleitend geschrieben, besteht ein Theorieteil im Wesentlichen aus Dokumen-ten, die (zumeist alleine) durchzuarbeiten sind. Ein gro�es Problem dabei ist die F�ulle anInformation und die fehlende Lenkung bei deren Bearbeitung1.Dabei ist den Autoren bzw. denjenigen, die die Information recherchieren in der Regelbekannt, welche Dinge besondere Relevanz haben. Sie kennen sowohl die sp�atere prakti-sche �Ubung als auch den Nutzen in der

"realen\ Welt. Einen L�osungsansatz, n�amlich die

Information auf ein Mindestma� zu beschr�anken und dadurch zu fokussieren halte ich {

1Neben eigenen Texten versuchen wir beim Internetpraktikum auf frei im Netz verf�ugbare verl�asslicheDokumente zur�uckzugreifen, die damit nat�urlich nicht 100%ig auf unsere Bed�urfnisse zugeschnitten sind.Bei ihrer sp�ateren T�atigkeit werden die Teilnehmer genau diese Situation vor�nden.

6 2. M�oglichkeiten durch und Anforderungen an ein Lernsystem

zumindest an der Universit�at { f�ur wenig sinnvoll2. Vielmehr muss und kann ein Mittelgefunden werden, den Lernenden zu motivieren und zu lenken.Der letzte Versuch des ersten Internetpraktikums war eine Kooperation mit dem schwei-zer Vitels-Projekt3 [vite]. Neben den Texten gibt es im Theorieteil der Vitels-VersucheMultiple-Choice-Fragen, die man innerhalb eines Websystems [webc] beantwortet.Solche Fragen kann man sehr gut nutzen, um die Studenten zu lenken. Neben der Leit-funktion scha�en sie auch einen Anreiz, den Theorieteil (aufmerksam) durchzuarbeiten.Dies f�uhrt zu einer besseren Vorbereitung der Lernenden.Beim Vitels-Projekt werden diese M�oglichkeiten meines Erachtens nicht genutzt. Die Multiple-Choice-Fragen werden n�amlich erst mit dem Praxisteil bewertet; also dann, wenn der Kor-rektor Zeit hat. Nach dieser Spanne nimmt sich der Teilnehmer aber nicht mehr die Zeit,die Korrektur aufmerksam durchzugehen. Vor allem hat er schon wieder vieles der hinterder Antwort stehenden Theorie vergessen, da er diese noch vor dem Versuch in der Vor-bereitung gelesenen hat. Gerade die Verwendung einer computerbasierten L�osung erlaubtmehr:

Multiple-Choice-Fragen k�onnen sofort korrigiert werden4.

Damit lassen sich gleich mehrere E�ekte erzielen:

� Die Teilnehmer haben zeitnah Feedback und erkennen dadurch ihre De�zite sofort

bei der theortischen Vorbereitung noch vor dem Praxisteil. Im Vitels-Fall kann esschlie�lich sein, dass ein Lernender alle Fragen falsch beantwortet, selbst aber davonausgeht, alles verstanden zu haben.

� Eine sofortige Korrektur erlaubt mehrere Antwortversuche. Der Teilnehmer kann so-mit seine Antwort korrigieren und besch�aftigt sich dabei eingehender mit der Theo-rie5. Ein

"Lernen durch falsch machen\ ist nur dann m�oglich, wenn es keine Punkte

auf die Fragen gibt6. Deshalb sollte man hier meines Erachtens auf eine notenre-levante Beurteilung verzichten. Die Korrektoren sollten lediglich darauf achten, obder Teilnehmer ernsthaft versucht hat, die Fragen zu l�osen und diese nicht einfach

"weggeklickt\ hat.

� Durch sofortige Korrektur kann auch die Teilnahme am Praxisteil davon abh�angig

gemacht werden, ob der Theorieteil erfolgreich gel�ost wurde: Die Teilnehmer erhaltenerst dann die M�oglichkeit, die Fragen des Praxisteils zu beantworten, wenn sie denTheorieteil abgeschlossen haben.Unvorbereitetes Erscheinen wird so bis zu einem gewissen Grad ausgeschlossen7.

Auch ohne Bepunktung ist bei Ankreuzaufgaben die Gefahr des"Abschreibens\ besonders

gegeben. Die L�osung l�asst sich n�amlich sehr einfach kommunizieren:"Antwortm�oglichkeit

2Im beru ichen Leben steht man ebenfalls vor einer F�ulle an mehr oder weniger relevantr Information.3Das Vitels-Projekt ist ein Verbund mehrerer schweizerischer Universit�aten. Es besch�aftigt sich mit

�ahnlichen Themen wie unser Internetpraktikum, �ndet aber vollkommen virtuell statt: Man kann als Kurs-teilnehmer ein Zeitfenster f�ur den Versuchsaufbau (an einer schweizer Universit�at) buchen und dann perRemote-Zugri� Experimente durchf�uhren.

4Es m�ussen nur Antwort- und L�osungsvektor verglichen werden.5Dies erfordert geeignetes Feedback, aus dem der Teilnehmer entnehmen kann, wo seine Fehler liegen.

Wenn er beispielsweise f�ur eine ganze Seite mit Fragen ein Feedback in der Form"Falsch\ im Sinne von

"Irgendwo auf der Seite ist mindestens ein Fehler\ bekommt, hilft ihm dies wenig und motiviert auch nicht,die richtige L�osung zu suchen.

6Sobald es punkterelevant wird, werden die Teilnehmer wahrscheinlich nicht mehr ausprobieren. . .7N�aheres dazu bei der Beschreibung des Multiple-Choice-Elements.

2.2. Der Theorieteil 7

Abb. 2.1 : Eine Seite im Theorieteil des Internetlabs mit Multiple-Choice-Frage. Der Teil-nehmer hat die Aufgabe zuerst falsch (rot hinterlegt), dann richtig gel�ost und bekommtjetzt die Erkl�arung der L�osung (ganz unten) angezeigt.

eins und drei sind richtig.\ Auch hier kann wieder ausgenutzt werden, dass die Fragendigital pr�asentiert werden, indem f�ur jeden Teilnehmer die Antwortm�oglichkeiten permu-tiert werden8. Der Austausch der L�osung bleibt weiterhin m�oglich, muss aber in Formvon

"Der Himmel ist blau, weil das blaue Licht bei Tag am meisten von der Atmosph�are

gestreut wird!\ erfolgen. Wenn die Teilnehmer sich so gegenseitig sogar noch die L�osungsagen, pr�agt sie sich mit gro�er Wahrscheinlichkeit ein. Somit ist der Lernerfolg auch durch

"Abschreiben\ sichergestellt.

Ein Problem der automatischen Korrektur in Bezug auf den Lerne�ekt ergibt sich, wenndie L�osung nicht sofort einsichtig ist. Dies wird oft der Fall sein. Der Teilnehmer bekommtzwar die L�osung, sieht sie aber nicht ein. Aus diesem Grund erscheint es mir wichtig, nebender Frage und den Antwortm�oglichkeiten als dritten Bestandteil auch noch eine kurze

Erkl�arung abzuspeichern, die die L�osung verst�andlich machen soll und mit ihr angezeigtwird.

2.2.2 Information aufteilen

Bei der traditionellen Aufbereitung von Information auf Papier gibt es nat�urliche Infor-mationsgrenzen, in Form eines DIN-A4-Blattes beispielsweise. Beim digitalen Authoringgibt es diese in der Regel nicht9. Dadurch l�auft man Gefahr, zu viele Information in eine

8Dies sollte freilich nur beim ersten �O�nen der Frage geschehen. Eine �Anderung des Erscheinungsbildesder L�osung bei jedem Neuladen w�urde sehr irritieren.

9Eine Webseite ist beispielsweise theoretisch unbegrenzt.

8 2. M�oglichkeiten durch und Anforderungen an ein Lernsystem

virtuelle"Seite\ zu packen. Die meisten Lernenden werden dann aber von der F�ulle an

Information (Scrollbalken!)"erschlagen\.

Gerade beim Einarbeiten von Information in digitale Informationssysteme sollte man da-her auf eine sinnvolle Aufteilung der Inhalte in Unterkapitel achten. Pers�onlich habe ichdie Erfahrung gemacht, dass es angenehmer ist, kurze Informationseinheiten nacheinanderdurchzulesen, da man so den Eindruck hat, vorw�arts zu kommen. Auch ist es angenehm,wenn man nicht scrollen muss.

2.2.3 Das Medium nutzen

Die Umstellung auf ein neues Medium scha�t andere M�oglichkeiten. Beispielsweise aufeiner Webseite k�onnen viele unterschiedliche Pr�asentationsformen wie Animationen oderFilme eingebunden werden, um ein neues

"Lernerlebnis\ zu scha�en. Davon sollte Gebrauch

gemacht werden, wo dies als Unterst�utzung sinnvoll erscheint und den Lern- und Lehrerfolgerh�oht.Auch die Rezeptionsform kann angepasst werden, beispielsweise vom linearen hin zu einerst�arker nichtlinear verlinkten Darstellung. In unserem Fall greift dies allerdings nicht, dahier alle Informationseinheiten durchgearbeitet werden m�ussen. Das sequentielle Vorgehenstellt implizit sicher, dass dies geschieht.

2.3 Der Praxisteil

Der Praxisteil besteht aus Instruktionen und zugeh�origen Aufgaben. Beim"klassischen\

Praktikum liegen die Aufgaben in Papierform vor. Wieso nicht diese Aufgaben auf Papierweiterhin verwenden und den Teilnehmern online die zugeh�origen Antwortfelder zur Ver-f�ugung stellen?Bei meiner ersten Realisierung eines Online-Systems waren nur die Aufgaben und ihreAntwortfelder online. Die Instruktionen befanden sich in einem auszudruckenden PDF-Dokument mit Verweisen auf die Fragen (

"Q10\) an den entsprechenden Stellen. Der Me-

dienbruch stellt ein nicht zu untersch�atzendes Problem dar: Die Teilnehmer versuchtenimmer wieder, die Aufgaben zu beantworten, ohne den (O�ine-) Instruktionstext zu Ratezu ziehen. Dadurch entstand unn�otiger Betreuungsaufwand, da dies zu Fragen f�uhrt. Mansollte also darauf achten, in einem Medium zu bleiben10.Noch etwas anderes zeigt diese Erfahrung: Unsere Fragen enthielten so viel Instruktion,dass man vermeintlich auf die Aufgaben schlie�en konnte. Als Autor sollte man daraufachten, Fragen und Instruktionen strikt zu trennen und in der digitalen Einheit

"Frage\

nur die eigentliche Frage zu stellen { die Instruktionen in einen Textabschnitt davor.Das eingangs beschriebene Problem, dass die Korrektoren den Versuchsablauf auswen-dig wissen m�ussen, war auch entstanden, weil diesen im Ursystem nur die Fragen zu denAntworten angezeigt wurden11. Die Korrektur erfordert h�au�g das erneute Nachlesen dergenauen Aufgabenstellung. Bei der Auswahl einer Lernplattform sollte daher darauf ge-achtet werden, dass den Korrektoren zur Orientierung auch die Instruktionen angezeigtwerden.

2.3.1 Information aufteilen

Beim Praxisteil gilt es noch st�arker, wie im Abschnitt 2.2.2 beschrieben, die Instruktionenaufzuteilen. Zumeist bestehen Praktikumsaufgaben aus mehrern Teilen. Diese wiederumsetzen sich oft aus kleinen Schritten zusammen.Ich habe die Erfahrung gemacht, dass man auf dem Papier eher dazu neigt, mehrere Auf-gaben zusammenzufassen (

"Wie sieht XY aus? Was bedeutet das f�ur YZ?\). Dies verf�uhrt

10Durch die Umstellung auf Onlineinstruktionen ist der Betreuungsaufwand signi�kant zur�uckgegangen.11Die Instruktionen waren ja nicht online vorhanden.

2.3. Der Praxisteil 9

die Teilnehmer, die Aufgaben nicht getrennt zu beantworten. Die Korrektoren m�ussen sichdie Antworten auf die einzelnen Teile aus der Antwort heraussuchen. Beim Online-Mediumist eine derartige Aufgabenzusammenfassung unn�otig. Es gilt keinen Platz zu sparen. Eineechte Aufteilung der Aufgaben f�uhrt vielmehr dazu, dass die Teilnehmer diese auch allebearbeiten und nicht aus Versehen Teile weglassen oder eine Mischung der Aufgaben be-antworten.Vierzig Aufgaben auf Papier wirken eher abschreckend { besonders, wenn sie sich dazunoch auf drei�ig Seiten be�nden. Online stellt dies kein Problem dar, da die Wahrneh-mung durch den Leser eine andere ist12.

2.3.2 Keine zu detaillierte Instruktionen

Wie in der Einleitung beschrieben, sind die Instruktionen in [LiZa04] sehr detailliert. Wirhaben bewusst darauf verzichtet. Anleitungen zu einer Problemstellung, die schon in einemvorhergehenden Versuch gel�ost wurde, sind deutlich abstrakter gehalten. So geben wir imersten Versuch den Befehl zum Setzen der Netzwerkadresse und �ahnlichem explizit an. Inden sp�ateren Versuchen �ndet sich nur noch der Hinweis, auf welche Adressen die Kartenzu setzen sind.Dies f�uhrt dazu, dass die Teilnehmer automatisch das erworbene Wissen memorieren undeinsetzen m�ussen. Aus eigener Erfahrung kann ich sagen, dass es so auch mehr Spa� macht,da man nicht seitenweise eigentlich irrelevante Information vor�ndet, sondern (heraus-)gefordert wird.Weniger ist also bei den Instruktionen mitunter mehr.

2.3.3 Verbesserungsvorschl�age erfragen

Beim Durcharbeiten eines Versuches hat man als Teilnehmer oft Verbesserungsvorschl�age.Im Zuge der Umstellung der Aufgaben habe ich zu jedem Versuch eine zus�atzliche Fragef�ur Verbesserungsvorschl�age und Hinweise eingebaut. Diese wird sowohl im Theorie- alsauch im Praxisteil angezeigt. Die Erfahrung hat gezeigt, dass die Lernenden beim Durch-arbeiten oft wertvolle Anmerkungen und Verbesserungsvorschl�age haben, diese aber biszur n�achsten Besprechung vergessen und somit nicht kommunizieren. Hier hilft das Feld13.

2.3.4 Musterl�osungen formulieren/ Hinweise f�ur Betreuer

Auch Praktikumsaufgaben haben einen Erwartungshorizont bzw. eine Musterl�osung. Dieseist sowohl f�ur die Betreuer als auch f�ur die Korrektoren sehr wichtig. Das eLearning-Systemsollte daher eine M�oglichkeit bieten, die Musterl�osung einzublenden14. Wenn Probleme beibestimmten Aufgabenteilen bekannt sind, k�onnen auch zus�atzliche Hinweise, die nur f�urdie Betreuer erscheinen, sehr hilfreich sein15.

2.3.5 Wichtigkeit der Punkte

Die Bedeutung der erreichbaren Punkte habe ich anfangs stark untersch�atzt. Es hat sichgezeigt, dass sich die Teilnehmer beim Umfang und der Qualit�at ihrer L�osung sehr daranorientieren. Die Punkte sollten also mit Bedacht vergeben werden.Wir haben es so gestaltet, dass alle Versuche bei uns jeweils gleich viele Punkte ergeben.Im Zuge der Konzipierung ist dies eine praktikable L�osung, da man nur schwer absch�atzen

12Der Monitor wird nicht"dicker\.

13Insgesamt hat sich dieser einfache Mechanismus als Feedbackkanal sehr bew�ahrt. Der Teilnehmer kanneinfach etwas notieren und der Adressat hat nach Abschluss des Versuchs eine komplette Seite mit Verbes-serungsvorschl�agen und Anmerkungen.

14Zur Korrektur kann die Musterl�osung zusammen mit der Teilnehmerl�osung eingeblendet werden.15Vorausgesetzt nat�urlich, diese Probleme sind f�ur die Teilnehmer von didaktischem Nutzen und machen

die Aufgaben nicht nur unn�otig langwierig { in solch einem Fall sollte man die Aufgabe anpassen.

10 2. M�oglichkeiten durch und Anforderungen an ein Lernsystem

kann, wie schwierig die einzelnen Aufgaben f�ur die Teilnehmer sein werden. Wenn manihren Schwierigkeitsgrad kennt { wie dies nach mehreren Jahrg�angen der Fall ist {, bietetes sich an, die Gesamtpunktzahl dem Versuch anzupassen. Wir haben zum Beispiel einigeeher kurze und einfache Versuche und andere, die �uber mehrere Pr�asenztermine gehen unddaher auch mit mehr Punkten in die Gesamtbewertung ein ie�en sollten.

2.3.6 Gemeinsames anstelle parallelen Arbeitens

Bei Teamarbeit kann es { vor allem bei guten Teilehmern { leicht geschehen, dass dieseversuchen, m�oglichst schnell durch das Praktikum zu kommen und daf�ur die Aufgabenaufteilen und parallel arbeiten. Damit sind sie zwar schneller, haben jeder aber auch nurden Teil, den sie selbst gemacht haben,

"erlebt\. Um dies zu verhindern, habe ich in meinem

System einen Mechanismus eingebaut, der es dem gesamten Team immer nur erlaubt, eineFrage zugleich zu beantworten16.

2.4 Die Korrektur

Noch st�arker als die Teilnehmer werden die Korrektoren durch ein computerbasiertes Sys-tem entlastet. Aus Gr�unden der Gerechtigkeit korrigieren sie quer17. Bei Papierabgabenginge dies nur, wenn sie sich genau zeitlich koordinierten und die Abgaben weiterreichten.Daneben m�ussten sie sich auf jeder Abgabe erst zurecht�nden.In einer geeigneten eLearningumgebung kann der Korrektor sich die Antworten aller Teams

zusammen mit der Frage und der Aufgabenstellung anzeigen lassen und in viel weniger Zeitkorrigieren.

Abb. 2.2 : Kreuzkorrektur einer Aufgabe des Praxisteils. Die zweite Zeile enth�alt die Mus-terl�osung. Team 8 ist gerade zur Korrektur ge�o�net.

16Als Seitene�ekt wird damit auch zu einem gewissen Grad verhindert, dass die Teammitglieder ausVersehen gegenseitig ihre L�osungen �uberschereiben.

17Also Korrektor A Aufgabe 1 aller Teams, Korrektor B Aufgabe 2 usw.

3. Konzeption des Labsystems

Um die in Kapitel 2 beschriebenen Anforderungen umzusetzen, bedarf es einer geeigne-ten Plattform { eines eLearning-Systems. Auf dem Markt gibt es viele solcher Systeme.�Ubersichten �nden heute vor allem sich im Web (z.B. [bild]). Einige aktuelle Open-Source-Projekte sind [mood], [ilia], [olat].Bei Beginn unserer Umstellung auf eine Online-Plattform Anfang 2004 war mir lediglichWebCT [webc] bekannt. Vor allem wegen der hohen Kosten und dem nicht optimalenFunktionsumfang1 schied dieses aus. [BaHMH02] zeigt, dass kosteng�unstige brauchbareSysteme damals nicht verbreitet waren. Ich habe mich daher entschieden, ein neues eLear-ningsystem auf Basis von PHP und MySQL zu entwickeln [labs]. Die konzeptuellen Aspek-te speziell dieses Systems m�ochte ich im Folgenden erl�autern. Sie lassen sich auf andere(PHP/ MySQL-) Softwareprojekte �ubertragen.Auch mit Kenntnis der neuen Systeme hat meine Entwicklung ihre Daseinsberechtigung.Im Gegensatz zu diesen beschr�ankt sich das Labsystem auf die (beschriebene) ben�otigteFunktionalit�at und ist auf schnelles e�zientes Lernen optimiert2.

3.1 Allgemeine Grundlagen

3.1.1 Was muss ein eLearning-System leisten?

Der Funktionsumfang, der f�ur ein vollst�andig rechnergest�utztes Praktikum ben�otigt wird,gliedert sich im Wesentlichen in die zwei Punkte Content-Management und Course-Ma-

nagement.Der Content-Management-Teil ist f�ur die Verwaltung der Inhalte zust�andig. Anders als einreines Content-Management-System muss ein eLearning-System auch mit Benutzerantwor-ten umgehen k�onnen (speichern, korrigieren, . . . ).Zum Course-Management z�ahlen Komponenten, wie die Benutzerverwaltung, die Punkteder Benutzer speichern und auswerten zu k�onnen, aber z.B. auch, den Teilnehmern Ver-suche nur zu bestimmten Zeiten freizuschalten (Scheduling).

1(in Bezug auf die von mir angef�uhrten Punkte und die komplexe Bedienung)2Der riesige Funktionsumfang und die dadurch leicht �uberladene Ober �ache vieler eLearning-Systeme ist

dazu hinderlich. Ich habe versucht, das System hinter dem Inhalt so weit wie m�oglich zur�ucktreten zu lassen.Dazu geh�ort auch eine m�oglichst unau��allige und gleichzeitig intuitive und �ubersichtliche Benutzerf�uhrung.

12 3. Konzeption des Labsystems

3.1.2 Wahl der Plattform

Die Wahl der Plattform ist grundlegend und h�angt wesentlich von der vorhandenen Infra-struktur ab.Eine wichtige Zielsetzung an mein System ist dessen Erreichbarkeit von Seite der Teilneh-mer: Der Zugri� sollte m�oglichst

"von �Uberall\ erfolgen k�onnen und nicht beispielsweise

nur innerhalb des Praktikumsraums3. Vor allem im universit�aren Umfeld, welches eherheterogen bez�uglich der Betriebssysteme und installierten Software ist, scheidet damiteine L�osung, die auf zu installierender Software basiert, aus. Diese ist auf Rechnern inComputer-Pools zumeist nicht vorhanden und f�ur normale studentische Nutzer nicht in-stallierbar, da diese keine entsprechenden Rechte besitzen.Eine gute L�osung des Problems ist ein webbasiertes Portal. Webbrowser existieren f�ur fastjedes Betriebssystem und sind innerhalb der Universit�at auch standardm�a�ig zusammenmit der physikalischen Anbindung an das Internet auf allen Rechnern vorhanden. Schon diePr�asenz von Browser-Plugins wie Flash oder auch Java kann zum jetzigen Zeitpunkt nichtvorausgesetzt werden4. Deshalb setzt das System clientseitig nur einen HTML-Interpreter(Webbrowser) voraus.Da sich auch die Browser unterscheiden, muss ein Beurteilungskriterium f�ur

"sauberen\

HTML-Code gefunden werden. Dieses existiert und zwar in Form des Validators desWorldWideWeb-Konsortiums [valib]. Sowohl der generierte HTML-Code, als auch die Sty-lesheets [valia] wurden auf Standardkonformit�at �uberpr�uft und sollten damit auf allenHTML-konformen Browsern zu akzeptabler Anzeige kommen.

Neben der breiten Installationsbasis an Browsern f�ur HTML bietet dessen Verwendung inKombination mit CascadedStyleSheets (CSS) einen weitereren gro�en Vorteil: Die schoneingebaute weitgehende Trennung von Inhalt und Aussehen. Die durchg�angige Verwendungvon CSS erlaubt die zentrale Ver�anderung des Aussehens, ohne den Code, der die Webseitengeneriert, anpassen zu m�ussen5.

3.1.3 Kon�gurierbarkeit

Eine weitere Grundfragestellung ist, auf welche Weise das System kon�gurierbar sein soll.Anpassungen, die �Anderungen im Quelltext erfordern, sind f�ur einen breiten Benutzerkreisnicht durchf�uhrbar. In meinem System gibt es eine zentrale Kon�gurationsdatei, aus deralle f�ur den Kurs relevanten Daten gelesen werden. Dies ist grundlegend, da alle im Pro-grammcode verwendeten Parameter damit stets dynamisch aus der Kon�guration gelesenwerden m�ussen.Nur durch Verwendung von separaten Kon�gurationsdateien kann eine Installation desSystems f�ur mehrere Kurse gleichzeitig genutzt werden6.Neben den

"normalen\ Kon�gurationsparametern habe ich auch die Interaktion des Sys-

tems mit dem Bediener exibel gehalten: Alle verwendeten Strings werden aus einerSprachdatei eingelesen. So ist es einfach m�oglich, das Programm auf eine andere Spra-che zu portieren.Schlie�lich lassen sich auch die in 3.1.2 angesprochenen Stylesheets und somit das Aussehendes Systems f�ur jeden Kurs �andern.

3Um beispielsweise den Theorieteil von zuhause bearbeiten zu k�onnen.4F�ur die Inhalte k�onnen diese selbstverst�andlich genutzt werden. Nur das eLearning-System selbst sollte

wenig Voraussetzungen auf Clientseite haben, um exibel eingesetzt werden zu k�onnen.5So l�asst sich beispielsweise im konkreten Beispiel des Labsystems die Farbe aller zentralen Komponenten

mit elf Eintr�agen in einen Theme-Stylesheet ver�andern.6Das System ist also nur einmal auf dem Server installiert, kann aber mehrere v�ollig verschiedene Kurse

(und damit Kon�gurationen) gleichzeitig bedienen.

3.1. Allgemeine Grundlagen 13

3.1.4 Aufteilung der Daten

Das Backend des Systems bildet die Datenbank. In ihr werden alle dynamischen Objektegespeichert. Um eine sinnvolle Verteilung der Daten vorzunehmen, habe ich mir folgendeFragen gestellt: Wer generiert die Daten? Was ist die Lebensdauer der Daten? Wie h�au�gwerden sie gebraucht?Ich bin zu dem Schluss gekommen, das System auf drei bzw. vier Datenbanken aufzubauen,die sich auf v�ollig verschiedenen Systemen be�nden k�onnen.

� Die erste Datenbank ist f�ur die langlebigen Daten: die Texte der Theorieteile, dieInstruktionen, die Fragen. . .

� Die zweite Datenbank ist f�ur die kurzlebigen Daten: die Benutzerantworten, die Kor-rekturen, die Punkte, die Benutzerrechte. . .

� Die dritte Datenbank ist f�ur tempor�are Systemdaten7.

� Die vierte Datenbank beherbergt die Benutzerstammdaten8.

3.1.5 Das Benutzerinterface

Das System interagiert mit dem Bediener �uber seine Benutzerschnittstelle. Auf deren sinn-volle Gestaltung ist daher besonderes Augenmerk zu legen [Hani03]!

Die Bedienung des Systems muss einheitlich erfolgen. Haupts�achlich bedeutet dies in mei-nem Fall, dass f�ur alle Elemente dieselbe Menuleiste mit denselben Symbolen erscheint unddie Anordnung der Felder bei Bearbeitung der Elemente immer gleich ist. Nur so kann sichder Benutzer auf die Bedienung einstellen und schnell arbeiten9.

Die Bedienelemente sollten so wenig physischen Platz auf dem Bildschirm verbrauchenwie m�oglich. Alle wichtigen Funktionen sollten dabei direkt erreichbar sein: Wichtig istder Inhalt, die dazugeh�origen Bearbeitungsm�oglichkeiten sollten nicht st�orend au�allen.Ich habe daher eine Reihe von aussagekr�aftigen Symbolen kreiert, mit deren Hilfe dieBedienung erfolgt.

Nicht ben�otigte Bedienelemente sollten ausgeblendet werden. Das Menusystem ist so imple-mentiert, dass es kontextbezogen Untermenus automatisch ein- und ausblendet. Dadurchbleibt die dargebotene Information �uberschaubar. Bedienelemente, die gerade nicht zurVerf�ugung stehen, werden ausgeblendet10.Ein anderes Beispiel f�ur die Kontextsensitivit�at der Ober �ache sind die Freitextfragen:Ist eine Frage aktiv11, werden die Schalt �achen zum Beantworten aller12 anderen Fragensolange ausgeblendet, bis die Frage gespeichert wurde13.

An kritischen Stellen, also beispielsweise beim L�oschen von Elementen, sollte das Systemzur Sicherheit nachfragen, um ungewollter Fehlbedienung vorzubeugen. Dem Benutzerwird so die Angst vor unvorhersehbaren schlimmen Folgen genommen, da er wei�, dass bei

7Im wesentlichen sind dies die Session-Daten.8Sie wird nur ben�otigt, wenn keine anderweitige Benutzerverwaltung eingebunden wird.9{ gegebenenfalls nach kurzer Einarbeitung10Dazu z�ahlt beispielsweise auch, dass man tempor�ar die Editorfunktionalit�at mit ihren zahlreichen

Schalt �achen ausblenden kann.11, wird also gerade beantwortet12(Innerhalb der aktuellen Lerneinheit)13Einem versehentlichen Nicht-Speichern (Antwort muss aktiv zum Server �ubertragen werden) wird da-

durch ebenfalls vorgebeugt.

14 3. Konzeption des Labsystems

solchen Vorg�angen eine Nachfrage erscheint14. Insbesondere, da ich keine Undo-Funktioneingebaut habe15, ist dies wichtig!

Es bietet sich an, Farben zur Lenkung einzusetzen. Innerhalb des Systems gibt es einFarbleitsystem: Jedes Element hat seine Farbe. Der Nutzen ist nicht zu untersch�atzen. Aufeiner langen Seite lassen sich so zum Beispiel schnell die Multiple-Choice-Fragen identi�-zieren.Die Korrektur der Antworten auf die Multiple-Choice-Fragen wird farblich gekennzeichnet

(vgl. Abb. 2.1) sowie der Korrekturstatus und der Punktebalken16 farbig hinterlegt. DerLernende erkennt sofort an der Farbe, ob eine Antwort richtig war und ob er sich noch im

"gr�unen Bereich\ be�ndet.Bei den vorhandenen Themes ist es so, dass der Hintergrund am dunkelsten und der Bereichmit den eigentlichen Inhalten am hellsten ist. Dadurch wird die gr�o�te Aufmerksamkeit

visuell auf den Inhalt gelenkt.

Die bisherigen Punkte zielen auf einfaches und schnelles Arbeiten mit dem System ab. InBezug auf die Arbeitsgeschwindigkeit sind auch Scrollwege zu ber�ucksichtigen: Ist es m�og-lich, bei einer langen Seite (oder geringen Au �osung) an die Bedienelemente zu kommen,ohne lange auf der Seite hin- und herscrollen zu m�ussen? Zu diesem Zweck habe ich dieNavigationselemente stets doppelt eingebaut: Oben und unten auf jeder Seite (vgl. Abb.2.1). Nach dem Lesen muss also nicht extra nach oben gescrollt werden, um �uber die dortvorhandenen Navigationspfeile oder das Menu umzubl�attern.

Ein wichtiger Punkt bei einem Lernsystem ist auch die Buchf�uhrung �uber �Anderungen: Dieso genannte History. Jeder Ver�anderungsvorgang an einem dynamischen Element generierteinen History-Eintrag, auf den alle Benutzer direkt zugegreifen k�onnen (Buchsymbole inAbb. 2.1). So lassen sich �Anderungen von Teilnehmern, Korrektoren und Autoren r�uck-verfolgen. F�ur die Teilnehmer ist dies vor allem relevant, um zu sehen, ob eine Frage imNachhinein ge�andert wurde und um den Verlauf der Korrektur und den Korrektor zu er-mitteln. Die Korrektoren sehen, wann wer auf eine Frage geantwortet hat. Die Autorensehen, wer zuletzt an einem Element gearbeitet hat.

3.2 Spezielle Umsetzung

Der erste Teil dieses Kapitels hat grundlegende �Uberlegungen dargestellt. Dieser Teil wid-met sich jetzt den konkreteren Implementierungsaspekten speziell des Labsystems [labs].Das System teilt sich in den Rahmen und die eigentlichen Lernobjekte.

3.2.1 Rahmenwerk

Der Rahmen �ubernimmt Funktionen, die um die Lernobjekten"herum liegen\ { sowohl

logisch als auch visuell.Ich will diese nur kurz andeuten: Er stellt die Funktionalit�at zur Benutzerauthenti�zierungzur Verf�ugung17 und verwaltet auch die Nutzerrechte18. Er stellt das Menu bereit und

14Exploratives Erlernen der Ober �ache wird m�oglich.15Implementierungsans�atze w�aren eine RollBack-Funktion der Datenbank oder die Implementierung einer

solchen"per Hand\.

16Dieser wird ab einer voreinstellbaren Prozentzahl an Pukten rot und zeigt damit an, dass die Punktzahlzu gering ist.

17Dazu existiert ein eigenes Interface. Eine authenti�zierung gegen eine beliebige Quelle (Kerberos/LDAP an der Informatik in T�ubingen) ist somit leicht realisierbar.

18Die Spezi�kation der ben�otigten Rollen innerhalb eines Lernsystems ist ebenfalls sehr wichtig undgrundlegend. Die wesentlichen Rollen in meinem System sind Benutzer (eingeloggt), Autor, Korrektor,Musterl�osungsbetrachter, Rechteadministrator.

3.2. Spezielle Umsetzung 15

bringt die Lernobjekte zur Anzeige19. Schlie�lich gibt es im Rahmen auch noch ein Mailin-

terface { eine einfache und e�ektive Art asynchroner Kommunikation mit den Betreuern.Die Lernenden k�onnen, ohne das Portal zu verlassen, ihre Fragen mailen20.Ebenfalls zum Rahmen w�urde ich die Stylesheets z�ahlen. Wie schon am Ende von Ka-pitel 3.1.2 beschrieben, lassen sich Inhalt und Ausehen durch die Verwendung von CSStrennen21. Zus�atzlich kann man dies nutzen, um die Pr�asentation dem Ausgabemedium

anzupassen. Durch die Verwendung eines Print-Stylesheets lassen sich die Inhalte saubermedienad�aquat ausdrucken22.Da die Kommunikation zwischen Rahmen und Lernobjekten einheitlich erfolgt (vgl. 3.2.3.2),kann der Rahmen auch die Generierung der Standardverwaltungsseiten f�ur Objekte und

�ahnliches �ubernehmen.

3.2.2 Klassen und Interfaces: Abstraktion

In der Programmiersprache PHP gibt es seit Version 4.3 Unterst�utzung f�ur objektori-entierte Programmierung23. Gerade beim Erstellen einer Lernumgebung bietet sich dieVerwendung von Klassen und Interfaces an, da diese die dem Inhalt zugrunde liegendeStruktur gut in ein Programm abbilden: Wenige grundlegende Lernobjektklassen existie-ren, die in verschiedensten Instanzen (Inhalte) zusammen eine Lerneinheit bilden.In 3.1.5 habe ich von einheitlicher Schnittstelle zum Benutzer gesprochen. Ebenso ist dring-lich darauf zu achten, dass die Schnittstellen der Objekte zueinander vereinheitlicht sind(Interface/ Vererbung). Das Abstraktionsprinzip [SpKl01] ist einzuhalten. Die Klassen sindalso voneinander abzukapseln und Sichtbarkeitsgrenzen nicht zu brechen.

3.2.3 Modulstruktur

Der vielleicht wichtigste Teil neben dem Abstecken des gew�unschten Funktionalt�atsumfan-ges ist der Entwurf einer geeigneten Modulstruktur. Von mir selbst auch oft untersch�atzt,hat sich bei diesem Projekt wieder gezeigt, dass jede in die Vorplanung investierte Stundebei der Implementierung mehrfach gewonnen wird24.Die wichtigsten Fragen f�ur mich bei dieser Arbeit waren: Welche Funktionalit�at ist vielenObjekten gemeinsam? Welche Komponenten m�ussen miteinander kommunizieren?Meine Aufteilung �ndet sich im Diagramm 3.2.3.

3.2.3.1 Kommunikation mit der Datenbank

Wie schon in 3.1 dargestellt, ist eine wichtige Funktionalit�at der Austausch mit der Daten-bank. Daher habe ich zuerst eine (Wrapper-)Klasse zur Kommunikation mit der Datenbankerstellt. Alle Anfragen gehen �uber sie25. Die einzelnen Lernobjekte haben dar�uber liegendjeweils eine (einheitliche) Schnittstelle, die sie mit den Daten aus der Datenbank versorgt(vergleiche Diagramm 3.2.3 mitte). Desweiteren haben sie Schnittstellen zu den zus�atzlichben�otigten Datenbanken mit den Benutzerantworten und �ahnlichem (vergleiche Diagramm3.2.3 unten).

19Dazu werden jeweils Funktionen in den entsprechenden Lernobjektinstanzen aufgerufen.20In diesem Zusammenhang k�onnte die Frage nach enem Chat, einem Forum oder �ahnlichem auftreten.

Deren Implementierung halte ich f�ur unn�otig, da f�ur dieses Aufgabengebiet geeignete Tools zur Verf�ugungstehen, die sich einfach einbinden lassen sollten.

21Auch Autoren k�onnen f�ur ihre Inhalte eigene Styles innerhalb des System erstellen. Dazu stellt derRahmen { ebenso wie f�ur das Menu { einen integrierten Editor f�ur einen Benutzerstylesheet bereit. DieDe�nition des Layouts kann also ebenfalls innerhalb des Systems erfolgen.

22Mein Print-Stylesheet blendet das Menu aus, f�ugt der Schriftart wieder Serifen hinzu etc.23In Version 4.3 fehlt noch die Unterst�utzung von Sichtbarkeitsbereichen. In Version 5 ist diese vorhanden.24Insbesondere �Anderungen, wie sie bei jedem Projekt unerwartet erforderlich werden, lassen sich mit

einer guten Modulstruktur zumeist mit wenigen Handgri�en durchf�uhren.25Dadurch sollte es sogar m�oglich sein, die Anfragesprache (MySQL) ohne gr�o�eren Aufwand zu wecheln

und das System beispielsweise mit einer Postgres-Datenbank zu betreiben.

16 3. Konzeption des Labsystems

+DBInterfaceUser()+authenticate()+getData4()+getAllData()+allSize()+getNextData()+sortableByArray()

DBInterfaceUser

+Ddbc()

Ddbc

+Wdbc()

Wdbc

+DBConnection()-query()+datasetsIn()+mkSelect()+mkInsert()+mkDelete()+mkUpdate()+mkUpdIns()+reportErrors()+table_exists()+db_exists()

DBConnection

+DBInterfaceUserRights()+getData4()+setData4()+getAllData()+allSize()+getNextData()+sortableByArray()

DBInterfaceUserRights

1 *

1 *

+isVisible()+getMenu()+getMatchingMenu()+show()+showEdit()+save()+showPropertyLegend()+getPropertyRow()+showPropertyRow()+showPropertyRowColl()+showNoFoundRowColl()#splitAddress()

Element

+BCElement()+getTOC()+getLinks()+show()+getMenu()

BCElement

+LcElement()-getFormattedStructureString()-showStructure()-notFoundVisibleNote()-showAllOnOne()-showAllElementsOfType()+show()+showEdit()+save()+showPropertyLegend()+getPropertyRow()-buildStructure()-getStructure()+isAtLeastOneElementVisibleForMe()-getMyVisibleElements()-isVisibleFinal()-getParagraphArray()-getParagraph()-getTokens()+extMap()

LcElement

+BCDBInterface()+getData2idx()+getData2idx()+getMenuData2idx()+getNextData()

BCDBInterface

+LcDBInterface()+getData2idx()+getMenuData2idx()+setData()+newCollection()+deleteData()+getAllData()+allSize()+getNextData()+sortableByArray()

LcDBInterface

1

*

1

**

1

*

1

*

1

*

1

1

*

1

*

1*

*

1

*

1

*

1

*

1

*

1

1

*

1

*

*

1

*

1

*

1

*

1

*

1

*

1

*

1

Data DataBase

Working DataBase

User DataBase

+LiElement()-loadUserData4()+getPossibleCredits()+getGivenCredits()-showComment()-showAnswer()-showCredits()-showAnswerData()+show()+showEdit()+save()-acquireLock4()+removeLock()+saveUserAnswer()+saveCorrectorStuff()+setUserAnswerLock()+closeInput()+reOpenInput()+mapInput()+showPropertyLegend()+getPropertyRow()

LiElement

+LiDBInterface()+getData2idx()+getMenuData2idx()+setData()+newInput()+deleteData()+getAllData()+allSize()+getNextData()+sortableByArray()

LiDBInterface

+LiDBInterfaceAnswers()+getData4()+setData4()+getAllTeams()+getNextData()

LiDBInterfaceAnswers

+LiDBInterfaceLocks()+getData4()+setData4()+remLock4()

LiDBInterfaceLocks

+LiDBInterfaceUidTeam()+getData4()+setData4()

LiDBInterfaceUidTeam

+LlElement()-showTOC()-showAllPrelabMultipleChoices()-showAllLabInputs()-labStatusTable ()-labStatusUID()-labStatusUIDALLLabs()-percentBar()-showTableResults()-getTableResultsLegend()-showLabStatus()-showStatusALLLabs()+show()+getMenu()+showEdit()+save()+showPropertyLegend()+getPropertyRow()+checkPreLab()+forceLockOn()-reallyCloseAllLabInputs()+closeAllLabInputs()+closeLabInputs()+reOpenAllLabInputs()+mapAllLabInputs()+reMapUidTeam()+setSeeingUID()+updateStatus()

LlElement

+LlDBInterface()+getData2idx()+getMenuData2idx()+setData()+newLab()+deleteData()+getAllData()+allSize()+getNextData()+sortableByArray()

LlDBInterface

+LlDBInterfaceUidStatus()+getData4()+setData4()+setPrelabFinished()+closeLab()+reOpenLab()+getAllData()+getAllTeamData()+getAllUidData()+getAllUidDataALLLabs()+getNextData()+sortableByArray()

LlDBInterfaceUidStatus

+LmElement()-loadUserData4()+getPossibleCredits()+getGivenCredits()-mask()-showAnswer()+show()-answerFields()+showEdit()+save()+saveUserAnswer()+checkUserAnswer()+showPropertyLegend()+getPropertyRow()

LmElement

+LmDBInterface()+getData2idx()+getMenuData2idx()+setData()+newMultipleChoice()+deleteData()+getAllData()+allSize()+getNextData()+sortableByArray()

LmDBInterface

+LmDBInterfaceAnswers()+getData4()+setData4()+getAllUIDs()+getNextData()

LmDBInterfaceAnswers

+LsElement()+getVisibility()+visiblePerSchedule()-emptyRow()-spacerRow()-monthRow()-scheduledRow()-addSchedule()+show()-makeOptions()+showEdit()+save()+showPropertyLegend()+getPropertyRow()

LsElement

+LsDBInterface()+getSchedule4()+getData2idx()+getMenuData2idx()+setData()+newSchedule()+deleteData()+getAllData()+allSize()+getNextData()+sortableByArray()

LsDBInterface

*

1

+LpElement()+show()+showEdit()+save()+showPropertyLegend()+getPropertyRow()

LpElement

+LpDBInterface()+getData2idx()+getMenuData2idx()+setData()+newPage()+deleteData()+getAllData()+allSize()+getNextData()+sortableByArray()

LpDBInterface

Abb. 3.1 : Die f�ur die Lernobjekte relevanten Modulea. Die Kommunikation zwischenRahmen und Lernobjekten (zweite Ebene von oben) sowie den Lernobjekten untereinan-der erfolgt �uber die Interfaces oben. Die einzelnen Lernelemente erben von Element. Diemittlere Schicht bilden die Interfaces der Objekte zu der Datenbank mit den langlebigenDaten (siehe 3.1.4)b. Die dritte Schicht diejenigen zu der Datenbank mit den kurzlebigenDatenc. Die eigentliche Datenbankkommunikation erfolgt �uber die Klasse DBConnection.Rechts unten sind die f�ur die Benutzerverwaltung relevanten Klassen aufgef�uhrt.

aDas UML-Diagramm ist unvollst�andig; insbesodere fehlen die Variablen in der Signatur der Methoden.b{ gekapselt in Ddbcc{ gekapselt in Wdbc

3.2. Spezielle Umsetzung 17

3.2.3.2 Kommunikation mit der Au�enwelt

Die Kommunikation zwischen den Lernobjekten und dem Rahmen26 erfolgt ebenfalls �ubereine genormte Schnittstelle (vgl. 3.2.1) bzw. eine Elementbasisklasse (vgl. Abb. 3.2.3). Diesbietet sich an, da ein Gro�teil der Funktionalit�at der Lernobjekte immer gleich ist und so-mit sowohl Methoden als auch Variablen nur in der Mutterklasse implementiert bzw. de-klariert sein m�ussen27. Durch die Verwendung einer genormten Schnittstelle zum Rahmenkann das System einfach um weitere Grundlernobjekte erweitert werden. Die Basisklasseliefert dazu schon einen Gro�teil der notwendigen Implementierung und beschleunigt dasEntwickeln damit sehr.

3.2.4 Die Lernobjekte

Die Lernobjekte stellen das Herzst�uck des eLearning-Systems dar. Sie bestimmen dieM�oglichkeiten. Als Grundelemente gibt es das Seitenelement Page, die Multiple-Choice-Frage und die Freitextfrage input. Diese lassen sich beliebig in einem Sammelelementcollection zu einer Einheit kombinieren. Daneben gibt es dann noch die Lerneinheit undEintr�age im Zeitplan schedule. Die Elemente werden innerhalb des Systems durch ihreK�urzel (p, m, i, c, l, s) angesprochen. Ich will nachfolgend kurz auf einige Details derImplementierung dieser Objekte eingehen.

3.2.4.1 Die Element-Basisklasse

+isVisible() : bool+getMenu(in $fullAddress : string, in &$menu2Populate, in $paragraph : string = '', in $isActive : bool = false) : string+getMatchingMenu() : string+show(in $fullAddress : string, in $paragraph : string = '', in $hideNavigation : bool = false) : string+showEdit(in $fullAddress : string) : string+save()+showPropertyLegend() : string+getPropertyRow(in $prefix : string, in $disabled : bool = false) : string+showPropertyRow(in $prefix : string, in $disabled : bool = false) : string+showPropertyRowColl(in $address : string, in $disabled : bool = true, in $prefix : string) : string+showNoFoundRowColl(in $address : string) : string#splitAddress(inout &$parentAddr : string, out &$myAddrArray : string)

+$elementId : char+$idx : int+$title : string+$matchingMenu : string+$visibleOnlyInCollection : bool+$history : string+$IamVisible : bool

Element

Abb. 3.2 : Element-Basisklasse.

Alle Lernelemente erben von der Element-Basisklasse. Ich m�ochte kurz auf ihre Eigen-schaften (vgl. Abb. 3.2) eingehen.Jedes Element kann �uber den Selektor

"isVisible()\ gefragt werden, ob es unter den gege-

benen Bedingungen28 sichtbar ist29.Die getMenu()-Methode muss das Menu f�ur die Instanz zur�uckliefern. Bei einfachen Ele-menten ist dies lediglich eine Zeile. Bei der Collection kann das Menu lang sein, da dieMethode hier rekursiv die gerade sichtbaren integrierten Elemente pollt.Die beiden show()-Methoden liefern die Pr�asentation des Objektes zur�uck.

26{ auf gewisse Weise die Darstellungsschicht und damit Schnittstelle zum Benutzer {27Code m�oglichst zentral halten!28Welche Rechte hat der Benutzer? Welche Schedules laufen gerade? Was ist der interne Zustand (bspw.

Antwort geschlossen)?29Dies dient nur als Information (bspw. f�ur das Menu). Bei der Darstellung muss diese Eigenschaft nicht

extra abgepr�uft werden. Nicht sichtbare Elemente liefern auch nur eine Fehlermeldung in ihrer show()-Methode.

18 3. Konzeption des Labsystems

Die restlichen Methoden dienen im Wesentlichen der Generierung der Element-Standard-verwaltungsseiten durch den Rahmen (vgl. 3.2.1).

3.2.4.2 Das Seitenelement

Dieses Element ist f�ur alle Arten von Texten gedacht. Also insbesondere f�ur die Theo-rieteiltexte und die Instruktionen des Praxisteils. Es besteht im Wesentlichen aus einemTextteil. Da sich sowohl direkt Texte als auch s�amtliche HTML-Tags einbauen lassen, istdieses Element sehr exibel. Flash-Objekte oder Java-Applets k�onnen problemlos inte-griert werden.Das Seitenelement stellt keine systemgest�utzte Interaktion mit dem Teilnehmer zur Ver-f�ugung. Es ist daher nicht sehr komplex und eignet sich gut als Beispielimplementierungf�ur eigene Lernobjektklassen.

3.2.4.3 Das Multiple-Choice-Element

Dieses Element ist die Repr�asentation der, vor allem f�ur den Theorieteil zur Lernunter-st�utzung vorgesehenen, Multiple-Choice-Fragen. Es besteht aus einer Frage, beliebig vielenAntwortm�oglichkeiten mit L�osungsvektor und dem Feld f�ur die Erkl�arung der L�osung (vgl.2.2.1 Ende).Das System interagiert mit dem Benutzer insofern, als dieser Antworten ankreuzen kann(vgl. 3.2.4.4). Wie in 2.2.1 besprochen, ist das Besondere meiner Implementierung, dass dieAntworten f�ur jeden Teilnehmer permutiert werden. Das System speichert dazu zu jedemTeilnehmer bei jeder Frage einen Permutationsvektor30. Die Antworten sind also f�ur denBenutzer auch beim n�achsten Betrachten der Frage in derselben Reihenfolge.Als interaktives Element kann die Multiple-Choice-Frage verschiedene Zust�ande haben:Sie kann o�en, also noch beantwortbar, sein und geschlossen31.

3.2.4.4 Problem Interaktion in HTML

Wie in 3.1.2 dargelegt, bietet der Client-/ Serveransatz mit HTML viele Vorteile. In Bezugauf Benutzereingaben ergeben sich jedoch einige Schwierigkeiten: Daten werden nur perPush vom Client zum Server �ubertragen. Zustands�anderungen, wie die Beantwortung einerFrage, sind also explizit an den Server zu �ubertragen32. Der in HTML dazu vorgeseheneWeg ist ein Formular.Problematisch wird es, wenn mehrere interaktive Elemente auf einer Seite zusammenkom-men (vgl. 3.2.4.6). Formulare kann man in HTML nicht schachteln. Dies w�are auch imSinne der Abkapselung der Elemente zueinander nicht realisierbar, da die Antworten andie einzelnen Elemente zur�uckgeschickt werden. Eine kombinierte Behandlung w�urde dieServerzeit deutlich erh�ohen, da jedes Mal potenziell alle Antworten ge�andert worden seink�onnten und gespeichert werden m�ussten.Zur L�osung habe ich einen Mechanismus implementiert, der daf�ur sorgt, dass immer nureine Frage zugleich beantwortet werden kann. F�ur die Multiple-Choice-Elemente ist diesdurch ein Flag, welches der Client sendet33 realisiert. Graphisch werden die Bedienelemen-te der anderen Fragen auf der Seite solange ausgeblendet, bis die aktuell ge�o�nete Fragegespeichert ist (vgl. Abb. 3.3). Dadurch wird dem Benutzer auch visuell klargemacht, dasser seine Antwort zum Server senden muss, damit es weitergehen kann.Bei den Freitextfragen (vgl. 3.2.4.5) ist der Sperrmechanismus serverseitig implementiert,da die Fragen f�ur alle Teammitglieder und nicht nur den aktuellen Client gesperrt werdenm�ussen (vgl. 2.3.6).

30W�urde der Vektor nicht gespeichert, spr�ungen die Antworten bei jedem Betreten oder Reload (Spei-chern einer Antwort) um.

31Der Teilnehmer hat sie dann entweder richtig beantwortet oder zu viele Fehlversuche gehabt undbekommt jetzt die L�osung angezeigt.

32Sie sind insbesondere nicht synchron zur Eingabe. Eingaben beim Client sind dem Server im Momentder Eingabe unbekannt.

33

"Ich will Frage drei beantworten.\

3.2. Spezielle Umsetzung 19

Abb. 3.3 : Zwei Freitexteingaben. Die obere Frage ist gerade in Beantwortung. Die unterehat keine Schalt �achen und ist gesperrt (symbolisch durch das Schloss angedeutet).

3.2.4.5 Die Freitextfrage

Die Repr�asentation der mit Freitext zu beantwortenden Frage besteht im Wesentlichen ausFrage, Musterl�osung und erreichbaren Punkten. W�ahrend der Bearbeitung kommen nochdie der Benutzerantwort, der Korrekturkommentar und die erreichten Punkte hinzu.Da die Freitextfrage sich nicht automatisch korrigiert, kann sie neben o�en und geschlossenauch noch in Korrektur34 und korrigiert sein.

3.2.4.6 Das Sammelelement

Das Sammelelement dient zur Aggregation der Grundelemente. Bei der Implementierungkommt die Verwendung der Vererbung und die damit vorhandene gemeinsame Au�en-schnittstelle zum Tragen: Alle aggregierten Elemente k�onnen gleich angesprochen werden.Ich habe zwei Darstellungsmodi implementiert. Einen, der alle aggregierten Elemente aufeiner Seite anzeigt und einen, der jedes Element auf einer eigenen Seite ausgibt und dazunoch eine �Ubersichtsseite generiert. Durch Kombination beider Ansichten35 l�asst sich derInhalt didaktisch sinnvoll gliedern (vgl. 2.2.2, 2.3.1).W�ahrend sich die Sichtbarkeiten der Grundelemente an Benutzergruppen binden l�asst,kann man die Sammelelemente an Zeitpl�ane (vgl. 3.2.4.8) binden36. Sie sind dann nurw�ahrend des Zeitplanes sichtbar. Da die Sammlung auch nur aus einem Element bestehenkann, l�asst sich somit jedes Element an einen Zeitplan binden.

34Der Zustand"in Korrektur\ erlaubt es den Korrektoren zwar Punkte zu vergeben und diese auch

zusammen mit einem Kommentar zu speichern, dies dem Teilnehmer aber noch nicht anzuzeigen, um sichbeispielsweise mit anderen Korrektoren abzustimmen.

35Jedes Sammelelement l�asst sich je nach Aufruf auf die eine oder andere Art betrachten.36Dadurch, dass man jedes Element in ein Sammelelement packen kann, ist es m�oglich jedes Element an

Zeitpl�ane zu binden. Umgekehrt ist ein Sammelelement auch nur sichtbar, wenn mindestens ein enthaltenesElement sichtbar ist.

20 3. Konzeption des Labsystems

3.2.4.7 Die Lerneinheit

Die Lerneinheit kapselt alle f�ur die Durchf�uhrung einer Lerneinheit ben�otigte Funktiona-lit�at (vgl. 2). Sie ist das komplexeste Element. Sie st�o�t die Korrektur der Fragen an undgeneriert �Ubersichtsseiten mit allen Fragen sowie die Punkte�ubersichten.Eine Lerneinheit besteht aus zwei Sammlungen (vgl. 3.2.4.6): Einer f�ur den Theorieteilund einer f�ur den Praxisteil.Auch die Lerneinheit l�asst sich an einen Zeitplan (vgl. 3.2.4.8) binden.

3.2.4.8 Der Eintrag im Zeitplan

Ein Eintrag im Zeitplan besteht aus einem Start-, einem Endzeitpunkt und einem Linkauf das Element, das er bindet.

3.2.5 Fazit

Die vorgestellten Lernobjekte erm�oglichen es, ein Praktikum auf die in den vorherigenKapiteln vorgestellte Weise durchzuf�uhren. Das System ist sicher weniger exibel als an-dere Lernsysteme. Daf�ur ist es aber auch nicht so komplex und damit zum einen leichthandhabbar und zum anderen auch leicht erweiterbar37.

37F�ur Chats, Foren und andere m�oglicherweise erw�unschte Funktionalit�at existieren gen�ugend Standar-dimplementierungen, die leicht eingebunden werden k�onnen.

4. Das Labsystem in der Praxis

Wie in 1.1 schon angef�uhrt, kam die erste Version des Systems bereits im Sommersemester2004 zum Einsatz. Die im vorigen Kapitel beschriebene vollst�andige �Uberarbeitung ist seitSommersemester 2005 am Lehrstuhl f�ur Rechnernetze und Internet [riwe] der Universit�atT�ubingen zur Durchf�uhrung des Internetlabs [colm] im Einsatz. Seit dem Wintersemester2005/ 2006 ist ebenfalls eine Installation an der Fachhochschule Albstadt-Sigmaringen imEinsatz.Da ich das Projekt von Anfang an begleitet habe, will ich in diesem Abschnitt von denErfahrungen, die sich mit der Umstellung ergaben, berichten.

4.1 Das Authoring

Das Erstellen von Inhalten, die in einer Webumgebung pr�asentiert werden, bietet andereM�oglichkeiten als ein Blatt Papier als Zielmedium: Es kann zwischen viel mehr verschie-denen Darstellungsformen ausgew�ahlt werden (vgl. 2.2.3).Wir haben dies beim Erstellen von neuen Inhalten f�ur das Internetlab nur zum Teil genutzt.Anstelle Informationen in unserem System bereitzustellen, verweisen wir des �Ofteren di-rekt auf frei verf�ugbare Webseiten mit relevanten Informationen1. Dem Teilnehmer wirdso nebenbei gezeigt, wo sich die relevanten Informationen im Netz (auch f�ur eigene Re-cherchen in Bezug auf nicht direkt behandelte Themen) �nden lassen.Ein De�zit sehe ich bei unseren Inhalten im Bereich der interaktiven Elemente. Wir habennur wenige Animationen und Applets, in denen die Teilnehmer direkt Sachverhalte aus-probieren k�onnen. Die praktischen Erfahrungen der Lernenden im Praxisteil gleichen dieszu einem gewissen Teil aus. Viele Dinge lassen sich aber in einer Animation besser ver-anschaulichen (Beispielsweise die Verteilung von Paketen in einem Netzwerk) und lernensich im Theorieteil damit einfacher. Grund f�ur das Fehlen ist, dass wir keine Zeit hatten,solche Animationen zu suchen oder zu erstellen. Hieran kann in Zukunft noch gearbeitetwerden.

In 2.2.2 und 2.3.1 habe ich die nicht mehr vorhandene"nat�urliche\ Segmentierung der

Inhalte durch DIN-A4-Seiten angef�uhrt. Es besteht die Gefahr, den Leser durch ein zuviel an Information abzuschrecken (sehr lange Webseiten). Sinnvoll genutzt bewirkt die

1Ein Problem, dass dadurch entsteht ist, dass Links im Internet zerbrechen und (schlimmer noch) Inhalteder verwiesenen Seiten sich einfach �andern k�onnen (Wikipedia). Als L�osung bietet es sich an, auf solcheSeiten nicht zu linken (Microsoft-Links waren beispielsweise nach einem halben Jahr tot) oder diese lokalzu spiegeln (Urheberrecht beachten).

22 4. Das Labsystem in der Praxis

Abb. 4.1 : Das Webportal http://colmar.informatik.uni-tuebingen.de

4.2. Praktikumsablauf im Wintersemester 2005/ 2006 23

freie aktive Seiteneinteilung allerdings genau das Gegenteil. Die Praxis hat best�atigt, dasskurze Texteinheiten dem Leser das Gef�uhl geben, voranzukommen. Es macht dabei einenUnterschied, ob die Inhalte auf einer Seite in kurzen Abschnitten oder immer nur wenigeAbschnitte auf vielen Seiten pr�asentiert werden. Im letzteren Fall wird die gleiche Mengean Text als deutlich weniger wahrgenommen2. Da auch der Autor dieser Wahrnehmungunterliegt, obliegt es diesem umso mehr, auf einen angemessenen Umfang zu achten.Anders als eine gedruckte Versuchsanleitung verleiten Webseiten nicht so sehr dazu, nachvorne zu

"spicken\. Bei einer sinnvollen Aufteilung werden die Teilnehmer nicht durch

sp�atere Aufgabenstellungen und Schaubilder abgelenkt. Die Versuchsteilnehmer sind sokonzentrierter auf den aktuellen Aufgabenteil. Die Gesamtheit des Versuches geht dabeinicht verloren, da sie sich in der Dokumentstruktur, die auf der ersten Webseite des Praxis-teils pr�asentiert wird, widerspiegelt. Durch eine sinnvolle Aufteilung wird Fehlerpotenzialund damit der Betreuungsaufwand vermindert.Wie schon in 2.3.1 beschrieben, hat es sich sehr bew�ahrt, in ein Freitextfragenelement(3.2.4.5) jeweils nur eine (Teil-)Frage einzubauen. Die Antworten der Teilnehmer sind da-durch pr�aziser auf die Frage gerichtet und die Korrektur wird schneller. Einzuwenden isthier allerdings, dass die Teilnehmer dadurch nicht mehr lernen, genau zu lesen und Aufga-benstellungen auch einzeln zu erfassen { ein wichtiger Bestandteil des Informatikstudiums.Der Vorteil einer beschleunigten Korrektur und weniger R�uckfragen �uberwiegt hier meinesErachtens.Ein letzter Punkt, den ich hier anf�uhren m�ochte, ist die sofortige �Anderungsm�oglichkeit

von Online-Inhalten3. Gerade beim ersten Durchlauf unserer neuen Versuche stellten sichInstruktionen und Aufgaben oft als verbesserungsbed�urftig heraus. Da wir als Betreuer an-wesend waren, konnten wir unsere Erkenntnisse aus den Teilnehmerr�uckfragen umgehendf�ur nachfolgende Teams in das System ein ie�en lassen. Dies ist nat�urlich problematisch, dafr�uhere Teams dann eventuell gewisse Hilfestellungen nicht hatten. Hier greift die History,anhand derer jeder �Anderungen nachvollziehen kann (vgl. 3.1.5). M�ogliche Ungerechtigkei-ten werden so auch f�ur die Teilnehmer transparent. Bei der Korrektur konnten wir dannebenfalls anhand der History nachvollziehen, ob die Antwort vor oder nach der �Anderungerfolgte und dies bei der Punktevergabe ber�ucksichtigen4.

4.2 Praktikumsablauf im Wintersemester 2005/ 2006

Dieser Abschnitt ist ein Einschub, in dem ich kurz anhand eines Versuches beschreibenm�ochte, wie der Ablauf des Praktikums bei uns im Wintersemester 2005/ 2006 aussieht.

Unser Versuch beginnt Donnerstag morgens mit einem kurzen Vortrag zu einigen der vor-kommenden Inhalte. Der Theorieteil ist zwar schon seit Montag verf�ugbar, aber unserTeilnehmer hat bisher erst kurz reingeschaut. Wie die Meisten erledigt er die theoreti-sche Vorbereitung am Wochenende. Dazu loggt sich der Teilnehmer auf der Portalseite[colm] mit seinem pers�onlichen Account ein, arbeitet die Inhalte durch und beantwor-tet die Multiple-Choice-Fragen. Wenn er alle Fragen beantwortet hat, klickt er auf eineSchalt �ache im Portal und das System �uberpr�uft seine Antworten. Er bekommt umgehendFeedback, welche Aufgaben richtig gel�ost wurden und welche falsch (vgl. Abb. 2.1). EineAufgabe wird als falsch angezeigt. Bei dieser Aufgabe war unser Student auch unsicherund entscheidet sich jetzt f�ur die andere L�osung. Eine erneute �Uberpr�ufung zeigt ihm an,

2Im Gegensatz zu allen anderen Labs ist in unserem TCP/ UDP-Lab genau der Fall vorhanden, dasssehr viele Instruktionen und Aufgaben auf einer Seite stehen. Regelm�a�ig ist dieses Lab dasjenige, bei demdie Teilnehmer �uber den Umfang st�ohnen.

3Die �Anderung wird dabei sofort propagiert, da ab dem �Anderungszeitpunkt nur noch die neue Formu-lierung angezeigt wird.

4Die Hinweise der Teilnehmer in den ersten Durchg�angen waren von enormer Hilfe bei der Optimierungder Aufgaben. Ihnen sei an dieser Stelle noch einmal ausdr�ucklich daf�ur gedankt.

24 4. Das Labsystem in der Praxis

Abb. 4.2 : Ansicht des Korrektors beim Korrigieren eines Teilnehmers (Teams). Der Teil-nehmer sieht dieselbe Seite nur ohne die Korrekturschalt �achen. Dies ist die �Ubersichts-seite mit allen Fragen. Die Instruktionen fehlen hier. Eine andere Ansicht zeigt auch dieInstruktionen zu den Aufgaben, so wie der Teilnehmer sie zur Verf�ugung hat.

dass diese stimmt. Den m�oglichen dritten Versuch hat er also { wie die meisten Teilnehmer{ nicht gebraucht.Erst wenn beide Teammitglieder mit ihrem Account die Multiple-Choice-Fragen fertig be-antwortet haben, bekommen sie Zugri� auf den Praxisteil.F�ur die praktischen Aufgaben hat jedes Team einen reservierten Zeitslot5. Das Team tri�tsich an diesem Tag im Praktikumslabor und arbeitet den Praxisteil gemeinsam durch. Jenachdem, wie viele Schwierigkeiten es mit dem Versuch hat, braucht es mal k�urzer undmal deulich l�anger f�ur einen kompletten Versuch. Deshalb habe ich dieses Jahr zum erstenMal ganze Tage vergeben. Ein Team hat also einen vollen Tag das gesamte Testbett f�ursich6. Dies ist ein Fortschritt zum letzten Semester, in dem wir Vier-Stunden-Bl�ocke ver-teilt hatten, da die Teilnehmer oft nicht innerhalb ihrer vier Stunden fertig wurden unddann an einem anderen Tag noch einmal komplett aufbauen und kon�gurieren mussten.Die Teams k�onnen sich ihre Zeit damit auch exibler einteilen und l�angere Pausen machenoder als Unterbrechung andere Veranstaltungen besuchen. Zu einer festgelegten Zeit desTages7 sind die Betreuer anwesend, die bei Problemen helfen k�onnen.Unser Team tri�t sich am Dienstag morgen im Labor und beginnt mit dem Setup. Nachdemdie Rechner verkabelt und kon�guriert sind, setzen die beiden Teilnehmer die Instruktio-nen um und beantworten die eingestreuten Fragen direkt an der entsprechenden Stelle aufder Webseite. Das Team hat noch eine Frage, die es mit dem Betreuer kl�art und ist dannnach f�unf Stunden mit dem Praxisteil fertig. Das System schlie�t einen Versuch automa-tisch, wenn dessen Zeit { in der Regel zwei Wochen { abgelaufen ist. Da unser Team aberschon fertig ist, kann es den Versuch gleich schlie�en. Da die beiden noch etwas nachschau-en wollen, lassen sie den Versuch noch o�en, korrigieren am �ubern�achsten Tag noch eine

5Der Theorieteil sollte entsprechend vor diesem Tag durchgearbeitet sein, was in der Regel auch klappt.6Da wir zwei komplette Testbetten haben, k�onnen zwei Teams pro Tag arbeiten.7{ normalerweise zwei Stunden lang {

4.3. Die Teilnehmersicht 25

Aufgabe und schlie�en den Versuch dann.Die Betreuer und Korrektoren haben schon die ganze Zeit die M�oglichkeit, die L�osungendes Teams einzusehen. Erst nach dem Schlie�en k�onnen sie aber korrigieren (vgl. Abb.4.2), da unser Team erst jetzt keine �Anderungen mehr vornehmen kann. Falls unser Teamdoch noch etwas �andern will k�onnen sie ihm den Versuch auch nochmal freischalten8. Dadie Korrektoren quer korrigieren, warten sie, bis alle Teams geschlossen haben, um dannauf einmal zu korrigieren. Die drei Betreuer Joachim, Andreas und Edgaras haben sich dieAufgaben aufgeteilt und korrigieren jetzt jeder ihren Teil. Unser Teilnehmer kann dabeidirekt den Korrekturstatus und auch schon die bereits korrigierten Aufgaben und derenKommentare einsehen (vgl. Abb. 4.2, Abb. 4.3). Manchmal ist dem Korrektor eine L�o-sung nicht ganz klar und muss erst besprochen werden. Dazu kann die Aufgabe im Systemkorrigiert, aber noch nicht freigegeben werden. Somit sehen die Teilnehmer die Korrekturnoch nicht, sie ist aber schon gespeichert und kann von allen Korrigierenden eingesehenwerden.Die drei Korrektoren werfen noch einen kurzen Blick auf die Theorieteilpunkte, um zusehen, ob unser Teilnehmer auch die Theorieteilfragen gewissenhaft beantwortet hat:

Da dies der Fall ist, ist die Bearbeitung des Versuchs damit abgeschlossen. W�are die Theo-rieteilpunktzahl zu gering, m�usste der Korrektor sich die L�osungen unseres Teilnehmersanschauen und ihn dazu befragen, falls beispielsweise bei allen drei Versuchen das Gleicheoder gar Nichts angekreuzt ist.Entsprechend der Punkte�ubersicht f�ur den einen Versuch (vgl. Abb. 4.3) gibt es auch eineaggregierte f�ur alle Versuche, in der die Gesamtpunktzahlen dargestellt werden.

Nach diesem Einschub komme ich zur�uck zu den �Anderungen die sich f�ur die verschiedenenBenutzer des Systems ergeben.

4.3 Die Teilnehmersicht

Hauptgrund f�ur die Erstellung des Systems und die Umstellung des Praktikums auf dieseswar der Wunsch, das Praktikum f�ur die Teilnehmer e�ektiver zu gestalten. Deshalb sinddiese Hauptangelpunkt.Da ich selbst das Praktikum vor der Umstellung als Teilnehmer und nach der Umstellungals Betreuer erlebt habe, kann ich nicht vom selben Standpunkt vergleichen. Dies ist al-lerdings vielleicht sogar ein Vorteil, da ich so wei�, wie es mir selbst erging und wie mirdieselbe Situation jetzt erscheint, wenn ich meine Teilnehmer beobachte.Wie schon in 1 angef�uhrt, sehe ich beim Theorieteil ein gro�es Problem im Umfang desMaterials und der fehlenden Lenkung innerhalb dieses. Au�erdem gibt es keinen Ansporn,das Material aufmerksam durchzuarbeiten, da sich die sp�ateren Aufgaben meist auch miteinem Teil des Wissens oder nachtr�aglichem Nachschauen bearbeiten lassen und damit we-niger Zeit gebraucht wird. Soweit die Sicht des Teilnehmers. Aus Sicht des Konzipierendendes Praktikums ist diese Einstellung schlecht. Es k�onnen immer nur wenige Teilaspekteinnerhalb des Praxisteils ber�uhrt werden. Wichtig zum Verst�andnis und Lernziel sind aberdie gesamten Informationen des Theorieteils oder zumindest ein deutlich gr�o�erer Teilals derjenige, der sp�ater f�ur die praktischen Versuche ben�otigt wird. Der vorgeschlageneL�osungsansatz mit den Multiple-Choice-Fragen (2.2.1) war ein Erfolg. Die Fragen zeigenden Teilnehmern an, worauf sie besonderes Augenmerk zu legen haben. Die H�urde, dassjeder Einzelne die Fragen beantwortet haben muss, um am Praxisteil teilnehmen zu k�on-nen bewirkt einen Ansporn, den gesamten Theorieteil durchzugehen9. Ein unvorbereitetes

8Bereits vorgenommene Korrekturen gehen dabei nicht verloren, werden dem Teilnehmer aber verborgenund m�ussen nach dem erneuten Schlie�en durch den Korrektor wieder freigeschaltet bzw. entsprechend derneuen L�osung angepasst werden.

9Die f�ur alle Teilnehmer einsichtige Liste, wer wann mit dem Theorieteil fertig wurde, spornt dazu an,bei Zeiten fertig zu werden.

26 4. Das Labsystem in der Praxis

Abb. 4.3 : Punkte�ubersicht w�ahrend der Korrektur. Die bunten Seiten links geben denKorrekturstatus der einzelnen Aufgaben wieder. Die Punktebalken spiegeln die Punktzahldes Theorie- und Praxisteils gra�sch wieder. Die Symbole dazwischen zeigen an, ob das ge-samte Team den Theorieteil abgeschlossen hat, der Praxistil geschlossen und die Korrekturabgeschlossen wurden.

4.3. Die Teilnehmersicht 27

Erscheinen wird durch das System praktisch unm�oglich gemacht. Nat�urlich k�onnten dieTeilnehmer einfach alle Fragen wegklicken, dies f�allt dann aber den Korrektoren auf. ImGegensatz zu vielen anderen Praktika, sind die Teilnehmer bei uns in der Regel ausreichendvorbereitet f�ur den praktischen Teil und zwar jedes einzelne Teammitglied. Dies ist sicherauch ein Grund, warum die Teilnehmer dieses Praktikum als besonders positiv erleben:Alle haben ausreichend Vorwissen, um gemeinsam durch den Versuch zu kommen undsp�atestens hinterher hat jeder Teilnehmer verstanden, was es mit der L�osung auf sich hat.Ohne diesen Vorbereitungszwang10 w�are dies nicht so, weil die meisten Studenten einfachzu faul w�aren sich ordentlich vorzubereiten.

Die Verwendung des Internet als zugrunde liegende Plattform hat dazu gef�uhrt, dass dieTeilnehmer dieses deutlich verst�arkter zur Recherche nutzen. Sie �nden damit beil�au�gsowohl weiterf�uhrende Informationen als auch heraus, welche Quellen es gibt11 und welchedavon wie verl�asslich sind. Da das Internet zur Zeit eine der wichtigsten, wenn nicht diewichtigste Informationsquelle { mindestens im Bereich Informatik { ist, ist das Wissen um

verl�assliche Informationsquellen wertvoll.

Der Praxisteil hat durch die Umstellung auf das neue System deutlich an Klarheit gewon-nen. Wenn ich mit unserem Betreuungsaufwand von fr�uher vergleiche, so ist dieser heutenahe bei Null. Die oben (4.1) schon angesprochene Aufteilung des Versuchs auf mehrereSeiten und Sinneinheiten kombiniert mit separierten Aufgabenteilen12 versetzt die Teil-nehmer in die Lage, autonom arbeiten zu k�onnen. Fragen, die sich ergeben, beziehen sichnicht mehr auf das, was zu tun ist, sondern auf unerwartete Probleme13. Diese treten aufund sind auch von den Betreuern nicht immer zu l�osen. Dazu braucht es einfach Erfahrung,die man nach mehreren Jahren in der Materie zu einem gewissen Ma�e hat. Gerade solcheProbleme haben manchmal den gr�o�ten Lerne�ekt: Die Durchf�uhrung des Versuches wirdzwar mehr oder weniger kurz unterbrochen, aber gerade die Fehlerlokalisation ist eine derAufgaben, vor die man im Beruf immer wieder gestellt werden wird.Die Bearbeitungszeit von vor der Umstellung auf die Online-Plattform und danach l�asstsich nicht direkt vergleichen, da wir die Aufgaben grundlegend erneuert haben. Aus mei-nem eigenen Erleben kann ich sagen, dass das Ziel, auf die Inhalte zu fokussieren vollerreicht wurde. Die Teilnehmer haben nach ihrer Versuchsdurchf�uhrung keinen Aufwandmehr, aus den Notizen ein Protokoll zu formen, da die Antworten schon das Protokollsind14. Damit l�asst sich auch eine etwas l�angere Arbeitszeit im Praktikumslabor, wie siebei uns der Fall ist, mindestens teilweise rechtfertigen. Eine Nachbearbeitungsphase zurAuswertung von Messergebnissen, wie beispielsweise in der Physik, gibt es bei uns nicht.Dennoch arbeiten die Teilnehmer auch nach dem Versuch zuhause noch an den Aufgaben.Auch bei vorhandener Nachbearbeitungsphase l�asst sich ein Online-System also sinnvollnutzen.Dadurch, dass die Aufgaben innerhalb des Systems korrigiert werden, k�onnen die Teilneh-mer die Korrekturen von einzelnen Aufgaben schon einsehen, bevor der gesamte Versuch

10, der aufgrund der technischen Vorkehrung durch das System und damit nicht durch eine Person(sozialdruck) ausge�ubt wird,

11Meinen ersten RFC habe ich beispielsweise im Rahmen des Internetlabs gelesen.12Nat�urlich ist auch eine klare Aufgabenstellung hier anzuf�uhren. Bis zu dieser hat es bei uns unge-

f�ahr drei Iterationen/ Semester gedauert. Die meisten �Anderungen ergaben sich allerdings beim erstenDurchlauf.

13Man hat zwar alles richtig gemacht, doch es tut nicht, weil irgendein Faktor Ein uss nimmt, dernormalerweise vielleicht nicht auftritt.

14Ich m�ochte auch hier nochmal erw�ahnen, dass dadurch das Wissen, wie ein Versuchsprotokoll auszu-sehen hat nicht unbedingt erworben wird. In unserem Fall waren die Abgaben aber von Anfang an keineProtokolle in dem Sinne, wie sie beispielsweise bei chemischen Versuchen abzugeben sind. Falls es darauf an-kommt, zu lernen, wie ein ordentliches Protokoll aussieht, kann man auch die Felder entsprechend anordnenoder diese auf einer abschlie�enden �Ubersichtsseite entsprechend pr�asentieren. Die neue Pr�asentationsformsteht dem also nicht im Wege.

28 4. Das Labsystem in der Praxis

korrigiert ist15. Dies ist insofern interessant, dass die Korrektur lerntechnisch am meistenbewirkt, wenn die zeitnah zum Versuch erfolgt, da die Teilnehmer dann noch in Erinnerunghaben, was sie �uberhaupt gemacht haben.

4.4 Die Betreuung

Durch die sich aus dem neuen Systems ergebenden M�oglichkeiten zur klaren Strukturie-rung und Aufteilung der Versuche ist der Betreuungsaufwand deutlich zur�uckgegangen.Mitlerweile16 ist es zum ersten Mal so, dass viele Teams g�anzlich ohne R�uckfragen dieVersuche bearbeiten. Dies liegt nat�urlich auch daran, dass wir die Aufgaben im Laufe derletzten Semester optimiert haben. Bei der Umstellung auf das neue System zum Sommer-semester 2005 war der R�uckgang aber signi�kant.Einen gro�en Nutzen f�ur die Betreuer bieten die Musterl�osungen. Mit ihrer Hilfe kann sichschnell in den Sachverhalt eingearbeitet werden: Der Betreuer �o�net einfach die Stelle, ander es Probleme gibt in seinem Account und bekommt die L�osung angezeigt17. Eine M�og-lichkeit, die wir bisher noch wenig nutzen, sind Hinweise innerhalb der Versuche, die nurden Betreuern angezeigt werden. Diese bieten sich an Stellen an, die sich f�ur die Teilnehmerals Problemstellen herausgestellt haben18.

4.5 Die Korrektur

Der Korrekturaufwand ist sehr zur�uckgegangen. In dem Jahr, in dem ich Teilnehmer war,gab es individuelle Abgaben pro Team ohne festgelegte Form. Die Korrektur einer solchenAbgabe dauert sehr lange und ist schwierig, da man als Korrektor st�andig vor Augen ha-ben muss, wo im Versuch sich der Antwortende gerade be�ndet. Verbessern l�asst sich dies,indem man wenigstens die Form vorgibt. Noch besser ist es, wenn man dem Teilnehmergleich einen Instruktionstext mit vorgefertigten Freir�aumen f�ur die Antworten gibt. Dannist man schon fast bei der Situation des Labsystems.Im jetzigen System ist die Ansicht des Versuchs f�ur Korrektoren und Teilnehmer dieselbe.Die Korrektoren k�onnen sich zus�atzlich die Musterl�osung einblenden (vgl. Abb. 4.3). Siesehen so zu jeder Zeit genau das, was auch die Teilnehmer zur Bearbeitung der Aufgabevor sich hatten { ein gro�er Vorteil, m�ussen sie jetzt nicht mehr nachschauen, worum esbei der Frage eigentlich geht19.Die Online-Abgabe ist getippt. Als langj�ahriger Korrektor von handschriftlichen Abgabenkann ich beurteilen, dass es mitunter sehr zeitaufw�andig ist, die Handschrift eines Men-schen zu lesen.Da wir mehrere Korrektoren haben, korrigieren diese aus Gr�unden der Gerechtigkeit20 undnicht zuletzt der E�zienz21 quer. Das hei�t Korrektor A Aufgaben 1-5 aller Teams, Kor-rektor B 6-10 etc. Das System bietet dazu die M�oglichkeit, die Antworten aller Teams auf

einmal anzuzeigen. Der Korektor kann so bequem alle Teams zu einer Aufgabe korrigieren(vgl. Abb. 2.2).Vor allem die letzten beiden Punkte haben die Korrektur sehr beschleunigt.

15Unsere drei Betreuer korrigieren quer.16Wintersemester 2005/ 200617In der Praxis haben wir im Betreuerraum einen Ausdruck des Versuches mit Musterl�osung, da man

diesen mit zu den Rechnern der Teilnehmer nehmen kann, ohne diesen die Musterl�osung auf dem Bildschirmzeigen zu m�ussen.

18Wenn solche Problemstellen keinen Lernefekt haben, sollte die Aufgabe ver�andert werden!19Bei Bedarf k�onnen Teilnehmer wie Korrektoren eine Seite aufrufen, die lediglich die Fragen und Ant-

worten ohne Instruktionstext enth�alt.20Eine andere M�oglichkeit w�are, die Teams unter den Betreuern jedes Mal zu tauschen.21Es geht deutlich schneller, eine Aufgabe bei allen Teams vergleichend zu korrigieren, als jedes Mal bei

einem Team von vorne mit dem Versuch anzufangen.

4.6. Punkteverwaltung 29

4.6 Punkteverwaltung

Bei der"manuellen Korrektur\ m�ussen nach der Korrektur noch die Punkte �ubertragen

werden, da das Protokoll zumeist zur�uckgegeben wird. Sinnvoller Weise sind die Punktealler Aufgaben zu �ubertragen. Im Idealfall hat der Teilnehmer Einsicht in seine Punkte,um zu sehen, wie er steht.Bei uns entf�allt dieser Schritt nat�urlich. Das System stellt Teilnehmern und Korrektorendiverse �Ubersichtseiten mit ihren Punkten zur Verf�ugung (vgl. Abb. 4.3). Hier hat sichbesonders das in 3.1.5 angesprochene Farbsystem bew�ahrt. Unsere Teilnehmer m�ussenmomentan 75% der m�oglichen Punkte erreichen, um zu bestehen. Das System zeigt durchdie F�arbung des Punktebalkens an, ob dieses Kriterium in Gefahr ist. Ein Blick auf dieStatistik zeigt, welche Teams im kritischen roten Bereich sind (vgl. Abb. 4.3).

30 4. Das Labsystem in der Praxis

5. Zusammenfassung und Ausblick

Die Arbeit hat gezeigt, dass die Umstellung eines Praktikums von konventioneller Formauf ein eLearningsystem viele Vorteile bringt. Sie hat dazu zuerst allgemeine Ver�anderun-gen angef�uhrt, die zu einer Verbesserung des Praktikums vor allem (aber nicht nur) f�urdie Lernenden beitragen k�onnen. Diese k�onnen als Kriterien zur Auswahl einer geeigne-

ten Lernplattform dienen. Sie waren die Anforderungen an das Labsystem. Schl�usselent-scheidungen bei der Konzeption dieses neuen eLearning-Systems wurden im n�achsten Teilaufgezeigt. Kapitel vier stellte die Vorteile, die sich f�ur das Internetpraktikum durch dieUmstellung ergeben haben, heraus.

Vielen Praktika steht der Wandel und damit einhergehende Wechsel in ein neues Mediumnoch bevor. Die Arbeit hat einen m�oglichen Weg gezeigt und soll auch dazu ermutigen, denSchritt zu wagen. Der Aufwand, der durch die Umstellung entsteht, wird in den Folgejahrenwieder ausgeglichen1 und die Lehre stark verbessert :

This course was excellent...2

1Der Betreuungs- und Korrekturaufwand geht deutlich zur�uck. Durch Einsparung von entsprechendenHiwis in den Folgejahren lassen sich auch die Umstellungskosten amortisieren.

2Abschlusskommentar eines Teams im Sommersemester 2005

32 5. Zusammenfassung und Ausblick

Literatur

[BaHMH02] Peter Baumgartner, Hartmut H�afele und Kornelia Maier-H�afele. E-LearningPraxishandbuch; Auswahl von Lernplattformen; Markt�ubersicht - Funktionen

- Fachbegri�e. StudienVerlag. 2002.

[bild] http://www.bildungsserver.de/zeigen.html?seite=1571, Vergleich von Web-systemen.

[colm] http://colmar.informatik.uni-tuebingen.de, Webportal des Internetprakti-kums.

[Hani03] Frank Hanisch. Evolution der neuen Medien in der Lehre, Kapitel 7, S. 27{43.WSI. Editor: Marc-Oliver Pahl, 2003.

[ilia] http://www.ilias.de, Das Ilias-Projekt.

[KlWa04] Bernd Kleimann und Klaus Wannemacher. E-Learning an deutschen Hoch-

schulen, Von der Projektentwicklung zur nachhaltigen Implementierung. HISGmbH. 2004.

[labs] http://labsystem.m-o-p.de, Das Labsystem.

[LiZa04] J�org Liebeherr und Magda El Zarki. Mastering Networks: An Internet Lab

Manual. Press. 2004.

[M�unz05] Stefan M�unz. SelfHTML 8.1. Kiel. 2005.

[mood] http://moodle.org, Das Moodle-Projekt.

[olat] http://www.olat.org, Das Olat-Projekt.

[riwe] http://net.informatik.uni-tuebingen.de, Webseite des Lehrstuhls f�ur Rech-nernetze und Internet.

[Schm04] Egon Schmid. PHP Handbuch. PHP Documentation Group. 2004.

[SpKl01] Michael Sperber und Herbert Klaeren. Vom Problem zum Programm. Ar-

chitektur und Bedeutung von Computerprogrammen., 3. Au age. Teubner.2001.

[valia] http://jigsaw.w3.org, CSS-Validator des W3C.

[valib] http://validator.w3.org, HTML-Validator des W3C.

[vite] http://www.vitels.ch, Webseite des Vitels-Verbundes.

[webc] http://www.webct.com, Webseite des kommerziellen WebCT-Programms.