shakedal1/Vorlesungsdeck-Neufassung

Was macht Vorlesungsdeck-Neufassung?

Ein trockenes Kursdeck in eines verwandeln, aus dem Studierende wirklich lernen. Die Ausgabe ist ein deck aus dem Slides-Artefakttyp (eines pro Sprache). Alles zu Folienformat, Dateien und Veröffentlichung stammt aus den Anweisungen dieses Typs. Dieses Skill fügt die Lehrgestaltung, die Animations- und Befehlsregeln sowie die hebräische RTL-Technik hinzu.

Lies references/patterns.md vor dem Schreiben der ersten Folie. Es enthält kopierfertiges Markup für jedes unten genannte Muster.

1. Die gesamte Quelle zuerst lesen

• PDF: Read mit pages in Blöcken von maximal 20, bis jede Seite gesehen wurde. PPTX: das pptx-Skill verwenden, um Text und Bilder zu extrahieren.
• Beim Lesen auflisten: die Themen in der Reihenfolge, jeden Befehl oder Codeausschnitt, jede Definition, jedes Quiz oder jede Frage, die bereits im Deck enthalten sind, und alle Folien, die denselben Screenshot mit einer geänderten Beschriftung wiederholen. Diese wiederholten Folien sind das Erste, was zusammengeführt wird.
• Außerdem jedes Bild auflisten, das es wert ist, behalten zu werden: Fotos, reale Objekte oder Modelle, Tool- Screenshots und Abbildungen, die etwas zeigen, das eine Handzeichnung nicht kann. Die jeweilige Seite und grobe Position in der Read-Vorschau notieren, weil du es später zuschneiden wirst (§6).
• Jede Tatsache aus der Quelle behalten: Namen, Daten, E-Mails, Bewertungen, Links, Befehls- flags. Niemals Zahlen, Zitate oder Tool-Verhalten erfinden, die nicht aus der Quelle oder der Logik des Beispiels selbst ableitbar sind.

2. Die Lehreinheit planen, dann bauen

Dem Benutzer den Plan in einer Zeile mitteilen und beginnen. Nicht auf Genehmigung warten.

• Ein durchgängiges Beispiel. Das eigene Beispiel der Quelle nehmen und ihm ein konkretes physikalisches Bild geben (ein 3-Bit-One-Hot-FSM wurde zu „Ein 3-Lampen-Lichtläufer“). Es auf jeder Folie wiederverwenden: Eigenschaften werden zu einfachen Fragen darüber, Ergebnisse werden in seinen Begriffen erklärt.
• Eine Analogie pro Konzept, aus dem Alltag, kursiv auf der Folie neben der formalen Definition geschrieben (Simulation vs. formal = 1.000 Schlüssel ausprobieren vs. ein Schlosser, der den Mechanismus nachweist; Reset = „Neues Spiel“; Takt = Metronom; Grenze = nächste Kaffeebar auf der Straße; Debugging „Warum“ = ein Detektiv, der in der Zeit zurückgeht).
• Alle 4–6 Folien Quizfragen: Vorhersage-vor-Ausführung, per Hand nachvollziehen, „Was wäre, wenn wir X ändern“, Wahr/Falsch. Die Antwort ist ein gepinntes Feld, das beim Klick aufgebaut wird; die Antwort auch in die Sprechernotizen setzen.
• Die Bilder der Quelle behalten und den Rest zeichnen. Der Benutzer möchte die relevanten Bilder des Originals im Deck haben. Sie nicht zugunsten von Zeichnungen weglassen. Für jedes Bild auf deiner Liste:
  • Wenn es dasselbe zeigt, was eine deiner Zeichnungen zeigen würde (einen Auflösungsstreifen, ein echtes Tool-Fenster, einen Vorher/Nachher-Vergleich), das Bild anstelle der Zeichnung verwenden.
  • Wenn es etwas hinzufügt, das eine Zeichnung nicht kann (ein echtes Foto, ein echtes 3D-Modell, einen echten Datensatz), es neben deine laufende Beispielzeichnung auf dieselbe Folie setzen, mit einer einzeiligen Bildunterschrift, die die beiden verbindet.
  • Wenn es rein dekorativ ist oder ein anderes Bild wiederholt, es weglassen und im Bericht nennen. Als SVG/Divs (patterns.md) zeichnen, was die Quelle nur in Worten sagt: Zustands- diagramme, Wellenformen, Zeitachsen, Zahlenstrahlen, schrittweiser Aufbau des durchgängigen Beispiels.
• Eine Idee pro Folie, etwa 20–26 Folien. Den Rhythmus verwenden: dunkle Aussagenfolien für das Cover, jeden Abschnittsöffner und die Zusammenfassung; helle Inhaltsfolien; einen warm getönten Hintergrund für Quizfolien.
• Mit einem Spickzettel enden: jeder Befehl in der Reihenfolge mit einer 2–3-Wort-Erläuterung, plus einem Glossar der Schlüsselbegriffe.

3. Animation ist erforderlich, nicht optional

Der Benutzer hat mehr Animation gewünscht. Jedes Deck muss:

• data-transition auf jeden Abschnitt setzen: fade für die meisten, push beim Übergang in einen neuen Abschnitt, magic zwischen zwei Folien, die dasselbe Diagramm in zwei Zuständen zeigen.
• Jede Inhaltsfolie hat mindestens eine Build-Sequenz: die Schlüsselelemente sind position:absolute-Kinder mit data-build-in="<Effekt> <Reihenfolge>", sodass sie im Präsentationsmodus nacheinander erscheinen. Builds funktionieren nur auf gepinnten Kindern, daher werden Folien, die Schritt für Schritt enthüllen, mit expliziten left/top/width-Angaben angelegt.
• Builds verwenden, die lehren. Einen Ablauf Schritt für Schritt enthüllen (rise 1, rise 2, …), einen Zustandsautomaten Pfeil für Pfeil zeichnen (ein gepinntes SVG pro Pfeilgruppe), einen Wellenform-Zyklus für Zyklus durchgehen, die Analogie nach der Definition enthüllen und Quizantworten zuletzt anzeigen.
• Magic-Move verwenden, um eine Änderung zu animieren: gleiche id auf dem passenden gepinnten Element von zwei aufeinanderfolgenden Folien (eine Lampe, die aufleuchtet, eine Hervorhebung, die zum nächsten Zyklus wandert, ein Intervall, das schmaler wird).
• Effekte zweckgerichtet variieren: rise für Listen und Schritte, pop für ein Ergebnis oder ein Häkchen, left/right für Dinge, die aus einer Richtung kommen, fade für Anmerkungen, scale für die große Enthüllung. Nicht mehr als etwa 6 Builds pro Folie verwenden.

4. Befehle müssen von der Folie springen

Der Benutzer hat auffälligere Befehle gewünscht. Jeder Befehl, jedes Flag oder jede Tcl- oder Shell- Zeile verwendet den Befehlschip aus patterns.md, und nichts anderes im Deck sieht so aus:

• Ein eigener Block (<p>), niemals inline in einem Satz. Spans können nur Farbe tragen, daher wird font-family auf einem Span stillschweigend ignoriert.
• Eine nichtproportionale Schrift (JetBrains Mono) mit 32–40px, fett. Dunkler Chip-Hintergrund, eine helle Akzentfarbe, die nur für Befehle reserviert ist, ein dicker Akzentbalken an der Vorderkante und ein Prompt-Glyphe (% für Tcl, $ für Shell).
• Neben jedem Chip eine kurze Beschriftung, die angibt, was er tut („kompilieren“, „alles beweisen“).
• Auf einer Schrittfolie ist der Befehlschip das größte Element nach dem Titel und wird zuerst eingeblendet.
• Code-Listings (ganze Dateien) verwenden einen separaten, ruhigeren Code-Kartenstil, sodass Befehle sich dennoch von ihnen abheben.

5. Sprachen

Wenn der Benutzer zwei Sprachen wünscht, zwei separate Decks vom Typ erstellen, mit demselben Folien-IDs und Inhalt. Zuerst die Ausgangssprache (oder Englisch) erstellen, dann die andere. Hebräisch benötigt die RTL-Technik in patterns.md: jeden hebräischen Textblock mit ⁧…⁩ isolieren, Inline-Code innerhalb von Hebräisch in ⁦…⁩ einschließen, text-align:right und row-reverse-Reihen verwenden, Tabellenspaltenreihenfolge umkehren, ← in Sequenzen verwenden und jede durch <br> getrennte Zeile separat isolieren. Code, Befehls- chips, Wellenformen und GUI-Drahtgittermodelle linksläufig lassen. Rubik deckt Hebräisch und Lateinisch ab.

6. Bauen und veröffentlichen

Den eigenen Anweisungen des Slides-Typs für Dateien und Aufrufe folgen, mit diesen aus der Nutzung gewonnenen Regeln:

• project/deck.json schreiben (vollständige order, sections, faces) und das Cover, veröffentlichen, dann etwa 4 Folien pro Runde schreiben und veröffentlichen.
• Eine Veröffentlichung mit edits kann nicht gleichzeitig files enthalten. Mit dem Edit-Tool bearbeiten, dann die Dateien veröffentlichen.
• Wenn eine Veröffentlichung mit einem Netzwerkfehler fehlschlägt, dieselben Dateien erneut senden. Das ist sicher.
• Quellbilder aus einem PDF zuschneiden (bevor die Folien geschrieben werden, die sie verwenden):
  • Das PDF in einen eigenen neuen Ordner im Scratchpad kopieren und die Zuschnitte in einen separaten assets-Ordner schreiben.
  • Die Seitengröße mit python -I -c "import pypdf,sys;print(pypdf.PdfReader(sys.argv[1]).pages[0].mediabox)" <pdf> ermitteln. PyMuPDF und Pillow sind hier nicht installiert; pdftoppm (MiKTeX) ist vorhanden. Seine Warnung „benötigt Windows 10“ ignorieren.
  • Direkt von der Seite zuschneiden: pdftoppm -f N -l N -r 250 -x X -y Y -W W -H H -png -singlefile <pdf> <assets>/<name>. Die Koordinaten stammen aus der Read-Vorschau: Maßstab = (250 / 72) × Seitenbreite in pt / Vorschaubreite in px. Eine 720-pt-Seite, die 1000 px breit als Vorschau angezeigt wird, ergibt ×2,5.
  • Jeden Zuschnitt einmal Readen und seine Kanten fixieren, bevor er hochgeladen wird: ein Streifen des benachbarten Bildes ist üblich.
  • Einen Streifen mit Panels (z. B. ein Bild bei 7 Auflösungen) in einen Zuschnitt pro Panel aufteilen, damit die Panels nacheinander eingeblendet werden können.
  • Alle Zuschnitte in einem Aufruf hochladen: Artifact publish mit url, asset: true und file_paths (bis zu 25). Jedes zurückgegebene /_blob/<id> direkt in <img src> mit object-fit:contain verwenden und einer Breite/Höhe, die dem Seitenverhältnis des Zuschnitts entspricht.
  • Aus einer PPTX die Bilder nehmen, die das pptx-Skill extrahiert, dann auf die gleiche Weise hochladen.
• Die Höhe budgetieren: 824px innerhalb der Ränder. Titelblock ≈130px, Tabellenzeile ≈ 2,1 × Schriftgröße pro Zeile, gepinnte Boxen müssen oberhalb von y 952 enden. Text vor dem Verkleinern kürzen und Text bei 24px oder größer halten.
• Nicht rendern oder einen Screenshot erstellen, um zu überprüfen, es sei denn, der Benutzer fragt.

7. Bericht

Jeweils den Link zum Deck angeben, was im Vergleich zum Original geändert wurde (das durchgängige Beispiel, die Analogien, die Illustrationen, welche Quellbilder behalten wurden, wo und welche weggelassen wurden, die Quizfragen, die Animationen, das Befehl-Stil, welche sich wiederholenden Folien zusammengeführt wurden), und was nicht überprüft wurde. Den Benutzer daran erinnern, dass die Decks privat sind, bis sie geteilt werden.