WYSIWYG-Editoren, In-Browser-Korrektur, Syntax Highlighting

Eingebettete Rich-Text-Editoren, In-Browser-Korrektur und Syntax Highlighting im Online-Übungssystem

Autor: Immo Schulz-Gerlach, ZMI, FeU-Anwendungen
Version: 2.2 vom 03.12.2018
[PDF-Version] [ePub-Version]

Kapitelübersicht

  1. Einleitung/Motivation
  2. Eingebettete WYSIWYG-HTML-Editoren
  3. In-Browser-Korrektur
  4. Syntax-Highlighting und Quelltext-Einsendungen

Einleitung / Motivation

Eine häufig genutzte Variante von Einsendeaufgaben im Online-Übungssystem sieht vor, dass Studenten ihre Lösungen in Form mehrzeiligen Klartextes in Eingabefelder eingeben, die direkt in der Aufgabenseite zur Verfügung stehen, und dass solche Einsendungen später von Korrekturkräften manuell korrigiert werden. Im Normalfall besteht ein derartiges Eingabefeld innerhalb der Aufgabenseite aus einer einfachen Textbox (HTML-Textarea), in die lediglich unformatierter Text eingegeben werden kann. Ein Aufgabenautor hatte zwar schon immer die Möglichkeit, einen JavaScript-HTML-Editor zur Eingabe (HTML-)formatierten Textes in die Aufgabenseiten einzubetten, nur musste er sich bisher für ein Produkt entscheiden, die benötigten Dateien als Kursressourcen hochladen und sich selbst eingehend mit der Einbindung des Editors in den HTML-Quelltext sowie dessen Konfiguration beschäftigen.

Eines der in diesem Dokument vorgestellten Features (seit Dezember 2010 im Online-Übungssystem verfügbar) ist daher ein integrierter Editor für formatierten Text, dessen Einbindung in eine Aufgabenseite sehr einfach lediglich durch Aufnahme einer einzigen Kommentarzeile erfolgen kann. Das Online-Übungssystem stellt dazu mehrere alternative vom ZMI vorkonfigurierte Ausprägungen des Editors zur Verfügung.

Ein zweites neues Feature (ab Dezember 2010) des Online-Übungssystems ist die sog. „In-Browser-Korrektur“. Das „herkömmliche Korrekturverfahren“ sieht vor, dass eine Korrekturkraft eine Suite aus Browser und HTML-Editor, wie z.B. »Mozilla SeaMonkey«, installiert. Zur Korrektur wählt der Korrektor dann im Browser eine zu korrigierende Einsendung aus, die ihm daraufhin im Browser angezeigt wird. Mit einem kurzen Befehl (Strg-E in SeaMonkey) öffnet er dann die Korrektur im Editor, kann sie beliebig bearbeiten und anschließend über einen Publish-Befehl wieder im Online-Übungssystem speichern. Über ein Formular im Browser trägt der Korrektor anschließend noch die vergebene Punktzahl ein und vermerkt den Korrekturstatus.

Diese herkömmliche Korrekturmethode steht unverändert weiter zur Verfügung, jedoch gibt es nun mit der „In-Browser-Korrektur“ eine Alternative mit insb. folgenden Eigenschaften:

Speziell an Anbieter von Aufgaben, in denen Studenten Quelltexte (z.B. von Programmen, Webseiten oder Datenbankanfragen) einsenden müssen oder in denen solche in den Aufgabentexten oder Musterlösungen dargestellt werden sollen, richtet sich ein drittes, seit Mai 2014 verfügbares Feature des Online-Übungssystems: Automatische Syntaxhervorhebung in Quelltexten.

Die folgenden Kapitel richten sich an Aufgabenautoren und beschreiben die Einbindung/Verwendung dieser drei Features (HTML-Editor, In-Browser-Korrektur sowie Syntax Highlightings sowie Quelltext-Einsendungen in Aufgaben).


Eingebettete WYSIWYG-HTML-Editoren

Seit Dezember 2010 ist der in JavaScript implementierte Open-Source-Editor TinyMCE ins Online-Übungssystem integriert. D.h. die benötigten Ressourcen (JavaScript-Quellen, Grafiken, Konfigurationsdateien) sind zentral auf dem Übungssystem-Server hinterlegt, und das Übungssystem bietet Aufgabenautoren verschiedene vorkonfigurierte Ausprägungen mit unterschiedlich großer Funktionsvielfalt zur Einbindung in Aufgabenseiten (für studentische Eingaben) oder Korrekturseiten (für In-Browser-Korrektur) an. Seit Mai 2014 wird die grundlegend überarbeitete Version TinyMCE 4 standardmäßig eingesetzt, die Vorversion ist aber parallel weiterhin installiert und kann zumindest in Aufgabenseiten und für die In-Browser-Korrektur noch alternativ verwendet werden.

Editor-Typen

Einfacher Editor

Die einfachste Ausprägung ist ein einfacher Editor, der lediglich Grundfunktionen zur Zeichenformatierung (wie z.B. Fettdruck) besitzt, Aufzählungen ermöglicht und eine Undo- und Redo-Funktionalität aufweist:

Abb. 2-1: Einfacher Editor
Abb. 2-1: Einfacher Editor

Weiterhin unterstützt bereits der einfache Editor das Zerlegen des Textes in Absätze. Dazu wird bei Betätigen der Enter-Taste ein neuer Absatz begonnen, während Shift-Enter einen Zeilenumbruch innerhalb des Absatzes einfügt.

Der einfache Editor ist besonders geeignet für kurze Texte, die nicht in großem Stil formatiert oder gegliedert werden sollen, sondern als kurze Fragmente in ein größeres Dokument (Einsendung bzw. Korrektur) eingebunden werden und für die lediglich Basisfunktionalitäten zur einfachen Hervorhebung / Betonung einzelner Wörter sowie ggf. die Eingabe von Stichpunkten gewünscht sind. Insbesondere für Korrektor-Kommentare im Rahmen der In-Browser-Korrektur (vgl. nachfolgenden Kapitel) bietet sich der einfache Modus an.

Erweiterter Editor

Als anderes Extrem neben dem einfachen Editor steht ein erweiterter Editor zur Verfügung, der viele zusätzliche Möglichkeiten der Zeichenformatierung (z.B. Schriftfarben) und erweiterte Funktionen (z.B. Suchen und Ersetzen, Drucken, Vollbild, Sonderzeichenpalette, Tabellen u.v.m.) bietet:

Abb. 2-2: Erweiterter Editor ohne optionale Funktionen
Abb. 2-2: Erweiterter Editor ohne optionale Funktionen

Der erweiterte Editor ist insbesondere durch die Vollbildansicht und Funktionen wie Suchen und Ersetzen bereits für größere „Dokumente“ ausgelegt. Falls es gewünscht wird, dass der Nutzer (Student bzw. Korrektor) die Möglichkeit haben soll, seinen Text durch Überschriften verschiedener Ordnung zu strukturieren, kann optional eine Auswahl entsprechender Absatzformate aktiviert werden. Unabhängig davon ist es auch möglich, die Auswahl einer Schriftart oder einer Schriftgröße zu erlauben1. Man sollte sich aber überlegen, ob das wirklich sinnvoll ist, oder ob z.B. unnötiger Einsatz von Schriftarten und Schriftgrößen in gewissen studentischen Einsendungen nicht vielmehr die Les- und Korrigierbarkeit beeinträchtigen könnte.

Die nachfolgende Abbildung zeigt den erweiterten Editor mit allen drei optionalen Auswahlmöglichkeiten freigeschaltet. Weiterhin wurde in dieser Abbildung eine weitere Option des erweiterten Editors aktiviert, die eine Veränderung der Größe des Eingabefeldes durch den Benutzer erlaubt, indem er den dreieckigen Greifer in der rechten unteren Ecke mit der Maus verschiebt:

Abb. 2-3: Erweiterter Editor mit optionalen Format-Auswahlmöglichkeiten
Abb. 2-3: Erweiterter Editor mit optionalen Format-Auswahlmöglichkeiten

Der erweiterte Editor unterstützt insbesondere auch das Einfügen von Grafiken aus der Zwischenablage (ggf. nicht in jedem Browser). Diese Bilddaten werden nicht – wie normalerweise in Webseiten üblich – als Dateien hochgeladen und dann im Dokument „nur“ verlinkt, sondern werden direkt als Binärdaten2 mit in den HTML-Code eingefügt. Vorteil: Studenten können in mit erweitertem Editor ausgestatteten Texteingabefeldern irgendwo in ihrem Text Bilder einbetten, ohne dass Übungssystem oder Aufgabenautor bestimmte Vorkehrungen wie spezielle Dateiupload-Felder in der Aufgabe vorsehen müssten. Nachteile sind vor allem die Dateigröße (eine solche eingebettete Grafik benötigt innerhalb des HTML-Quelltextes etwa ein Drittel mehr Speicherplatz als in einer lokal gespeicherten Grafikdatei!) und die Einschränkung auf vom Browser darstellbare Grafikformate (i.W. JPEG, PNG und GIF – insbesondere können keine PDF-Grafiken eingebettet werden).

Wenn die Einsendung von Grafik- oder PDF-Dateien zu einer Aufgabe die Regel ist / erwartet wird, sollten Sie als Aufgabenautor dazu normalerweise besser ein Datei-Einsendefeld in der Aufgabe vorsehen und nicht auf diese Grafik-Einfügefunktion des Editors verweisen! Aber wenn Sie eigentlich nur Texteinsendungen erwarten, ein Student aber meint, seine Ausführungen besser anhand einer kleinen Grafik erläutern zu können, so hat er hierzu im erweiterten Editor standardmäßig die Möglichkeit. Sie können als Aufgabenautor aber auch für den erweiterten Editor die Möglichkeit, Bilder einzubetten, ganz abschalten (siehe Einbindung).

„Kompakter“ Editor

Als Kompromiss-Lösung zwischen dem einfachen und dem erweiterten Editor bietet das Online-Übungssystem eine weitere Editor-Variante, die über den einfachen Editor hinausgeht und einen ausgewählten Teil der Funktionen des erweiterten Editors mitbringt, dabei jedoch mit einer einzigen Symbolleiste auskommt. Dieser „kompakte“ Editor ist für die Einbindung in Seiten gedacht, in denen viele Eingabefelder vorhanden sind und der erweiterte Editor „zu dick aufträgt“, der einfache Editor jedoch zu wenig Funktionalität bietet:

Abb. 2-4: Kompakter Editor
Abb. 2-4: Kompakter Editor

Einbindung in eine Aufgabenseite oder Korrektur

Assistentengestützte Einbindung

Falls Sie die Aufgabe mit einem Assistenten des Online-Übungssystems erzeugen, fügen Sie Ihrer handbewerteten Aufgabe einfach ein „Freitext-Eingabebox“-Element hinzu und stellen Sie ein, ob und ggf. welchen Editortyp Sie verwenden wollen:

Abb. 2-5: Einbinden mit HB-Aufgabenerstellungsassistent
Abb. 2-5: Einbinden mit HB-Aufgabenerstellungsassistent

Manuelle Einbindung in HTML-Code

Zur Einbindung des Editors in einer der oben abgebildeten Varianten ist lediglich das Einfügen einer kurzen HTML-Kommentar-Zeile in das jeweilige HTML-Dokument (Aufgabenseite bzw. Korrekturseite) nötig, wahlweise im HEAD oder im BODY-Bereich des Dokuments.

Zur Einbindung des einfachen Editors genügt der Kommentar <!-- WYSIWYG -->. Dieser bewirkt, dass zur Laufzeit – sofern JavaScript im Browser aktiviert ist – jede Textarea der Seite durch einen einfachen HTML-Editor wie in Abbildung 2-1 gezeigt ersetzt wird.

Zur Einbindung des kompakten Editors dient der Kommentar <!-- WYSIWYG kompakt -->.

Zur Einbindung des erweiterten Editors ist dem Kommentar das Wort erweitert hinzuzufügen. Die optionalen Format-Auswahllisten des erweiterten Editors werden durch Hinzufügen der Wörter Absatzformate, Schriftarten und/oder Schriftgroessen aktiviert.
<!-- WYSIWYG erweitert --> erzeugt also z.B. den erweiterten Editor ganz ohne Zusätze, während <!-- WYSIWYG erweitert Absatzformate Schriftarten --> den erweiterten Editor mit Absatzformat-Auswahl und Schriftart-Auswahl, jedoch ohne Möglichkeit zur Schriftgrößenmodifikation einbindet.

Um den Greifer zur Größenänderung der Eingabebox zu aktivieren, ist weiterhin das Wort groessenaenderung zum Kommentar hinzuzufügen3.

Falls Sie das im erweiterten Editor standardmäßig erlaubte Einfügen von Bildern aus der Zwischenablage (Bilder eingebettet in HTML-Code, Base64-kodiert, siehe Abschnitt Editor-Typen) nicht erlauben wollen, fügen Sie dem Kommentar zusätzlich das Wort keinebilder hinzu4.

Das Einbinden eines solchen Kommentars bewirkt, dass der jeweilige Editor identisch auf jede Textarea der geladenen Seite angewendet wird. Ist das nicht gewünscht, d.h. möchten Sie den Editor nur auf bestimmte Textareas anwenden oder gar verschiedene Editoren für verschiedene Textareas laden, lesen Sie die folgenden Unterabschnitte.

Beschränken des Editors auf bestimmte Eingabeboxen

Falls nicht alle Textareas der Seite mit einem WYSIWYG-Editor ausgestattet werden sollen, markieren Sie jede mit WYSIWYG-Editor auszustattende Textarea, indem Sie das Attribut class="WYSIWYG" zum Textarea-Tag hinzufügen, und geben Sie im oben beschriebenen Kommentar zusätzlich das Wort class mit an. Alternativ können Sie auch andere Klassennamen verwenden, indem Sie class="irgendwas" sowohl zum WYSIWYG-Kommentar als auch zu jeder mit dem Editor auszustattenden Textarea hinzufügen.

Falls Sie den erweiterten Editor mit aktivierter Option zur Größenänderung verwenden, haben Sie an dieser Stelle noch eine besondere Option: Fügen Sie sowohl dem Class-Attribut der Textarea selbst als auch der class-Angabe im Kommentar das Wort fullwidth hinzu (z.B. class="area51 fullwidth"), so wird die Größenänderungsmöglichkeit durch den Benutzer auf die Höhe beschränkt, der Editor passt sich aber weiterhin automatisch an die Seitenbreite an5.

Laden verschieden konfigurierter Editoren für bestimmte Eingabeboxen

Falls Sie unterschiedliche Editor-Konfigurationen für verschiedene Textareas einer Seite laden möchten, fügen Sie mehrere WYSIWYG-Kommentare hintereinander in die Seite ein, einen für jede zu verwendende Editor-Konfiguration. Geben Sie in jedem der Kommentare den Zusatz class="Name" an, wobei Sie für jeden Kommentar einen anderen Namen in die Anführungszeichen einsetzen. Dieser Name identifiziert Ihre jeweilige Editor-Konfiguration. Fügen Sie nun zum öffnenden Tag jeder Textarea, die mit einem WYSIWYG-Editor ausgestattet werden sollen, dasselbe class-Attribut hinzu wie in dem jeweiligen WYSIWYG-Kommentar.

Ein Beispiel:

<html>
<head>
…
<!-- WYSIWYG class="einfacherEditor" -->
<!-- WYSIWYG erweitert absatzformate class="erweiterterEditor fullwidth"-->
</head>
<body>
	…
	<textarea class="einfacherEditor">Diese Box nutzt den einfachen Editor</textarea>
	<textarea class="erweiterterEditor fullwidth">Diese Box nutzt den erweiterten Editor mit Absatzformatauswahl.</textarea>
	<textarea>Diese Box nutzt gar keinen WYSIWYG-Editor.</textarea>
	…
</body>
</html>

Erzwingen des älteren Editors (TinyMCE 3)

Seit April 2014 wird ein neuerer Editor (TinyMCE 4) eingesetzt, der in vielerlei Hinsicht eine Verbesserung darstellt (z.B. bessere Darstellung auf hochauflösenden Displays, neues Plugin für Programmtext-Einfügung, Pulldown-Menüs im erweiterten Modus an Stelle von mehreren „vollgestopften“ Symbolleisten).

Falls Sie aber schon vor dieser Umstellung den Editor benutzt hatten und mit dem alten zufriedener waren, Ihnen die Umstellung auf TinyMCE 4 also nicht gefällt oder damit unerwartete Probleme auftreten, können Sie in Ihren Seiten die Nutzung des alten TinyMCE-3-Editors erzwingen. Fügen Sie dazu – zusätzlich zu den oben beschriebenen Kommentaren zur Editor-Konfiguration – einen weiteren Kommentar in den Seitenkopf ein:

<!-- WYSIWYG-EDITOR tinymce3 -->

Anpassung von Quittungs- und Korrekturseiten

Falls in einer Aufgabenseite ein HTML-Editor für studentische Eingaben eingebunden wurde, sind auch noch die Quittungs- und Korrekturseiten entsprechend anzupassen, so dass die HTML-Eingaben der Studenten auch korrekt formatiert dargestellt werden. Zu diesem Zweck sind folgende Punkte zu beachten:


In-Browser-Korrektur

Wie bereits in der Einleitung beschrieben, ist die In-Browser-Korrektur ein alternatives Korrekturverfahren, bei dem eine Korrekturkraft direkt im Browser korrigiert. Sie als Aufgabenautor müssen dazu zunächst in den Korrekturschablonen Eingabemöglichkeiten für Korrekturkräfte vorsehen. Ein Korrektor bekommt dann bei Auswahl einer zu korrigierenden Einsendung nicht mehr die „nackte“ Korrekturseite zum Laden und Bearbeiten in einem externen HTML-Editor angezeigt, sondern die ihm angezeigte Korrekturseite enthält die von Ihnen vorgesehenen Eingabefelder sowie einen Button zum Speichern der Korrektur. Nach dem Speichern erhält der Korrektor eine Vorschau auf die Korrektur, wie der Student sie nach Freigabe sehen wird: An Stelle der Eingabefelder werden hier die Korrektoreingaben direkt (und automatisch hervorgehoben) angezeigt.

Abb. 3-1: In-Browser-Korrektur
Abb. 3-1: In-Browser-Korrektur

Obige Abbildung zeigt exemplarisch die Ansicht des Korrektors (mit Eingabeboxen) und die Ansicht der fertigen Korrektur, wie der Student sie sehen wird.

Die In-Browser-Korrektor bietet Ihnen drei verschiedene Arten von Eingabemöglichkeiten für Korrektoren an (i.F. als „In-Browser-Korrektur-Elemente“ bezeichnet), die Sie in der Korrekturschablone vorsehen können:

Abb. 3-2: Übersicht der In-Browser-Korrektur-Elemente
Abb. 3-2: Übersicht der In-Browser-Korrektur-Elemente
  1. Ein KorrektorKommentar dient zur Aufnahme eines aus einem oder mehreren Absätzen bestehenden Textes. In der Korrektoransicht wird hierzu eine Textbox dargestellt, die wahlweise mit einem der im vorigen Kapitel beschriebenen HTML-WYSIWYG-Editoren ausgestattet werden kann. In der Studentenansicht wird der Kommentar als optisch hervorgehobener Block dargestellt.
  2. Ein KorrektorKommentarInline dient zur Aufnahme eines kurzen Klartext-Kommentars, der insbesondere nicht aus Absätzen besteht und in der Korrektur innerhalb einer bestehenden Zeile eingefügt werden kann, also kein HTML-Block-Element bildet. In der Korrektoransicht wird hierzu eine einfache Texteingabezeile dargestellt. In der Studentenansicht wird der Kommentar als Inline-Element in den umgebenden Text eingefügt.
  3. Ein KorrektorCheck dient zur Aufnahme einer „Richtig-oder-Falsch-Kennzeichnung“. Dem Korrektor werden hierzu zwei Radiobuttons „Richtig“ und „Falsch“ angezeigt, und er kann nach Durchsicht des Teils der Einsendung, auf die sich dieser KorrektorCheck bezieht, markieren, ob die Lösung korrekt ist oder nicht. So lange er keinen von beiden Radiobuttons markiert hat, gilt die Antwort als unkorrigiert.
    Die Beschriftungen „Richtig“ bzw. „Falsch“ der Radiobuttons können Sie als Aufgabenautor beliebig austauschen. Außerdem können Sie einem KorrektorCheck Punkte zuordnen. Wird dann eine Korrektur gespeichert, so wird die Summe der Punkte aller in der Korrektur als richtig markierten KorrektorChecks automatisch als erreichte Gesamtpunktzahl für die Korrektur eingetragen. Auch wird beim Speichern einer Korrektur ihr Status ggf. automatisch von „unkorrigiert“ oder „vorläufig korrigiert“ auf „korrigiert“ gesetzt, falls alle vorkommenden KorrektorChecks ausgefüllt wurden und mindestens einem auch Punkte zugeordnet sind. In allen anderen Fällen (insb. wenn die Korrekturschablone keine KorrektorChecks enthält, wenn keinem KorrektorCheck Punkte zugeordnet sind oder wenn der Korrektor nicht alle KorrektorChecks ausgefüllt hat) wird der Korrekturstatus ggf. von „unkorrigiert“ auf „vorläufig korrigiert“ gesetzt.
    Dem Studenten wird an der Stelle des KorrektorChecks im Normalfall je nach Markierung des Korrektors das Wort „Richtig“ oder „Falsch“ angezeigt, bzw. der jeweilige vom Aufgabenautor definierte Alternativtext. Sind dem KorrektorCheck Punkte zugeordnet, wird bei richtiger Antwort in der Regel auch die mit dieser richtigen Antwort erreichte Punktzahl hinter dem Wort „Richtig“ angezeigt, z.B.: „Richtig (5 Punkte)“.
    Sowohl die Anzeige der Punkte als auch die Anzeige von „Richtig“ oder „Falsch“ lässt sich auch abschalten. So ist es insbesondere möglich, die KorrektorChecks nur dem Korrektor anzuzeigen, um die Punktzahl zu berechnen, ohne dass der Student diese zu sehen bekommt.

In den folgenden Abschnitten wird die Einbindung/Konfiguration der In-Browser-Korrektur-Elemente bei der Aufgabenerstellung beschrieben.

Assistentengestützte Einbindung

Im Aufgabenerstellungsassistenten des Online-Übungssystems für handbewertete Aufgaben können Sie am Fuße der Seite unter „Korrekturmodus“ die In-Browser-Korrektur aktivieren. Damit wird bereits eine KorrektorKommentar-Box am Ende der Korrekturseite eingefügt. Weitere Elemente können Sie einzeln hinzufügen:

Der folgende Screenshot zeigt die typsichen Elemente zur In-Browser-Korrektur im Aufgabenerstellungs-Assistenten:

Abb. 3-3: In-Browser-Korrektur-Elemente im Aufgabenerstellungsassistenten
Abb. 3-3: In-Browser-Korrektur-Elemente im Aufgabenerstellungsassistenten

Manuelle Einbindung in HTML-Code

KorrektorKommentar einbinden

Syntax

Um einen KorrektorKommentar in Ihre Korrekturschablone einzubinden, notieren Sie dort ein Element der folgenden Art:

Dabei ist jeweils # durch eine Nummer zu ersetzen, die den KorrektorKommentar eindeutig identifiziert (also nicht bereits für einen anderen KorrektorKommentar verwendet wurde).

An der Stelle Attribute können Sie optional Attribute für das HTML-Textarea-Tag angeben: Alle Attribute, die Sie hier einfügen, werden in der Korrektoransicht 1:1 ins HTML-Tag übernommen. Insbesondere können Sie durch Angabe der Attribute cols und rows die Größe für die Textarea festlegen. Geben Sie diese Attribute nicht an, bekommt die Textarea eine vom Online-Übungssystem (nicht vom Browser) festgesetzte Defaultgröße. Neben cols und rows sind alle Attribute erlaubt, die fürs Textarea-Tag erlaubt sind, mit Ausnahme des Attributs name, das vom Online-Übungssystem vergeben wird!

Hinweis: Wenn Sie den KorrektorKommentar mit einem WYSIWYG-Editor kombinieren, wird (zumindest seit TinyMCE Version 4) der Editor sich in der Breite immer an die Seitenbreite anpassen, eine cols-Angabe also ignoriert. Aber für Plaintext-Eingabefelder ist die Angabe ggf. sinnvoll.

Falls Sie die Textbox für den Korrektor bereits mit einem Inhalt vorfüllen möchten, den dieser später ersetzen bzw. bearbeiten kann, dann geben Sie diesen wie oben gezeigt zwischen einem öffnenden und einem schließenden KorrektorKommentar#-Tag an. Andernfalls ist die Kurzschreibweise mit atomarem Element möglich.

HTML-Kontext

Ein KorrektorKommentar-Element wird in der Studentenansicht durch ein div-Element ersetzt. Es darf daher nur an Stellen im HTML-Code der Schablone notiert werden, an denen nach HTML-Standard auch div-Elemente stehen dürfen.

Typischerweise wird ein KorrektorKommentar direkt als „Body Text“ notiert, also als direktes Kind des Body-Elements. Insbesondere nicht erlaubt ist die Positionierung innerhalb eines Absatzes oder z.B. eines pre-Elements für vorformatierten Text! (Falls Sie die Korrekturschablone mit dem SeaMonkey Composer im WYSIWYG-Modus bearbeiten, achten Sie darauf, dass in der Auswahlbox oben links das Absatzformat „Body Text“ eingestellt ist (vgl. obige Abbildung).

Sollen alle KorrektorKommentare in der Korrekturseite mit einem WYSIWYG-Editor ausgestattet werden, binden Sie außerdem in der Korrekturseite noch den entsprechenden Kommentar ein (vgl. obiges Kapitel zu WYSIWYG-Editoren).

Beispiele

Der folgende Beispiel-Ausschnitt zeigt die Einbindung eines Korrektorkommentars mit expliziter Angabe der Textbox-Größe (10 Zeilen à 100 Zeichen) und vorgefüllt mit Text für einen abschließenden Korrektor-Kommentar vor der Angabe der erreichten Punkte am Ende der Korrekturseite:

<h3>Anmerkungen</h3>
[KorrektorKommentar3 cols="100" rows="10"]{hier bitte zus&auml;tzl. Anmerkungen eintragen}[/KorrektorKommentar3]
<h3>Erreichte Punktzahl: $KorrekturPunkte von $MaximalPunkte</h3>

Dasselbe Beispiel noch einmal, nur ohne explizite Größenangabe und ohne vorgefüllten Inhalt:

<h3>Anmerkungen</h3>
[KorrektorKommentar3 /]
<h3>Erreichte Punktzahl: $KorrekturPunkte von $MaximalPunkte</h3>

KorrektorKommentarInline einbinden

Syntax

Die Syntax ist praktisch identisch zu der Einbindung eines KorrektorKommentars:

Dabei ist wieder jeweils # durch eine Nummer zu ersetzen, die den KorrektorKommentarInline eindeutig identifiziert.

Attribute werden 1:1 ins HTML-Input-Tag übernommen, d.h. hier dürfen alle Attribute angegeben werden, die in HTML-Input-Tags erlaubt sind (mit Ausnahme der Attribute type, name und value). Insbesondere können Sie per size die Größe der Eingabezeile festlegen oder auch per maxlength (maximale Länge der Eingabe in Zeichen) dem Korrektor ein Limit für die Kommentarlänge setzen.

HTML-Kontext

Ein KorrektorKommentarInline-Element wird in der Studentenansicht durch ein Inline-Element (span) ersetzt. Es darf – anders als ein KorrektorKommentar – auch innerhalb von Absätzen oder vorformatiertem Text, Tabellen etc. vorkommen, überall, wo auch span-Elemente zulässig sind.

Beispiel

<p>Kommentar des Korrektors: [KorrektorKommentarInline1 size="70" /]</p>

KorrektorCheck einbinden

Syntax

Zur Einbindung eines KorrektorChecks in die Korrekturschablone notieren Sie ein Element mit folgendem Aufbau:

Dabei ist # wieder durch eine Nummer zu ersetzen, welche das KorrektorCheck-Element eindeutig identifiziert. Der schließende Slash (/) ist beim KorrektorCheck-Element optional (darf also entfallen) – anders als bei den KorrektorKommentar(Inline)-Elementen, bei denen, falls kein Slash vor der schließenden Klammer des öffnenden Tags steht, ein entsprechendes schließendes Tag am Ende des Vorgabetextes erwartet wird.

Die folgenden optionalen Attribute sind möglich:

Attribut Bedeutung
richtig Alternative Beschriftung an Stelle des Wortes „Richtig“.
Kann leer sein (richtig = "").
Falls das Attribut auf ‚-‘ endet, wird die Ausgabe der Punktzahl unterdrückt (s.u.). Das ‚-‘ selbst wird nicht mit ausgegeben.
falsch Alternative Beschriftung an Stelle des Wortes „Falsch“.
Kann leer sein (falsch = "").
punkte Zu vergebende Punktzahl bei richtiger Antwort.
Ordnen Sie damit Ihren KorrektorChecks Punkte zu, falls die Gesamtpunktzahl der Aufgabe sich als Summe der Teilpunkte für alle richtigen Antworten errechnen soll.
value Zulässige Werte (unabhängig von der mit richtig oder falsch festgelegten Beschriftung): „Richtig“ oder „Falsch“.
Hiermit wird ein (Vorgabe-)Wert festgelegt. Im Normalfall ist von der Angabe dieses Attributs in Korrekturschablonen abzuraten, denn nur, wenn alle KorrektorChecks zu Beginn unausgefüllt sind (also kein value-Attribut besitzen), kann der Korrektor erkennen, welche er schon bearbeitet (ausgefüllt) hat und welche nicht.

Der folgende Unterabschnitt geht noch genauer auf den Einsatz dieser Attribute ein:

Beschriftungen der KorrektorChecks

Die Standardbeschriftungen lauten „Richtig“ bzw. „Falsch“, können aber durch Angabe der oben genannten Attribute richtig bzw. falsch angepasst werden. Die Beschriftung „Super!“ bei richtiger Antwort z.B. legt man demnach durch Angabe des Attributs richtig="Super!" fest. Im Normalfall stimmen die Beschriftungen der Radiobuttons in der Korrektorsicht und die je nach markiertem Radiobutton dem Studenten angezeigten Werte überein, d.h. wenn der Korrektor den Radiobutton mit der Beschriftung „Super!“ selektiert, wird auch dem Studenten der Text „Super!“ in seiner Korrektur angezeigt. Eine Ausnahme liegt vor, falls Sie „leere Beschriftungen“ festlegen (z.B. falsch=""). Dann wird dem Studenten kein Text angezeigt, die entsprechende Checkbox für den Korrektor trägt dann wieder die Default-Beschriftung („Richtig“ bzw. „Falsch“).

Falls das Attribut punkte angegeben und somit eine erreichbare Punktzahl festgelegt wurde, wird in der dem Studenten angezeigten Korrektur im Falle einer richtigen Antwort hinter dem Wort „Richtig“ bzw. der festgelegten Alternativbeschriftung auch noch in Klammern die Punktzahl angezeigt, z.B.: „Richtig (5 Punkte)“. Bei Angabe von richtig="" und Angabe des punkte-Attributs wird dem Studenten bei richtiger Antwort nur die Punktzahl in Klammern angezeigt, z.B. „(5 Punkte)“.

Sollen die den KorrektorChecks zugeordneten Punkte zwar intern zur Berechnung des Gesamtergebnisses der Aufgabe herangezogen, für die Studenten jedoch nicht sichtbar sein, so legen Sie per Attribut richtig eine Beschriftung für richtige Antworten fest und hängen Sie dieser Beschriftung ein ‚-‘ an, z.B. richtig="Richtig-" (zur Ausgabe nur des Wortes „Richtig“ ohne Punktzahl) oder richtig="-" (falls gar nichts angezeigt werden soll, weder eine Beschriftung noch die erreichte Punktzahl). (Bei falschen Antworten entfällt diese Sonderregelung mit dem ‚-‘-Suffix, da dort ohnehin niemals eine Punktzahl angezeigt wird.)

HTML-Kontext

Analog zu einem KorrektorKommentarInline wird ein KorrektorCheck als Inline-Element (span) in den HTML-Code eingebunden und darf daher überall vorkommen, wo span-Elemente erlaubt sind, insbesondere innerhalb von Absätzen oder auch Überschriften.

Beispiele

Die einfachste Variante ist ein KorrektorCheck ohne Attribute, das folgende Beispiel zeigt dessen Einbindung in die Überschrift zu einer Teilaufgabe:

<h4>Teil a) [KorrektorCheck1 /]</h4><pre>$FeldA1P</pre>

Dem Korrektor werden hier (hinter der Überschrift „Teil a)“) zwei Radiobuttons (beschriftet mit „Richtig“ und „Falsch“) angezeigt, der Student sieht je nach vom Korrektor markiertem Radiobutton das Wort „Richtig“ bzw. „Falsch“ (bzw. gar nichts, falls der Korrektor keinen der beiden Radiobuttons markiert hat). Da keine Punkte zugeordnet sind, wird dieser KorrektorCheck nicht zur Berechnung der Gesamtpunktzahl herangezogen.

Die folgenden Beispiele zeigen nur noch Varianten des KorrektorCheck-Elements selbst, ohne umgebenden HTML-Text.

[KorrektorCheck2 punkte="10" /]

Abweichend vom ersten Beispiel ist diesem KorrektorCheck eine Punktzahl zugeordnet. Bei richtiger Antwort wird dem Studenten „Richtig (10 Punkte)“ (statt nur „Richtig“) angezeigt, weiterhin bekommt der Student automatisch 10 Punkte für diese Teilaufgabe vergeben. (Die insgesamt vergebene Punktzahl ist die Summe der Punkte aller als richtig markierten KorrektorChecks.)

[KorrektorCheck3 richtig="Ja" falsch="Nein" /]

Dieses Beispiel definiert einen KorrektorCheck, dessen Radiobuttons für den Korrektor mit „Ja“ und „Nein“ beschriftet sind, und auch dem Studenten wird „Ja“ bzw. „Nein“ angezeigt. Da keine Punkte zugeordnet sind, wird dieser KorrektorCheck nicht zur Berechnung der Gesamtpunktzahl herangezogen.

[KorrektorCheck4 punkte="10" richtig="Ja-" falsch="Nein" /]

Hier bekommt der Student bei richtiger Antwort 10 Punkte. Da das richtig-Attribut auf einem ‚-‘ endet, wird ihm bei richtiger Antwort nur „Ja“ (und nicht „Ja (10 Punkte)“) angezeigt.

[KorrektorCheck5 punkte="10" richtig="" falsch="" /]

In diesem Beispiel sieht der Korrektor zwei Radiobuttons mit den Beschriftungen „Richtig“ und „Falsch“. Der Student dagegen bekommt bei falscher Antwort gar nichts, bei richtiger Antwort die Punktzahl „(10 Punkte)“ angezeigt.

[KorrektorCheck6 punkte="10" richtig="-" falsch="" /]

Auch in diesem Beispiel sieht der Korrektor zwei Radiobuttons mit den Beschriftungen „Richtig“ und „Falsch“, für den Studenten jedoch bleibt der KorrektorCheck vollständig unsichtbar.

Button zum Speichern der Korrektur verändern

Das Online-Übungssystem bindet in der Korrektoransicht einen Button zum Speichern der Korrektur am Ende des HTML-Bodys ein (vgl. z.B. Abbildung 3-1). Dies geschieht vollautomatisch und bedarf keiner Konfiguration von Ihrer Seite.

Falls Sie aber z.B. ein Webdesign für die Korrekturseite verwenden, in dem Sie selbst die Position des Buttons festlegen möchten, den Button vielleicht auch mehrfach an verschiedenen Positionen (z.B. einmal über und einmal unter der Korrektur) einbinden möchten oder falls Sie Formatierungen am Button vornehmen möchten, können Sie optional ein Element KorrektorSubmit in die Korrekturschablone aufnehmen.

In der nach dem Speichern einer Korrektur angezeigten Vorschau wird jeweils an Stelle des Speichern-Knopfes ein Link zum Neu-Laden angezeigt. Auch dessen Position wird durch das KorrektorSubmit-Element festgelegt.

Syntax

Das Element darf mehrfach im Quelltext vorkommen. Es ist keine identifizierende Nummer (wie bei den anderen Tags) anzugeben. Der abschließende Slash ‚/‘ ist optional (wie beim KorrektorCheck auch).

Attribute werden 1:1 in HTML-Input-Tag übernommen. Es dürfen alle Attribute angegeben werden, die in HTML-Input-Tags des Typs „submit“ erlaubt sind – mit folgenden Ausnahmen: type und value. Letztere werden bereits vom Online-Übungssystem gesetzt. (Beim Link in der Vorschau werden die Attribute ignoriert.)

HTML-Kontext

Das KorrektorSubmit-Element wird direkt durch ein HTML-input-Element (bzw. in der Vorschau durch einen Link, also ein a-Element) ersetzt. Es darf überall im HTML-Code eingebunden werden, wo Formularelemente und Links erlaubt sind. (Sie können voraussetzen, dass der gesamte Inhalt der Korrekturseite ein HTML-Formular ist. Die form-Tags werden vom Online-Übungssystem automatisch direkt nach <body> bzw. vor </body> in die Korrekturseite eingefügt.)

Korrekturansicht für Betreuer

Ein Kursbetreuer kann wie gehabt in der Einsendungs- und Korrekturübersicht die Korrekturen der Studenten einsehen. Er bekommt dabei die Korrektur genauso angezeigt, wie auch der Student sie sehen wird.

Speziell für Betreuer besteht zusätzlich die Möglichkeit, die gespeicherte Korrektur in ihrer Rohform einzusehen, also ohne Aufbereitung durch z.B. Ersetzen von Variablen oder optische Aufbereitung der In-Browser-Korrektur-Elemente.

Um diese Rohansicht zu erreichen, kann der Betreuer zunächst eine Korrektur wie gewohnt öffnen und dann in der URL-Zeile seines Browsers hinter dem Servicenamen „KorrekturAccess“ den Zusatz „Roh“ einfügen. Die resultierende URL sieht dann z.B. folgendermaßen aus:
https://Servername/vus/KorrekturAccessRoh/01614/SS11/2/5/7777777/

CSS-Anpassung

Die Darstellung von In-Browser-Korrektur-Elementen wird durch eine zentrale CSS-Datei bestimmt. Sie können selbst diese Darstellung modifizieren, indem Sie eigene CSS-Regeln definieren, die die Voreinstellungen überstimmen. Dazu können Sie eine eigene CSS-Datei als Kursressource hochladen und in Ihre Korrekturschablonen einbinden, oder – wenn es sich um aufgabenspezifische Formatierungen handelt – direkt in der Korrekturschablone CSS-Code einfügen (vgl. das Beispiel im nachfolgenden Unterabschnitt Bearbeitung einer Einsendung im KorrektorKommentar).

Die globalen CSS-Vorgaben, können Sie unter folgender URL einsehen:
https://online-uebungssystem.fernuni-hagen.de/stylesheets/inBrowserKorrektur.css

Die vom Online-Übungssystem zur Darstellung der In-Browser-Korrektur-Elemente in der Studentensicht der Korrektur generierten HTML-Elemente können Sie zur Formatierung in CSS wie folgt adressieren:

Korrektor-Element HTML-Element CSS-Klasse ID
[KorrektorKommentar#] div KorrektorKommentar KorrektorKommentar#
[KorrektorKommentarInline#] span KorrektorKommentar KorrektorKommentarInline#
[KorrektorCheck#] span KorrektorCheckRichtig bzw.
KorrektorCheckFalsch
KorrektorCheck#

Dabei ist wieder jeweils # durch eine konkrete Nummer zu ersetzen.

Beispiele

Submit-Button

Falls Sie am „Korrektur speichern“-Knopf CSS-Formatierungen vornehmen möchten, fügen Sie ein KorrektorSubmit-Element (siehe oben) ein. In diesem können Sie z.B. per style-Attribut Formatierungen vornehmen oder per class-Attribut eine selbst gewählte CSS-Klasse zuordnen.

Bearbeitung einer Einsendung im KorrektorKommentar

Primär ist die In-Browser-Korrektur darauf ausgelegt, dass die Eingaben des Studenten und des Korrektors streng getrennt sind, d.h. der Korrektor sieht die Einsendung des Studenten, kann sie aber nicht modifizieren. Statt dessen kann er an vorgesehenen Stellen in der Korrekturseite seine Kommentare einfügen.

Die herkömmliche Korrektur, bei der ein Korrektor die gesamte Korrekturseite in einem HTML-Editor öffnet, bietet dem Korrektor dagegen mehr Freiheiten, z.B. kann er an beliebigen Stellen in der studentischen Eingabe eigene Anmerkungen einfügen, vorzugsweise in roter Schrift. Er kann auch z.B. Teile der studentischen Einsendung, auf die er Bezug nimmt, hervorheben oder durchstreichen. Beispielsweise bei der Korrektur von Programmieraufgaben ist es praktisch, direkt an den fehlerhaften Stellen im Quellcode des Studenten Korrekturen anbringen zu können und die Fehlerstelle nicht in einem nachfolgenden Kommentar beschreiben zu müssen.

Ein solches Szenario lässt sich auch mit der In-Browser-Korrektur umsetzen. Wie in KorrektorKommentar einbinden beschrieben, kann man für ein KorrektorKommentar-Element einen Inhalt festlegen, und das kann durchaus auch die studentische Einsendung sein.

Das folgende Beispiel stellt eine mögliche Korrekturschablone für eine Programmieraufgabe mit der Möglichkeit zur Korrektur direkt innerhalb des eingesendeten Quelltexts dar:

<html>
<head>
	<meta http-equiv="content-type" content="text/html; charset=ISO-8859-1">
	<title>Einsendung zu "$Kursname", Aufgabenheft $AufgabenheftNr,
		$Aufgabenname</title>
	<style type="text/css">
		#KorrektorKommentar1 {border:none; color:black}
	</style>
	<!-- WYSIWYG erweitert schriftarten groessenaenderung -->
</head>
<body>
	<h1>Einsendung zu "$Kursname", Aufgabenheft $AufgabenheftNr,
		$Aufgabenname</h1>
	<p>von $Vorname $Nachname</p>
	<p>Korrektor: $Korrektor</p>
	<p>Datum: $KorrekturDatum</p>
	<hr>
	<h2>Aufgabe 8 )</h2>
	<h3>Eingabe in Feld 1:</h3>
	[KorrektorKommentar1 rows="35" cols="100"]<pre><code class="language-pascal">$FeldA1P</code></pre>[/KorrektorKommentar1]
	<hr>
	<h3>Anmerkungen</h3>
	[KorrektorKommentar2]{zus&auml;tzl. Anmerkungen}[/KorrektorKommentar2]
	<h3>Erreichte Punktzahl: $KorrekturPunkte von $MaximalPunkte</h3>
	<hr>
</body>
</html>

Folgende Besonderheiten sind hierbei zu beachten:

  1. Unter der Annahme, dass die studentische Einsendung ein Programmquelltext ist, der in einer einfachen Textbox (ohne WYSIWYG-Editor) eingegeben wurde, und dessen Zeilenumbrüche ebenso wie Leerzeichenfolgen (insb. am Zeilenbeginn) unbedingt erhalten bleiben müssen, wird die Variable $FeldA1P in ein Element für vorformatierten Text (pre) eingebunden. Sie trägt das Suffix P, da die studentische Einsendung selbst keinen HTML-Text, sondern Plaintext enthält und alle darin enthaltenen ‚<‘- und ‚>‘-Zeichen nicht als HTML-Tagklammern, sondern als Text interpretiert werden sollen.
  2. Um den Inhalt des Pre-Elements nicht nur als beliebigen vorformatierten Text auszuzeichnen, sondern als Programm-Quellcode, der vom Übungssystem (in der normalen Anzeige, nicht im WYSIWYG-Editor selbst) automatisch mit Syntax-Hervorhebungen versehen werden soll, wird dieser zusätzlich in ein Code-Element verpackt. Außerdem wird hier die Programmiersprache Pascal explizit per Class-Attribut ausgezeichnet (optional, ohne solche Angabe erfolgt beim Syntax-Highlighting eine automatische Spracherkennung).6
  3. Das komplette Pre-Element mit der studentischen Einsendung wird als Inhalt in eine große Eingabebox (KorrektorKommentar1) eingebunden.
  4. Damit der Korrektor nun dort innerhalb des vorformatierten Texts seine eigenen Kommentare einfügen kann, wird für ihn ein HTML-Editor eingebunden (siehe Kommentar im Kopf), und zwar der erweiterte Editor, um dem Korrektor zu ermöglichen, seine Bearbeitungen optisch (z.B. durch rote Farbe) von den studentischen Eingaben abzugrenzen.
  5. Die Absatzformat-Auswahl des erweiterten Editors wurde absichtlich nicht aktiviert. Der gesamte vorformatierte Text, also die gesamte studentische Eingabe, wird vom Editor TinyMCE als zusammenhängender Absatz behandelt, und auch die Enter-Taste fügt innerhalb vorformatierten Textes nur Zeilenumbrüche ein und keine neuen Absätze. Die Absatzformat-Auswahl würde daher stets das Absatzformat für den gesamten Text (und nicht nur für Einfügungen des Korrektors) verstellen – was wiederum zum Verlust der Einrückungen und Zeilenumbrüche der studentischen Eingabe führen würde!
    Das Absatzformat darf also nicht verstellbar sein. Statt dessen wird dem Korrektor eine Schriftartauswahl angeboten, so dass er seine Kommentare innerhalb des vorformatierten Textes nicht nur durch rote Schriftfarbe, sondern auch durch Zuweisung einer anderen Schriftart von der studentischen Einsendung abgrenzen kann.
  6. Da normalerweise der gesamte KorrektorKommentar in roter Schrift angezeigt wird – hier also auch die studentische Einsendung, was unpassend wäre –, wurde direkt im Kopf der Seite ein CSS-Code zur Überstimmung dieser Regel durch Festlegung schwarzer Schriftfarbe für KorrektorKommentar1 eingefügt (vgl. Abschnitt CSS-Anpassung). Auch der Rahmen um den leicht schattierten Hintergrund des Korrekturkommentars wird dort abgeschaltet.
    Der Korrektor muss bei dieser Art der Korrektur seine Eingaben wieder manuell hervorheben.
Abb. 3-4: Bearbeitung einer Einsendung im Korrektorkommentar
Abb. 3-4: Bearbeitung einer Einsendung im Korrektorkommentar

Obige Abbildung zeigt exemplarisch die In-Browser-Korrektur für obiges Beispiel: Der Korrektor hat einen Kommentar am Ende der zweiten Programmzeile des Studenten angefügt und diese rot eingefärbt sowie die Schriftart „Comic Sans“ gewählt. Ebenfalls in der Abbildung dargestellt ist die Ansicht der Korrektur für den Studenten.

Wichtige Hinweise:

In-Browser-Korrektur und Offline-Korrektur

Die In-Browser-Korrektur ist ausschließlich bei Online-Korrektur verfügbar und nicht mit dem Offline-Korrekturassistenten kompatibel!

Sollte ein Korrektor sich die ihm zugeteilten Korrekturen mit dem Korrekturassistenten herunterladen, kann er sie dennoch korrigieren, jedoch nicht im Browser, sondern auf die herkömmliche Art mit externem HTML-Editor7. Er wird dann in der Korrektur den in der Aufgabenschablone zur Definition der In-Browser-Korrektur-Elemente verwendeten Markup-Code sehen, kann dort jedoch prinzipiell auch seine Kommentare hineinschreiben. Nachfolgende Abbildung zeigt beispielhaft die herkömmliche Offline-Korrektur für das Fallbeispiel aus Abschnitt „Bearbeitung einer Einsendung im KorrektorKommentar“.

Abb. 3-5: KorrektorKommentare bei Offline-Korrektur
Abb. 3-5: KorrektorKommentare bei Offline-Korrektur

So lange alle KorrektorKommentar-Elemente aus einem öffnenden und einem schließenden Tag bestehen (wie in obiger Abbildung), kann der Korrektor bei der Offline-Korrektur seine Anmerkungen ganz einfach direkt zwischen diese für ihn sichtbaren Tags schreiben, und die Korrektur wird später für den Studenten genauso aussehen, als sei sie mit In-Browser-Korrektur erstellt worden. Problematischer ist es, falls atomare Tags wie [KorrektorKommentar5 /] vorkommen. Hier müsste der Korrektor den Querstich aus dem Tag löschen, seinen Kommentar dahinter schreiben und selbst das schließende Tag [/KorrektorKommentar5] hinter seinen Kommentar setzen. Falls also die Offline-Korrektur unterstützt werden soll, ist es besser, wenn der Aufgabenautor statt atomarer Elemente stets ein öffnendes und ein schließendes Tag (mit leerem Inhalt dazwischen) in die Korrekturschablone einfügt, z.B.:
[KorrektorKommentar5][/KorrektorKommentar5].

Alternativ kann der Offline-Korrektor natürlich auch die KorrektorKommentar-Elemente ganz löschen und seine Anmerkungen in herkömmlicher Weise einfügen und selbst rot einfärben.

Sollten in der Korrekturschablone nicht nur KorrektorKommentare, sondern auch KorrektorChecks vorkommen, so kann ein Offline-Korrektor diese ggf. ausfüllen, indem er im KorrektorCheck-Tag das Attribut value einfügt und ihm den Wert "Richtig" bzw. "Falsch" zuweist. Das ist aber unkomfortabel und fehleranfällig, außerdem wird auch bei dieser Art der Korrektur keine automatische Berechnung der erreichten Gesamtpunktzahl (als Summe der Punkte aller richtigen KorrektorChecks) durchgeführt. Es empfiehlt sich, Korrekturen von KorrektorChecks ausschließlich in der Online-Korrektur durchzuführen.


Syntax-Highlighting und Quelltext-Einsendungen

Automatisches Syntax-Highlighting einbinden

Das Online-Übungssystem bindet ggf. automatisch einen JavaScript-basierten Syntax-Highlighter („highlight.js“) ein, der Schlüsselwörter, Kommentare, Literale etc. in Sourcecodes automatisch einfärbt, vgl. z.B. Abbildung 3-4.

Assistentengestützte Einbindung

Wenn Sie Ihre Aufgabenseite mit einem Aufgabenerstellungs-Assistenten des Online-Übungssystems erstellen, können Sie seit Mai 2014 die „Code einfügen/bearbeiten“-Funktion des WYSIWYG-Editors verwenden, um z.B. Quelltexte in Ihren Aufgabentext einzufügen. Details siehe im folgenden Abschnitt Studentische Einsendungen in WYSIWYG-HTML-Editoren.

Die Einbindung von Syntax-Highlighting für studentische Eingaben behandelt ein späterer Abschnitt.

Manuelle Einbindung in HTML-Quellcode

Die Einbindung des Syntax Highlighters erfolgt automatisch dann, wenn in einer Aufgaben- oder Musterlösungsseite (auch in einer Quittung oder Korrektur, siehe folgenden Abschnitt) ein Code-Block innerhalb eines Pre-Blocks gefunden wird, d.h. die einfachste Syntax zur Einbindung sieht wie folgt aus:

<pre><code>Der Quellcode</code></pre>

Bei dieser Schreibweise versucht der Syntax Highlighter heuristisch, die Sprache zu erraten und ein passendes Farbschema dazu auszuwählen. Alternativ kann auch eine Sprache explizit deklariert werden, z.B.:

<pre><code class="language-java">Java-Quellcode</code></pre>

Diese Darstellung ist konform zu den W3C-Empfehlungen für HTML 5. Pre-Blöcke ohne Code-Block werden ebenso wenig formatiert wie Code-Blöcke, die nicht innerhalb von Pre-Blöcken liegen.

Die folgende Tabelle gibt den derzeitigen Stand (subject to change) der unterstützten Sprachen und der dazu im class-Attribut zu notierenden Klasse wieder:

Sprache CSS-Klasse
AppleScript language-applescript
Backus-Naur-Form (BNF) language-bnf
Bash/shell language-bash
Brainfuck language-brainfuck
C++ language-cpp
C# language-cs
CoffeeScript language-coffeescript
CSS language-css
D language-d
Delphi / Pascal language-delphi
Erlang language-erlang
F# language-fsharp
Go language-go
Haml language-hall
Haskell language-haskell
HTML language-html
Java language-java
JavaScript language-js
JSON language-json
Lasso language-lasso
Less CSS language-less
Lisp language-lisp
LiveScript language-livescript
Lua language-lua
Markdown language-markdown
Mathematica language-mathematica
Matlab language-matlab
Objective-C language-objectivec
Perl language-perl
PHP language-php
Prolog language-prolog
Python language-python
R language-r
Ruby language-ruby
Scala language-scala
Scheme language-scheme
SCSS language-scss
Smalltalk language-smalltalk
SQL language-sql
TeX language-tex
VB.Net language-vbnet
VBScript language-vbscript
XML language-xml

Um für einen bestimmten Code-Block das automatische Syntax-Highlighting zu verhindern, verwenden Sie die Klasse no-highlight:

<pre><code class="no-highlight">Hier erfolgt kein Syntax Highlighting</code></pre>

Highlight-Stylesheet

Der Syntax Highlighter bietet eine ganze Reihe von Stylesheets (i.W. Farbschemata) zur Quelltextauszeichnung an. Das Übungssystem verwendet ein bestimmtes Schema als Default (derzeit das an Google Code angelehnte Schema, aber der Default könnte sich in Zukunft auch ändern).

Falls Sie selbst für Ihren Kurs ein ganz bestimmtes Schema einstellen möchten, finden Sie in den Kursparametern eine entsprechende Auswahlmöglichkeit. Diese wählt das Stylesheet global für alle Seiten Ihres Kurses.

Quelltexte in studentischen Einsendungen

Während Sie in Aufgabentexten oder Musterlösungen eigene Code-Fragmente problemlos wie oben beschrieben auszeichnen können, gibt es bei studentischen Code-Einsendungen verschiedene Dinge zu beachten. Im Wesentlichen haben Sie hier zwei Alternativen:

Studentische Einsendungen in Plaintext-Textareas

Dies ist normalerweise die empfohlene Art, Aufgabenformulare zur Codeeinsendung zu konfigurieren: Studenten bekommen eine Textarea für Plain-Text, d.h. nicht mit HTML-Editor ausgestattet, angezeigt und die gesamte Eingabe dieser Textarea soll als Quelltext interpretiert werden. (Dies ist insbesondere auch dann sinnvollste Eingabeart, wenn Sie ein eigenes Vorkorrekturmodul zur automatische Auswertung des eingegebenen Codes einsetzen möchten.)

Assistentengestützte Einbindung

Erstellen Sie Ihre Aufgaben mit dem Erstellungsassistenten für handbewertete Aufgaben, so fügen Sie Ihrer Aufgabe ein Element des Typs »Quelltext-Eingabebox« hinzu. Das erzeugt eine Textarea für Quelltext und konfiguriert die Darstellung in Quittungs- und Korrekturseite zur Verwendung von Syntax-Highlighting. Die Sprache können Sie direkt im Assistenten auswählen.

Fortgeschrittene Aufgabenerstellung

In diesem Fall ist die studentische Einsendung in Quittungs- und Korrekturseite typischerweise wie folgt einzubinden:

<pre><code class="language-java">$FeldA1P</code></pre>

(In diesem Beispiel ist natürlich das Class-Attribut auf die in der Aufgabe erwartete Sprache einzustellen – oder ganz wegzulassen – und die FeldNummer (hier A1) ggf. anzupassen, falls die einzufügende Eingabe nicht dem ersten Feld des Aufgabenformulars entnommen werden soll.)

Das P-Suffix am Feldnamen ist wichtig, damit der eingesendete Text nicht als HTML-, sondern als Plaintext interpretiert wird. Siehe auch das Beispiel und die Erläuterungen aus Abschnitt Bearbeitung einer Einsendung im KorrektorKommentar.

Studentische Einsendungen in WYSIWYG-HTML-Editoren

Falls Sie nicht eine einzelne Eingabebox nur für Code (und ggf. zusätzliche für Text/Erläuterungen) ins Aufgabenformular einbinden möchten, sondern den Studenten eine Eingabemöglichkeit bieten wollen, in der jeder Student eine beliebige Abfolge von Klartext-Absätzen und Quellcode, ggf. noch strukturiert durch Überschriften – sprich: ein Dokument mit ggf. Quelltext-Anteilen – eingeben können soll, dann verwenden Sie eine Textarea und kombinieren Sie diese mit einem WYSIWYG-Editor, wie im ersten Kapitel genauer beschrieben.

Im neuen TinyMCE-4-Editor steht Studenten zu diesem Zweck eine spezielle Funktion „Code einfügen/bearbeiten“ zur Auswahl. Damit können sie Quellcode z.B. aus einer IDE direkt einfügen und optional auch die jeweilige Programmiersprache auswählen – voreingestellt ist „Sprache automatisch erkennen“:

Abb. 4-1: Code-Insert-Funktion im WYSIWYG-Editor
Abb. 4-1: Code-Insert-Funktion im WYSIWYG-Editor

Die so eingefügten Code-Teile werden automatisch so ausgezeichnet, wie weiter oben in diesem Kapitel beschrieben, erhalten also auch automatisch das korrekte Syntax Highlighting. Wichtig ist lediglich, dass die $Feld-Variable – wie schon oben im Kapitel zur WYSIWYG-Editor-Einbindung beschrieben – ohne P-Suffix und in einem wie oben beschriebenen HTML-Kontext in die Quittungs- und Korrekturseite eingebunden wird (bei assistentengestützter Aufgabenerstellung erfolgt dies automatisch passend).


  1. Streng genommen bietet zumindest der aktuelle Editor TinyMCE 4 in seiner erweiterten Form immer die Möglichkeiten, Absatz- und Schriftformatierungen anzuwenden, und zwar über die Menüleiste. Die optionalen Einstellungen bewirken nur, dass eine weitere Symbolleiste die Absatzformat-, Schriftart- oder Schriftgrößen-Auswahl prominenter und schneller zugänglich anbietet, vgl. Abb. 2-3  ↩

  2. Bild-Einbettung in HTML-Code erfolgt in Base64-Kodierung mit entsprechend größerem Speicherbedarf.  ↩

  3. Statt groessenaenderung kann alternativ das Wort statusleiste angegeben werden, dann enthält die Fußleiste neben dem Greifer zur Größenänderung auch noch einen Statustext, der einen Pfad „geöffneter“ HTML-Elemente anzeigt, z.B. „ul » li“, falls der Cursor gerade innerhalb eines Listenelementes einer unnummerierten Liste steht. Das ist für Benutzer mit HTML-Kenntnissen mitunter hilfreich.  ↩

  4. Die Option keinebilder funktioniert nicht im alten Editor TinyMCE 3, d.h. falls Sie die Nutzung von TinyMCE 3 erzwingen, bleibt die Option wirkungslos.  ↩

  5. Dies gilt speziell für den aktuellen Editor „TinyMCE 4“. Sollten Sie die Nutzung des älteren Editors „TinyMCE 3“ erzwingen, so bewirkt die fullwidth-Klasse nur, dass der Editor sich überhaupt an die volle Seitenbreite zum Zeitpunkt des Seitenaufbaus anpasst – TinyMCE 4 tut das grundsätzlich und passt sich auch dynamisch an, wenn das Fenster nach Seitenaufbau in der Größe verändert wird.  ↩

  6. Hinweis: Diese Verschachtelung eines Code- innerhalb eines Pre-Elements darf nicht verwendet werden, wenn Sie die Verwendung des alten Editors TinyMCE 3 erzwingen, denn der kann dieses Konstrukt nicht verlustfrei bearbeiten!  ↩

  7. Bei Online-Korrektur ist das im Übrigen nicht möglich: Ein Upload mit dem Composer wird dort fehlschlagen, wenn die Aufgabe KorrektorKommentar- oder KorrektorCheck-Elemente enthält, also klar auf In-Browser-Korrektur ausgelegt ist.  ↩