Präsentiert man im Bereich der Softwareentwicklung, ist es häufig sinnvoll oder gar nötig, „Butter bei die Fische“ zu packen – direkt Quellcode zumindest auszugsweise zu präsentieren. Ob auf Fachkonferenzen, im Rahmen von Code Reviews oder gar in Prüfungs-Präsentationen1: Es hat wohl fast jeder Entwickler schon hunderte2 Folien voller „totem“, schlecht lesbarem und in viel zu kleiner Schrift gesetztem Code über sich ergehen lassen müssen – weder wirklich beeindruckend noch ernsthaft zielführend. Davon, wie man Sourcecode besser präsentiert, handelt dieser Artikel. Für den Eiligen findet sich am Ende des Artikels eine kompakte, priorisierte Checkliste.
Sourcecode auf Folien ist ein wenig wie Trockenblumen: hübsch, aber tot. Nur lebendiger Quellcode lässt sich lebendig präsentieren – und das geht nur in der IDE. Mit der eigenen Entwicklungsumgebung zu präsentieren, dürfte fast immer authentischer wirken – und ermöglicht es, flexibel mit dem Publikum und seinen Fragen zu interagieren.
Nun könnte man annehmen, man könne sich auf diese Weise die ungeliebte Vortrags-Vorbereitung sparen – schnell das Notebook an den Beamer anschließen, aus dem Standby aufwecken und einfach nur in der IDE da weitermachen, wo man gerade aufgehört hat. Das ist leider nicht der Fall – ein wenig Vorbereitung ist unvermeidbar und das eine oder andere ist zu beachten:
Den Quellcode für die Präsentation vorbereiten
Niemand präsentiert den Inhalt z. B. eines Papers, indem einfach die PDF mit dem Beamer an die Wand geworfen wird. Ebenso wenig sinnvoll ist es, Quellcode unverändert zu präsentieren – meist sind zumindest an den auf jeden Fall zu präsentierenden Stellen Anpassungen notwendig, um den Sourcecode „präsentabel“ zu machen:
- Der Umbruch sollte angepasst werden. Was während der Entwicklung hilfreich ist, kostet beim Präsentieren u. U. schlicht zu viel Platz: Die Breite der Zeilen sollte so gering sein, dass eine lesbare Schriftgröße möglich ist – die Tiefe der Einrückungen sollte also ggf. reduziert werden. Mit der Höhe – der Anzahl der Zeilen – muss ebenfalls sorgsam umgegangen werden3: Öffnende und schließende Klammern beispielsweise in eigene Zeilen zu setzen, erhöht zwar die Lesbarkeit des Codes am Bildschirm ungemein, nimmt aber beim Präsentieren meist zu viel Platz weg – mehr Code am Stück zeigen zu können, ist i. d. R. wichtiger und für das Verständnis hilfreicher.
{
abort();
} | { abort(); } |
- Sie haben wirklich wenig Platz: Meist sind nur die oberen zwei Drittel des Bildschirms wirklich für das gesamte Publikum sichtbar (s. u.).
- Kommentare sind im präsentierten Code ausnahmsweise überflüssig. Auch, wenn man gern zeigen möchte, dass man lege artis kommentiert: Die meisten Menschen können nicht gleichzeitig lesen und zuhören – und das, was normalerweise in Ihren Kommentaren zu lesen sein sollte, gehört im Falle der Präsentation von Code auf die „Tonspur“. Ebenso, wie eine Präsentation kein Handout ist (vgl. hier), ist präsentierter Sourcecode eben etwas anderes als der „echte“ Code, den man (natürlich wohlkommentiert) in das Repository übergibt.
- Zu guter letzt: Der Code sollte möglichst noch funktionieren. Ein Vorteil des Präsentierens mit der IDE ist ja gerade das flexible und lebendige Präsentieren – und dazu gehört m. E., quasi in vivo arbeiten zu können, bei Bedarf den Code auch ausführen oder debuggen zu können. Wenn irgend möglich, sollte der Code also das Umformatieren „überleben“ – „toten“ Code kann man auch mit PowerPoint präsentieren.
Die IDE für die Präsentation einrichten
Eine IDE ist von Haus aus kein Präsentationswerkzeug. Um sinnvoll mit einer IDE zu präsentieren, sind meist Anpassungen notwendig:
- Die Schrift sollte so groß wie irgend möglich gewählt werden. Die maximal sinnvoll nutzbare Schriftgröße hängt naturgemäß sehr stark vom zu präsentierenden Code ab – die Schriftgröße sollte also erst endgültig festgelegt werden, nachdem der Code für die Präsentation vorbereitet wurde (s. o.). Eine „Faustregel“ für die minimale Schriftgröße anzugeben, erscheint mir übrigens wenig sinnvoll: Was noch erkennbar ist, hängt stark von der Größe des Raumes ab.
- Das GUI der IDE sollte minimiert werden, es sollte kein Platz für während der Präsentation nicht benötigte Werkzeugleisten o. ä. verschwendet werden. Eventuell bietet der Editor sogar einen „full-screen mode“, der zum Präsentieren geeignet ist – dann sollte man allerdings beachten, dass der untere Teil des Bildschirms u. U. aus den hinteren Reihen nicht sichtbar ist (s. u.).
- Die Syntaxhervorhebung sollte ggf. angepasst werden. Was am eigenen Monitor gut erkennbar und gut unterscheidbar ist, ist als projiziertes Beamer-Bild unter Umständen kaum noch erkennbar oder nicht auseinander zu halten. Gibt es (z. B. durch die Defaults einer extrem verbreiteten IDE) einen Standard, sollte man diesen allerdings möglichst nur behutsam verändern – die (Code‑)Lesegewohnheiten des Publikums sind meist recht ausgeprägt; das Publikum zu irritieren, ist wenig hilfreich. Existieren für die Syntaxhervorhebung keine Quasi-Standards, sollten erkenn- und unterscheidbare Farben gewählt werden. In jedem Fall empfiehlt es sich, die Farbwahl mit dem für die Präsentation vorgesehenen Beamer zu testen – am besten unter realistischen Lichtverhältnissen. Zeigt man „klassische“ Folien (und nicht direkt die IDE), empfiehlt es sich, Screenshots aus der IDE zu präsentieren – auf diese Weise kann mit wenig Aufwand die „normale“ Syntaxhervorhebung übernommen werden. Auch für Screenshots aus der IDE gilt übrigens natürlich alles hier Gesagte – und zusätzlich der Hinweis, dass diese am besten in der Ziel-Auflösung angefertigt (und nicht nachträglich bis zur Unschärfe vergrößert) werden sollten.
Raum und Bildschirm sinnvoll einrichten
Ist es im Falle „normaler“ Präsentationen manchmal geradezu eine Gnade, nicht alle Zeilen der überfüllten Folie sehen zu müssen, ist dies beim Präsentieren von Code fatal: Präsentiert man Quellcode, kommt es auf jede Zeile an. Problematisch ist nun, dass (abhängig davon, wie hoch die Leinwand hängt) zumindest die hinteren Reihen des Publikums meist nur die oberen zwei Drittel des Beamer-Bildes wirklich sehen können – der Rest ist häufig von den Köpfen der weiter vorne Sitzenden mehr oder minder verdeckt. In den meisten Vortragsräumen lässt sich dementsprechend nur der obere Teil des Bildes wirklich für die Präsentation nutzen. Besonders fatal wirkt dieses Problem übrigens bei „Live-Demos“ an der Kommandozeile: Spätestens nach den ersten paar Befehlen ist man am unteren Rand des Konsolen-Fensters angekommen und das Geschehen findet womöglich für große Teile des Publikums unsichtbar statt. Es hilft nur eins: Beschränken Sie sich auf den oberen Teil des Bildschirms – und testen Sie aus der letzten Reihe, welchen Teil Sie trotz der vielen Köpfe zwischen Ihnen und der Leinwand noch sicher sehen können. Dieser Hinweis gilt natürlich auch, falls Sie Sourcecode mit „klassischen“ Folien4 präsentieren: Jede einzelne Zeile muss auch von ganz hinten sicht- und lesbar sein.
Gerade bei „Live-Demos“ neige ich dazu, das Problem der hinteren Reihen „im Eifer des Gefechts“ zu vergessen. Ich diszipliniere mich falls nötig, indem ich die (Windows‑)Taskleiste so vergrößere, dass der untere Bildschirmbereich davon verdeckt wird5. Die „work area“6 wird dementsprechend kleiner und selbst maximierte Fenster werden nicht größer7. Nun ist eine überdimensionale Taskleiste zugegebenermaßen nicht gerade eine Zierde. Ich habe mir deswegen ein kleines Script geschrieben, das die Taskleiste temporär mit einem schwarzen, randlosen Fenster überdeckt (siehe Anhang 2).
 |  |  |
Das Präsentieren von „lebendigem“ Quellcode ist eine der wenigen Präsentations-Situationen, in denen ich ein Rednerpult für sinnvoll (wenn nicht gar notwendig) halte: Mit der IDE im Stehen zu präsentieren ist ohne Rednerpult nahezu unmöglich. Einzig Stehen aber (im Gegensatz zum Sitzen des Publikums) erscheint mir für den Referenten sinnvoll, es unterstreicht die Rolle als Vortragender. Ein sitzender Referent wirkt auf mich, als würde die Rolle nicht wirklich angenommen oder gar abgelehnt.
Nicht nur Code
Präsentiert man mit der IDE, wird der Bildschirm auf den Beamer gespiegelt. Möchte man nun zusätzlich Folien zeigen, erfordert dies mindestens einen Wechsel des Programms und meist sogar eine Änderung der Bildschirm-Konfiguration – eine Änderung, die bspw. PowerPoint unter Umständen sogar automatisch durchführt und die man anschließend mühsam rückgängig machen muss. Plant man einen solchen „Medien-Mix“, ist eine vollständige und realistische Generalprobe dringend angezeigt.
Sofern der Raum nicht zu groß ist, um darauf auch aus den hinteren Reihen noch etwas zu erkennen, empfiehlt es sich m. E. immer, ein Flipchart oder ein Whiteboard bereitstehen zu haben. Der hochgradig interaktive Charakter des Präsentierens mit der IDE erfordert die Möglichkeit, aus dem Stegreif visualisieren zu können. Damit schließt sich dann auch der Kreis hin zum eigentlichen Thema von Buch und Blog: Dem spontanen Visualisieren von IT-Themen an Whiteboard und Flipchart. Das Flipchart steht hier im selben Verhältnis zu PowerPoint wie die IDE: Beide ermöglichen das spontan-interaktive, lebendige Präsentieren!
Anhang 1: Checkliste „Lebendig(en) Quellcode präsentieren“
Diese Checkliste ist der Anhang zum Artikel „Lebendig(en) Quellcode präsentieren“ – gewissermaßen die extrem verkürzte Zusammenfassung. Der erste Punkt der Checkliste ergibt sich damit quasi automatisch:
|
Anhang 2: Script zum Überdecken der Taskleiste
Vor rund 15 Jahren habe ich „die Seiten gewechselt“ – weg von der (Datenbank‑)Softwareentwicklung hin zu IT-Infrastruktur-Themen. Seitdem ist es eher selten geworden, dass ich Code schreibe – und wenn, dann eher kurze und lange Scripts, inzwischen meist in PowerShell oder wie in diesem Fall (gerade beim relativ systemnahen „Basteln“) auch gern mal mit AutoIt <https://www.autoitscript.com/>. Das folgende Script verdeckt die Taskleiste durch ein schwarzes, randloses Fenster, das sich bei Drücken von Esc schließt. Es ist weder „schön“ noch besonders innovativ; wie vielleicht typisch für Scripte ist es wirklich nur „fit for purpose“ – z. B. geht es davon aus, dass die Taskleiste sich am unteren Bildschirmrand befindet. Mir hilft es – aber vielleicht findet sich ja beizeiten jemand, der sich die Mühe macht, das Problem über eine schwarze, randlose AppBar8 ganz allgemein und deutlich eleganter zu lösen. Bis dahin kann ein Jeder gern auf eigene Gefahr und ohne jede Gewähr den folgenden Code nutzen, für sich anpassen und ggf. sogar der Einfachheit halber kompilieren – wer dieses Script für seine Präsentation braucht, wird vermutlich auch damit klarkommen.
#include <GUIConstantsEx.au3>
#include <WindowsConstants.au3>
#include <WinAPIGdi.au3>
#include <WinAPISys.au3>
AutoItSetOption('GUICloseOnESC', 1)
$hWorkArea = _WinAPI_GetWorkArea()
$dwWorkAreaWidth = DllStructGetData($hWorkArea, 'Right') - DllStructGetData($hWorkArea, 'Left')
$dwWorkAreaHeight = DllStructGetData($hWorkArea, 'Bottom') - DllStructGetData($hWorkArea, 'Top')
$aCurrentDisplaySettings = _WinAPI_EnumDisplaySettings('', $ENUM_CURRENT_SETTINGS)
$dwDisplayWidth = $aCurrentDisplaySettings[0]
$dwDisplayHeight = $aCurrentDisplaySettings[1]
Global $dwWindowHeight = $dwDisplayHeight - $dwWorkAreaHeight
Global $dwWindowWidth = $dwDisplayWidth
Global $dwWindowX = 0
Global $dwWindowY = $dwWorkAreaHeight
Global $hWindow = GUICreate('HideTaskBar', _
$dwWindowWidth, $dwWindowHeight, _
$dwWindowX, $dwWindowY, _
$WS_POPUP, _
$WS_EX_TOPMOST)
GUISetBkColor(0x000000, $hWindow)
GUISetState(@SW_SHOW, $hWindow)
While 1
$nMsg = GUIGetMsg($hWindow)
Switch $nMsg
Case $GUI_EVENT_CLOSE
Exit
EndSwitch
WEnd
GUIDelete($hWindow)
Fußnoten:
- ↑ Vgl. <https://fachinformatiker-anwendungsentwicklung.net/sourcecode-gehoert-nicht-in-die-praesentation-mythen-der-projektpraesentation/> (29.08.2016).
- ↑ Womöglich Markdown-basierte.
- ↑ Ja, das sind konkurrierende Ziele.
- ↑ Zum Beispiel mit Screenshots aus der IDE, s. o.
- ↑ Zuvor muss ggf. „Taskleiste fixieren“ (engl.: „Lock the taskbar“) deaktiviert werden.
- ↑ Vgl. <https://msdn.microsoft.com/en-us/library/windows/desktop/dn742493(v=vs.85).aspx> (29.08.2016).
- ↑ Es sei denn, für das Fenster ist z. B. der Style
WS_EX_APPWINDOWgesetzt, vgl. <https://msdn.microsoft.com/de-de/library/windows/desktop/ff700543(v=vs.85).aspx> (29.08.2016). - ↑ Vgl. <https://msdn.microsoft.com/en-us/library/windows/desktop/cc144177(v=vs.85).aspx>.