Archive for Januar 2014

h1

Leichte Sprache oder nicht?

31. Januar 2014

ECM-Berater schreiben deutlich mehr Word-Texte, als Programm-Code. Daher habe ich mich schon immer intensiv mit der Verständlichkeit von Fachtexten auseinandergesetzt.

Sofern es der Kunde nicht anders wünscht, nutze ich die vorzügliche Information-Mapping-Methode, um die Informationen aufzubereiten. Ich versuche den Empfehlungen von Wolf-Schneider und anderen Autoren zu folgen.

Nun bin auf einen Ansatz gestoßen, deutsche Texte für geistig Behinderte und schlecht deutsch Sprechende aufzubereiten: „Leichte Sprache„. Und dieser Ansatz entspricht über weite Strecken den Vorgaben für gute technische Dokumentation.

Bestätigt das den Verdacht mancher Geisteswissenschaftler, daß die in der Software-Industrie Tätigen geistig zurückgeblieben sind? Nein. Aber technische Texte folgen eigenen Regeln:

  • Sie sollen niemanden beeindrucken.
  • Sie müssen nicht schön sein.
  • Sie sollen unmißverständlich klar sein.

Ironie, abwechslungsreiche Wortwahl, tief geschachtelte Nebensätze, ausgefallene Fremdwörter, doppelte Verneinung können jeden verwirren – auch Hochintelligente. Solche Texte liest man langsamer (bei belletristischen Büchern durchaus mit Genuß!). Aber genau das will man bei technischen Texten nicht.

Welche Regeln kann man nun übernehmen von der „Einfachen Sprache“?

  • Benutzen Sie einfache Wörter!
    Benutzen Sie Wörter, die einen Sachverhalt genau beschreiben!
  • Vermeiden Sie Fremdwörter!
  • Benutzen Sie immer die gleichen Wörter für die gleichen Dinge!
  • Benutzen Sie kurze Wörter!
  • Verzichten Sie auf die meisten Abkürzungen!
    („d. h.“ sollte man ausschreiben)! Gut bekannte Abkürzungen helfen aber.
  • Benutzen Sie Verben!
  • Schreiben Sie im Aktiv – nie im Passiv!
    („Ein Event wird ausgelöst“ verrät uns nicht, wer das Event auslöst. Und genau darauf kommt es im technischen Text an.)
  • Vermeiden Sie den Konjunktiv!
    (ein Konjunktiv im Text sollte sie anblinken: Haben Sie jedesmal auch die Bedingung für dieses mögliche Ereignis dazugeschrieben?)
  • Schreiben Sie positiv – vermeiden Sie Verneinungen!
  • Vermeiden Sie Redewendungen!
    (viele technische Texte werden später übersetzt. Wird der Übersetzer diese Redewendung verstehen?)
  • Schreiben Sie kurze Sätze mit einfachem Satzbau!
    In jedem Satz nur eine Aussage!
  • Vermeiden Sie Fragen im Text!
  • Lösen Sie sich von übernommenen Texten! Kürzen Sie sie! Schreiben Sie sie um! Erfinden Sie Beispiele!
  • Schreiben Sie linksbündigen Flattersatz!
  • Machen Sie viele Absätze und Überschriften!
  • Drucken Sie wichtige Satzteile fett!
  • Fügen Sie oft erklärende Bilder ein!
  • Wenn Ihr Leser etwas nicht versteht, dann war ihr Text schlecht.

Ein paar Regeln würde ich jedoch trotzem mißachten in meinen Texten.

  • Eingeführte Fachbegriffe helfen – wenn alle die Fachbegriffe verstehen. Sicherheitshalber sollte man sie aber zu Beginn definieren. (Zu „SOA“ alleine habe ich schon etliche grundverschiedene Definitionen gelesen.)
  • Lange Wörter kann man durch Bindestriche gliedern. All zu rigoros widerspricht es aber unseren Lesegewohnheiten und schadet der Verständlichkeit.
  • Den Genitiv lasse ich nicht sterben. Der schmälert bei gebildeten Lesern nicht die Verständlichkeit – behaupte ich.
  • Bildhafte Sprache kann durchaus helfen. Gerade die abstrakten Softwarekonstrukte werden verständlicher, wenn wir eine Parallele aus der Alltagswelt heranziehen.
  • Jahreszahlen und Zahlen müssen exakt in Ziffern angegeben werden. Wenn die „Aufbewahrungsfrist 20 Jahre“ beträgt, hilft es niemanden von einer „Vernichtung nach langer Zeit“ zu reden. Auch wenn wir uns das bildlich besser vorstellen können.
  • In Softwarekonzepten darf man auch keine Scheu vor Zahlen mit vielen Ziffern oder Prozentangaben haben.
  • Zahlen schreibe ich nur als Ziffern, wenn ich wirklich die Zahl meine. Ich denke, daß „es gibt drei Spezialfälle“ zu weniger Mißverständnissen führt.
  • Einen Satz mit „Oder“ zu beginnen kann man machen. Konsequent durchgeführt führt das aber zu einer Staccato-Satzmelodie, die das Lesen womöglich wieder verlangsamt.
  • Definitiv muß man ständig auf andere Textstellen verweisen. Die Information-Mapping-Methode empfiehlt auch Redundanz (alles was ich zur Fragestellung meines aktuellen Kapitels wissen muß soll ich auch in meinem Kapitel finden). Aber in der Praxis läßt sich so ein Text schlecht warten und wäre teilweise extrem lang.
  • Schrifttypen mit Serifen sind bei gedruckten Texten nachweislich schneller zu lesen. Und Courier hat Vorteile bei Codestellen.
  • Pro Satz eine neue Zeile wäre schon etwas rigoros. Die extrem hilfreichen Aufzählungen mit Spiegelstrichen führen allerdings zu einem ähnlichen Effekt.
  • Ich nutze Silbentrennung. Ich würde aber davon ablassen, wenn ich einen Nachweis lesen würde, daß sie die Lesegeschwindigkeit bremst.
  • Es könnte schon sinnvoll sein, einen Seitenumbruch nur am Satzende zu machen. Aber da wir Texte ständig überarbeiten, kämen wir mit den manuellen Seitenumbrüchen nicht mehr hinterher.

Wenn Sie selbst Texte schreiben: Schauen Sie mal die unprätentiösen Worterklärungen bein Hurraki an! Das macht doch Lust, die vielen kursierenden Blähworte zum Platzen zu bringen, oder?

Ein Leitbild für meine Texte ist: Ein aufgeweckter Zehnjähriger sollte sie verstehen. Wenn ich das jemals schaffe, dann schreibe ich selbst ein Buch über gute technische Texte.

h1

In die Cloud oder nicht?

26. Januar 2014

Srijith Gopalakrishnan beschreibt in seinem Blog ganz stolz, wie er ein Büro papierlos gestellt hat.

2 Dinge haben mich dabei frappiert:

  • Seine einzige Motivation scheint zu sein, daß er es cool findet. Es sei sozusagen von vornherein besser, papierlos zu arbeiten. Nur leider könne man sich zu selten dazu aufraffen.
    Das reicht meiner Ansicht nach nicht.
    Ehe ich das Neuland Papierlosigkeit betrete, sollte ich schon ein Ziel vor Augen haben. Es gibt viele gute Gründe, Dokumente zu scannen und nur noch als Datei zu betrachten. Aber bei jedem spezifischen Grund würde man seine papierlose Umgebung anderes ausgestalten.
    Und: Viele kleine Büros arbeiten wunderbar mit Papier. Sie haben meist wenig Post; alle Mitarbeiter kommen immer an einem einzigen Ort zusammen, um die Dokumente zu bearbeiten. Das Büro ist feuer- und überschwemmungssicher etc.
  • Er speichert alle Dokumente in der Cloud.
    Das hat so viele Nachteile, daß man es schon erstaunlich ist, daß Srijith Gopalakrishnan überhaupt darüber nachgedacht hat:

    • Mein Anbieter kann die Lust an diesem Geschäftsmodell verlieren und den Betrieb einstellen. Über die Jahre haben sich dann zig Terrabyte Daten angesammelt, die ich nun per Download und Upload zu einem anderen Anbieter schaufeln muß. Jeder kann sich ausrechnen, wieviele Tage bis Wochen das bei seiner Upload-Geschwindigkeit dauert. In dieser Zeit ist mein Betrieb in Zwangsurlaub!
    • Mein Anbieter kann verboten werden, wie das bei Megaupload passiert ist. Dort wurden ja nicht nur illegal kopierte Filme hochgeladen. Wer dort seine Geschäftsdaten gelagert hatte, hatte hoffentlich auch eine lokale Kopie. Sonst hätte er zusperren können.
    • Jeder Geheimdienst und Hacker kann natürlich meine Dokumente mitlesen – wenn ich sie nicht verschlüssle. Das kann einer Schreinerei egal sein. Aber schon ein kleiner Softwareentwickler bekommt oft Echt-Kundendaten von seinen Auftraggebern und muß sie absolut vertraulich behandeln. Diese Dokumente darf er dann nur verschlüsselt in der Cloud ablegen.
    • Ich habe bei Dropbox etc. nur eine Filesystem mit Dateinamen. Meine Dokumente kann ich also nicht mit den Indexfeldern eines DMS wiederfinden. Ich bin auf einen Volltextindex angewiesen, der mir regelmäßig zu viele Treffer liefert und manche Treffer nie, weil OCR doch nicht so gut funktioniert.

Mir scheint fast, dieser „business process guy“ wäre besser bei seinen Prozeßbildchen geblieben und hätte nicht versucht, ECM-Umgebungen zu konzipieren.

h1

Dokumente verarbeiten oder nicht

10. Januar 2014

Wir Menschen lieben Dokumente. Einen Auftrag „schreiben“ wir gerne. Eine Bestellung haken wir gerne ab. Wenn wir an eine Freigabe denken, entsteht ein Blatt Papier vor unserem geistigen Auge.

Andererseits lieben unsere Fachanwendungen Datenbanken. Unsere Programme möchten nicht, daß wir auf Dokumente schreiben, sondern unsere Daten in Tabellen ablegen. Das ist natürlich indiskutabel für den Alltag. Also hat sich als Kompromiss die GUI herausgebildet, die eine menschenfreundlichere Sicht auf die Datenbanktabellen bietet. So schön manche GUIs auch gemacht sind, man bekommt nie das Gefühl ein autarkes, separat abspeicherbares Dokument vor sich zu haben.

Ein interessanter Gedanke ist natürlich: Warum soll ich als Benutzer nicht die totale Bequemlichkeit fordern? Ich möchte nicht mit GUI-Masken arbeiten, sondern mit „richtigen“ Dokumenten (auch wenn ich sie am Ende doch nur am Bildschirm zu sehen bekomme).

Ein DMS bietet (zusammen mit entsprechend angepaßten Fachanwendungen) durchaus Möglichkeiten, diesem Traum näher zu kommen:

  • Wir erfassen die Daten (z. B. eines Auftrags) doch in einer GUI: nämlich der Indexfeldmaske des Dokuments – lassen aber jedesmal ein schönes, gut lesbares Dokument daraus generieren. Wer nichts ändern muß, arbeitet dann nur mit der Dokumentform der Daten.
  • Wir schreiben unsere Dokumente mit Word. Während der Bearbeitung ändern diverse Personen das Word-Dokument. Am Ende werden die so erfaßten Daten automatisch herausgezogen („Capturing“). Spannend bleibt bei dieser Variante, ob alle Beteiligten die nötige Disziplin aufbringen, um sich an die Struktur eines korrekt interpretierbaren Auftrages zu halten.
  • Wir haben ein wohlstrukturiertes Formularformat (Adobe LiveCycle nutzt XFA, ExsoForm nutzt ein proprietäres Format), mit dem immer schöne Dokumente in einem Viewer (z. B. der AdobeReader) dargestellt werden. Das Formular gestattet die Eingabe zusätzlicher Daten. Im selben Format werden auch die Daten gehalten. Das Dokument ist in sich immer komplett und kann im DMS verwaltet werden oder im Workflow bearbeitet werden. Ob das so schön funktioniert, wie man das wünscht, hängt von Fähigkeiten des Formularformats und den Renderingmöglichkeiten ab. Adobe LiveCycle ist da bekanntlich sehr leistungsstark.

Fazit: DMS- und Workflow-Systeme bieten uns die Chance so zu arbeiten, wie wir wollen. Man darf sich ganz naiv die ideale Arbeitsweise wünschen. Es geht mehr, als man oft denkt! (Auch wenn Randparameter gelegentlich doch einen Kompromiß erzwingen.)