Gemeinsam mit Jason Harder von den Performers habe ich ein recht großes und vermutlich auch sehr typisches Automatisierungsprojekt mit InDesign und Skripten realisiert. Auf dem langen Weg dorthin sind uns viele Dinge ein- und aufgefallen. Da wir beide bloggen – Jason steckt hinter printpraxis.net – dachten wir uns: Das sollten wir vielleicht einmal zusammenfassen!

Die Idee ist, sowohl aus der Sicht des Auftraggebers als auch des Entwicklers offen und ehrlich die Sichtweisen in Bezug auf Kernfragen der Automatisierung zu klären. Die Antworten von Jason findet ihr auf seinem Blog, meine Antworten gibt es natürlich hier.

Auch wenn die Fragen und Antworten auch ohne Kenntnisse zum Projekt für sich genommen gültig sind, hier noch ein paar Eckdaten was wir gemacht haben:

Ausgangslage: PDFs einer Preisliste mit 20 Typen. Datenquelle ist ein Datenbankauszug im Format CSV dessen Inhalte neu zusammengesetzt und sortiert werden müssen.

Ziel: Automatisierung der Preisliste bei größtmöglicher Flexibilität. Eine manuelle Korrektur und typographische Feinjustuierung soll möglich bleiben.

Umsetzung: InDesign-Skript und -Templates.

Aber jetzt zu den eigentlichen Fragen:

Wann sollte ich eine Aufgabe automatisieren?

In InDesign kann nahezu jede Funktion per Skript angesprochen werden, deswegen gibt es zunächst kaum technische Limitierungen. Anders gesagt: Wenn es eine Vorlage gibt, kann ich dieses auch per Skript erstellen. Klar ist, eine Automatisierung kommt aber nur in Betracht, wenn sich die Aufgabenstellung oder Teile davon wiederholen, d.h. das Skript auch wirtschaftlich Sinn macht.

In der Praxis tauchen dann immer wieder die selben Themen auf:

• Welcher Teilbereich ist eigentlich wiederholbar? Hier spannt sich der Bogen von einem Absatz, einer Tabellenzeile über komplette Seiten bis zum gesamten Dokument. Eine 100% Automatisierung ist hier übrigens eher ein Ausschlusskriterium, da dann andere Technologien wie z.B. PrintCSS zum Einsatz kommen würden. Die Stärke von InDesign ist das manuelle Finishing, sodass oft nur ein Automatisierungsgrad von 70, 80 oder 90% angestrebt wird. Bei der abschließenden Durchsicht wird dann das schwierig automatisierbare Feintuning durchgeführt. Das hat nebenbei bemerkt zur Folge, dass das Pareto-Prinzip die Kosten einer Automatisierung deutlich senkt.
• Hat man Kandidaten für die Automatisierung gefunden, muss aus den vorhandenen Daten eine Regel abgeleitet werden, mit der die InDesign Objekte erstellt werden können. Je strukturierter die Daten sind, z.B. aus einer Datenbank, desto besser. Im einfachsten Fall mit der Tabellenzeile, müssen die passenden Inhalte der Zeile in der Datenquelle vorhanden sein. Hier kann eigentlich nur der Kunde weiterhelfen, weil man als Entwickler nur selten Eingangsdaten und Ziellayout kennt bzw. versteht. Das Problem ist nun, dass der Kunde selten wie ein Programmierer an das Problem herangeht. Die einfachsten Kunden in dieser Hinsicht sind übrigens Informatiker, die keine Kapazität haben, das Projekt selber zu implementieren. Für alle anderen aber gilt: Durch intensives Nachfragen und nachvollziehen der Aufgabenstellung kann man gemeinsam meist recht gut erarbeiten, wie die Daten strukturiert sind bzw. strukturiert sein müssten und wie man aus diesem Datenwust ein sauberes Layout erstellt. Hier sind je nach Projektgröße persönliche Treffen und/oder Telefonkonferenzen unabdingbar.

2. Was benötige ich für eine Anfrage?

Nach einem ersten Telefonat bekommt der Kunde meist die Hausaufgabe alle Punkte zur Erstellung der Anforderungsliste zusammenzutragen. Keine Sorge die Anforderungsanalyse machen wir dann zusammen!

1. Alle Materialien Dokumente und Datenquellen zusammensuchen.
2. Voraussetzungen definieren. Wann soll was passieren? Ein Testdokument zusammenstellen.
3. InDesign Version? Wie variabel soll das Skript einsetzbar sein?
4. Arbeitsschritte und Aufgabenstellung formulieren.
5. Wer soll das Skript verwenden?

Bei kleineren Projekten reicht aber für gewöhnlich ein Vorher/Nachher-Dokument.

Unabhängig von den genannten Punkten lohnt es sich aber meistens schon vorher anzurufen, um grundlegende Fragen der Machbarkeit zu prüfen.

3. Wie gelingt die Umsetzung?

Die Entwicklung von Software ist ein iterativer Prozess. Außer bei ganz kleinen Skripten ist eigentlich immer notwendig mehrere Schleifen zu durchlaufen. In größeren Projekten sind meist abgewandelte Methoden des agilen Projektmanagement üblich. Für kleinere und mittlere InDesign-Skript-Projekte ist das aber meist gar nicht notwendig, sondern man sollte eher die folgenden Punkte berücksichtigen:

• Für die Kommunikation, die oft die Hälfte des Gesamtbudgets ausmacht (auch wenn ich das selten so explizit ins Angebot schreibe), muss genügend Zeit auf Seiten des Kunden und Entwicklers eingeplant sein.
• Klar definierte Teilbereiche sollten schrittweise implementiert werden, damit der Kunde frühzeitig prüfen und ggfs. gegensteuern kann. So entwickle ich eigentlich immer erst ein Proof of Concept und lasse dann die Funktionsweise durch den Kunden testen. Das hat den Vorteil, dass die Anwendung und Wartbarkeit über Formate und Templates direkt in der Praxis geübt und verstanden wird.
• Bei Fragen sollte sowohl der Kunde als auch Entwickler schnell reagieren. Nichts ist anstrengender als sich nach langer Pause wieder in ein Projekt einzudenken.

Wie kontrolliere ich das Ergebnis?

Als Entwickler bietet es sich an die in Anforderungsanalyse gefundenen Punkte in eine Checkliste zu überführen und diese vor Auslieferung systematisch abzuarbeiten. In der Praxis erstelle ich mir gerade bei kleineren Projekten jedoch meist nur ein Testdokument, das alle Fälle beinhaltet. So kann relativ schnell visuell kontrolliert werden, ob das Skript die gewünschten Punkte auch umsetzt. Wenn eine strukturierte Datenquelle vorliegt, wird diese ebenfalls zu Testzwecken eingedampft.
Hier müsste, genauso wie im Bereich Dokumentation, eigentlich deutlich mehr Energie investiert werden. Der Einsatz von Unit Testing mit einem Testframework ist leider bei kleineren Projekten kaum wirtschaftlich abbildbar.

Budget? Das wird doch eh’ nie eingehalten

Je größer ein Projekt, desto schwieriger wird auch eine seriöse Kostenschätzung, deswegen ist die detaillierte Anorderungsnanlyse so wichtig. Wie oben schon angesprochen, muss man ein gutes Polster für Kommunikation und Feinabstimmung bereithalten. Wenn es Probleme gibt, liegt es fast immer an Erweiterungen und Änderungen. Klar kleine Erweiterungen sind erstmal inklusive. Zu einem Problem wird der sogenannte Feature Creep, wenn die Erweiterungen nicht enden wollen: Der Kunde findet bei jeder Kontrolle viele neue Punkte, die bei der Anforderungsanalyse gar nicht genannt wurden. In den meisten Fällen entsteht die Situation, dass ich viele kleine Erweiterungen kostenlos implementiere und wenn es mir dann irgendwann zu bunt wird, vor dem Problem stehe, für eine kleine Anpassung verhältnismäßig viel Geld zu verlangen. Manchmal gibt es auch das Problem, dass die Architektur des Skripts gar nicht für diese Aufgaben vorgesehen ist und aufwändige Umstellungen notwendig werden, deren Kosten für den Kunden schwierig nachvollziehbar sind.

Ich versuche diese Probleme durch frühe und offene Kommunikation zu beheben, gelingen will es mir nicht immer. Trotz dieser in der Softwareentwicklung üblichen Probleme komme ich normalerweise mit meinen Schätzungen hin: Rund 75% der Projekte bleiben bei mir im ursprünglich abgesprochenen Kostenrahmen.

---

Jason Text zum Thema findet auf seinem Blog unter dem Titel Ich Du Er Sie Es Wir Ihr Sie Automatisieren. Die andere Perspektive erweitert den Horizont ungemein.