Die Wolken verbinden

Lange war von «Cloud» nur als Idee und Konzept die Rede, dann hat Adobe uns den Begriff verleidet. Zeit für den zweiten Blick, denn nichts weniger als ein neu gedachtes «Betriebssystem» für die Medienproduktion ist gerade am Entstehen.  

Was ich die letzten Jahre gemacht habe, hat mit klassischer Medienproduktion nichts mehr zu tun. Früher, da war ich es gewohnt, in einem Layoutprogramm Stilvorlagen anzulegen, Rahmen auszurichten und die Typografie zu verfeinern. Unzählige Male habe ich Druck-PDFs exportiert und im Anschluss nochmals alles genau geprüft. Meistens so lange, bis ich mindestens einen Fehler gefunden habe. Das ist vorbei, wenn ich heute Medienproduktion mache, lege ich Felder und Inhalte in Con-tent-Management-Systemen an und entwickle intelligente HTML-Tem-​plates, um diese Inhalte auszugeben – und das nicht nur im Web. Gestaltung ist in dieser Welt ein Algorithmus, den es zu definieren gilt. Und Publishing ist dabei ein Prozess, der genauso modelliert wird wie die vielen anderen Prozesse im Unternehmen. Das klingt alles verdächtig nach IT, und genau das ist es: Publishing, Medienproduktion, Gestaltung, Marketing – alles IT.

Das ist natürlich nichts Neues, mögen manche jetzt aufschreien: Publish­ing war doch schon immer IT! Richtig, doch IT ist heute auch etwas anderes, als sie es mal war. Wo früher der Arbeitsplatzcomputer mit installierten Programmen dominierte und wo auch genau die eigentliche Rechenarbeit passierte, zeigt sich heute ein anderes Bild: Immer häufiger öffnen wir den Browser und darin eine Applikation, die zwar vor Ort bedient, aber in Wirklichkeit auf irgendeinem entfernten Server ausgeführt und kalkuliert wird. Das Tempo, in dem sich immer mehr Anwendungen vom Desktop in den Browser verlagern, ist atemberaubend. Und auch viele Desktopanwendungen sind ganz oder teilweise nur noch Fenster zu fernen Servern, auf denen die eigentliche Arbeit erledigt wird. Diese entfernten Server nennt man gerne Cloud. Wenn nur dieser Begriff nicht so schrecklich bekannt und öde klingen würde!

Leider hat Adobe uns Publishern das Wort von der Cloud besonders verleidet, indem es einfach die bekannten Programme vermietet und gleichzeitig «Cloud» draufgeschrieben hat. Ärgerlich, denn Cloud ist so viel mehr.

Schon in Publisher 1-16 habe ich in einem Artikel geschrieben: «Denn die reine Speicherung der Daten (egal ob in der Cloud oder lokal) ist wenig sexy, zentral ist die Intelligenz der Infrastruktur – was also mit diesen Daten passieren kann. Und gerade da kratzt Adobe die Möglichkeiten nur an.» Im gleichen Text habe ich dann weiter spekuliert über ein «Betriebssystem für die Cloud». Jetzt, da ich wieder ein paar Jahre älter, in manchen Bereichen auch klüger geworden bin und in vielen Projekten Neues lernen durfte, glaube ich, die alte Spekulation zu einer Gewissheit machen zu können. Das Betriebssystem ist gefunden. Mit einem entscheidenden semantischen Unterschied: Es braucht kein Betriebssystem für die Cloud, die Cloud ist das Betriebssystem. Und alles, wirklich alles, was die Cloud zum Funktionieren braucht, sind – Trommelwirbel – URLs!

Gehts noch? Schon wieder so ein altbekannter, vertrauter, irgendwie auch langweiliger Begriff. Vielleicht liegt das Spannende an der Cloud genau darin, dass wir viele Konzepte dahinter schon lange kennen. Neu ist, dass sich die Puzzlestücke jetzt zusammenfügen. Dass sich URL, API, Webhook, Browser, HTML und viele andere Konzepte, die es für manche erst noch zu entdecken gilt, jetzt zu einem stimmigen Gesamtbild zusammensetzen. All das zeigt sich in Tools, die wiederum miteinander verbunden eine Publishing-Welt entstehen lassen, die flexibler, dynamischer, erweiterbarer und, ja, auch einfacher ist, als das, was bisher da war. Mag die Creative Cloud das Betriebssystem des bisherigen Publishings gewesen sein, das neue Betriebssystem besteht aus URLs, Webhooks und APIs.

Klingt kryptisch? Okay, machen wir es konkret:

Erst mal bunte Bilder

Natürlich muss die Geschichte des neuen Publishing-Betriebssystems in der Cloud mit den Inhalten beginnen. Mit was denn sonst. Zur ersten Assoziation, den Texten, komme ich gleich. Mit Bildern, ebenfalls gewichtige Inhalte, ist der Einstieg einfacher. Bilder haben wir bisher auf dem File-Server gespeichert, mit Photoshop retuschiert, verfremdet, montiert und wieder neu gespeichert. Was wäre gewonnen, wenn das Bild statt auf dem lokalen File-Server in der Cloud läge? Erst mal nichts. Gut, das Bild hätte zwar eine URL: www.mycloud.com/bild.jpg. Schon wieder gähn. Aber, aufwachen, jetzt wird es spannend: Könnten wir damit nicht auch so etwas machen: www.mycloud.com/breite_300,hoehe_300/bild.jpg? Wir schreiben in die URL einfach, wie wir das Bild gerne haben möchten, 300 Pixel breit, 300 Pixel hoch. Voilà, da haben wir das Bild, zugeschnitten in der gewünschten Grösse. Richtig gut sieht das jedoch noch nicht aus, die Gesichter sind abgeschnitten. Also nächster Versuch: www.mycloud.com/breite_300,hoehe_300,focus_gesichter/bild.jpg. Viel besser!

Aus der gerade noch als dumm und profan belächelten URL wird plötzlich ein Fenster in eine ganz neue Welt. Welche Befehle mögen sich hier noch verbergen? Und wie funktioniert der Trick? Wenn wir die URL aufrufen, läuft im Hintergrund auf dem Server ein Programm ab, das die Adresse auswertet und aus ihren Parametern Befehle konstruiert und ausführt. Die URL ist also eine Schnittstelle zu einem Computerprogramm. Diese Schnittstelle ist das, was man Application Programming Interface, kurz API, nennt. Eine Buchstabenkombination, die, und das sage ich schon seit x Jahren, jeder im Publishing kennen sollte. Wenn wir jetzt www.mycloud.com/breite_300,hoehe_300,focus_gesichter/bild.jpg in den Browser eingeben, führt unsere Bild-Cloud zuerst eine Gesichtserkennung durch (das klingt fancier, als es ist), setzt die Gesichter als Fokuspunkt des Bildes, schneidet darum ein Quadrat und rechnet das Ganze auf 300 Pixel herunter.

Solche Cloud-Services für Bilder (und Videos) gibt es wirklich, sie sind keine Erfindung von mir. Cloudinary ist mein liebstes Beispiel, imgix ein anderes. Dienste, die Bilder über URL-Parameter manipulierbar machen, mit Möglichkeiten, die noch weit über das einfache Beispiel hier hinausgehen. Glauben Sie nicht? Also bauen wir mal einen etwas komplexeren Workflow.

Ein echter Printbolide

Wer von den alten Printhasen unter den geschätzten Lesern kennt noch Enfocus Switch? Natürlich, ein immer wieder faszinierendes Tool. Dateien werden von Ordner zu Ordner geschleust, dazwischen führen verbundene Programme Befehle auf diesen Dateien aus. Übrigens – und ich sage es so oft, bis es nervt –, auch das sind APIs. Switch ist das bewährte Arbeitstier in den PDF-Workflows unzähliger Druckereien und Vorstufen. Aber Switch kann so viel mehr. Weil Switch auch mit URLs kommunizieren kann, wird es flugs zum Teil unseres Cloud-Betriebssystems.

Wir nehmen einen Eingangs-Hotfolder in Switch und legen unsere aktuellen Bilder darin ab. Switch nimmt diese Bilder auf und sendet sie an eine URL. Auch das ist wiederum eine API, aber eine etwas andere: Keine wie oben, von der ich passiv auf Nachfrage etwas erhalte (technisch: GET-Request), sondern eine, an die ich selbst aktiv Daten übergebe (technisch: POST-Request). Die API ist wieder nichts anderes als eine URL à la www.mycloud.com/hier-neue-bilder, an die wir unsere Bilder senden, die dann von dort weiterverarbeitet werden. Das Programm auf dem Server nimmt unsere Bilder entgegen und legt sie bei Cloudinary ab. Mit diesen beiden Typen von API-URLs – ein GET-Request, der uns etwas liefert, und ein POST-Request, an den wir etwas liefern – können wir alles bauen, was wir uns an Cloud-Anwendungen vorstellen können.

Ziemlich cool, wir haben unsere interne Welt mit derjenigen der Cloud verbunden und unsere Bilder via Switch bei Cloudinary abgelegt. Gleich wird es aber noch besser, denn die neuen Bilder bei Cloudinary stossen den nächsten Prozess an. Wir lesen die Metadaten (etwa EXIF oder XMP) innerhalb eines Bildes aus und bekommen so Zugriff auf die Copyright-Informationen der Datei. Wenn wir noch wissen, dass Cloudinary auch Texte und Wasserzeichen auf Bilder setzen kann, können wir (hier in beispielhaftem Pseudoprogrammiercode geschrieben) Folgendes machen:

Wenn (Bild hat Copyright) {

speichere mycloud.com/ quadratisches Bild mit Wasserzei- chen und Copyright-Info/bild.jpg}

Dieses fertige Bild senden wir über eine URL zurück an Switch (POST-Request), wo es bei uns auf dem File-Server abgelegt wird. So haben wir gerade nichts anderes gemacht, als einen Prozess gebaut, der neue Bilder nimmt, in die Cloud lädt, Copyright-Daten im Bild auswertet, ein quadratisches Bild mit Copyright-Zeile – etwa für Social Media – erstellt und es schliesslich wieder ablegt. Alles über URLs, die miteinander sprechen. Kids würden jetzt dazu wohl WTF sagen.

Daten in Feldern

Drehen wir die Schrauben weiter an. Copyright-Informationen in Bildern, das sind Metadaten, also Daten über Daten. Sie sind extrem wichtig und in ihrer Bedeutung kaum zu überschätzen – vor allem wenn wir den Blick auf die neuen Medien rund um Alexa und Siri richten. Die grossen Brüder der Metadaten, die Daten, sind aber natürlich noch wichtiger: Bilder und Videos haben wir im Cloud-Betriebssystem schon verankert, fehlt noch Text in all seinen Facetten.

Ach, Text! Lange haben wir Medienproduzenten ihm mehr als unrecht getan. Ihn in unhandliche, riesige Rich-Text-Editoren gekippt, gar ganze Seiten in ihnen aufgebaut – wie in Word. Komplette Websites wurden so zu dummen «Blobs», wie die Amerikaner sagen. Ein einziger Sauerteig aus Text, Bild und Formatierung. Für nichts zu gebrauchen, ausser zur schönen Gestaltung, die wir uns gerade zimmern. Auch Text in einem Rahmen in InDesign ist übrigens ein solcher dummer Blob.

Der Markt ist da glücklicherweise weiter. Aus den Blobs werden «Chunks» – in semantisch verständliche Informationsatome zerlegte Inhalte, die nicht dumm auf die Seite geworfen, sondern intelligent in Regelwerke verpackt werden (siehe dazu Publisher 1-16). Es hat sich daraus sogar eine eigene Disziplin herausgebildet: das Content Engineering. Diese mit Bedeutung aufgeladenen Inhalte sind perfekt für unsere Publishing-Cloud. Doch es wird noch besser. Es gibt auch die Systeme, die das alles erschwinglich und zugänglich machen. Natürlich kann auch WordPress, Gutenberg-Editor hin oder her, so verwendet werden. Ich finde aber Systeme besser, die genau dafür gedacht sind. Kirby ist ein solches und gerade mein absoluter Favorit. Contentful ist ein anderes – und es gibt noch viele weitere.

Beide Systeme werden in Deutschland entwickelt: Contentful ist etwas spitzer als Content Management für das Cloud-Zeitalter positioniert, während sich Kirby auch für stinknormale Websites verwenden lässt. Das Prinzip ist bei beiden das gleiche: Man definiert die Felder (Chunks!), aus denen der Inhalt seine Bedeutung zieht, und erhält eine massgeschneiderte Einpflegemaske, um diese Felder zu befüllen. Diese Masken können flexibel bis zum Exzess angepasst werden. Das macht Spass, dem Softwareentwickler, weil die Systeme genau für diese Anpassungen gemacht sind, und dem Inhaltsentwickler, weil die Masken nichtnach Windows 95 aussehen und sich dem Inhalt anpassen, nicht umgekehrt.

Auch Freigabe- und Abstimmungsprozesse – in manchen Unternehmen komplizierter als das Organigramm – lassen sich mit der gleichen Power passgenau umsetzen. Bei Kirby geht das integriert, bei Contentful braucht es andere Dienste wie Zapier oder IFTTT. Gerade Kirby glänzt hier aus meiner Sicht. Man merkt, dass ein Konzept aufgeht, wenn es sich von der einfachsten Poppel-Anwendung bis hin zur hochkomplexen Enterprise-Applikation ohne Verrenkungen skalieren lässt. Wenn der Inhalt in die ganzen schönen Masken eingegeben ist, kommt schon wieder das unvermeidliche, wir setzen eine API drauf! Und schon hat jeder Inhalt nicht nur seine Repräsentation als verwendbares, intelligentes Datenformat wie JSON oder XML, sondern auch eine URL. So könnte etwa www.mycloudcms.com/produkte alle Produktdaten zurückliefern. Cool, dann kann es ja wieder losgehen mit dem Basteln von Cloud-Workflows.

An dieser Stelle sei ein Einschub erlaubt, dem Leser wird es vielleicht etwas schwindlig ob der Zahl an Systemen, die hier involviert sind und miteinander sprechen (und ich bin noch nicht fertig!). Wäre es nicht einfacher, ein System zu finden, das alles integrieren kann? Auch da hat sich etwas verändert. Während früher in der IT der Monolith dominierte, eben jenes allmächtige, hochgezüchtete Monstersystem, das vermeintlich alles konnte, macht man heute gerne einen auf «Best of Breed». Die besten ihrer Rasse, das klingt stark nach Sozialdarwinismus, ist aber in Wirklichkeit die pure Naturromantik. Was gibt es Schöneres als eine bunte, vielfältige Umwelt? Genau so ist es auch mit Software – natürlich kann Kirby sich auch um die Bildumrechnungen kümmern, aber Cloudinary wurde genau dafür gebaut und kann es eben auch besser. Best of Breed ist die IT-Strategie für das Cloud-Zeitalter: Für jede Aufgabe sucht man sich das beste System, dieses System kümmert sich dann auch nur genau um diese eine Aufgabe, löst diese unkompliziert und perfekt – und kommuniziert mit den anderen Systemen über APIs und URLs.

Wir woll’n Gestaltung sehn!

Am Schluss geht es im Publishing immer um das «Ding», das angeschaut, gelesen, gehört oder was auch immer werden soll. Wir brauchen ein Front­end, egal für welches Medium. Docken wir die nächsten APIs an unser Cloud-Betriebssystem an. Welches Medium hätten’s denn gern?

Ich unterscheide da oft zwischen zwei Ansätzen im Setup des Front​ends: Gestalten wir ein Medium, das sich komplett in Regelwerke giessen lässt, das also vollständig automatisiert produziert werden kann? Oder machen wir etwas, an das wir unabhängig von der Qualität des Regelwerks nochmals Hand anlegen und gestalterisch eingreifen müssen? Für beides gibt es erprobte Werkzeuge. Die Mechanik bleibt immer die gleiche – wir lassen wieder URLs miteinander sprechen: Wir haben beispielsweise einen tollen Inhalt in unserem CMS, wir speichern ihn, er wird freigegeben. In einem modernen CMS wie Kirby oder Contentful löst dieses Freigabeereignis etwas aus, worauf wir wieder etwas draufsetzen können – in der Programmierung wird das Hook genannt. Immer, wenn im CMS eine neue Freigabe erteilt wurde, sendet dies ein Signal, einen «Web-Hook» (eigentlich einfach einen POST-Request) an ein anderes System. Dieses andere System nimmt das Signal auf und macht etwas damit.

Hier ein Beispiel einer automatisierten Printproduktion: Freigabe wird in Kirby erteilt. → Hook «Inhalt XX freigegeben» geht an DocRaptor, ein System zur Erstellung von Print-PDFs in der Cloud. → Doc­​Raptor holt sich die Infos zu Inhalt XX aus der API von Kirby. → Doc­Raptor lässt die abgeholten Inhalte in ein vorbereitetes HTML-Template (etwa für ein Datenblatt) einfliessen und produziert ein Print-PDF daraus. → Dieses Ereignis lässt Doc­Raptor einen Hook an Kirby senden: «Neues PDF von Inhalt XX.» → Kirby holt das PDF ab und speichert es in einem eigens dafür vorgesehenen Feld im CMS. Et voilà, ein fixfertiger Roundtrip-Workflow vom geänderten Inhalt zum immer aktuellen Datenblatt. DocRaptor ist ein Beispiel für einen Service, der auf Basis neuer CSS-Spezifikationen hochwertige, printtaugliche Gestaltung in HTML-Templates realisiert. Es gibt noch mehr. Die Technologie ist hier schon weit, obwohl es natürlich gerade in der Typografie noch einige Beispiele gibt, wo InDesign und Co. im Vorteil sind – Abhilfe ist aber in vielen Fällen schon in Arbeit oder kann über JavaScript-Libraries integriert werden. Ich wage mal eine Prognose: Es wird wohl bald ziemlich normal sein, Printprodukte auf diese Art und Weise zu erstellen.

Bei diesem Workflow läuft alles automatisch. Er ist perfekt geeignet für alle Produkte, die sich in Regelwerken formulieren lassen, etwa Datenblätter oder Anzeigen. Es gibt aber genügend Produkte, bei denen das (noch?) nicht so einfach geht. Machen Sie mal Folgendes – und jetzt fängt hoffentlich der Leserkopf an zu rauchen: Ersetzen Sie in der obigen Ereigniskette Doc­Raptor durch Switch und HTML durch InDesign. Ja! Krass! Genauso funktioniert es auch. Switch kann den Hook aus Kirby genauso entgegennehmen und in einem InDesign-Script weiterverarbeiten. Als kleine Randbemerkung hier noch ein Vorteil von Best of Breed: Die Systeme sind leichter auszutauschen, wenn sich die Anforderungen ändern.

Ein InDesign-Script kann dabei erst einmal genau so arbeiten wie DocRaptor auf HTML-Ebene, also die Daten von der API abholen und auf Basis von Regelwerken in ein Template giessen. APIs abfragen geht in InDesign-Scripten leider nicht «out of the box» (in QuarkXPress übrigens schon). Zum Glück hat Deutschlands InDesign-Scripter Gregor Fellenz mit Restix da Abhilfe geschaffen. Den Satz mit InDesign durchzuführen, löst die Probleme, die aktuell mit HTML-Templates noch bestehen mögen – und es öffnet natürlich eine neue Welt: die des manuellen Eingriffs in das Dokument. Ich spreche da gerne vom «Kuratieren» eines Mediums. Das Script/Template produziert ein gutes Vorlayout, danach ist es am Menschen, Individualität und Kreativität in das Endprodukt zu bringen. Ist «das Beste aus beiden Welten» dafür eine zu banale Phrase? Egal, es stimmt und sollte alle beruhigen, die APIs und CMS-Felder für Schrauben­kataloge ganz nett finden, aber für mehr bitte nicht. Das fertige Satzprodukt kann wieder per Switch und lässigen POST-Request in das CMS gejagt, oder, wem’s Spass macht, auch per Hand eingepflegt werden.

Der gleiche Ansatz von automatischen und kuratierten Medien lässt sich auch auf das Web übertragen. Kann das ganze Frontend in Regelwerke gepackt werden, sind Statische-Seiten-Generatoren (gibt es wie Sand am Meer) oder JavaScript-Frame­works wie vue.js oder (fast schon wieder out) React angesagt. Diese Systeme holen sich natürlich die Inhalte aus der CMS-API, von Cloudinary oder von wo auch immer und lassen sie in Templates mit Ausgabelogik einfliessen. Klappt das nicht und muss die Website, ähnlich einer Drucksache, mit manuellen menschlichen Eingriffen verfeinert werden, setze ich gerne eine erst einmal seltsam anmutende Methode ein: Ich setze ein zweites CMS, eines für das Frontend, auf. Erstaunlich, dieses zweite CMS holt sich die API-Daten ab, setzt diese in den Seitenbaum und gibt dem «Kuratoren» bestimmte Gestaltungsmöglichkeiten und Erweiterungen frei. Ja, das funktioniert ziemlich gut! Es ist eigentlich das gleiche wie oben bei InDesign. Ein Fest für alle Theoretiker und Praktiker der Trennung von Medienneutralität und Medienspezifität – bei Fragen, fragen.

Nun wollen wir uns noch kurz ein paar Medien im Schnelldurchlauf anschauen. Einen Newsletter mit Mailchimp? Mailchimp hat eine API. Eine App kann APIs abfragen. Ein Chat-Bot spricht auch mit Ihrer API. Eine Suchengine wie Algolia? API … Ein Translation Management System? Rein und raus über die API. Eine Social-Media-Planung? Hootsuite-API to the Rescue. Einen Alexa-Skill? Ich denke, Sie haben die Idee verstanden …

Eine Kommandozeile für die Cloud

Alles klar, lieber Leser, liebe Leserin? Einen hab ich noch für Sie! Dieses ganze Hin und Her aus GET- und POST-Requests, aus Abfragen, Hooks und Produktionen ist ja schon recht fancy, aber es läuft irgendwie doch etwas unkontrolliert ab. Gut, irgendjemand hat sich das Ganze ausgedacht und es umgesetzt. Aber mal ehrlich: Ein Klick in einem System hat tausend Folgen in unterschiedlichsten anderen Systemen – und niemand bekommt was davon mit? Das geht ja mal gar nicht. Zum Glück gibt es Slack, oder Stackfield, oder Microsoft Teams oder eines der anderen WhatsApp-für-Unternehmen-Chat-Tools. Diese Programme ersetzen nicht nur E-Mails, sie haben auch APIs. Und damit sind wir wieder mittendrin im Spass:

Ein neues Bild, das etwa via Switch bei Cloudinary aufschlägt, löst dort einen «Neues Bild»-Event aus. Auf diesen Event schalten wir uns jetzt wieder auf und senden einen Request an Slack: «Schau mal hier, ein neues Bild.» Slack nimmt das Signal auf und sendet allen, die es interessiert (und gerne noch ein paar Leuten mehr) eine Info über das neue Bild in den Chatkanal. Oder: In Kirby wird ein neuer Inhalt freigegeben – Hook, POST-Request, bämm, über Slack wissen alle Bescheid. Gleiches Spiel, wenn ein Inhalt abläuft. Wann immer etwas passiert, wir sehen es im Chatfenster. Das ist so erschreckend einfach, dass es schon fast wehtut. Ohne grosse Verrenkungen und ohne neue technische Mittel haben wir zu unseren eh schon tollen Cloud-Workflows eine veritable Benachrichtigungsschicht (Notification Layer) hinzugefügt. Ich bin immer wieder erstaunt, wie sehr nach «Software» ein Prozess aussieht, wenn er plötzlich in Slack seinen Status mitteilt.

Zeit für die letzte Eskalationsstufe. Jetzt wird es richtig extrem. Wie wäre es, wenn Slack in seiner Chatzeile nicht nur etwas «reporten» könnte, sondern wenn wir über den Chat auch Befehle in die Cloud schicken könnten? Ja, das wäre wohl cool. Und natürlich geht auch das. Die «New York Times» hat es vorgemacht und seinerzeit für die Präsidentschaftsdebatte der Republikaner (!) ein Redaktionssystem in Slack gebaut. Für den Live-Blog «slacken» die Reporter munter vor sich hin. Ein Redaktor liest die Nachrichten in Slack, redigiert sie eventuell etwas und drückt final auf den (hinzugebauten) Publizieren-Knopf. Zack! Slack sendet einen Request an das Publishing-System: «Hier, ein neuer Inhalt.» Und schon nimmt das Publishing seinen Lauf. Welche Möglichkeiten das eröffnet! Das neue Bild, über das wir informiert werden, können wir direkt aus Slack in verschiedenen Varianten von Cloudinary anfordern. Der Beitrag, der morgen läuft, lässt sich über ein neues Datum in der Chatzeile verändern …

Oder, wo ich so darüber nachdenke, wie wäre dieser Workflow: Der Chat fragt uns Schritt für Schritt die Felder unserer Inhalt-Chunks ab, wir schreiben die Antworten in den Eingabeschlitz, ist alles fertig, erteilen wir aus dem Chat heraus die Freigabe an das CMS und flugs bekommen wir fertige Datenblätter, Social-Media-Posts oder was auch immer in den Chat zurückgeliefert. OMG.

Gibt es vielleicht doch ein Betriebssystem des Cloud-Publishings? Ist es der Chat? Oder ist er wie die klassische Kommandozeile eher ein Anachronismus, den man bald nicht mehr missen möchte? Oder ist der Chat am Schluss doch nur eine Komponente in unserem Konzert aus APIs, URLs, Hooks, Requests und Templates, den wir Best-of-Breed-mässig einfach austauschen können? Mir ist das eigentlich egal, das ist mir zu philosophisch. Mir würde es schon reichen, wenn Ihr Gehirn jetzt richtig raucht und die ersten GET- und POST-Requests zwischen den Synapsen hin- und herjagen.