Screencasts erfreuen sich steigender Beliebtheit. Nicht nur bei technischen Themen, sondern ganz allgemein zur Wissensvermittlung. Pluralsight ist da nur ein Vertreter, auch wenn es, international gesehen, schon ein recht großes Unternehmen ist.

In diesem Beitrag geht es aber nicht um Pluralsight. Nur am Rande, denn meine Konfiguration und mein Equipment zum Aufzeichnen, Bearbeiten und Produzieren von Screencasts basiert auf den Empfehlungen von Pluralsight. Es ist die gleiche Konfiguration, die ich beispielsweise auch für meine Screencasts zur Rubrik „Frameworks“ der dotnetpro verwende.

Die Tipps, Tricks und insbesondere die Konfiguration sind nur als Hinweise gedacht, wie es gemacht werden beziehungsweise aussehen kann. Ich habe damit sehr gute Erfahrungen gemacht. Allerdings habe ich – professionell gesehen – nichts mit Sound- und Video-Bearbeitung zu tun. Ich bin also kein Toningenieur oder ähnliches. Vermutlich gibt es viele Verbesserungen an der hier vorgestellten Konfiguration oder an meinem Workflow. Vor allem in dedizierte Hardware könnte ich investieren. Vielleicht mache ich das in Zukunft auch.

Für Tipps bin ich daher immer dankbar und freue mich über Kommentare und Nachrichten aller Art.

Hardware

Der erste wichtige Punkt beim Aufzeichnen von Screencasts ist die Hardware. Die beschränkt sich bei mir auf ein Mikrofon. Ich habe, bisher zumindest, nicht vor, ein Interface dazwischen zu schalten. Das lohnt sich aktuell einfach nicht. Der Hauptgrund ist, dass Pluralsight mein Material, dass ich so gut es geht geschnitten und bearbeitet habe, eh noch etliche Male zusätzlich bearbeitet. Aktuell weiß ich von acht Schritten. Acht Mal wird mein Material überarbeitet und neu kodiert. Daher reicht mir mein Mikrofon bisher voll und ganz.

Entschieden habe ich mich für ein Rode Podcaster. Dieses USB-Sprechermikrofon hat den Vorteil, dass es mit seinem USB-Anschluss direkt an einen PC angeschlossen werden kann. Es ist kein dediziertes Interface notwendig, da die Umwandlung direkt im Mikrofon passiert. Hier noch einige detailliertere Daten zum Rode Podcaster:

• Dynamischen Großmembran-Kapsel
• A/D-D/A Wandlung erfolgt im Mikrofon
• regelbarer Kopfhörerverstärker mit 3,5 mm Klinkenbuchse integriert
• Richtcharakteristik Niere
• Grenzschalldruck: 115 dB
• Übertragungsbereich: 40 Hz bis thomann 14 kHz
• Lieferumfang: Halter für Mikrofonstativ, USB Kabel 3 m

Abbildung 1 zeigt das Mikrofon, montiert in einer Spinne und befestigt an einem Schwenkarm. Diese Teile sind optional, im Grunde aber Pflicht, wenn viel aufgenommen werden soll. Zu guter Letzt noch ein Link auf den Shop, wo ich das Mikrofon gekauft habe.

Beim Schwenkarm habe ich mich auch für ein Modell aus dem Hause Rode entschieden. Konkret für den Rode PSA-1. Sehr von Vorteil ist, dass sich der Arm um 360° drehen lässt. Ich habe ihn zwar an der Wand montiert, so dass ich nicht mal die Hälfte davon ausnutze. Allerdings musste ich bei der Montage nicht darauf achten, in welcher Richtung beziehungsweise in welchem Winkel ich den Arm befestige. Drehen lässt er sich eh. Die folgende Liste enthält einige Daten zum Schwenkarm, auch wenn diese sicherlich nicht ganz so wichtig sind wie die Daten des Mikrofons.

• 3/8″ Gewinde
• belastbar bis 2 kg
• um 360 grad drehbar
• Abmaße der Arme: 820 mm horizontal, 840 mm vertikal

In Abbildung 2 ist der Schwenkarm etwas detaillierter zu sehen. Und erneut ein Verweis auf den Shop für den käuflichen Erwerb.

Jetzt fehlt nur noch etwas Zubehör für das Mikrofon. Zum einen die sogenannte Spinne, mit der das Mikrofon an dem Schwenkarm befestigt wird. Der Vorteil einer Spinne ist, dass das Mikrofon darin locker eingehängt ist und die Konstruktion mitschwingen kann. Das bedeutet, dass sich Schwingungen nicht direkt auf das Mikrofon auswirken. Dadurch wird verhindert, dass sich jede Erschütterung gleich auf die Aufnahme auswirkt. Auch die Spinne habe ich bei Thomann gekauft. Konkret das Modell PSM1 von Rode.

Zusätzlich habe ich mich noch für einen sogenannten Pop-Schutz beziehungsweise Pop-Filter entschieden. Dieser verhindert starke Zischgeräusche, wie beispielsweise P- und S-Laute. Hier habe ich den t.bone MS 250 gekauft. Wieder im gleichen Shop wie bisher auch. Beide Komponenten sind, im montierten Zustand, in Abbildung 1 zu sehen. Den vollständigen Aufbau zeigt das Bild am Anfang des Blogposts.

Alles in allem kostet diese Ausstattung circa 300 Euro. Je nach Shop und Sonderangeboten mal etwas mehr, mal etwas weniger. Die oben gesetzten Links gehen alle zum Shop des Thomann Musikhaus. Es sind keine Affiliate Links! Ich bin nur äußerst zufrieden mit der Ware, dem Preis und dem allgemeinen Bestellverlauf.

Software

Die Softwareseite ist schnell abgedeckt. Erstaunlicherweise, wie ich finde, denn zu Beginn war ich davon ausgegangen, einen großen Batzen an Software zu benötigen. Das liegt natürlich auch an der Tatsache, dass ich kaum Nachbearbeitungen an meinem Rohmaterial vornehmen muss. Das meiste übernimmt Pluralsight.

Camtasia Studio von TechSmith, wieder eine Empfehlung von Pluralsight, hat sich als gute Wahl erwiesen (siehe Abbildung 3). Mittlerweile in Version 8.4 erschienen, übernimmt es eine ganze Reihe von Funktionen. Von der Aufnahme, über die Bearbeitung bis hin zur Produktion ist mit Camtasia alles möglich. Daneben gibt es noch viele zusätzliche Funktionen. Beispielsweise können Übergänge oder sonstige Animationen eingefügt werden. Sehr komfortabel ist, dass der Mauszeiger nachträglich ausgeblendet werden kann. Bei der Aufnahme kann die Maus noch recht wichtig sein, im Video dagegen aber schnell stören.

Ich nutze Camtasia für Windows. Das ist ein wichtiger Hinweis, denn die Versionen für Windows und Mac unterscheiden sich teilweise erheblich. Seit der aktuellen Version 8.4 ist wenigstens das Aufnahmeformat für das Rohmaterial vereinheitlicht worden. Die können jetzt zwischen den Systemen ausgetauscht werden.

Gekauft habe ich Camtasia Studio 8 bei megasoft. Der Preis ist unschlagbar, die Lieferung war schnell und der Lizenzschlüssel funktionierte ohne Probleme. Aktuell liegt der Preis bei 225 Euro. Mehr Software habe ich auch nicht käuflich erwerben müssen. Die Präsentationen erstelle ich mit PowerPoint, das ich aber eh schon installiert hatte.

Wer sich doch etwas mit der Nachbearbeitung befassen möchte, vor allem in Richtung Audio, kann sich die Werkzeuge Reaper beziehungsweise Adobe Audition anschauen. Ersteres ist recht günstig. Adobe Audition kostet deutlich mehr. Dafür ist allerdings die Geräuschunterdrückung auch um einiges besser.

Workflow

Nun zum Workflow für Screencasts. Das ist eine kurze Zusammenfassung, wie ich bei der Vor- und Nachbearbeitung vorgehe. Final ist dieser Workflow in keiner Weise. Ich ändere immer wieder Teile davon. Bei meinem aktuellen Pluralsight Kurs habe ich sogar mittendrin Änderungen vorgenommen, weil ich mit meinem Vorgehen nicht ganz glücklich war.

Angenommen das Thema steht fest und ist bereits leicht umrissen. Beispielsweise durch eine Sammlung von Stichpunkten oder ähnliches. Wenn das Thema nicht neu ist, sondern vielleicht schon mal in einem Artikel/Blogpost oder in einer Präsentation behandelt wurde, ist das natürlich umso besser. Bei größeren Screencasts ist das aber in der Regel nicht der Fall.

1. Die Präsentationen

Anschließend bereite ich die Präsentationen vor. Mit allem, was ich im Screencast zeigen möchte. Dabei handelt es sich meistens um den theoretischen Teil. Die Präsentationen an sich unterscheiden sich nicht wirklich von anderen. Also beispielsweise für Schulungen oder für Konferenzen. Ich versuche so wenig Aufzählungspunkte wie möglich einzubauen. Manchmal gelingt mir das gut, manchmal weniger. Wichtig ist, dass die Folien das gesagte unterstützen. Bei Screencasts ist das noch wichtiger als bei einem Vortrag, denn in einem Video, wo nur der Bildschirm mit den Folien zu sehen ist, fehlt die komplette Körpersprache. Eine langweilige Präsentation ist in diesem Fall noch schlimmer als bei einem Vortrag.

2. Die Beispiele

Nachdem die Präsentationen fertig sind, meistens teile ich diese in Abschnitte oder Module ein, bereite ich die Beispiele vor. Völlig unabhängig davon, um was für Beispiele es sich handelt. Möglicherweise stelle ich eine Anwendung vor oder ich benötige eine Solution in Visual Studio. Vielleicht auch die Kombination von beidem. Hauptsache ist, dass ich nach den Vorbereitungen etwas funktionsfähiges habe, was ich flüssig im Screencasts präsentieren kann. Sowohl vom Ablauf her als auch auf sprachlicher Ebene. Letzteres zumindest teilweise.

3. Drehbücher

Denn diese sprachliche Ebene manifestiert sich zuerst in meinen Gedanken. Es ist noch nichts vorhanden, was ich ablesen kann. In der Regel habe ich zu diesem Zeitpunkt nur ein paar Notizen. Daher sind im dritten Schritt nun die Drehbücher an der Reihe. Am Anfang dachte ich, das Wort Drehbuch wäre übertrieben und das mir ein paar ausführlichere Notizen reichen sollten. Bisher hat sich das als Trugschluss herausgestellt. Ich verzettel mich viel zu oft beim Sprechen wenn ich gegen meinen Monitor rede und nicht vor Publikum stehe. „Ähhs“ und „Öhhs“ sind in Screencasts tödlich.

Also bin ich angefangen komplette Drehbücher zu schreiben (siehe Abbildung 4). Insbesondere für die theoretischen Teile, also die Abschnitte, die durch Folien abgedeckt sind. Bei Beispielen ist das nicht ganz so kritisch. Wenn ich vor Code sitze, fällt mir in der Regel schnell ein, was ich wann und warum sagen möchte. Meistens habe ich auch ein paar Notizen aus dem vorherigen Schritt. In den Drehbüchern stehen teilweise sogar die Punkte drin, an denen ich durch einen Klick eine Aktion auslöse. Beispielsweise für eine kleine Animation. Das mag sich übertrieben anhören und ist sicherlich sehr aufwändig. Bisher konnte ich dadurch aber viel Zeit bei der Aufnahme und der Bearbeitung einsparen.

Als kleine Daumenregel hat sich bei mir bewährt, dass ich circa vier Stunden für circa 10 Minuten Videomaterial brauche. Und zwar nur in der Vorbereitung der Folien und der Drehbücher. Beispiele, Aufnahme und Nachbearbeitung noch nicht mit eingerechnet.

4. Aufnahme

Jetzt ist die eigentliche Aufnahme an der Reihe, bei der die oben beschriebene Hard- und Software zum Einsatz kommt. In der Regel zeichne ich den Bildschirm vor mir auf. Wenn ich nicht viel sagen muss, öffne ich das Drehbuch auf meinem zweiten Bildschirm auf der linken Seite. Ist das Thema komplexer und die Anweisungen im Drehbuch umfangreicher, nutze ich oft mein Ultrabook, dass ich vor mir aufklappe. Wenn ich das Drehbuch dort anzeige, kann ich es gut lesen und muss mich bei der Aufnahme nicht sonderlich verrenken.

Ich versuche immer so viel wie möglich aufzunehmen. Verspreche ich mich zwischendurch, mache ich eine Pause von mindestens fünf Sekunden und starte den Satz oder die Aktion erneut. Die Pause ist ausreichend, damit ich bei der Nachbearbeitung genug Zeit habe, um den Fehler zu erkennen und aus der Aufnahme zu schneiden. Manche nutzen auch Klopfgeräusche oder ein bestimmtes Wort, um bei der Nachbearbeitung direkt an den Fehler erinnert zu werden. Welche Vorgehensweise auch genutzt wird, ist vollkommen egal. Hauptsache ist, dass überhaupt etwas zum Einsatz kommt. Denn das erleichtert die Nachbearbeitung enorm.

5. Nachbearbeitung

Nach dem Aufzeichnen des Rohmaterials ist es an der Zeit, das endgültige Video zu produzieren. Dazu muss das vorliegende Material bearbeitet werden. In welchem Umfang, hängt natürlich vom Rohmaterial ab. Sind viele, kleinere Aufnahmen vorhanden, müssen diese in der richtigen Reihenfolge zusammengefügt und eventuell mit Animationen versehen werden. Bei größeren Aufnahmen müssen die Fehler herausgeschnitten werden. Ich bevorzuge mittlerweile die zweite Variante. Ich habe lieber mehrere größere Aufnahmen vorliegen, aus denen ich dann die Fehler herausschneide, als kleinere Aufnahmen. Hintergrund ist, dass ich bei größeren Aufnahmen flüssiger aufnehmen kann.

In diesem Schritt müssen auch Hintergrundgeräusche und beispielsweise zu lautes Atmen herausgeschnitten werden. Bei Pluralsight geschieht das – und viel mehr – in den nachfolgenden Schritten, mit denen ich nichts zu tun habe. Bei meiner dotnetpro Kolumne bin ich selbst dafür verantwortlich. Hier gefällt mir auch die Qualität noch nicht so ganz. Vermutlich werde ich in etwas Hard- und Software investieren, damit ich ein deutlich besseres Ergebnis erziele.

Fazit

Das soll es für diesen Blogpost gewesen sein. Meinen Workflow werde ich, wenn er etwas finaler ist, noch mal gesondert beschreiben. Dann kann ich die Vor- und Nachteile besser herausheben und die einzelnen Varianten gegenüber stellen.

Mein allgemeines Fazit zu Screencasts ist, dass sie sehr viel Spaß machen. Auf der anderen Seite steckt aber auch deutlich mehr Aufwand dahinter, als viele vermuten. Insbesondere, wenn Drehbücher notwendig oder die Beispiele sehr aufwändig sind. Ich würde mir also gut überlegen, warum ich Screencasts mache und wer meine Zielgruppe ist.