Meine Klebezettel finden sich jetzt in Wunderlist ToDoist. Da habe ich verschiedene Listen angelegt, etwa für die Arbeit mit den aktuellen To-Dos, das ist die aktivste. (Außerdem müsste-man-mal-Listen und eine Liste für angehende Praktikant*innen bei uns.)
Aber auch fürs Bloggen habe ich einen Themenspeicher dort angelegt. Genauer: für jedes Blog ein eigenes Projekt. Der Titel des Eintrags ist dann der geplante Titel des Blogposts.
Manchmal reicht der Speicher aber nicht. Besichtige ich die dürren, nur aus dem Titel des künftigen Blogposts bestehenden Notizen, Monate später dort, wo gern auch noch mal Rechtschreibfehler enthalten sind, fällt mir oft nicht mehr ein, was ich eigentlich bloggen wollte. (Notiz an mich selbst: gleich Skelett des Beitrags mit anlegen, im Kommentar zur Aufgabe.)
Der noch bessere Weg ist es daher für mich, bereits einen Entwurf für einen Post mit einer Outline mit Stichworten anzufangen. Dass mir Posts gern mal aus dem Ruder laufen, vor allem im Einstieg – geschenkt. So eine Outline zwingt im Nachgang zu etwas mehr Sorgfalt. Derzeit liegen in meinem Blog mehr als 190 Entwürfe, die ich auch versuche abzuarbeiten. Warum so viele? Weil ich aus meinem Lieblingsclient zum Bloggen, MarsEdit, wegen der geplanten Neuinstallation alle ins Blog geschickt habe. Gern auch mal in unterschiedlichen Zuständen. Versionskontrolle von Blogpostentwürfen wäre auch ein Thema für einen Post. Heute soll es aber über die Übersichtlichkeit des Redakteursbackends in CMSen gehen.
Es ist ganz sicher ein Edge Case in der CMS-Entwicklung. Die User Story liest sich auch nicht ganz schmeichelhaft:
Als Redakteur möchte ich eine Ansicht im CMS-Backend haben, die es mir ermöglicht, den Zustand vieler (n= 50-100) angefangener Beiträge auf einen Blick einzusehen, damit ich schneller entscheiden kann, welchen Blogpost ich als nächsten fertigstelle.
Als Product Owner würde ich so eine Story auch nach hinten priorisieren. Der Business Value ist zweifelhaft. Einem Stakeholder in einem solchen Projekt würde ich sagen: Dafür ist das System nicht vorgesehen. Da sollen die Nutzer weniger anfangen und mehr beenden.
Aber warum ist das eigentlich so und wie müsste das in einer besseren Welt aussehen? Es wäre eine Liste mit Spalten, so ähnlich wie in Outlook. Stürzt das Programm ab, so speichert es in der Regel die bereits begonnenen Entwürfe ab. Es gibt dann nicht nur einen Eintrag mit dem Betreff, sondern auch dem Empfänger und einen Zeitstempel der letzten Änderung an dieser Mail. Seltsamerweise sind aber die meisten Outboxen oder Postausgänge nicht so durchkonzipiert wie die Inboxen. Inboxen sind für schnelle Abarbeitung ausgelegt, Outboxen nicht. Offenbar weil die Konzepter von einer 1:n-Beziehung ausgehen, vermute ich. Alle (=n) können dir schreiben, aber nur 1 kann nach außen senden. (Haben die eine Ahnung. Wer unter Andruckstress und hartem Redaktionsschluss produziert hat, kann erstaunlich viel produzieren. Zum Beispiel auf der Heimfahrt – da gehen zwei vollständige Blogposts, ohne Links, oder etwa drei bis vier Outlines.)
Das gewünschte System würde die Einträge also in einer stufenlos verstellbaren Ansicht anbieten – mehr Details, wenn der Autor das gern hätte. Wie man das Problem neu betrachten kann, beweist für mich die Desktop-WordPress-App für den Rechner. Anders als beim klassischen wp-Admin, dem beliebten und auch verhassten Backend der Blogsoftware, ist für das Anzeigen eines Posts da nicht eine Zeile, sondern gleich eine ganze Karte. Nimmt noch mehr Platz weg, ist zum Abarbeiten aber ein bisschen hilfreicher, weil man erahnen kann, worum es in dem Entwurf geht:
Dieses Stück Software heißt im WordPress-Slang Calypso, und der Talk, den ich dazu auf dem WordCamp Europe 2016 in Wien gesehen habe, zeigte mir: Bei Automattic macht man sich wirklich Gedanken, wie man die User Experience verbessern kann. Gleichzeitig muss man eben die Legacy-Software-Probleme des beliebtesten CMS der Welt beachten. Ein… weit aufgespreizter Spagat, um das nett zu sagen.
Die meisten Redaktionssysteme gehen auch von einem mehrstufigen Publishing-Workflow aus. Autor schreibt etwas, schickt das zum abnehmenden Redakteur, der gibt frei und plant den Beitrag ein. So ist etwa die Dashboard-Ansicht in einem anderen CMS, das ich gut kenne, eZ Publish zu verstehen.
Auch Non-CMS-Web-Publishing-Lösungen wie Jekyll lösen das Problem nicht. Dort hat man dann nur in dem Posts-Ornder der Installation lokal einen Haufen Markdown-Dokumente vorliegen, die man mit dem Finder oder dem Explorer previewen kann. Auch nicht ideal, um den Überblick zu behalten.
Meine Lösung ist jetzt jedenfalls pragmatisch. Ich bin kein Coder, daher kann ich mir nicht das Interface bauen, das ich brauche. Ich räume auf. Ein Post nach dem anderen. Ein CMS ist auch nur wie ein Wohnzimmer. Wenn ich mich da nicht mehr wohlfühle, muss ich einfach mal aufräumen. Da kann ich nicht einfach nach einer Fee rufen, die für mich klar Schiff macht. Es ist eine Herkulesarbeit, aber dann habe ich genug Blogposts im Köcher, die im Urlaub erscheinen können.
Nur noch 194 to go.
Photo by Kelly Sikkema on Unsplash