Bei “Print first” ist eine Ausgabe auch gleich die “Publikationseinheit“: Mehrere Beiträge, Kapitel (oder was auch immer) werden in einer Ausgabe zusammengeführt. Warum eigentlich? Weil es Verschwendung wäre, jeden Beitrag separat zu drucken und per Post zu versenden. Digital ist das anders. Beiträge in Portalen, Blogs oder auf Social-Plattformen erscheinen einzeln und nicht gesammelt (siehe dazu auch Continuous Publishing). Somit stellt sich die Frage, was bei “Content First” die optimale “Publikationseinheit” ist. Ich glaube, es sind “Beiträge” (oder Neudeutsch “Posts”) in unterschiedlichen Varianten.
Minimal Information Unit (MIU)
Wenn wir uns auf den “Beitrag” als “Publikationseinheit” einigen, ist die Frage, welche Varianten eines “Beitrages” es gibt. Es geht darum herauszufinden, was die kleinste Einheit ist, welche sinnvoll publiziert werden kann, die Suche nach der sogenannten Minimal Information Unit. Hier gibt es kein Patentrezept. In einem News-Portal der Massenmedien ist das komplett anders als in einem Lehrmittel, wo “Beiträge” in einem didaktischen Zusammenhang stehen.
Das Geschäfts- und Datenmodell
Die eigenen Geschäftsmodelle geben vor, welche “Varianten” der “Beiträge” sinnvoll sind
- Was wollen wir heute verkaufen? (Ausgaben, einzelne Beiträge, Newsletter, Zusammenfassungen, Checklisten…)
- Was wollen wir heute auf Social-Plattformen ausspielen?
- Was wollen wir in fünf Jahren verkaufen?
- Welche Ausgabekanäle wollen wir heute bedienen?
- Welche Ausgabekanäle wollen wir morgen bedienen?
Die Beantwortung dieser Fragen zeigt die notwendigen “Varianten” auf. Erst jetzt wird es technisch: Die benötigten Varianten bilden das Datenmodell, auf welchem ein Content-First-System basiert – und das ist von Projekt zu Projekt stark unterschiedlich, je nach Geschäftsmodell.
Varianten verwalten
Typische “Varianten” eines Beitrags bei Content First
- Web
- App
- Social Channel 1, Social Channel 2, Social Channel 3…
- Sprache
- Region
Und gell: “Varianten” nicht mit “Versionen” verwechseln. Versionen entstehen, wenn Varianten im Laufe ihrer Entstehung mehrfach gespeichert werden.
Varianten in WordPress
WordPress ist von der Herkunft her ein Web CMS. Also ein System für den Ausgabekanal “Web”. Somit ist WordPress nicht vorbereitet für “Varianten” in der “Content-First-Denke”. Doch WordPress ist ein Baukasten, Varianten können gebildet werden über
- Custom Fields: Eigene Felder pro “Minimal Information Unit” im Beitrag
- Custom Post Types: Eigene Inhaltstypen pro Kanal
- Verwandte Posts: Wenn sich Varianten inhaltlich sehr stark unterscheiden – etwa bei Mehrsprachigkeit oder starker Unterscheidung des Inhalts zwischen Print und Web – lassen sich Varianten über “verwandte” Posts managen. Plugins, welche die Mehrsprachigkeit in WordPress regeln, arbeiten damit. Wir haben selber ein Plugin entwickeln lassen, für den Fall von Einsprachigkeit bei gleichzeitiger Notwendigkeit von “verwandten Posts”.
Fazit
Wie immer: Strategie vor Technologie. Zuerst muss klar sein, in welchen “Varianten” publiziert werden soll. Die Varianten und damit die “Minimal Information Units” leiten sich aus der Unternehmensstrategie und den daraus resultierenden Geschäftsmodellen ab.
Ist ein sauberes Datenmodell definiert, ist es wie beim Spielen mit Legos: Mit immer den gleichen Bausteinen können unterschiedlichste Konstrukte für unterschiedlichste Bedürfnisse zusammengestellt werden.
Über mich
2 Antworten
Bin immer wieder erfreut und dankbar über diese guten und fachlich sehr fundierten Publishing-Blog-Beiträge!
Danke Matthias, das freut mich sehr!