Fallkontext

Die Fälle sollten curricular eingebunden sein, da Studierende nicht-Prüfungs-relevanten Inhalten erfahrungsgemäß sehr wenig Interesse entgegenbringen.

Für die Studierenden, die sich auf eine Prüfung vorbereiten wollen und eine größere Anzahl von Fällen im zur Vorlesung gehörenden WueCampus verfügbar ist, ist der Fallstatistik-Link im WueCampus-Kurs wichtig!

Falldauer

Die Fälle sollen einfach bedienbar und kurz sein (~15Minuten). Einfach bedienbar bedeutet:

• Die Situationsbeschreibungen sollten so kurz sein, dass der Lerner nicht (viel) scrollen muss.
• Die für den Fall wichtigen Aspekte bei Bildern und Videos sollten auch in skalierter Größe einigermaßen erkennbar sein.
  [ Details]
• Lange Warte- oder Ladezeiten bei Videos sollten vermieden werden, deshalb sollten die Videodateien nicht zu groß sein - diese Problematik wird durch Verwendung des Videostreaming-Servers des Rechenzentrums etwas mitigiert, je nach verwendetem Endgerät bietet aber auch Streaming keine Abhilfe.
• Terminologie-basierte Fragen sollten nur dort verwendet werden, wo sie auch Sinn machen. Wenn eine Frage auch gut mit wenigen Antwortalternativen gestellt werden kann, dann sollte dies bevorzugt werden. Ebenso sind Wort-Fragen oder numerische Fragen aufwändiger als Multiple/One choice Fragen.

Intro / Abschlusskommentar

Im Intro oder spätestens in der Information des ersten Abschnitts sollte ein Bild zu sehen sein, das den Fallrahmen vorgibt, also z.B. ein Patientenfoto (Medizin) oder ein Bild der Firma die umstrukturiert wird (Wirtschaftswissenschaften) oder bei einem Mordfall (Jura) ein Kreideumriss - eben irgendetwas das den Lerner auf den Fall einstimmt. Solche Fotos wurden bisher von den Studierenden der Medizin immer gewünscht.

Der Abschlusskommentar sollte nochmal den Fall zusammenfassen, auf Besonderheiten hinweisen, den Fall in Bezug zum Fachgebiet und zu den anderen Fällen setzen (ohne bei diesen zuviel zu verraten). Es wird empfohlen, alle Abschlusskommentare eines Fachgebiets, eines Kurses bzw. einer Menge von zusammengehörenden Fällen stets gleichartig zu strukturieren. Studierenden sind die Abschlusskommentare besonders wichtig.

Bewertung der Bearbeitungsdauer

... sollte nur dort eingesetzt werden wo Fälle "so wie sie in der Klausur kommen können" angeboten werden - dort macht es Sinn, einem Fall nur soviel Zeit zu geben wie den Prüflingen auch in der Klausur maximal zugestanden wird.

Freitext-Fragen

Bei diesen Fragen, bei denen die Lernenden viel Text eingeben müssen, sollte durch die Fragestellung klar gemacht werden, was genau erwartet wird und dass diese Aufgabe nicht automatisch bewertet wird. Es ist zu erwarten, dass die Lerndenden hier keinen ausführlichen Text sondern höchstens stichpunktartig schreiben werden, was bei der Erstellung schon berücksichtigt werden kann. Sie sollten hier die Möglichkeit nutzen, genaue Hinweise zur eigenen Bewertung anzugeben.

Fragebewertung

Da der Autor beim Bewertungsschema hier große Freiräume hat, die unterschiedlichen Bewertungsschema für die Lernenden aber bei der Beantwortung der Frage nicht erkennbar sind, sollte bei allen Fragen eines Falles ein ähnliches Bewertungsschema verwendet werden und dieses bei extremen Schemata ("alles oder nichts") auch im Intro schon angekündigt werden.

Erklärungen

Ausführliche Erklärungen zu allen Fragen sind für die Lernenden das wichtigste. Ob man dort jetzt die entsprechenden Inhalte aus anderen Dokumenten kurz zusammenfasst oder diese außerhalb des Falls (z.B. in WueCampus) öffentlich verfügbar macht und auf diese per Link verweist ist Geschmackssache.

Feedback

Der Feedback sollte so konfiguriert werden, dass die Auflösung nach jeder Frage anforderbar ist. Abschalten sollte man dies nur, wenn eine Prüfungssituation trainiert werden soll. Ganz abschalten (d.h. nicht mal am Fallende wird eine Bewertung angezeigt) wird aus didaktischen Gründen nicht empfohlen. Automatisches Feedback, d.h. sofort nach Eintragen erscheint das Feedback wird von Studierenden oft als störend wahrgenommen.

Evaluation

Um die Lernenden nicht zu nerven (leider empfinden das viele so) sollten nur wenige, schnell zu beantwortende Fragen nach Fallende gestellt werden. Es existiert ein vorgefertigter Evaluationsabschnitt, der jedem Fall automatisch (sofern man diese Option nicht abwählt) hinzugefügt wird. Im Fall bereits vorhandene eigene Evaluationsfragen werden erkannt und dann nicht überschrieben. Evaluationsfragen sollten immer mit einem knappen motivierenden Text eingeleitet und mit einem entsprechenden Text beendet werden, also z.B.:

"Wir möchten Sie bitten, die folgenden n Fragen kurz zu beantworten. Nur durch Ihre Mitarbeit ist es uns möglich, das Trainingssystem und die darüber angebotenen Inhalte kontinuierlich zu verbessern."

und

"Wir danken Ihnen für Ihre Mitarbeit!"

Versionierung / Historie / TODOs / Datum

Versionierung ist wichtig für die Statistiken, da bei der Evaluation die Fallbearbeitung nach Versionen getrennt erfasst werden. Diese können dann bei der Auswertung auch wieder zusammengefasst werden, es ist aber wichtig, später nachvollziehen zu können, welche Versionen zusammengefasst werden können und welche nicht. Deshalb wird empfohlen ausgiebig Gebrauch von Versionierung & Historie zu machen. Eine ideale Verwendung sähe dabei folgendermaßen aus:

• Anhand der Versionsnummer lässt sich erkennen, welche Versionen kompatibel sind und welche nicht, also Version A.X ist vergleichbar zu A.Y und A.Z, aber nicht mehr vergleichbar mit B.X. Wurden nur Rechtschreibfehler verbessert, bessere Bilder hinzugefügt, dann muss die Version nicht geändert werden. Ein großer Versionssprung ist immer dann erforderlich, wenn neue Fragen hinzugekommen, Fragen stark geändert oder entfernt wurden. Neuere Versionen sollten immer höhere Nummern haben, also 0.9 -> 1.0 ... 1.9 -> 2.0 etc.
• Bei jedem TODO-Eintrag ist die Version angegeben auf die sich das TODO bezieht und das Datum wann das TODO hinzugefügt wurde.
• Beim Datum steht das Datum der letzten Änderung.
• In der Historie steht zu jeder bisherigen Version ein Eintrag, was sich gegenüber der letzten geändert hat. Wurde ein TODO bearbeitet, dann sollte dies erwähnt werden.

Also

FALL_VERSION	0.1
FALL_TODO	bessere Bilder in Abschnitt "Röntgen"
FALL_TODO	Wissensfragen im Abschnitt "Weitere Diagnostik"
FALL_HISTORIE	0.1 erste Version
FALL_DATUM	09.05.2007

zu

FALL_VERSION	1.0
FALL_TODO	bessere Bilder in Abschnitt "Röntgen"
FALL_HISTORIE	1.0 vier neue Wissensfragen im Abschnitt "Weitere Diagnostik" 0.1 erste Version
FALL_DATUM	12.05.2007

Dies lässt sich mit dem Workflow zur verteilten Fallerstellung soweit verbinden, dass in der Fallhistorie jeweils noch der Bearbeiter vermerkt wird und TODOs nur vom Autor hinzugefügt und gelöscht werden, während Hilfskräfte erledigte TODOs mit einem (erledigt) kennzeichnen. Das zwischen den beiden obigen Versionen gehörende Dokument enthielte also folgenden Abschnitt:

FALL_VERSION	1.0
FALL_TODO	bessere Bilder in Abschnitt "Röntgen"
FALL_TODO	Wissensfragen im Abschnitt "Weitere Diagnostik" (erledigt)
FALL_HISTORIE	1.0 Max Musterhilfskraft: vier neue Wissensfragen im Abschnitt "Weitere Diagnostik" 0.1 Max Musterhilfskraft: erste Version
FALL_DATUM	10.05.2007

Die hier beschriebene Versionierung hat NICHTS zu tun mit den Begriffen "neue Version", "aktuelle Version" und "alte Version(en)" eines Falles.