Ratgeber gibt es schon mehr als genug – sollte man meinen – jedoch werden immer wieder welche veröffentlicht, die aus dem trögen Einerlei herausragen. Dazu gehört zweifellos auch „Weniger schlecht über IT schreiben“ von Christina Czeschik und Matthias Lindhorst. Dem Leser/potentiellen Autor* wird in diesem Buch aufgezeigt, wie er sich den typischen Herausforderungen beim Verfassen von IT-spezifischen Inhalten stellen kann, nämlich einem leeren Bildschirm mit einer eindringlich blinkenden Eingabeaufforderung (für Nicht-IT-ler: ein weißes Blatt Papier) einen (wirklich) guten Text abzutrotzen, der irgendetwas mit IT zu tun hat. Möglicherweise wird der Autor aber trotzdem an einem Grundübel von so vielen unverständlichen/unerträglichen IT-Texten scheitern, dem Textbrei.
Handbücher, Gebrauchsanleitung und technische Dokumentation bilden (zum Glück) nicht den Schwerpunkt in „Weniger schlecht über IT schreiben“. Vielmehr werden auf eindringliche und amüsante Weise einige Grundregeln für gutes Schreiben von technischen Texten unterschiedlicher Art vorgestellt, bei denen man sich nur wünschen kann, dass sie häufiger zur Anwendung kommen. Jedoch reichen diese unter Umständen nicht ganz aus, vor allem dann, wenn man einen Blick auf Texte wirft, die intern in Unternehmen kursieren und dann (zum Unglück der Kunden) auch noch veröffentlicht werden.
„Interne technische Dokumentation ist sehr wichtig: Man sieht leicht, welcher wirtschaftlicher Schaden entsteht, wenn sie nicht ordentlich durchgeführt wird – wenn beispielsweise die eingebettete Software eines elektronischen Geräts geändert werden soll und der daran arbeitende Programmierer aus dem Code seines Vorgängers nicht mehr schlau wird.“
Wohl war, wohl war. Und in dem typischen Szenario ist nicht nur der Programmierer betroffen, sondern auch andere Mitarbeiter, wie zum Beispiel der Projektmanager oder weitere Programmierer, die wissen wollen, welche Funktionen für das programmierte Modul zur Verfügung stehen und wie es verwendet werden kann. Das, was dann als Text oder „Beschreibung“ erstellt wird, treibt selbst den hartgesottensten Ich-möchte-es-gerne-verstehen-Leser die Tränen in die Augen. Das Erstaunliche an diesen Texten ist, dass deren Konsistenz praktisch universell ist, das heißt, es macht keinen Unterschied, in welchem Unternehmen sie erstellt werden. Und es sind diese Text, die in dem Unternehmen Stimmen laut werden lassen, die nach einem Technischen Redakteur rufen (schreien). Und natürlich sind es dann auch diese Texte, die dem (externen) Technischen Redakteur vorgelegt werden, mit der bangen Frage, ob man denn helfen könne.
Was ist nun das „Besondere“ an diesen Texten? Um es kurz auf einen Nenner zu bringen: Es handelt sich dabei um einen Textbrei, gemixt mit einem toxischen Modal-Nominalisierungs-Passiv-Cocktail, der mit kreativen Inkonsistenzen verziert ist. Der entscheidende Punkt dabei ist jedoch, dass in diesen Texten keine Unterscheidung stattfindet zwischen beschreibenden und handlungsorientierten Textelementen. Der Leser darf unter mühseligsten Anstrengungen herausfinden – wenn es denn gelingt – ob er etwas tun soll/darf/muss, damit die IT benutzt werden kann, ob die Maschine/Programm etwas (automatisch) tut, oder ob etwas beschrieben wird.
Bei DITA (Darwin Information Typing Architecture), einem XML **-basierten Standard, der ursprünglich für die Technische Dokumentation für Software entwickelt wird, wurden von Beginn an drei Informationstypen unterschieden, die in der Technischen Dokumentation und bei technischen Texten immer wieder zu finden sind. Dabei handelt es sich um die Informationstypen Beschreibung (concept), Prozedur (task) und Referenz (reference). Die Unterscheidung zwischen Beschreibung und Prozedur ist dabei wesentlich, was sich auch in der unterschiedlichen XML-Struktur ausdrückt, das heißt, eine Prozedur ist immer eine Liste, eine Beschreibung dagegen eine Abfolge von einem oder mehreren Absätzen.
Dass bei DITA eine Unterscheidung von Informationstypen vorgenommen wird, ist nichts DITA-Spezifisches, sondern rührt vom Verständnis her, dass technische Texte nicht einfach eine Abfolge von technischen Informationen sind, die nett aufbereitet werden wollen, sondern dass unterschiedliche Fragen des Lesers adressiert werden müssen, nämlich, „Was ist…?“ (concept) und „Wie kann ich…“ (task).
In einem Buch wie „Weniger schlecht über IT schreiben“ muss sicherlich nichts über DITA stehen – das wären zu große Kanonen auf zu kleine Spatzen. Jedoch hätte ich mir gerne einen prominenteren Hinweis in der Weise gewünscht, der lautet: „Trennt den Inhalt in Textelemente, die etwas beschreiben, und in Textelemente, die dem Leser zeigen, was er tun kann/soll/muss.“ Das würde das Leid vieler Autoren und Leser deutlich mindern und mit einem Schlag hätte man Texte, die deutlich besser wären, als der unleserliche Durchschnitt.
Natürlich gibt es zahlreiche IT-Texte, die „nur“ ein Konzept oder eine Strategie beschreiben. Dort sucht man vergeblich nach Prozeduren. In Praxis sind diese Texte jedoch eher selten zu finden (für diese Kunstwerke werden in der Regel auch keine Technischen Redakteure gesucht). Bei internen oder bei Texten für Kunden ist diese Art von Prosa aber wohl eher die Ausnahme. Der Regelfall sind solche Texte, mit denen den Willigen oder Unwilligen vermittelt werden muss, wie IT funktioniert und wie sie benutzt werden kann.
Letzten Endes läuft alles darauf hinaus, dass man seinen Leser, eben das unbekannte Wesen, kennt. Dieser fragt sich oft genug: „Was ist…?“ (concept) und „Wie kann ich…“ (task). Wenn der Autor dies weiß, wird es ihm nach der Lektüre von „Weniger schlecht über IT schreiben“ noch leichter fallen, weniger schlecht über IT zu schreiben.
*Autor = Autorin, Leser = Leserin, Mitarbeiter = Mitarbeiterin, Technischer Redakteur = Technische Redakteurin, Projektmanager = Projektmanagerin, Programmierer = Programmiererin, Ich = Ich
** Eine simple Methode, um Inhalte auszuzeichnen – vor allem für diejenigen, die dazu noch SGML (eine schwierige Methode) verwenden durften/sollten/mussten.