Videos, Sequenzen, Textfragen und mehr

Videos

Mit dem Flash-Player ist die Welt hier einfach: Mit ffmpeg jedes Video nach flv konvertieren und fertig. Da die Konvertierung normalerweise auch ziemlich schnell geht ist diese einfach in den Vorgang des Falleinlesens integriert. Sobald also der Fall eingelesen ist und gestartet werden kann, sind auch die Videos konvertiert und abspielbar - in Flash und auf jedem Browser.

Mit dem HTML5-Player, der direkt im Browser läuft, sind Videos furchtbar kompliziert geworden: Zum einen gibt es verschiedene Formate, die die jeweiligen Browser (auch abhängig vom Betriebssystem) unterstützen - Safari @ iOS mag gar nichts außer MP4, gestreamt bitte als HLS, Chrome unterstützt mehr Formate, mag aber als Streaming-Methode eher DASH, alte Browser haben keine passende GPU für ein effektives Dekodieren von H.264 und Firefox ist besonders empfindlich, was verschlüsseltes Streaming betrifft. Zum anderen haben die Geräte der NutzerInnen auch noch verschiedene Bildschirmgrößen bzw. -auflösungen und Internet-Bandbreiten, so dass EINE Datei nicht mehr alleinseligmachend sein kann.

Zum Glück betreibt das Rechenzentrum einen Video Streaming Server, der diese Probleme löst: Man schickt ihm ein Video und dieses wird in verschiedenen Formaten (H.264 als DASH / HLS / Native) und Größen bereitgestellt, so dass jeder Client das Video in der ihm passenden Art erhalten kann.

Das Zusammenspiel der beiden Systeme ist nicht ganz einfach: Die Videos müssen beim Hochladen dem Videoserver übermittelt werden, so dass die AutorInnen damit keinen zusätzlichen Aufwand haben, einmal so auf dem Videoserver verfügbar gemachte Videos sollen in anderen Fällen wiederverwendet werden können, und der Player muss vom Server ein Video anfordern, das beim Erzeugen des Falles noch gar nicht existiert.

Und so geht's: Um den Videoserver zu entlasten, werden alle Videos - zusätzlich zur Konvertierung ins flv-Format - auf dem CaseTrain-Server auch noch mit dem x264 Encoder vorkonvertiert, erhalten einen eindeutigen Namen und werden an den Videoserver übertragen, d.h. in einen CaseTrain-Ordner auf den Videoserver kopiert.

Regelmäßig überprüft der Videoserver den Ordner auf neue Dateien, erkennt dabei neue Videos, registriert diese in seiner Datenbank (und gibt ihnen dabei eine eigenen eindeutigen Namen), steckt sie in die Verarbeitungspipeline und eine ungewisse Zeit später sind sie dann fertig konvertiert (neben verschiedenen Größen werden auch für das Streaming optimierte key frames eingefügt).

Der CaseTrain-Server wiederum überprüft regelmäßig den Zustand "seiner" Videos auf dem Videoserver und kann erkennen, ob das Video registriert ist und ob die Konvertiertung beendet wurde. Sobald erkannt wurde, dass das Video fertig ist, schickt der CaseTrain-Server der Autorin des Falles eine entsprechende Mail - ab diesem Zeitpunkt kann der Fall im HTML5-Player abgespielt werden und das Video auch in anderen Fällen verwendet werden. Bereits ab der Registrierung in der Datenbank kann die Autorin schon nachschauen, unter welcher Adresse das Video in weiteren Fällen verwendet werden kann.

Im Fall selbst (der nach dem Hochladen nicht mehr verändert wird), steht für jedes Video nur der Identifikator, den CaseTrain bei der Fallerzeugung vergeben hat, zum Abspielen benötigt der Player aber den Identifikator des Videoservers. Daher fragt der CaseTrain-Player beim Fallstart den CaseTrain-Server nach dem bzw. den jeweiligen Videoserver-Identifikator/en, die dieser in der Videoserver-Datenbank nachschaut und zurückmeldet. Der CaseTrain-Player erzeugt daraus verschiedene Quellen für das Video.

Für das Abspielen wird der von Universität Würzburg lizensierte Flowplayer verwendet, der dann den Magie-Teil übernimmt und das Video auf die für die jeweilige Umgebung passende Weise abspielt ggf. auch als SSL verschlüsselten Stream.

Mehr in der Dokumentation und noch mehr in der Dokumentation.

Sequenzen

CaseTrain kennt 2 Bearbeitungsmodi: Den linearen Modus und den freien Modus. Im linearen Modus muss jede Frage beantwortet werden, bevor man zur nächsten Frage weitergehen kann. Eine Navigation zurück ist nicht möglich - frühere Infos, Fragen, Antworten und ggf. Auflösungen und Erklärungen sind über die Übersicht zugänglich. Im freien Modus kann man beliebig zwischen Fragen springen und Fragen mehrfach beantworten. Normalerweise finden alle Bearbeitungen, bis eine Bearbeitung komplett abgeschlossen wurde (egal mit welchem Ergebnis), im linearen Modus statt. Bei allen weiteren Bearbeitungen können die Studierenden über die Übersicht beliebig zu Fragen und Abschnitten springen, vor- und zurückblättern und Fragen neu beantworten. Dieses Verhalten kann von den Autorinnen beeinflusst werden, so kann die freie Navigation und das Fragen neu beantworten unabhängig voneinander immer erlaubt oder immer verboten werden. Immer erlauben macht Sinn bei Fragesammlungen, immer verbieten macht Sinn bei konstruktiven Fällen, bei denen die Fragen aufeinander aufbauen.

Bei Fällen, die sowohl aus Abschnitten mit voneinander unabhängigen Fragen bestehen als auch Abschnitte bzw. Fragen beinhalten, die aufeinander aufbauen und daher nur in der vorgegebenen Reihenfolge beantwortet werden können, gibt es nun die Möglichkeit, solche Abschnitte als Sequenzen auszuzeichnen. Es kann dann ggf. immer noch frei navigiert werden, alle späteren Inhalte einer Sequenz bleiben aber verborgen bis alle Fragen vorher beantwortet wurden. Zudem kann jede Frage innerhalb einer Sequenz nur einmal beantwortet werden. Sequenzen können auch in Prüfungen verwendet werden.

Mehr dazu in der Dokumentation.

Textfragen

Textfragen können nicht automatisiert ausgewertet werden. Die Lernenden haben nur die Möglichkeit sich selbst zu bewerten, was mit den Erklärungen der Fallautorin unterstützt werden kann. Eine bessere bzw. weitere Möglichkeit ist das Hinzufügen von Bewertungskritierien, anhand derer eine objektivere Bewertung durch die Lernenden selbst vorgenommen werden kann. Es war schon lange möglich, diese Bewertungskriterien einzugeben - jetzt gibt es auch im HTML5-Player die Möglichkeit, diese einzusetzen.

Mehr dazu in der Dokumentation.

Die Lernenden sehen am Ende das Gesamtergebnis aufgrund ihrer eigenen Bewertungen - nichtsdestotrotz bleibt die Eigenbewertung nur eine zusätzliche Bewertung, "offiziell" zählt nur eine Bewertung durch Korrektorinnen und da diese beim freien Training nicht stattfindet wird, wird dort (vorerst...) weiterhin jede Textfrage mit 0% gewertet.

Evaluationsfragen im Fall

Es ist möglich am Ende des Falles eine Evaluation durchzuführen, diese Fragen müssen - auch im linearen Modus - nicht beantwortet werden, werden nicht ausgewertet und fließen daher auch nicht in die Bewertung ein.

Es gibt aber verschiedene Situationen, in denen es auch Sinn macht, Evaluationsfragen innerhalb des Falles zu stellen, z.B. könnte man nach Meinungen der Studierenden fragen oder Fragen zur Selbsteinschätzung zu Beginn des Falles stellen usw. Im Flash-Player gab es die Möglichkeit, Fragen als Quasi-Evaluationsfragen behandeln zu lassen, indem man sie mit 0 Punkten gewichtete und keine richtige Antwort hinterlegte. Dies unterstützt nun auch der HTML5-Player. Zusätzlich werden diese Fragen in der Übersicht anders angezeigt und tauchen in der Endbewertung gar nicht mehr auf.

Vereinfachungen bei konstruktiven Fällen

Es gibt einige Fälle bei denen nach und nach eine Lösung aufgebaut wird, dabei ändern sich die Titel der Abschnitte nicht und den Infos die links angezeigt werden werden nur immer weitere hinzugefügt. Für die AutorInnen ist das ein bisschen umständlich, da immer der Abschnittstext kopiert und dann ergänzt werden muss. Muss dann ein Inhalt des ersten Abschnitts verbessert werden, dann muss der gleiche Inhalt ebenso in allen folgenden Abschnitten nach-verbessert werden. Deshalb gibt es nun die Möglichkeit, dies effizienter einzugeben:

Wird als Abschnittstitel nur ein * eingegeben, dann wird der vorherige Abschnitt soweit übernommen und um die Inhalte des Abschnitts ergänzt. Dies kann mehrfach hintereinander gemacht werden, so dass nur im ersten Abschnitt ein Titel und die Startinformationen angegeben werden und in weiteren Abschnitten dann immer nur * und die neu hinzukommenden Inhalte.

Multi-Choice-Fragen

Ein weiteres Feature, das dem HTML5-Player noch fehlte, sind die Mehrfach-Auswahl-Fragen, bei denen mehrere Teilfragen auf die gleiche Weise beantwortet werden müssen.

Nach einigem Refaktorieren konnte dieses Feature so implementiert werden, dass die vorhandenen Mechanismen zur Beantwortung von Auswahlfragen, zum Erzeugen der Erklärungen und zum Verrechnen bei Mehrfachfragen (wie bei Mehrfach-Wort- oder -Zahlen-Fragen) zur Bewältigung von Mehrfach-Auswahl-Fragen wiederverwendet werden konnten


Ein Vorteil gegenüber der Implementierung im Flash-Player ist, dass damit prinzipiell auch andere Auswertungsschemata bei Multi-MC-Fragen verwendet werden können. Eine schönes Feature von CSS3 ist die transform: rotate Anweisung, mit der bei Multi-Choice-Fragen die möglichst kurzen Antworttext schräg angezeigt werden können und so vielleicht einige Antwortmöglichkeiten mehr dargestellt werden können. Nichtsdestotrotz müssen hier die AutorInnen die Darstellung der Frage im Player überprüfen.


Da diese Fragen häufig für Umfrage-artige Abschnitte innerhalb eines Falles verwendet (bzw. eigentlich missbraucht) werden, diese Nutzung aber irgendwie auch berechtigt ist, muss im nächsten Schritt ebenso nachimplementiert werden, dass nicht-auswertbare Fragen wie Evaluationsfragen behandelt werden, d.h. nicht ausgewertet, erklärt und im Endergebnis miteinberechnet werden.

Design des Zeitfortschrittsbalkens

Ein möglichst originalgetreuer Nachbau des Zeitfortschrittsbalkens wäre ungefähr so gewesen:

Da aber in der Ergebnisanzeige auch um die Farben hellrot und hellgrün eingesetzt werden, wurde eine dieser Ergebnisanzeige möglichst ähnliche Darstellung gewählt:

Hier fehlt aber die klar erkennbare Grenze zwischen "gesetzte maximale Bearbeitungsdauer" und Überziehungszeit.

Das sind nun zuviele Informationen: 2 Striche und dann noch verschiedene Farben, vielleicht doch wieder der einfacher grün/rot-Verlauf:

Die Farbe zwischen grün oder rot ist aber leider nicht schön. Vielleicht wäre es besser, wenn man das einfach in drei Zonen aufteilt: Grün, hellgrün, hellrot - dunkelrot wird der sich wachsende Zeitbalken bei Erreichen von 100% sowieso:

Das ist leider zu hässlich, also vielleicht einfach den mittleren Strich weglassen?

Und dann vielleicht noch einen ein bisschen weicheren Übergang zwischen hellgrün und hellrot?

Eigentlich gar nicht schlecht so.


Aber eigentlich soll der Fortschrittsbalken dazu da sein, die Prüfungssituation nachzustellen - und in einer Prüfung schaut es so aus:

bzw. für Datenfreaks:

Oben der Zeitfortschritt, unten der Bearbeitungsfortschritt.


Es wäre also doch zweckdienlich, den Zeitfortschrittsbalken möglichst ähnlich zu gestalten - und da die Zeitanzeige bei zeitkritischen Fragen sowieso schon fast so wie die Zeitanzeige in Prüfungen aussieht, wird diese Anzeige der Bearbeitungsdauer nun einfach auch so gestaltet.


Während die Zeit "im grünen Bereich" abläuft, schaut es dann so aus:

Und bei Überschreiten der vorgesehenen maximalen Bearbeitungsdauer so:



Man könnte im nächsten Schritt zusätzlich auch den Bearbeitungsfortschritt wie in einer Prüfung anzeigen - vielleicht sollte das aber auch nicht passieren, denn der ist auch unten links im Ergebnisbereich irgendwie mit enthalten. Da bei den meisten Trainingsprüfungen die Fragen sowieso sofort ausgewertet werden und eine Erklärung dazu angegeben ist, würde man dann oben den Bearbeitungsfortschritt sehen und unten links das Ergebnis - das wären vielleicht zu viel eigentlich gar nicht benötigte Informationen. Der letzte sehr einfache Entwurf sollte ausreichen, um den gewünschten Zweck zu erzielen - nämlich einen leichten Zeitdruck zu erzeugen.

Notizblock-Funktion

Vor kurzem wurde das Markierungs-Feature vorgestellt, mit dem man Markierungen in den Informationen zu Fragen vornehmen kann. Dabei gibt es aber die Einschränkung, dass solche Markierungen nur angezeigt werden können, solange die entsprechenden Fragen auch angezeigt werden.


Da es aber manchmal auch hilfreich sein kann, sich Notizen machen zu können, auf die man dann jederzeit zugreifen kann, wurde zusätzlich mit der gleichen Technik wie bei der Markierungsfunkton ein Notizblock zur Verfügung gestellt:

Zeitbeschränkung bei Fällen und Fragen

Ein Unterschied zwischen Training und echter Prüfung ist der Zeitdruck wenn man für das Bearbeiten einer Prüfung weniger Zeit zur Verfügung steht als man benötigt. Zum Prüfungs-Training stellen viele Dozentinnen alte Prüfungen als Trainingsfälle zur Verfügung, jedoch fehlte im HTML5-Player bisher der Zeitdruck.

Jetzt war wieder mal ein bisschen Zeit und dieses Feature konnte nun auch fertig gestellt werden. Die Einberechnung der Bearbeitungsdauer in das Endergebnis gab es schon seit längerem, es fehlte nur noch die entsprechende Anzeige:

Solange sich der Balken im Grünen bewegt erhält man noch volle Punkte, dann wird die Bewertung immer schlechter (bis zur Bestehensgrenze), ab da ist man im roten Bereich und wenn die maximale Bearbeitungsdauer erreicht ist wird der Balken rot.

Ein weiteres bisher leider wenig genutztes Feature, das nur im Flash-Player existierte waren zeitkritische Fragen, d.h. Fragen für deren Beantwortung man nur eine bestimmte Zeit hat. Diese Fragen können auch nicht unterbrochen oder erneut beantwortet werden. Dies wurde nun auch im HTML5-Player mit Änderungen nachgebaut:

Flash-Player	HTML5-Player

Die Aufteilung des Frage/Antwort-Bereichs ist im HTML5-Player nicht anders als bei einer Frage, es gibt einen eigenen Button um die Frage zu starten (um ein versehentliches Starten zu vermeiden), der Hinweis bleibt verborgen bis die Frage gestartet wurde und die Zeitanimation ist vom Eintragen-Button in den Zwischenraum zwischen Frage und Antwort gewandert.

Wut im Bauch (I)

Um keine Meldung zu technischen Problemen zu verpassen werden alle Kommentare zu Fragen auch an die Admin-Accounts weitergeleitet. Da flattert auch mal Unflätiges in das Postfach, wie heute z.B. folgendes:


Ein Nutzer hat am 10. März 2017 16:52 einen Kommentar zur Frage 6 im Fall 'Herzilein' abgeschickt:

what the fuck????

Link zum Fallkommentar: ...

Ein Nutzer hat am 10. März 2017 16:56 einen Kommentar zur Frage 2 im Fall 'Herzilein' abgeschickt:

?????????????????????? DAS IST EIN ÜBERDREHTER LINKSTYP!!!!! DIE ZWEITE ABLEITUNG ZEIGT SICH MIT DEUTLICH NEGATIVEM VEKTOR!!!! DAS IST WICHTIG ZU ERKENNEN

Link zum Fallkommentar: ...


Kleiner Tipp: Atemübung 2: Länger ausatmen

Atmen Sie etwa doppelt so lange aus wie ein. Wenn Sie beispielsweise etwa fünf Sekunden lang einatmen, versuchen Sie dann Ihre Ausatmung zehn Sekunden in die Länge zu ziehen. Einfach bewusst ganz langsam ausatmen. Das entspannt ungemein.
Entspannungsübung 22 @ zeitblüten - leider kann man nicht schön dahin verlinken, da je nach Browser die angelinkte Übung entweder zu weit oben oder zu weit unten erscheint.

YouTube was machst Du?

Nachdem ich gestern morgen über einen eigenen Google CaseTrain Account 2 Videos ungelistet hochgeladen (das erste stand um 9:21 bereit) hatte, diese in einem bereits veröffentlichten Blog-Beitrag verlinkt und den Blog-Beitrag aktualisiert hatte, erhielt ich um 10:10 eine Mail, dass das erste der beiden Videos entfernt wurde:

In unseren Community-Richtlinien wird beschrieben, welche Inhalte auf YouTube erlaubt sind und welche nicht. Dein Video "Antwortmarkierungen" wurde zur Überprüfung gemeldet. Bei der Überprüfung haben wir festgestellt, dass dein Video gegen unsere Richtlinien verstößt. Deshalb haben wir dieses Video aus YouTube entfernt. Außerdem hat dein Konto eine Verwarnung wegen der Verletzung unserer Community-Richtlinien bzw. vorübergehende Strafe erhalten.

Beschränkungen für Videoinhalte

Es ist nicht in Ordnung, große Mengen ungezielter, unerwünschter oder sich wiederholender Inhalte auf YouTube zu posten. Wenn deine Inhalte vorwiegend dazu dienen, andere Nutzer von YouTube wegzuleiten und auf eine andere Website zu führen, dann verstoßen sie wahrscheinlich gegen unsere Spam-Richtlinien. Auch irreführende Beschreibungen, Tags, Titel oder Thumbnails sind unzulässig, wenn sie hauptsächlich darauf abzielen, die Aufrufzahlen für Videos zu erhöhen. Außerdem dürfen Tags nicht in der Videobeschreibung platziert werden, sondern nur im dafür vorgesehenen Abschnitt. Weitere Informationen

Auswirkung von Verwarnungen

...

Zunächst: Ich habe Beschwerde eingelegt und das Video wurde heute morgen um 00:15 - also ca. 14h nach der Beschwerde - wieder eingestellt und die Verwarnung rückgängig gemacht.


Aber jetzt wollte ich mich doch mal schlau machen, was da so passieren kann, passiert sein könnte und so weiter.




https://support.google.com/youtube/answer/185111?hl=de

Verwarnungen wegen Verletzung der Community-Richtlinien werden erteilt wenn unsere Prüfer auf eine Verletzung der Community-Richtlinien aufmerksam gemacht werden.

https://support.google.com/youtube/answer/2802032?hl=de&ref_topic=2803138

Was geschieht, wenn du eine Verwarnung erhältst

Wenn eine Verwarnung erteilt wird, erhältst du eine E-Mail. Außerdem erscheint eine Benachrichtigung in den Kanalfunktionen für dein Konto. Darin wird erklärt, aus welchem Grund deine Inhalte entfernt wurden (z. B. wegen pornografischer oder gewalttätiger Inhalte). Bitte lies dir diese Erklärung und die Informationen in unserem Richtlinien-Center sorgfältig durch. So kannst du vermeiden, dass ein ähnliches Problem noch einmal auftritt.

 https://support.google.com/youtube/answer/2802027

Unangemessene Inhalte melden

Du kannst in der YouTube-Community einen wichtigen Beitrag leisten, indem du Inhalte meldest, die du für unangemessen hältst. Gemeldete Inhalte werden nicht automatisch entfernt.

• Inhalte, die gegen unsere Community-Richtlinien verstoßen, werden von YouTube entfernt.
• ...

Unsere Mitarbeiter überprüfen gemeldete Videos rund um die Uhr. Videos können jederzeit gemeldet werden, nachdem sie auf YouTube hochgeladen wurden. Anschließend werden sie von YouTube-Mitarbeitern überprüft. .... Die Meldung von Videos erfolgt anonym. Man weiß also nie, wer dahinter steckt.

 https://www.youtube.com/yt/policyandsafety/communityguidelines.html

We review your reports carefully

You might not like everything you see on YouTube. Some of the content might offend you. If you think it's inappropriate, locate the flagging feature on the video and submit it for review by our YouTube staff. Learn more

Our staff reviews flagged videos 24 hours a day, 7 days a week to determine whether they violate our Community Guidelines. When they do, we remove them. Sometimes a video doesn't violate our guidelines, but might not be appropriate for everyone. These videos may get age-restricted. Accounts are penalized for Community Guidelines violations, and serious or repeated violations can lead to account termination. If an account is terminated, that person won't be allowed to create any new accounts.

Dementsprechend müsste jemand zwischen 9:21 (bzw. dem Speichern des aktualisierten Blog-Eintrags ) und 10:10 das Video gemeldet haben und dieses müsste dann auch noch von einem YouTube-Mitarbeiter überprüft worden sein. Das erscheint äußerst unwahrscheinlich, da das Blog nur 2 Abonennten hat (und ob die von einer Aktualisierung informiert werden weiß ich gar nicht) und der Blog-Eintrag wurde per Tweet schon am Vortag veröffentlicht. Es müsste schon mit dem Teufel zugehen, dass genau in den wenigen Minuten jemand das Video anschaut und derjenige das dann auch meldet. Folglich gehe ich davon aus, dass dies nur völlig automatisiert passiert sein kann - auch wenn nirgendwo steht, dass sowas überhaupt passert und entsprechend auch Verwarnungen automatisiert verteilt werden.




Da die EMail eine Begründung enthalten soll, kann diese nur im Absatz über Beschränkungen für Videoinhalte zu finden sein:

Es ist nicht in Ordnung, große Mengen ungezielter, unerwünschter oder sich wiederholender Inhalte auf YouTube zu posten.

Die beiden Screencasts zur Bedienung sind die bisher einzigen Videos, die hochgeladen wurden (vorher gab es das Konto auf YouTube gar nicht). Als ungezielt und unerwünscht würde ich die Videos jetzt nicht einstufen, sich wiederholend erscheint bei zwei ähnlichen Videos auch unwahrscheinlich.

Wenn deine Inhalte vorwiegend dazu dienen, andere Nutzer von YouTube wegzuleiten und auf eine andere Website zu führen, dann verstoßen sie wahrscheinlich gegen unsere Spam-Richtlinien.

Schwierig zu sagen, ob man das so interpretieren könnte, ich würde das aber verneinen. Wenn das hier der Grund wäre, dann würden auch z.B. alle LetsPlays hier Probleme bekommen.

Auch irreführende Beschreibungen, Tags, Titel oder Thumbnails sind unzulässig, wenn sie hauptsächlich darauf abzielen, die Aufrufzahlen für Videos zu erhöhen.

 Das kann ich ausschließen, da das Video den Titel "Antwortmarkierungen" hat und die Beschreibung "Antwortmarkierungen im CaseTrain HTML5-(Prüfungs-)Player".

Außerdem dürfen Tags nicht in der Videobeschreibung platziert werden, sondern nur im dafür vorgesehenen Abschnitt.

Es kann sein, dass ich das Wort CaseTrain alleine in der Videobeschreibung stehen hatte und dies auch (zwischen-)gespeichert hatte, ich habe es aber direkt danach in die jetzige Beschreibung geändert und diese gespeichert.




Was war beim ersten Video anders als beim zweiten, so dass es vielleicht automatisch entfernt wurde?


Die Videos wurden mit Camtasia 8 erstellt, dort exportiert und dann manuell auf YouTube hochgeladen. Man kann zwar auch direkt aus Camtasia nach YouTube exportieren, dazu müsste man aber Camtasia seine Zugangsdaten geben und Meta-Daten werden dabei auch automatisch gesetzt - da ich davon ausgegangen bin, dass ich danach alle "Erstellt mit Techsmith Camtasia Studio 8" Tags hätte entfernen müssen wollte ich diese Möglichkeit nicht nutzen. Das erste Video hatte ich zunächst mit der von Camtasia vorgesehenen Methode "MP4 mit Smartplayer" exportiert und die enthaltene MP4-Datei hochgeladen - diese konnte aber von YouTube nicht verarbeitet werden. Ich habe dann noch mehrere andere Exportmöglichkeiten ausprobiert (Nur MP4 bis 1080p, Nur MP4 bis 720p, Nur MP4 bis 480p) die auch alle von YouTube nicht verarbeitet werden konnten - die hochgeladenen nicht-öffentlichen Videos waren zwar in meiner Video-Liste konnten aber nicht abgespielt werden. Nach etwas Recherche versuchte ich dann das Video als QuickTime zu exportieren, dazu musste zuerst QuickTime installiert werden und dann hätte Camtasia NEU INSTALLIERT werden müssen, damit der Techsmith Quicktime Codec installiert wird (wat?) - das wurde also verworfen und QuickTime nebst Apple Support Software und Apple Update Service wieder deinstalliert. Schließlich konnte ich mit "Benutzerdefinierten Produktionseinstellungen / AVI / Techsmith Screen Codec 2 (?), Kein Audio" eine Datei erzeugen, die von YouTube verarbeitet werden konnte. Ich hatte beim Upload während der Verarbeitung schon den Titel "Antwortmarkierungen" vergeben und die kaputten Videos gelöscht, nachdem es dann schließlich geklappt hat - zu dem Zeitpunkt hatte ich drei oder vier Videos mit dem Titel "Antwortmarkierungen" in meiner Video-Liste (alle nicht-gelistet).




Kann es wirklich sein, dass diese mehreren gleichen Videos - von denen alle bis auf eines kaputt waren und keines richtig öffentlich war - einen sauschlechten Automatismus dazu veranlasst haben, diese Videos als "große Mengen ... sich wiederholender Inhalte" zu markieren, zu sperren und mich dafür zu verwarnen? Das wäre echt dämlich - aber anders kann ich es mir nicht erklären.




Natürlich kann man dazu niemanden bei Google fragen, man kann sich nur einmal pro Sperre beschweren (sonst verwirkt man sein Beschwerde-Recht), die Freischaltung kam von einer noreply-Adresse, nirgendwo gibt es einen Ansprechpartner (außer "Die Community fragen") und auf https://productforums.google.com/forum/#!topic/youtube-de/38ucIWbbbHk findet sich ein Link Twitter + YouTube = Help on Social #YThelp, der zu einer völlig verkorksten Seite von April 2016 führt die einen Link zu https://crowds.conversocial.com/signup/helponsocial enthält was aber wieder nur ein halbgares irgendwas ist. An die Nutzerinnen outgesourcter Support scheint die Zukunft zu sein.


Man ist also einem wild false positives schmeißenden Algorithmus ausgeliefert und kann nur hoffen, dass man jedesmal alles 100% so macht, wie es der Algorithmus akzeptiert, nur damit man nicht verwarnt wird - und die Entscheidung dann nach Stunden von einem YouTube-Mitarbeiter nach Beschwerde rückgängig gemacht wird. Übrigens wird nach 3 solcher Verwarnungen in 3 Monaten das Konto unwiderruflich gesperrt.


Note to self: Bessere Video-Hosting-Plattform suchen.


Und wo wir schon dabei sind: blogger.com ist leider inzwischen so schlecht, dass dieses Blog demnächst umziehen wird.

Notiz-Funktionen (für Prüfungen) & mehr

tl;dr Man kann im Player nun Antworten markieren und verschiedene Markierungen im Infobereich setzen. Der Infobereich lässt sich verkleinern, wenn dieser keine Informationen enthält.


In der Prüfungsphase am Ende des WS 16/17 wurden in der Medizinischen Fakultät drei echte Prüfungen auf iPads erfolgreich durchgeführt - erfolgreich in dem Sinn, dass die Infrastruktur (WLAN + Server) gehalten hat und auch der HTML5-Player die Prüfung erfolgreich abgespielt hat. Es gab aber auch viele z.T. sehr berechtigte Kritik der Prüflinge - die den Player betrifft folgt hier:

Markieren von Antworten

Nach den Testprüfungen im Vorfeld hatten viele TestteilnehmerInnen bemängelt, dass durch den Wechsel von Papier auf "Nur iPad und sonst nichts" die Möglichkeit fehlt, Antworten zu markieren. Medizinprüfungen bestehen traditional aus 1-aus-5-Auswahlfragen, bei denen man auf Papier gut nach dem Ausschlussprinzip vorgehen kann, d.h. man streicht nach und nach die jeweils am wenigsten plausible Antwort durch bis nur noch die eine hoffentlich richtige Antwort übrig bleibt.
Es gab zwar schon (immer) die Möglichkeit, Fragen mit einer (kleinen) Markierung zu versehen - etwa "Nochmal anschauen" oder "unsicher" etc. - dies ließ sich aber nicht erweitern um dem Wunsch der Prüflingen nachzukommen. Es musste also eine andere Möglichkeit geschaffen werden, Antworten zu markieren, die das Beantworten der Fragen ähnlich gut unterstützt wie Papier:

Dieses Video wurde zunächst von YouTube wegen Verstoß gegen die Community-Richtlinien
entfernt und nach Beschwerde wieder eingestellt. Falls dies wieder passiert: Dieses Video bei Wistia.

Blog-Eintrag zu diesem Vorgang.

Umsetzung Durch die Aufteilung des Players in Informationsbereich links, Fragetext rechts oben und Antworten rechts unten ist im Antwortbereich nicht viel Platz für graphische Spielereien, weswegen man Antworten nicht durch Antippen eines Buttons markiert sondern durch langes Antippen. Dabei sind zwei verschiedene Markierungen möglich: Beim ersten langen Antippen wird die Antwort unterstrichen, bei weiterem langen Antippen wird die Antwort durchgestrichen, beim dritten Mal wird die Markierung entfernt. Die Idee einer farbigen Markierung wurde verworfen, da beim Ausschlussverfahren Antworten die Bedeutungen "falsch / wenig plausibel / wenig wahrscheinlich" oder "richtig / sehr plausibel / sehr wahrscheinlich" erhalten, was man typischerweise mit einer roten und einer grünen Markierung umsetzen würde - das würde aber mit der letzten Erweiterung bei MC-Fragen kollidieren. Andere Farben sind schwierig umzusetzen, da blau im Prüfungs-Theme dominiert und ohne rot, grün und blau keine zwei geeigneten schönen Farben mehr zur Verfügung stehen - wer möchte schon mit rosa vs. türkis markieren? Weitere Textstile wie fett und kursiv wurden verworfen da hier beim Ändern störende Zeilenumbrüche entstehen können.


Technische Details Bei Prüfungen muss sichergestellt sein, dass der Bearbeitungszustand erhalten bleibt, selbst wenn der Prüfling aus Versehen die Prüfung schließt oder das iPad ausfällt. Deshalb wird die Auswahl einer Antwort sofort an den Server übertragen. Der bestehende Mechanismus wurde relativ einfach so erweitert, dass nicht nur der Auswahl-Zustand der Antworten übertragen wird, sondern zusätzlich noch der Markierungs-Zustand. Um die Bearbeitung nachher auch auf Plausibilität überprüfen zu können, wird die komplette Historie der Bearbeitung aller Fragen gemerkt und bei jedem Senden einer Änderung komplett mit-übertragen. Bei einer durchschnittlichen Prüfung beträgt das Übertragungsprotokoll am Ende ca. 10 kByte - ein Hinzufügen der Markierungsinformationen hat dies nicht wesentlich erhöht.


Nachgang Dieses Feature wurde bereits in den echten Prüfungen eingesetzt und fand auch Anklang - es bereitete aber auch unvorhergesehene Probleme: Auf dem iPad funktioniert Scrollen durch Wischen, man kann aber auch Scrollen indem man den Bereich antippt und den Finger langsam bewegt. Das Dumme dabei ist, dass man praktisch nicht zwischen "lange Antippen" und "lange Antippen und den Finger langsam bewegen" unterscheiden kann - ein bisschen Bewegen muss schließlich erlaubt sein. Bei vielen Prüflingen kam es daher vor, dass beim Scrollen Markierungen geändert bzw. gelöscht wurden - was für einigen Unmut gesorgt hat. Deshalb wurde der Antwortbereich zur dritten Prüfung so verändert, dass auf Tablets im Fall, dass gescrollt werden muss, rechts der Antworten ein graphisch ausgezeichneter (auf dem iPad etwa fingerbreiter) Bereich frei bleibt, der zum Scrollen verwendet werden kann.

Markieren von Informationen mit Textmarker und Stiften

In den bisherigen Prüfungen wurde der Infobereich nur wenig genutzt: Bei der Prüfung der Radiologie waren hier die Ergebnisse bildgebender Verfahren zu begutachten, bei der Prüfung in Allgemeinmedizin gab es einige kurze Texte (hauptsächlich die zu bewertenden Aussagen*), bei der letzten Prüfung war der Infobereich immer leer. Zukünftig sollen aber vermehrt key feature Fragen zum Einsatz kommen, bei denen ein klinisches Szenario mehr oder weniger ausführlich beschrieben wird und der Prüfling eine kritische Entscheidung treffen muss. Was von den Prüflingen nach der Prüfung in Allgemeinmedizin gewünscht bzw. als fehlende bemängelt wurde (und was bei längeren Vignetten noch sehr viel relevanter ist), ist die Möglichkeit Elemente des beschriebenen klinischen Szenarios, z.B. abnorme Werte des klinischen Befunds, zu markieren so dass die wesentlichen Informationen schneller zugänglich sind.


[Einschub *: Da in Medizin-Prüfungen meist von fünf möglichen Antworten eine Antwort ausgewählt werden soll, es aber oft nicht möglich ist, Fragen so zu formulieren, dass nur genau eine Antwort richtig ist, werden oft 2-stufige Fragen verwendet: Es werden zu einer Frage mehrere (nummerierte) Aussagen vorgegeben und die Prüflinge müssen dann aus fünf Antworten wie z.B. "Nur die Aussagen 1 und 2 sind richtig." eine auswählen. Da für die Aussagen kein Platz im Fragetext-Bereich ist, werden diese im Infobereich angezeigt. Auch hier kommt ein (meist einfacheres) Ausschlussverfahren zum Einsatz: Kann man eine Aussage ausschließen, kann man sofort alle Antworten ausschließen, die diese Aussage als richtig beinhalten.]


Dazu wurde eine leicht zugängliche und bedienbare Zeichenfunktion hinzugefügt, die sich mit Touch sogar sehr gut bedienen lässt.

Umsetzung Um das Feature möglichst einfach für die drei verschiedenen Darstellungsvarianten Desktop-Browser, Tablet und Smartphone zu  ermöglichen, wurde dem Infobereich links oben ein kleines Textmarker-Symbol hinzugefügt, über das das Markierungsfeature aktiviert oder deaktiviert wird. Die Idee den Button nach Linksaußen zu verschieben wurde verworfen, da dieser Bereich auf dem Smartphone nicht zur Verfügung steht und dort der Markierungsbutton nirgendwo anders untergebracht werden kann. Um dem Button bzw. dem Markierungsmenü Platz zu bieten, musste nur der linke weiße Rand um die Breite eines Buchstaben erweitert werden - das ist akzeptabel. Aktiviert man das Feature, dann öffnet sich ein Menü mit verschiedenen Werkzeugen: Vier Textmarker in den Farben gelb, rot, blau und grün, vier Stifte in den Farben grau, rot, blau und grün sowie ein Radierer (und die Undo-Funktion) stehen zur Verfügung. Über den gesamten Infobereich wird eine (mit Absicht nur fast) durchsichtige Ebene gelegt, die dann für Markierungen genutzt werden kann. Der Nachteil dieser Ebene ist, dass solange das Markieren aktiviert ist, Bilder nicht mehr vergrößert werden oder Links angetippt werden können, da diese unter der Ebene liegen - dazu muss man das Markieren wieder deaktivieren. Scrollen auf Tablets funktioniert so, dass man den zu scrollenden Bereich antippt und den Finger bewegt - auch das klappt mit aktiviertem Markieren nicht, da man genauso auch malen würde. Ein ständiges Wechseln zwischen Markieren und Scrollen (d.h. Markierung anschalten, Markieren, Markieren ausschalten, Scrollen, ...) wäre zu umständlich - deswegen wurde das so gelöst, dass der Malbereich den Infobereich rechts nicht ganz überdeckt und (wie bei den Antworten) ein hervorgehobener freier Bereich bleibt, der zum Scrollen genutzt werden kann.


Technische Details Auch bei Markierungen im Infobereich muss sichergestellt werden, dass diese einen Ausfall des iPads überstehen. Dies zu bewerkstelligen war erheblich aufwändiger als das Speichern der Antwortmarkierungen - das größte Problem dabei ist die verfügbare Bandbreite. In einer perfekten Welt könnte man jede Änderung sofort an den Server schicken - da die iPads aber nur per WLAN angebunden sind und sich ca. 100 iPads einen Accesspoint teilen, ist dies so nicht möglich. Das verwendete canvas-Element bietet die Möglichkeit, seinen Inhalt als Bild abzufragen und dieses Bild könnte man auch übertragen. Würde man aber die Markierung einfach als Bild übertragen, dann würde dies bei pro Infobereich ca. 50kByte ausmachen - im gegebenden Kontext wäre also die Übertragung einer einzelnen Markierung vermutlich schon schwierig und würde 5x mehr Bandbreite benötigen als die gesamten übrigen zu übertragenden Daten. Da das verwendete sehr einfache Zeichentool intern sowieso eine Liste aller durchgeführten Aktionen speichert (was dann auch für die Implementierung der Undo-Funktion genutzt werden konnte), wurde zunächst versucht, diese Liste als JSON-Daten zu übetragen - dies brachte aber keinen Vorteil, da die JSON-Daten nach wenigen Aktionen bereits ähnlich groß waren wie bei einer Übertragung im JPG-Format (diese JSONifizierten Aktionen könnten sogar unbeschränkt groß werden, wohingegen die Größe der Bilddaten durch die Größe des Infobereichs beschränkt wird). Um dem zu begegnen werden nun durch den Einsatz einer weiteren Bibliothek (unter WTFPL) die Daten zusätzlich komprimiert und dann übertragen, was (besonders bei JSONifizierung vieler ähnlicher Daten) erhebliche Einsparungen bringt - die Daten könnten sogar noch stärker komprimiert werden, dann können die Daten zwar noch intern als Javascript-String gespeichert werden, aber aufgrund der invaliden Codierung könnten sie nicht mehr übertragen werden.

Im obigen Beispiel kann man sehen, dass eine "normale" Markierung im komprimierten aber noch übertragbaren Format LZHTML kleiner als 10kB bleibt. Diese Art der Speicherung bietet auch - im Gegensatz zur Übertragung als Bilddaten - den Vorteil, dass die komplette Markierungshistorie mit-übertragen wird und bei Wiederaufnahme sogar die Undo-Fähigkeit erhalten bleibt. Zudem kann man aus der Historie auch das letzte verwendete Werkzeug ersehen und muss dieses (um den vorherigen Zustand wiederherzustellen) nicht extra merken.


Für die Übertragung der Bearbeitungsprotokolle gibt es bereits einen elaborierten Mechanismus, der sicherstellen soll, dass alle Protokolle übertragen werden - so wird z.B. bei Übertragungsschwierigkeiten das neueste zuerst übertragen, nicht übertragene Protokolle im Browser gespeichert und bei der nächsten Bearbeitung (egal welchen Falles) übertragen usw. Da sich dieser Mechanismus leider nicht erweitern ließ, wurde ein ähnlicher zweiter Mechanismus implementiert, der ebenso sicherstellt, dass Markierungen übertragen werden. Auf dem Server wird für jede Bearbeitung (und jeden Infobereich eines Falles) die Markierung abgespeichert und bei Wiederaufnahme in den Fall eingefügt - im Gegensatz zu den anderen Bearbeitungsdaten weiß der Server aber überhaupt nicht, was da kodiert ist - er überträgt die Daten unbesehen zurück und nur der Player hat die Fähigkeit diese Daten zu dekomprimieren, zu deJSONifizieren und die enthaltenen Aktionen durch Wiederausführen wiederherzustellen.
Im Gegensatz zu den Bearbeitungsprotokollen (die übertragen werden müssen, bevor der Fall wiederaufgenommen werden kann), können nicht gespeicherte Markierungen aus dem lokalen Speicher wiederhergestellt werden. Wird also ein Fall geladen, der gespeicherte Markierunginformationen enthält UND gleichzeitig noch nicht zum Server übertragene Markierungsinformationen lokal gespeichert sind, dann kann der Player selbst entscheiden, welche Informationen neuer sind und die älteren Markierungen ggf. mit den neueren aus dem lokalen Speicher überschreiben (und versuchen diese an den Server zu übertragen).

Variable Aufteilung

Wenn eine Prüfung keinerlei Zusatz-Informationen enthält, dann ist die Aufteilung des Oberfläche des Prüfungsplayers ungünstig, da etwa 60% des Bildschirms frei bleiben, dafür aber der Antwortbereich vielleicht so klein ist, dass man für die Anzeige aller Antworten scrollen muss. Dies wurde von den Prüflingen nach der dritten Prüfung bemängelt, die keinerlei Zusatz-Informationen beinhaltete.
Um dem zu begegnen wurde der Player so erweitert, dass die AutorInnen eines Falles die Aufteilung zwischen Infobereich und Frage/Antwort-Bereich selbst festlegen können.


Nachtrag: Noch mehr technische Details zur Markierungsspeicherung
Trotz der effizienteren Speicherung der Markierungsdaten ist es nicht sinnvoll, jede Markierung sofort zu übertragen - es wird angenommen, dass typischerweise alle Markierungen eines Infobereichs ohne größere Unterbrechungen "in einem Stück" vorgenommen werden und dass eine Teilspeicherung einer solchen Meta-Markierung zu wenig Vorteile bietet. Deswegen wird nach jeder Änderung ein Timer von (momentan) 3s (neu)gestartet und erst wenn dieser abgelaufen ist (d.h. für 3s keine weitere Markierung getätigt wurde) wird gespeichert. Um dennoch lange ausführliche Markierungen nicht zu verlieren, wird immer dann gespeichert, wenn seit der letzten ungespeicherten Änderung 30s vergangen sind. Zusätzlich wird immer dann gespeichert, wenn vom Infobereich wegnavigiert wird oder die Markierungsfunktion deaktiviert wird - weil davon ausgegangen wird, dass dann die Markierung "fertig" ist.
Beim freien Training und im Übungsbetrieb (d.h. man hat mehrere Tage Zeit für eine Bearbeitung, das Ergebnis ist aber auf eine Weise relevanter als das normale Training) wird - wie bei den Bearbeitungsprotokollen auch - weniger oft gespeichert: Beim freien Training wird nur in großen Abständen regelmäßig und beim Beenden des Falles gespeichert, im Übungsbetrieb (bei dem es einen Eintragen-Button gibt und zusätzlich nach "Eintragen" gespeichert wird) wird auch dann gespeichert, wenn die Markierungfunktion deaktiviert wird oder wegnavigiert wird.


Nachtrag: Ausblick Markierungen
Im nächsten Schritt wird die Markierungsfunktion um die Möglichkeit erweitert, Markierungen auf einem oder mehreren "leeren" Bögen unabhängig von einem Infobereich vornehmen zu können. Der Zusatzaufwand dafür scheint nicht allzu hoch zu sein und von den Prüflingen wurde die Möglichkeit gefordert Skizzen (z.B. zu Wirkkreisläufen) erstellen zu können - wofür im Infobereich zu wenig Platz sein könnte - statt jetzt an jeden Infobereich unten freien Platz hinzuzufügen, ist es vermutlich sinnvoller, einfach einen oder mehrere leere Bögen zur Verfügung zu stellen.

Erweiterungen bei MC-Fragen

Die Schwierigkeit, eine Antwort auf eine Frage zu bewerten, steigt mit der Komplexität der Antwort. Auf der einen Seite gibt es one-choice-Fragen, bei denen aus den vorgegebenen Antworten die eine richtige ausgewählt werden muss - mit trivialer Auswertung: Wurde die richtige Antwort gegeben, dann gibt es den Punkt, ansonsten nicht. Auf der anderen Seite gibt es Freitext-Fragen, bei denen ein längerer Antwort-Text nuanciert bewertet werden muss - was für Computerprogramme nur mit großem Aufwand und auch nicht immer ausreichend möglich ist.

Irgendwo dazwischen liegen die multiple-choice-Fragen, so wie sie in CaseTrain verstanden werden: Mehrere Antworten stehen zur Auswahl und beliebig viele davon sind (ggf. verschieden) richtig und müssen ausgewählt werden. Wenn nun nur ein Teil der richtigen Antworten aber auch ein Teil der falschen Antworten ausgewählt wird, dann sind viele verschiedene Auswertungen denkbar: Punkte nur bei völliger Übereinstimmung, Teilpunkte für richtige Antworten und Abzüge für falsche, usw.

CaseTrain bietet zunächst zur Auswertung von MC-Fragen sehr umfangreiche Möglichkeiten, wie festgelegt werden kann, welche Antwort wie richtig und wie falsch ist (s. Dokumentation) - und für alle damit dann doch nicht umsetzbaren Auswertungen noch weitere spezielle Auswertungsschemata. Um diese Frageauswertung für Lehrende und vor allem für Lernende möglichst einfach und transparent zu halten wurde frühzeitig festgelegt, dass alle MC-Fragen eines Falles (also einer Trainingseinheit oder einer Prüfung) mit dem gleichen Schema ausgewertet werden. Andernfalls müsste bei jeder Frage erklärt werden, worauf bei der Beantwortung geachtet werden sollte, z.B. ob es schlimmer ist, eine richtige Antwort zuwenig auszuwählen, als eine falsche Antwort zuviel auszuwählen usw.

Inzwischen gibt es aber einige Anwendungsfälle, bei denen es schön wäre, verschiedene Arten der Auswertung in einem Fall zu ermöglichen, z.B. wenn eine Prüfung aus verschiedenen Teilprüfungen verschiedener Fächer besteht, bei denen traditionell unterschiedliche Auswertungsschemata zum Einsatz kommen. Oder wenn ein Fall aus mehreren Blöcken mit verschiedenen Arten von MC-Fragen besteht, z.B. weil die Antworten bei Fragen des einen Blocks nicht unabhängig voneinander sind und deshalb mit AON oder AHN ausgewertet werden können, und Antworten bei Fragen eines anderen Frageblocks voneinander unabhängig sind und deswegen mit MOCR ausgewertet werden.

Dementsprechend wurde nun die Möglichkeit geschaffen, bei jeder MC-Frage das Auswertungsschema individuell festzulegen. Damit sind nun abwechslungsreichere Auswahl-Fragen möglich.

mutiple true-false / kprim

Durch die Art, wie in CaseTrain die Eingabe bei MC-Fragen erfolgt - nämlich durch ganz normale HTML Checkboxen bzw. bei Papierprüfungen durch Kästchen zum Ankreuzen - gibt es ein kleines Problem bei Auswertungsschemata, bei denen auch das Nicht-Auswählen von falschen Antworten belohnt wird: Wird die Frage gar nicht wirklich beantwortet, dann sind keine Antworten ausgewählt. Folglich sind dann auch die falschen Antworten nicht ausgewählt, gelten also als richtig behandelt und dadurch gibt es schon Teilpunkte. Bei Anwendung des Schema MOC könnte man bei einer Prüfung, die nur aus solchen Fragen besteht und etwa gleich viele richtige und falsche Antworten enthält, bei Nicht-Beantworten aller Fragen also trotzdem die Note 4 erhalten. Dem kann begegnet werden, indem die Rate-Wahrscheinlichkeit bei jeder Frage herausgerechnet wird, was vor allem bei der Einsichtnahme von Prüfungen die Prüflinge verwirren kann.

Einfacher geht dies mit sogenannten multiple true-false items (MTF), bei denen bei der Beantwortung erzwungen wird, dass jede Antwort als richtig oder falsch bewertet werden muss - eine nicht bewertete Antwort gilt immer als Fehler. In der deutschsprachigen Test-Community hat sich daran angelehnt der Fragetyp kprim etabliert, bei dem immer 4 Antworten bewertet werden müssen und die Frage nur bei vollständiger Übereinstimmung als richtig beantwortet gewertet wird. CaseTrain bietet mehr Möglichkeiten: Es können beliebig viele Antworten vorgegeben werden und es können auch beliebige Auswertungsschema eingesetzt werden - gibt man 4 Antworten vor und wählt das Auswertungsschema AON hat man eine "klassische" kprim-Frage. Eigentlich ist die Darstellung als multiple true-false Fragen aber eine logische Ergänzung der Auswertungschemata MOC, MOCP und MOCR, bei denen eine Frage mit n Antworten behandelt wird, als wären es n Einzelfragen, bei denen jeweils eine der Antworten unabhängig von den anderen mit richtig oder falsch bewertet wird - bisher wurde "falsch" eben durch Nicht-Ankreuzen kommuniziert.

CaseTrain wurde jetzt um den Fragetyp MCkprim* erweitert, die Darstellung im Player wurde entsprechend erweitert und sieht nun (etwas unspektakulär) so aus:

Darstellung MC-Fragen. Links: herkömmlich, rechts: multiple true-false.

Bei der ersten Auswahl einer Antwort wird statt einem Kreuz ein grün hinterlegtes Häkchen gesetzt, bei nochmaliger Auswahl ein rot hinterlegtes Kreuz, bei nochmaliger Auswahl wird die Markierung gelöscht. Im Beispiel kann sich bei der letzten Antwort "Kalium" ein Unterschied bei der Bewertung ergeben: Ist die Antwort falsch, dann gibt es für die Beantwortung links (Teil-)Punkte, rechts gibt es keine Punkte. Ist sie richtig, dann wird in beiden Versionen gleich bewertet: Links gilt die Antwort als fälschlicherweise nicht gewählt, rechts als falsch (da nicht bewertet).

Ein möglicher Nachteil der neuen Darstellung kommt zum Vorschein, wenn viele Antworten zur Auswahl stehen, von denen nur wenige richtig sind: Dann müssen trotzdem alle falschen Antworten  - insbesondere auch die offensichtlich falschen - doppelt ausgewählt werden, um sie als falsch zu markieren - was für die Lernenden schnell lästig werden kann. Aus diesem Grund ist auch die kprim-Darstellung nicht bei long menu Fragen möglich.

Literatur: David A. Frisbie and Daryl C. Sweeney, The Relative Merits of Multiple True-False Achievement Tests, Journal of Educational Measurement, Vol. 19, No. 1 (Spring, 1982), pp. 29-35, https://www.jstor.org/stable/1434916

* Statt des eigentlich richtigeren Begriffs MTF wird aus Gründen der Verständlichkeit in CaseTrain (als Trainings- und Prüfungssystem einer deutschen Universität) der Begriff kprim verwendet.

HTML5-Player (Update)

Der HTML5-Player ist seit Beginn des Wintersemesters 2016/17 im Produktivbetrieb und hat größtenteils den Flash-Player ersetzt - nur Fälle, die ein Feature benötigen, das gerade nur der Flash-Player unterstützt, werden mit diesem gestartet. Alle anderen werden im neuen HTML5-Player gestartet - der dafür schon einige Features hat, die der "alte" Player nicht hat. Damit gibt es nun das Problem zu entscheiden, welcher Player gestartet werden soll, wenn ein Fall Features fordert, von denen einige nur mit Flash und andere nur mit HTML5 erfüllt werden können :)


Leider bzw. eigentlich natürlich war der neue Player nicht fehlerfrei und so sind auch einige ernstere Fehler erst im Produktivbetrieb zutage getreten und haben teilweise zu hektischen Überstunden geführt. Schließlich musste sichergestellt werden, dass die Bearbeitungen der Lernenden zur späteren Wiederaufnahme bzw. zur Auswertung korrekt gespeichert wurden. Auch dass eine Fallbearbeitung bei Klick auf den Pause-Button nicht nur pausiert sondern endgültig beendet wurde, war für die Teilnehmer der ersten Übung im neuen Semester nicht besonders lustig ...


Die Browserunzulänglichkeiten, die mit dem Flash-Player als besiegt geglaubt waren, haben durch die Umstellung auf einen HTML5-basierten Player "im Browser" wieder ihr hässliches Haupt gereckt. Insbesondere bei der Implementierung von Textfragen zeigte sich, dass es da doch einige Unterschiede zwischen den Browsern gibt. Und Safari auf dem iPad hat auch so seine Sonderlocken, die extra glatt geföhnt werden müssen (es ist zwar Webkit, aber dann doch nicht), so z.B.

/* needed for safari @ ios */

label > * {
pointer-events: none;
}

oder

// safari @ ios needs this

window.getSelection().removeAllRanges();
$('<div/>', { contenteditable: true }).appendTo('body').focus().remove();

Naja.

Das wichtigste was momentan leider immer noch nicht klappt, sind die Videos. Diese müssen vom Videostreamingserver des RZ abgespielt werden, was leider insgesamt (übertragen, konvertieren, Links umbiegen, verschlüsselt in mehreren Formaten streamen, ...) komplexer war und ist als gedacht - aber es wird daran gearbeitet.

Alles in allem hat die Einführung aber gut geklappt, 100000 Fallstarts wurden schon mit dem neuen Player in diesem Semester durchgeführt (gegenüber 25000 mit dem alten) und die Zahl der Supportanfragen war nicht wesentlich höher als zu Beginn früherer Semester.

Und in 2 Wochen wird die erste echte elektronische Prüfung auf iPads durchgeführt - es bleibt also spannend.