Das Arbeiten mit den Facebook Instant Articles ist in vielen Fällen schwierig.
- Man konfiguriert die im eigenen CMS,
- die werden dann per RSS oder API an Facebook übermittelt.
- Das Debugging des Feeds macht man im Business Manager, einer Anwendung für Fanpage-Besitzer und -Admins.
- Die visuelle Kontrolle kann man aber nur in der mobilen App Seitenmanager machen (für Android und iOS).
Das ist ein sehr vielschrittiges Vorgehen, und an jedem Schritt kann man Fehler machen. (Wir haben da noch Probleme, dazu gleich mehr.) Für mich ist das ein Beispiel, dass diesen umfangreichen Bericht beim Nieman Institut bestätigt:
Access, Accountability Reporting and Silicon Valley – Nieman Reports: „Companies like Facebook and Google have the power to make or break a newsroom. That’s what makes Facebook, in particular, a daunting ‘partner-competitor-savior-killer,’ as the writer John Herrman put it.“
(Via.)
Weiter zu meinem Beispiel: Wir haben bei TargetVideo den Visual Composer im Einsatz, ein beliebtes Plugin für WordPress, mit dem Seiten grafisch gestalten kann – letztlich ist das eine Funktion, mit der WordPress erst Parität mit anderen Content Management Systemen erhält. Plugins sind der Segen und der Fluch der WordPress-Plattform. Es gibt schon alle Funktionen, die man sich nur wünschen kann, aber erst, wenn man ein Plugin probiert hat, weiß man, ob es etwas taugt. Und leider haben wir feststellen müssen, dass Visual Composer und Facebook Instant Articles nicht zusammenspielen.
This kind of plugin (Visual Composer) isn’t supported by our Instant Articles plugin out of the box.
But you can change the hook, to transform the content after „visual composer“ translates its short-code into HTML code, then you can hook the Transformer (from our PHP-SDK).
Also muss man das Plugin hacken. Automattic hat das Plugin selbst geschrieben und kennt selbst die Installationszahlen des Visual Composers, eines beliebten Seitenbuilders, am besten. Und der Support von VC – naja, reden wir auch hier von etwas Anderem. Ich dachte, niemand hätte das kritisiert bisher, und daher zögerte ich, diesen Post zu schreiben. Aber das stimmt nicht. T3N war schon da.
Ständig gab es technische Veränderungen und viele Prozesse mussten bereits in der Etablierungsphase wieder verworfen werden. Es brauchte einige Versionen, bis der Export der Artikel stabil verlief. Zudem dauerte der Review-Prozess bei Facebook oft sehr lange. Wir mussten jedes Mal zehn Instant Articles einreichen, die schlussendlich erst nach einer Woche abgelehnt wurden. Die Fehlermeldungen waren nicht immer einleuchtend.
Was haben wir also gelernt? Bevor wir ein Plugin jetzt hernehmen, schauen wir uns an, was es tut und wie man die Funktion durch eigenen Code selbst schreiben kann – das ist für die Performance nämlich im Zweifelsfall besser. Und wir setzen unser eigenes Templating für solche Anforderung in der Content-Distribution auf. AMP ist sicher nicht der letzte Kandidat in dieser Richtung.