Sind klassische Content Management Systeme Vergangenheit? Meist schon einige Wochen nach Fertigstellung einer Homepage werden sie stiefmütterlich behandelt. Warum? Zu viel Aufwand. Aufwand, sich an das Passwort zu erinnern, Aufwand die Inhalte erst dafür aufzubereiten und zusammenzustellen.
Aber eigentlich braucht man sie ja auch gar nicht. Die Inhalte, die produziert werden, liegen doch ohnehin schon bei Facebook und Youtube. Soziale Medien, die im Alltag angekommen sind, die mit Spaß verwendet werden. Aber vor allem: Medien, die ständig aktualisiert werden, weil sie im Alltag der Benutzer sind.
Was liegt also näher als die Inhalte einfach dynamisch da raus zu ziehen, wo man sich ohnehin schon bewegt? Facebook-Fanpages sind vor allem dafür da, Fans und solche, die es werden wollen, mit Neuigkeiten zu versorgen. Warum also nicht einfach den größten Benefit einer eigenen Facebook Page auch für die eigene Homepage nutzen – Nutzer mit aktuellen Informationen versorgen, über eine Plattform, aber sichtbar auf zweien.
Die News sind dabei nur der Anfang. Fotoalben können ausgelesen und Events können sogar mit Anzahl der Teilnehmer direkt auf der Homepage in einem Kalender angezeigt werden. Die Website braucht dafür auch keine Installation. Daten von Fanpages sind ja ohnehin frei verfügbar.
Ein Optimaler Use-Case für ein solches CMS ist beispielsweise ein Sportverein. Um Zuständigkeiten für Homepage wird im klassischen vereinsinternen Kompetenzgerangel zwar gerne gestritten, sind sie aber einmal vergeben, rostet die Aktivität schnell ein. In Facebook allerdings ist jeder gerne. Ständig.
Neben der alltäglichen strategischen Arbeit für große Markenunternehmen hat sich ein so zu beschreibender Sportverein für das Experiment gefunden. Die Titans Berlin Cheerleader, unter anderem Motivatoren für die Handballmannschaft der Berliner Füchse, haben nun eine ständig aktuelle Homepage ohne dediziertes Content Management System.
Das einzige was statisch blieb, sind Inhalte die selten Änderung benötigen: Trainingszeiten, Anfahrtsweg und Impressum. An folgenden Stellen werden die Inhalte aus Facebook gezogen:
News: Die Facebook-Statusmeldungen der Fanpage.
About: Die Beschreibung der Facebook-Fanpage.
Bild der Woche: Neustes Bild aus einem vorher definierten Album.
Die Mannschaften: Jeweils ein Facebook-Album mit entsprechenden Bildern und Bild-Unterschriften für die Namen der Mitglieder.
Bildergalerie: Die besten und aussagekräftigsten Alben der Facebook-Page. Es werden prinzipiell alle Alben sowie neu hinzugefügte angezeigt. Mittels Blacklisting werden z.b. Fotoalben für Pinnwandfotos und Profilfotos nicht angezeigt.
Videos: In diesem Fall direkt aus Youtube gezogen, da der Content dort vorhanden ist. Könnte natürlich auch Facebook sein. Oder Vimeo.
Technisch gesehen ergeben sich große Vorteile und ein richtig großer Nachteil.
Wenn alle Inhalte asynchron per Javascript ausgelesen werden, dann ist die Seite ohne großen Aufwand skalierbar.
Durch Javascript lädt die Seite zusätzlich super schnell, vor allem subjektiv. Die Seite ist für den Nutzer bereits fertig geladen, während erst die eigentlichen Inhalte von Facebook angefragt werden. Vor allem werden, da Javascript sich “nonblocking” verhält, auch die Inhalte aller Fotoalben parallel verarbeitet, was so in den meisten Backend-Programmiersprachen von Natur aus nicht implementierbar ist. Eine Backend-Lösung dafür könnten Batch-Requests an die Facebook-API sein. Allerdings muss das HTML dann iterativ erstellt werden. Zusätzlich gibt es noch Ladezeiten von mehreren Sekunden, bis die Seite ausgeliefert werden kann. Eigentlich nicht akzeptabel.
Der Nachteil dabei: Da alle Inhalte erst zum ausgelieferten Zeitpunkt erzeugt werden, ist eine Indizierung von Suchmaschinen schwierig. Optimalerweise müsste man eine gespiegelte Version anbieten, welche alle Inhalte nochmals in HTML anbietet. Eine Automatisierung könnte Abhilfe schaffen, so dass der durch Javascript erzeugte DOM leichter abzuspeichern und zu exportieren wäre. Vielleicht schickt man ihn einfach per Ajax regelmäßig wieder zurück. Vielleicht ergeben sich ja Vorschläge oder eine Diskussion, wie das angegangen werden kann.
Fazit:
Einen Luxus ist man allerdings von serverseitigen Sprachen gewohnt, der Javascript von Haus aus fehlt: Wiederverwendbare Code-Schnipsel, die als Templates dienen. Aber auch in Javascript gibt es seit geraumer Zeit Template-Engines. Hier wurde Handlebars verwendet.
Javascript war tot, lang lebe Javascript. Zumindest bis Dart angreift. Prinzipiell geht der Trend schon seit einigen Jahren verstärkt zu Javascript. In diesem Fall nicht für fancy Animationen, sondern für die komplette Datenhaltung. Mit JavaScriptMVC gibt es gar schon ein komplettes MVC-Framework für Javascript. In diesem Fall wurde das allerdings nicht verwendet. Als Model dient hier ganz klar die Facebook-API und als View dienen die Handlebars-Templates.
Als nächster Schritt nach dem Proof of Concept steht die Vereinheitlichung an. Wiederverwendbares bietet sich hier ja eine Menge. Im besten Falle bietet ein fertiges Tool dem Nutzer am Ende an, die Fanpage anzugeben und die Templates anzupassen. Alles andere läuft automatisch.
