Mit Untis erstelle ich einen Vertretungsplan. Das ist aber nur die halbe Geschichte, denn der schönste Plan nutzt nichts, wenn ihn niemand kennt. Deshalb muss der erstellte Plan auch irgenwie publik werden.

Dazu werden meistens HTML-Dateien erzeugt und exportiert. Das sind sogar meistens mehrere Dateien: für jeden Tag eine, also mindestens für heute und morgen, aber auch das in verschiedenen Fassungen, nämlich als Ansicht gedacht für die Schülys (mit weniger Informationen), für die Lehrkräfte (mit mehr Informationen), für die Anzeige in der App, für die Anzeige auf einem Monitor in der Schule.

Ganz unten in diesem Blogeintrag stehen ein paar Ideen zum Basteln, die sind dann vielleicht wieder für mehr Leute interessant. Denn es wird jetzt eine ganze Weile recht technisch, weil der Weg vom Vertretungsplanprogramm zum Monitor kein so ganz einfacher ist. Vielleicht macht ihn diese Grafik etwas verständlich? (Draufklicken zum Vergrößern.)

Kleiner Scherz. Ich weiß schon, dass das verwirrend aussieht. Das Diagramm ist ein in der Informatik verwendetes Klassendiagramm, das ich hier zweckentfremdet habe. Aber ich kann es selber gut lesen, und ich habe die Information auch in einer anderen Diagrammform dargestellt, wo sie mir noch unübersichtlicher erscheint.

1. Wie die HTML-Seiten entstehen

Das grüne, das ist das Vertretungsplanprogramm Untis. Damit kann man unterschiedliche Vertretungsformate erzeugen, und außerdem unterschiedliche Monitor-HTML. Das heißt so, weil das HTML produziert für die Ausgabe an einem Monitor. Dabei ist jedem HTML-Format ein Vertretungsformat zugeordnet (da kommen die Informationen her) und ein Ausgabetemplate, eine Art HTML-Vorlage (das bestimmt das Aussehen der HTML-Seite). Diese Zuordnung läuft nur, soweit ich das weiß, implizit über Namensgleichheit; Untis sucht in einem speziellen Verzeichnis nach einem passenden Template, wenn ein solches Verzeichnis angegeben ist; sonst sucht es in einem Standardverzeichnis danach. Zu jedem Monitor-HTML gehört nun wieder ein eigenes Ausgabeverzeichnis, und in dem landen dann die fertigen HTML-Seiten und die Aufgabe von Untis ist erledigt. Wir haben vorliegen: verschiedene Verzeichnisse mit verschiedenen HTML-Dateien darin, verschiedene Vertretungspläne darstellend.

2. Wie die HTML-Seiten zum Server kommen

Wenn man die Software DSB (Digitales Schwarzes Brett) nutzt, übernimmt ab diesem Zeitpunkt diese. Dazu muss man lokal auf dem Rechner eine Software DSBsync installieren, das ist das gelbe im Diagramm. DSBsync überwacht die angegebenen lokalen Verzeichnisse auf geänderten Inhalt und lädt diesen auf einen zentralen Firmenserver hoch. Dazu muss DSBsync wissen, a) welche Verzeichnisse überwacht werden sollen und b) wo deren Inhalt auf dem Server landen sollen. Potentielle Landeplätze auf dem Server sind hier bereits vorgegeben, das heißt, man muss davor auf dem Server mögliche Landeplätze anlegen. Diese Zuordnung von lokalen Verzeichnissen zu serverseitigen Landeplätzen ist die Aufgabe des im Hintergrund stets weiter laufenden DSBsync und damit ist dieser Punkt erledigt. (Das orange, das ist der potentielle Landeplatz.)

3. Wie der Monitor weiß, was er anzeigen soll

Das orange, das ist jetzt der Server, oder eher: die Webzugangsseite zum Server, mit der man bestimmte Einstellungen vornehmen kann. (Ja, genau da legt man die potentiellen Landeplätze für das hochgeladene Zeug aus den lokalen Verzeichnissen, mithin HTML-Dateien, an.)

Man verwaltet auf der Webseite mehrere Digitale Schwarzer Bretter, die entweder App-Zugänge sind (jeweils mit eigenen, selbst gewählten Zugangsdaten; die App selber ist vorgegeben) oder Monitore (die im Schulgebäude verteilt und ans Internet angeschlossen sind). Die App-Zugänge lasse ich mal weg und konzentriere mich auf die Monitore.

Für jeden Monitor kann man verschiedene Bildschirmeinteilungen anlegen; immer eine davon ist gerade aktiv, die anderen behält man für besondere Anlässe in der Hinterhand.

Jede Bildschirmeinteilung kann aus mehreren Multimediamodulen bestehen, das sind letztlich wohl HTML-Frames. Die können nach Belieben platziert sein – eine kleine Fußzeile oben, zwei große Bereiche nebeneinander darunter, eine etwas größere Fußzeile darunter, ganz wie man will.-

Jedem Multimediamodul (jedem Frame) ist ein Spot zugewiesen. Spots tragen den eigentlichen Inhalt. Derselbe Spot kan in verschiedenen Modulen in verschiedenen Bildschirmeinteilungen für verschiedene Monitore verwendet werden. Es gibt verschiedene Arten von Spots: Bild, Diashow, Powerpointdatei, Videodatei, Webseite. Im Kopfzeilen-Frame könnte man einen Bild-Spot zeigen, im Fußzeilen-Frame einen Film- oder Diashow-Spot. Das sind alles relativ statische Inhalte, die man nur ändern kann, indem man sich auf der Webseite einloggt und manuell etwas umstellt. Für den Vertretungsplan wäre das umständlich. (Gut, über eine eingebundene Webseite lässt sich auch immer Verschiedenes zeigen.)

Und dann gibt es eine besondere Art Spot, den DSBSync-Spot. Das ist der Spot, dessen Inhalt man ändern kann, ohne sich eigens einloggen zu müssen. Denn das ist der Spot, der seine Informationen aus dem mit DSBsync synchronisierten lokalen Verzeichnis erhält. Ein DSBSync-Spot fragt etwa minütlich beim Firmenserver nach, ob dort neue Inhalte angekommen sind, lässt sie sich schicken und zeigt sie dann an. Das können übrigens auch Video- oder Bilddateien sein, oder eben, wie im Fall des Vertretungsplans, die von Untis erzeugten HTML-Seiten.

4. Geht das nicht auch einfacher?

Kriege ich die HTML-Dateien nicht auch ohne DSB auf den Monitor? Klar. Also, ich nicht, aber jemand, der sich ein wenig auskennt, kann das sicher gut machen. Zu jedem Monitor braucht man einen Rechner, der im Netzwerk hängt und auf dem ein Browser die in einem zentral zugänglichen Verzeichnis gespeicherten HTML-Dateien anzeigt und dabei die Seite jede Minute aktualisiert, weil ja inzwischen die Datei durch eine neue Fassung ersetzt worden sein könnte. Man müsste einmal ein HTML-Frame-Gerüst bauen mit einer linken Seiten für „heute.htm“ und einer rechten für „morgen.htm“. Automatisches Scrolling noch irgendwie dazu, wenn die Seite mal zu lang für den Platz werden sollte. Und halt die beiden Dateien regelmäßig ersetzen, das ginge wohl wie bisher.

Am umständlichsten scheint auf den ersten Blick die DSBsync-Brücke. Aber da fällt mir keine andere gangbare Lösung ein. Vor allen kann ich so von der Schule aus eine DSBsync-Verbindung anlegen, die mein Büro-Verzeichnis S:/ mit dem Sync-Spot „Plan Lehrkräfte heute“ verbindet, und von zuhause aus eine DSBsync-Verbindung anlegen, die mein Verzeichnis Z:/ mit demselben Sync-Sport verbindet. Heißt, ich kann den Vertretungsplan dann nicht nur zuhause machen, das geht ja leicht, sondern auch die Monitore und die App von zuhause aus mit diesem Plan befüllen. Theoretisch.

Das nur für den Fall, dass ich doch mal wegen Corona oder so zuhause bleiben müsste. Die Informationen darüber, wer neu erkrankt ist und wer welche Wünsche hat, müssten dann nur noch auf einem geeigneten Weg zu mir kommen.

5. Bastelideen

Man kann Schneeflocken über den Vertretungsplan rieseln lassen, so wie wir in unseren Blogs vor zwanzig Jahren. Bei uns ein alter Hut, auf dem Vertretungsplan vielleicht noch originell. Muss man nur ein bisschen Javascript ins Untis-Template packen. Eine verlinkte js-Datei funktioniert vielleicht nicht, das habe ich aber noch nicht ausprobiert.

Man kann Bilder unterhalb der Vertretungsstunden anzeigen, zum Beispiel jeden Tag ein neues als Adventskalender, oder einen Adventskranz mit brennenden Kerzen als Video. (Gif ging bei mir nicht; vielleicht wird die Größe konvertiert und dabei geht die ANimation verloren.) Das geht über einen Sync-Spot.

Man kann den Vertretungsplan in einer neuen Schriftart darstellen, passend zu Weihnachten oder Halloween. (Auf offene Lizenzen achten, Urheberrecht.) Eigentlich ist es nicht schwer, eine Schriftart mitzuschicken, man schreibt dazu nur in einem <style>-Block:

@font-face {
  font-family: Schriftartname;
  src:url('schriftartdatei.otf');
  font-weight: normal;
  font-style: normal;
}

und wählt dann, immer noch bei den style-Angaben, für Body als Stil:

body: Schriftartname, Arial, Helvetica, sans-serif;

Dazu muss die URL der eingebetteten Schriftart stimmen, hier ist es ein relativer Pfad. Am DSB funktioniert das aber nicht. (Ich glaube, das liegt daran, dass Schriftartendateien gar nicht erst in die Sync-Spots hochgeladen werden. Außerdem würden sie ohnehin wie alle anderen dort hochgeladenen Dateien umbenannt in gehashte Form und wären dann auch nicht verfügbar.) Absolute Pfade zu anderen URLs gehen auch nicht.

Also muss man die Schriftart in die HTML-Datei selber einbauen, dann wird sie auf jeden Fall mitgeschickt. Das geht, indem man die Schriftart in Base64 als Textzeichen kodiert und so einbaut:

@font-face {
  font-family: 'Schriftartname';
  src: url(data:application/font-woff;
charset=iso-8859-1;base64,......................) format('woff');
  font-weight: normal;
  font-style: normal;
}

Da, wo die vielen Punkte stehen, steht stattdessen eine laaaaaaaaange Folge der Zeichen A-Z, a-z, 0-9, / und + (und ganz am Ende =) – in meinem Schriftartenbeispiel etwa 115.000 solcher Zeichen. Klingt viel, sind aber immer noch nur etwa 115 KB. Diese Zeichenfolge ist die Repräsentation der Schriftart-Datei in einem speziellen 64er-Stellenwertsystem. (Und das charset muss zur Seite passen, kann also auch utf-8 sein.)

Das Ergebnis sieht dann so aus, oben die neue Schriftart, unten das Standard-Arial:

Nichts für jeden Tag, aber kann man doch mal machen.

6. Warum das alles?

Ich wollte nur mal herausfinden, wie das funktioniert. Auch weil ich die Möglichkeit haben wollte, von zuhause aus auf die Monitore zuzugreifen. Und weil ich sonst hätte korrigieren müssen.