Tech 15. Apr. 2014 No-CMS

Cloud basiertes Markdown Blog

Warum, wieso und wozu?

Die eigene Website ist ja immer auch Ziel von wirren Ideen und Inkubator Projeken. So auch mein Blog. Neben den Spieltrieb haben die bisherigen Lösungen aber auch immer Nachteile gehabt. Das massivste Manko der Web CMS Lösungen (Wordpress, Drupal, TYPO3 und Co.) ist, dass sie eigentlich nur online funktionieren. Und auch mit Blogging-Apps muss man i.d.R. vor dem Publishen mal im Web CMS mal nachsehen was aus dem Beitrag geworden ist. Da meine Zeitfenster zum Bloggen sich aber auf Lazenzzeiten unterwegs und viel ohne Internet (Zug, Flugzeug) beschränken, ist das ein Problem. Hinzu kommt die Datenhaltung. Meine Blogbeittäge möchte ich nicht in einer MySQL Datenbank, sondern in einem einfacheren, besser greifbarem und beständigerem Format aufbewahren. Mehrere Migrationen von CMS zu CMS mit zumeist dann veralteten Versionen haben hier einen bleibenden Eindruck hinterlassen. Außerdem möchte ich zur Bearbeitung von all meinen Geräten zugreifen können. Darauf aufsetzend möchte ich dann einen automatisierten Publishing Prozess inkl. Social Media Marketing usw. haben.

Die Vision ist also:

Schnell, einfach und überfall in einen einfachen und nachhaltigem Format Blog Posts erstellen und diese automatisch auf meine Website, Facebook, Twitter und Co. pushen
Und als Zuckerguss noch die
Rückintegration von Facebook Posts in diese Blog Datenquelle.

Recherchen und Ideen

Gefühlt habe ich Millionen Varianten recherchiert. Im engeren waren es für die Datenhalten

Google Drive (Cloud Speicher mit API und strukturiertem Dokumentenformat, aber schlechter Offline Verfügbarkeit),
Evernote (Cloud Speicher mit API, Multi Device Editor, Embedded Medien, aber leider gruseliger Firmatierung inkl. Unterschieden zwischen den Gerätevarianten),
Blog Lösungen wir Blogger.com (direkte Bloglösung mit Editor Apps, aber properotärer und damit wenig nachhaltiger Dazenhaltung) und schließlich
Markdown und Dropbox (nachhaltiges und einfaches Datenformat, Flexibilität bei der Wahl der Editoren und Editing Apps, Cloud Speicher inkl. einfachem lokalem Dateisystemzugriff, zwar mit der Hürde dass keine Medien im Text embedded sind, das Mediahosting aber direkt auch per Dropbox erfolgen kann.

Für die Webdarstellung ist das ähnlich. Viele Varianten habe ich angedacht und ausprobiert. Zum Teil auch aus Technologieinteresse. Zum Beispiel

wie oben schon erwähnt einfach ein Standard Blog,
eine PHP Lösung zur Anzeige von Evernote Artikeln als HTML Dokumente und
eine sexy Java Lösung per Tapestry und SolR mit Anbindung an Evernote, Facebook, Twitter, Xing und LinkedIn.

Die Java Lösung ist ziemlich Klasse und den Kern habe ich bereits fertig, aber sobald Projekte die Zeit binden wird klar, dass dieser Weg zu viel Entwicklungsarbeit kostet. Also nochmal auf Null.

Reduktion als Ziel - die einfachste Lösung ist oft die beste

Nach längeren Prozessen und Versuchen steht fest: Markdown (also Textdateien) werden der Kern der Datenhaltung sein. Und diesen Artikel schreibe ich im Zug auf den Handy per Byword und speichere ihn in meiner Dropbox. Das Format erscheint mit so neutral und nachhaltig, dass ich bereits ohne Festlegung auf den Editor, den Datenspeicher und die Anzeige bereits jetzt fertige Artikel so schreibe. Denn auf Basis von Markdown lassen sich viele Varianten denken - und damit auch immer wieder ändern ohne die Artikel selbst konvertieren oder migrieren zu müssen.

Das Medienproblem

Da Markdown - so toll das Format durch seine Simplizität auch ist - eben doch nur Text ist, stellt sich (leider) unweigerlich die Frage, wie man nun Medien - hauptsächlich Bilder - nutzt. Ja klar, per Link im Dokument. Aber wo werden die Dateien abgelegt, wie skaliert, wir kann man Dateiverknüpfungen einfach auch auf einem Smartphone einfügen, wie kommen die Bilder ins Web und bleibt die Datenhaltung gleichzeitig konsistent? Alles Fragen die Varianten wie Google Docs oder Evernote lösen, da hier ein Dokumentenformat mit eingebetteten Medien möglich ist. Die Lösung ist auch hier die Dropbox. In der Ablage können so die Bilder im Filesystem direkt bei den Artikeln gespeichert werden - also weiterhin eine komplett dateibasierte Ablage die entsprechend nachhaltig ist. Durch die Nutzung einer Dropbox ist es aber zusätzlich möglich direkt Webreferenzen zu verwenden. D.h. die Bilder liegen in einem Public Ordner (das Blog ist ja eh öffentlich) und die passenden Public Links nutze ich als Referenzen im Markdown. An die Public Links kommt man auf dem Desktop schnell per Rechtsklick und auf den Smartphone mit (leider) minimalen manuellem Eingriff auch. Damit sind die Bilder auch sofort online verfügbar und das Markdown kann unabhängig vom Mediadatenthemen über andere Kanäle veröffentlicht werden. Größter Nachteil: Die Links im Markdown sind Dropbox-spezifisch - d.h. hier gibt es einen Punkt der die Nachhaltigkeit der Datenhaltung einschränkt. Wer Ideen für eine bessere Lösung hat - her damit. Ein weiteres Thema ist die Skalierung. In der Datenhaltung sollten ggf. große Originale liegen - in Zeiten von großen Auflösungen und Retina Displays sollte man hier nicht zu klein denken. Für das Web im aktuellen Status braucht man aber schon nur wegen der Ladezeiten auch kleine Bilder mit mal nur 1024px. Das kann man natürlich ersteinmal manuell machen und das auch per Desktop (einfach per Preview), per App oder Automator. Denkbar ist aber auch ein Dropbox Automator, der das Thema übernimmt. Oder ein Resize Webservice der das Rendering erst für die Webansicht übernimmt.

Web Publishing - die eigentliche Blog Ansicht

Hier könnte man nun was eigenes bauen, ein Worpress befüllen, meine Java/SolR Lösung versorgen - oder was fertiges nehmen. Letzteres wird ab schnellsten zum Ziel führen und Folgethemen wie Serverkonfigurationen usw. reduzieren. Hier gibt es die o.g. Lösung von Scriptogr.am, aber euch ein oder zwei weitere. Diese nehme ich gerade unter die Lupe und bin bisher halb überzeugt. Die Alternative könnte noch ein Weg sein, per Editoren Publishing Funtionen eine Plattform wie Blogger.com oder TumlR zu nutzen. Eine weitere könne ebenfalls über Standard Blogs und Zapier, IFTT o.ä. sein. Hier bleibt es noch spannend.

Wenn die Beiträge dann im Netz sind ist viel geschafft. Aber sie müssen dann noch publiziert werden. Das Thema ist gar nicht so einfach, möchte man nicht viel selbst machen. Entweder man nutzt hier eine Standard Blog Lösung wir Wordpress, TumblR oder Blogger die so etwas z.T. können. Oder man nimmt eine Plattform die sich wiederum gut mit Zapier oder IFTT versteht - damit kann man dann gut das Verteilen der Artikel organisieren. Zu klären sind natürlich noch Details wie Kampagnentracking usw. Meine Tendenz geb dahin solche regelbasierten Dienste einzusetzen, da sie zum einen genau dafür gemacht sind und zum anderen ich damit bisher gute Erfahrungen im nicht-business-kritischen Bereich gemacht habe.

Ab und an passiert es, dass eine Art Microblogging Beitrag direkt auf Facebook oder Co. entsteht. Und das möchte ich auch nicht ändern. Wenn diese aber auch auf meinem Blog erscheinen sollen und zwar eingegliedert und die anderen Beiträge, dann braucht es einen Rückkanal zu meiner Markdown Datenquelle - oder wenn man auf die langfristige Persistierung verzichten kann, einer Plattform die die Integration kann. Hier wird es dann schon dünner als man denkt. Zapier oder IFTT könnten eine Rückintegration übernehmen, aber hierüber ein sauberes Markdown zu erzeugen ist nur umständlich mit Worarounds möglich. Meine Tests stehen noch aus. Zudem müssen die Posts dann beidseitig gefiltert werden - sonst kann schnell eine Publishing Rekursion entstehen. Wäre auch mal spannend. Plattformen mit einer guten Umterstützung inkl. der Anbindungsoptionen an meine Markdown/Dropbox Lösung sind aber auch nicht sooo üppig. Einem Worpress würde ich keine Prozesssteuerung anvertrauen. TumblR kann das vielleicht - zumindest sieht das ganz gut aus. Aber auch hier stehen noch Tests aus.

Schluss für heute

Es wird also noch genügend spannende Themen und diese werde ich gerne wieder publizieren. Und am Ende steht dann eine perfekte No-CMS Blogging-Lösung mit der ich meinen einen Artikel im Monat schreiben kann. Aber wie gesagt: Die eigene Website ist meist eine Spielwiese für wirre Ideen.

Tech-Blog