Zur Zeit schreibe ich an einem Buch. Es ist kein Roman, keine Prosa, nicht mal eine Biographie. Es ist die härteste Art von Buchschreiben, die einem unterkommen kann: ein Benutzerhandbuch für eine komplexe, über Jahre gewachsene Software. Diese letzten Worte sagen den Kundigen, dass nur zentrale Funktionen überhaupt dokumentiert sind, dass es hunderte von anprogrammmierten Rucksäcken gibt, und dass keiner so wirklich den Gesamtüberblick hat.

Sieht man von der Recherche ab, um wenigstens das Bekannte aufzuspüren, und um dann zufällig auf das Unbekannte zu stoßen, ist die Planung eines solchen Projektes die Fußangel. Wenn man nicht schon ein Dutzend Manuals hinter sich hat. Es ist für mich das erste Projekte dieses Umfanges, am Ende wird es auf ca. 250 bis 280 A5-Seiten hinauslaufen, Schriftgröße 9 pt. Und trotz aller gut gemeinten Vorplanung ist einiges schief gegangen. Weil ich nicht weit genug gedacht habe. Diese Erfahrungen anderen Schreibern, die zum ersten Mal vor so einem Brocken stehen, als Warnungen mit auf den Weg gegeben.

Kenne Deinen Gegner

Um ein Produkt zu beschreiben, ist es zwingende Voraussetzung, dieses Produkt und seine Funktionen zu 70 oder 80% zu kennen. Wie will sonst etwas nicht nur beschreiben, sondern auch seine Anwendung verständlich machen? Das ist eine Grundlage, ohne die man nicht anfangen sollte. Neben der reinen Kenntnisse der Funktionen ist es unumgänglich, sich die Fachterminologie anzueignen, und Begriffe miteinander in Beziehung setzen zu können. Ich muss als Autor kompetent und fachlich fundiert sein, sonst merkt der Leser sehr schnell, was nur Fassade ist.

Das Produkt muss ich auch deshalb gut kennen, um ein Bedienkonzept zu vermitteln. Für einen DVD-Player mag eine Erklärung der vorhandenen Tasten ausreichen, eine umfangreiche Software, ein digitales Studiomischpult oder eine komplizierte Maschine braucht ein Bedienkonzept, eine logische Linie in der Handhabung. Nun ist es eine bevorzugte Eigenschaft von älterer Software, ihr Bedienkonzept durch immer neue Funktionen und Erweiterungen verloren zu haben. Wenn sie es je hatte. Dann ist es Aufgabe des Autors, ein Bedienkonzept zu entwickeln. Viele Anleitungen sind nur eine weitschweifige Erklärung für das, was auf Buttons und in Menüs kürzer steht. Aber sie vermitteln, leider, kein Konzept. Ohne Konzept kann der Benutzer nicht ahnen, was er mit dem Zeugs soll. Der Leser muss aus meinem Geschreibsel verstehen, wie die Dinge zusammenhängen, was was bedingt, wie Dinge miteinander verbunden sind. Und wie er das erreicht, was er erreichen möchte. Er muss auch die verbundenen Fachbegriffe lernen, sie sollten ihm nach dem Studium unseres Manuals quasi bildlich vor Augen stehen. Lege den ersten Schwerpunkt darauf, ein Bedienkonzept zu entwickeln, und was der Leser an Vorwissen haben muss, bis es an’s Eingemachte geht. Erst dann kommen Planung oder gar Feinheiten. Was nützt es mir, das Navi perfekt programmieren zu können, wenn ich gar nicht Auto fahren kann?

Rechne damit, dass 10 bis zu 15% der Projektzeit für die Entwicklung eines Konzeptes drauf gehen. Darin ist dann aber auch schon die Idee vorhanden, wie ich meine Kenntnisse, Erfahrungen und Entdeckungen rüber bringe. Der Rest ist Handwerk. Und das kommt jetzt.

Gliederung und Struktur

Der vorherige Absatz ist bewusst länger geworden, weil dieser Teil im Grunde nur noch das Aufschreiben dessen ist, was im ersten Absatz beackert wurde. Schreibe nun die Struktur des Manuals auf, die ersten beiden Überschrifts-Ebenen und ein paar Stichworte zum Inhalt der Kapitel. Diskutiere Deine Struktur mit Leuten, die das Produkt kennen und nutzen, die Regel, dass vier Augen mehr sehen als zwei, gilt auch an dieser Stelle. Fürchte Dich nicht davor, dass diese Leute vom Produkt viel mehr wissen als Du, Du bist Schreiber, und Dein Gegenüber kann vielleicht super programmieren, aber schreiben in unserem Sinne kann er nicht. Software-Entwickler können keine Dokumentation schreiben, das ist ein Oximoron, eine Unvereinbarkeit. Du machst Deinen Job, er seinen, und Ihr braucht Euch gegenseitig.

Dann fange an. Nach letzten Vorbereitungen.

Schrift, Satz, Layout, Tools

Schreibt man ein Dokument für eine Firma, muss man etwas über das Corporate Design wissen. Welche Schriftarten sind Firmenschriftarten? Welche Größe? Welche Logos müssen wo stehen? Gibt es sogar eine Festlegung im CD, wie Dokumente aussehen müssen? Das ist alles zu klären, bevor der erste Buchstabe geschrieben wird. Noch bevor irgendein Gedanke an Satz oder Layout verschwendet wird.

Thema Tools. Man kann ein umfangreiches Manual mit Word als Schreibprogramm und Gimp für die Bildbearbeitung machen. Man kann auch mit einem Smart bis Sizilien fahren. Spaß macht das nicht. Und lange dauern wird es auch. Für professionelles Schreiben braucht man professionelle Werkzeuge. InDesign für Layout und Satz, Fireworks oder Photoshop für die Bildbearbeitung und Illustrator für Diagramme und Zeichnungen. Oder etwas Vergleichbares. Da sind dann gut 2000 € an Lizenzen über den Tisch gegangen, aber man kann auch Adobe-Programme in England kaufen, das kosten sie nur ein Viertel. Wenn man doch Word nutzt, und nach einer Änderung auf Seite 112 das Layout von Seite 8 zerbröselt, sollte man sich nicht wundern. Auch für diese Tools gilt, dass man sie einigermaßen nutzen kann, wobei es wenigstens für die verbreiteten Tools auch gute Handbücher gibt. Da wäre dann wieder etwas weitere Zeit vergangen, bevor wir in medias res gehen. Aber alles andere ist Bastelei, die sich rächen wird. Versprochen.

Letzte Vorbereitungen

Konzept da, Tools vorhanden, Ideen gesammelt, Struktur vorbereitet, Tools erlernt, Gliederung erarbeitet. Go? Noch nicht ganz. Das Layout und der Satz müssen noch gemacht werden, in InDesign wären das die Master Pages, die Paragraph und Character Styles, Table/Cell Styles, also alles, was das Bild und die Gestaltung unseres Dokumentes ausmacht. Seitenränder, wie sollen Kopf- und Fußzeilen aussehen, mache ich nur ein Inhaltsverzeichnis, oder auch einen Index? Addendum planen, was soll aus dem Hauptinhalt an das Ende? Keyboard-Shortcuts, alle Icons erklären, Übersicht der Fachbegriffe, wenn diese Fragen in der Strukturierung noch nicht eingeflossen sind, sollte es spätestens jetzt geschehen.

Jetzt noch ein Hinweis aus eigener Erfahrung. Man braucht immer Screenshots. Daher sollte man noch ganz am Anfang sich drei Größen von Screenshots nehmen, die kommen. Hauptfenster, Dialoge und Unterfenster, als Standardgrößen und diese von 72 auf 300 dpi hochskalieren, sonst ist davon später im Print nichts mehr lesbar. Welche Größen müssen die Screenshots im Dokument haben, damit es noch lesbar bleibt? Auch diese Werte festschreiben und im gesamten Dokument konstant halten. Überhaupt so viel wie möglich ganz am Anfang, vor dem ersten Satz festlegen, ausdrucken und an den Bildschirm pappen.

Welche Seitenabstände der Bilder und Zeichnungen? Welcher Textfluss um Bilder? Farben in Paletten packen, so dass Zeichnungen einen einheitlichen Stil haben. Blocksatz ist für Zeitungen, beim Flattersatz muss ich aufpassen, dass es nicht zu unruhig wird und mein Layout darauf abstimmen. Alles, was irgendwie Maß oder Größe hat, immer fest definieren und auch dokumentieren. Nicht dass das vorletzte Kapitel im Layout völlig anders aussieht als das zweite. Und so weit wie möglich vorausdenken, was bald kommt. Diese paar Stunden an Vorbereitungen, an Vordenken und Vorplanen, können einem spätere Schweißausbrüche und Panikattacken ersparen. Und sie sorgen für ein professionelles Dokument.

Jetzt aber

Genau, nun ist es Zeit einzusteigen und loszufahren. Es mag eine Menge Vorarbeit gewesen sein, jedoch kann man sich nun auf das konzentrieren, was man rüberbringen will. Sein Konzept der Bedienung vermitteln, den Benutzer an die Hand nehmen und ihm sagen: „So, pass auf, ich erkläre Dir das jetzt mal ganz genau.“

0 Kommentare

Dein Kommentar

An Diskussion beteiligen?
Hinterlasse uns Deinen Kommentar!

Schreibe einen Kommentar

Deine E-Mail-Adresse wird nicht veröffentlicht. Erforderliche Felder sind mit * markiert.

Diese Website verwendet Akismet, um Spam zu reduzieren. Erfahre mehr darüber, wie deine Kommentardaten verarbeitet werden.