Auf dem Weg zum Altpapiercontainer werden meine Arme unter der Last eines Stapels alter Softwareschachteln immer länger. Das hat auch sein Gutes, denn dann kann ich die Treppe besser sehen, die ich heruntertappe. Wer wie ich letztens umziehen will, mistet vorher schweren Herzens und schweren Schrittes aus. Einziger Trost: Beim nächsten Umzug wird alles besser, denn dank Downloads und Subscriptions stehen Softwareboxen auf der Liste der akut vom Aussterben bedrohten Alltagsutensilien. Kulturell ist das haptische Erlebnis des Brechen eines Kunststoffsiegels zu verkraften (“Mit dem Öffnen der Verpackung erkennen Sie die Lizenzbedingungen…”). Zudem fallen die oft voluminösen Handbücher weg.
Ich bin kein Nostalgiker, mein Leben als Anwender könnte auch ohne gedruckte Handbücher gelingen, die ich Jahre später sowieso zu einem Papiercontainer bugsieren muss. Die Praxis zeigt jedoch, dass Hersteller und freie Projekte gleichermaßen die digitale Form von Dokumentation als Einladung zum Reduzieren bis zur Unkenntlichkeit verstehen. Damit kommen die Anbieter durch, weil die Kunden keine Softwareschachtel mehr zur Kasse tragen. Früher signaliserten Größe und Gewicht der Box noch etwas über die Bereitschaft des Produzenten, seine Anwender beim Benutzen des Programms zu unterstützen – heute nicht.
Nach dem Wegfall ausführlicher Handbücher geht es mir nicht mal darum, wie der viel beschworene Einsteiger seine ersten Schritte hinbekommt – die Hauptfunktionen vieler GUIs sind heute einigermaßen selbsterklärend. Das wahre Elend lauert jenseits der ausgetretenen Wege – auch für technisch fittere Anwender. Letztens wollte ich Maßlinien in Open Office Draw benutzen. Allein um herauszufinden, wie ich eine 3 mal 1 Meter große Zeichenfläche anlege, habe ich fünf Minuten gebraucht.
RTFM, Read the fucking Manual, hätte man mir früher beschieden, wenn ich mich in einem Forum beschwert hätte. Heute ist “RTFM” zu posten außer Mode – zurecht: Read the fucking what?! Die Erklärungen zu den Bemaßungsfunktionen in der Open-Office-Hilfe beginnen thematisch irgendwo und enden kurz danach. Wie die zugehörige Ebene funktioniert, hat sich mir auch nach einer Stunde nicht erschlossen. Dann habe ich das Projekt “Jan macht am PC eine einfache technische Zeichnung” aufgegeben, die Sache mit Stift und Lineal in wenigen Minuten auf Papier erledigt und das Ergebnis eingescannt.
Ich bezweifle nicht, dass “man” in Open Office diese Arbeit ganz passabel erledigen kann – aber eben nicht “jedermann”. Vielleicht wird diese Funktion so selten benutzt, dass es nicht lohnt, ihre Usability perfekt zu gestalten. Aber genau hier entsteht die Notwendigkeit einer verständlichen und vor allem vollständigen Dokumentation! “Stiefmütterlich” behandeln viele Projekte ihre Hilfetexte, ist oft zu lesen. Wer das schreibt, tut angesichts des lieblos-verknappten Geschreibsels Millionen Stiefmüttern tiefes Unrecht, die ihren angeheirateten Kindern jeden Morgen das Pausenbrot in den Schulranzen stecken.
Ich meine, die Tendenz Programmbeschreibungen bis zur oder unter die Wahrnehmungsgrenze zu schrumpfen, führt geraden Weges in die Sackgasse: Wozu noch Dutzende neuer Features, die als Stichworte in Changelog-Dateien und sonst nirgends auftauchen?! Kaum jemand wird sie nutzen. Mit ein bisschen Weitsicht ist eine gute Dokumentation kein disponibler Kostentreiber, sondern ein Marketingmittel, das Kunden den eigentlichen Entwicklungsaufwand am Produkt erst verdeutlicht. Darum: Doku statt Produktflyer!
Solche Gedanken kommen einem, der eine gefühlte Zehn-Kilo-Dbase-Schachtel drei Etagen nach unten schleppt und Handbuch für Handbuch in den Schlitz eines Altpapiercontainers plumpsen lässt.
