Übungsaufgaben zu Wiki und Content-Management-System

Je Notiz 1 Punkt für eine passende Eigenschaft und 1 Punkt für die Erläuterung mit Bezug zur Notiz, z. B.:

• Notiz 1 – eine zentrale, durchsuchbare Stelle mit nur einer gültigen Fassung: Die Raumbelegung steht auf genau einer Wiki-Seite, die von der Startseite des Bereichs „Sessionplanung“ verlinkt und über die Suche sofort zu finden ist. Dateien wie …_v3_final_NEU entfallen, weil ältere Stände in der Versionsgeschichte liegen und nicht als eigene Kopien.

• Notiz 2 – ein gemeinsamer Stand für alle Teams: Die Eckdaten (Teilnehmendenzahl, Essenswünsche, Zeiten) stehen auf einer Seite, die Orga-Team und Catering-Team gleichermaßen lesen. Wer die Zahl ändert, ändert sie für alle; nichts muss mehr weitergeleitet werden. Wer die Seite beobachtet, bekommt die Änderung zusätzlich gemeldet.

• Notiz 3 – alle Beteiligten können direkt bearbeiten: Emre korrigiert den falschen Schritt selbst auf der Wiki-Seite, statt auf Mia zu warten. Mia sieht später in der Versionsgeschichte, was er geändert hat, und kann bei Bedarf auf der Diskussionsseite nachfragen.

Andere passende Eigenschaften (z. B. Zugriff im Browser von unterwegs bei Notiz 1) sind zu werten, wenn sie das Ärgernis tatsächlich beheben.

• Explizites Wissen (1 Punkt) lässt sich in Worte, Tabellen oder Anleitungen fassen und dokumentieren. Beispiel (0,5 Punkte): die VLAN-Liste mit IP-Bereichen, die Packliste für den Technikaufbau am Freitag, die Anleitung zum Akkutausch der E-Ink-Türschilder, die Fristenliste.

• Implizites Wissen (1 Punkt) beruht auf Erfahrung und Können und lässt sich nur schwer oder gar nicht vollständig aufschreiben. Beispiel (0,5 Punkte): Emres Gespür, welcher Badge-Drucker gleich klemmt; wie man aufgeregte Referierende vor der Session beruhigt; welche Kabelwege sich im Gebäude bewährt haben.

• Weitergabe (1 Punkt): durch Zusammenarbeit, z. B. Emre arbeitet sein Nachfolgeteam beim Technikaufbau 2027 im Tandem ein, Hospitation, Erfahrungsrunde nach dem Barcamp (Lessons Learned). Teile davon lassen sich im Wiki sichtbar machen, etwa als Abschnitt „Typische Probleme und was hilft“ oder mit Fotos und kurzen Videos, und das Wiki nennt Ansprechpersonen.

• Wiki (2 Punkte): eine Sammlung verlinkter Webseiten, die die Nutzenden im Browser selbst anlegen und ändern können. Viele schreiben gemeinsam an einem Nachschlagewerk, das immer den aktuellen Stand zeigt; jede Änderung wird als Version gespeichert.

• Abgrenzung Blog (1 Punkt): Ein Blog ist eine chronologische Folge von Beiträgen einzelner Autor*innen; Lesende können höchstens kommentieren, ältere Beiträge werden nicht weiter gepflegt. Für das Barcamp 2028 braucht das Team aber ein aktuelles Nachschlagewerk („Wie läuft der Check-in?“), keinen Verlauf von Berichten. Ein Blog eignet sich eher für Neuigkeiten auf der öffentlichen Website.

Je Risiko 1 Punkt für das Risiko und 2 Punkte für eine passende, beschriebene Maßnahme. Zwei aus z. B.:

• Veraltete oder falsche Inhalte: Seiten werden nach dem Barcamp nicht aktualisiert, 2028 arbeitet das Team mit falschen Angaben (z. B. alte VLAN-Nummern). Maßnahme: Für jeden Bereich (Technik, Catering, Sessionplanung, Helfende) ist eine Person verantwortlich; jede Seite hat ein Prüfdatum; vier Wochen nach dem Barcamp gibt es eine feste Aufräumrunde.

• Wildwuchs und schlechte Auffindbarkeit: Jede*r legt Seiten nach eigenem Schema an, Inhalte sind doppelt. Maßnahme: Dimitrios Papadopoulos gibt vor dem Start eine Startseite mit Bereichen, Namensregeln und Vorlagen (Checkliste, Anleitung, Protokoll, Lessons Learned) vor.

• Geringe Beteiligung: Viele lesen, kaum jemand schreibt; Lehrkräfte sehen das Wiki als Mehrarbeit. Maßnahme: kurze Einführung beim Kick-off, Startinhalte vorab einpflegen, Wiki in Abläufe einbinden („Eine Aufgabe gilt erst als erledigt, wenn die Anleitung im Wiki steht“).

• Datenschutz und Sicherheit: Telefonnummern von Referierenden oder MQTT-Zugangsdaten landen auf Seiten, die viele lesen; gelöschte Angaben bleiben in der Versionsgeschichte. Maßnahme: Regel „keine Zugangsdaten, nur nötige personenbezogene Daten“, Rechte je Bereich, Zugangsdaten im Passwortmanager der Schul-IT, endgültiges Löschen von Versionen durch die Administration.

• Pflegeaufwand nach dem Weggang der Azubis: Niemand fühlt sich 2028 zuständig. Maßnahme: Übergabe der Bereichsverantwortung an Schüler*innen eines jüngeren Jahrgangs schon im Frühjahr 2027.

Je Zeile 1 Punkt:

Andere passende Funktionen (z. B. Suche, Vorlagen, Diskussionsseite) sind zu werten, wenn sie die Anforderung erfüllen.

Ein CMS ist eine Software, mit der man digitale Inhalte (Texte, Fotos, Videos, Downloads) einer Website erstellen, verwalten und veröffentlichen kann (1 Punkt), ohne Programmier- oder HTML-Kenntnisse zu brauchen – die Redaktion arbeitet in einer Oberfläche im Browser (1 Punkt).

• Trennung (1 Punkt): Inhalte werden in der Datenbank gespeichert, das Aussehen wird getrennt davon in Themes (Vorlagen) festgelegt. Die Schule kann das Layout austauschen, ohne Inhalte anzufassen, und Redakteur*innen müssen sich beim Schreiben nicht um die Gestaltung kümmern.

• Dashboard (Bearbeitungsanwendung, Content Management Application, Backend) (1 Punkt): Oberfläche für die Redaktion im Browser; dort werden Texte geschrieben, Fotos und Videos hochgeladen und der Platz im Menü festgelegt.

• Delivery engine (Auslieferungsanwendung, Content Delivery Application, Frontend) (1 Punkt): Ruft jemand eine Seite auf, holt sie den Inhalt aus der Datenbank, setzt ihn in das aktive Theme ein und liefert die fertige HTML-Seite aus (dynamische Seitenerzeugung).

Je CMS 0,5 Punkte, Wiki-Software 1 Punkt.

• CMS z. B.: WordPress, TYPO3, Joomla, Drupal (auch Baukästen wie Wix oder Headless-CMS wie Strapi sind zu werten).

• Wiki-Software z. B.: MediaWiki, DokuWiki, BookStack, Wiki.js, XWiki, Confluence.

Je Panne 1 Punkt für die passende Funktion und 1 Punkt für den beschriebenen Einsatz im Barcamp-Bereich, z. B.:

• P1 → Inhaltstypen mit festen Feldern (Seitenvorlagen): Das Software-Team legt einen Inhaltstyp „Session“ mit den Feldern Titel, Referierende, Raum, Slot, Kurzbeschreibung, Folien und Video an. Wer eine Session-Seite anlegt, füllt nur die Felder aus; Anordnung und Gestaltung kommen aus dem Theme der Schulwebsite. So sehen alle Session-Seiten gleich aus, egal wer sie erstellt.

• P2 → Rollen und Rechte: Schüler*innen bekommen nur die Rolle Autor*in für Beiträge im Barcamp-Bereich. Sie dürfen dort Entwürfe schreiben, aber weder das Menü noch fremde Seiten ändern noch selbst veröffentlichen; Menü und Startseite bleiben der Redaktion und der Administration vorbehalten. Jede Person erhält nur die Rechte, die sie für ihre Aufgabe braucht.

• P3 → zeitgesteuerte Veröffentlichung mit Ablaufdatum: Die Seite zum Call for Participation bekommt das Ablaufdatum 31.01.2027 und verschwindet danach von selbst aus Menü und Startseite. Der Sessionplan wird vorbereitet und erscheint automatisch am 01.03.2027.

• P4 → Medienverwaltung: Das CMS erzeugt beim Hochladen automatisch verkleinerte Bildgrößen für Smartphone und Galerie. Pflichtfelder für Alternativtext, Bildrechte und Fotoeinwilligung verhindern, dass ein Bild ohne diese Angaben eingebunden wird.

Andere passende Lösungen sind zu werten, wenn sie die Panne verhindern, z. B. bei P2 ein Freigabe-Workflow für Änderungen am Menü oder die Versionsverwaltung, mit der sich der gelöschte Menüpunkt wiederherstellen lässt (verhindert die Panne aber nicht). Nur genannte Funktionen ohne Beschreibung des Einsatzes zählen je 1 Punkt.

Je Station 1 Punkt:

Statt der Schulleiterin ist auch eine andere verantwortliche Person (z. B. Website-Verantwortliche der Schule) richtig, wenn Prüfung und Freigabe getrennt sind.

• Spätestens bei der Prüfung (Station 2) muss Dimitrios Papadopoulos die Fotoeinwilligungen mit den Anmeldedaten abgleichen (1 Punkt). Besser schon beim Hochladen: Das Pflichtfeld „Einwilligung liegt vor“ in der Medienverwaltung zwingt die Autorin, die Einwilligung zu prüfen.

• Umgang (1 Punkt): Das Foto wird nicht veröffentlicht, durch ein anderes ersetzt oder Fatma wird unkenntlich gemacht (Bildausschnitt, Verpixeln). Ohne Einwilligung bzw. andere Rechtsgrundlage dürfen personenbezogene Daten wie ein erkennbares Foto nicht veröffentlicht werden (DSGVO, Kunsturhebergesetz); bei Minderjährigen ist besondere Vorsicht geboten. Wird das Foto erst später entdeckt, reicht Löschen von der Seite nicht: auch alte Versionen und Bildgrößen in der Medienverwaltung entfernen.

Zwei Gründe à 1 Punkt, z. B.:

• Im Wiki dürfen alle Beteiligten ohne vorherige Prüfung ändern; für öffentliche Inhalte, für die die Schule verantwortlich ist, braucht es eine Freigabe durch eine verantwortliche Person (Workflow im CMS).

• Das Orga-Wiki enthält interne Informationen (Notfallkontakte, Netzplan, Zugangswege), die nicht öffentlich sein dürfen.

• Die Barcamp-Seite soll im Design der Schulwebsite erscheinen (Themes, Navigation); ein Wiki ist schlicht gestaltet und als Nachschlagewerk aufgebaut.

• Funktionen für Besucher*innen wie Veranstaltungskalender, Kontaktformular und zeitgesteuerte Veröffentlichung bietet das CMS.

• Grund gegen ein CMS (1 Punkt): Die Projektseite ändert sich kaum. Bei seltenen Änderungen lohnt sich ein CMS nicht; Installation, Updates und Absicherung kosten mehr, als die Redaktion spart. Statische Seiten sind schneller, günstiger und bieten weniger Angriffsfläche.

• Barcamp-Bereich (2 Punkte): Die Inhalte ändern sich häufig (Call for Participation, Sessionplan mit Verschiebungen, Nachberichte, Folien, Videos), und viele Personen ohne HTML-Kenntnisse schreiben mit (Schüler*innen, Referierende, Orga-Team). Inhalte müssen vor der Veröffentlichung geprüft werden (Datenschutz, Fotoeinwilligungen). Das CMS läuft ohnehin schon für die Schulwebsite und wird von der Schul-IT gewartet – zusätzlicher Betriebsaufwand entsteht kaum. Deshalb ist das CMS hier die bessere Wahl.

Bewertungshinweis: Eine gut begründete abweichende Entscheidung (z. B. statischer Seitengenerator mit Markdown und Git, weil das Software-Team ohnehin mit Git arbeitet) ist mit voller Punktzahl zu werten, wenn Änderungshäufigkeit und Freigabe berücksichtigt werden.

Je richtiger Zuordnung 1 Punkt:

Übrig bleiben ERP (Enterprise Resource Planning, Planung von Ressourcen wie Material, Personal, Finanzen) und CAD (Computer-Aided Design, rechnergestütztes Konstruieren).

Je Angebot 2 Punkte für eine sinnvolle, auf die Situation bezogene Begründung. Naheliegend:

Andere Auswahl mit guter Begründung ist zu werten. Weniger geeignet: FAQ auf der öffentlichen Seite (richtet sich an Teilnehmende, nicht an Helfende; interne Abläufe gehören nicht in die Öffentlichkeit), Chatbot (Aufwand für einen einzigen Tag, Antworten ggf. ungeprüft), gedrucktes Handbuch (nicht aktuell, am Stand unhandlich; höchstens als einseitige Notfallkarte bei Netzausfall sinnvoll).