Obsahový model a redakční procesy

Editor otevře v CMS typ „Stránka O nás". Vyplní hero-nadpis, nahraje hero-foto, napíše blok 1, blok 2, přidá CTA. Hotovo.

Za týden píše článek a chce u něj fotku autora, kterou už minulý měsíc nahrával do jiné stránky. Nahraje ji znovu. Pak se autor přejmenuje a editor proklikává osm míst, aby všude opravil stejné jméno. To je signál, že web nemá obsahový model, ale jen sadu stránek, které lze editovat.

Obsah se dá stavět dvěma způsoby. Buď jako stránky, které v CMS kopírují budoucí layout, takže se informace rychle začnou opakovat. Nebo jako entity s poli a vztahy: autor je autor, článek je článek, stránka je jen jeden způsob, jak tyto entity ukázat.

To platí u složitých webů na Contemberu i u jednoduchých statických webů, kde podobnou práci dělají kolekce v Markdownu. Správná otázka proto nezní „jak bude stránka vypadat", ale „jaké typy obsahu máme a jaké jsou mezi nimi vztahy".

Entita má pole, stránka má layout

Typ obsahu je kontejner složený z polí. Každé pole má datový typ: text, formátovaný text, číslo, datum, pravda/nepravda, mediální podklad, JSON nebo referenci, která propojí dva typy obsahu.

Když modelujete blog, nemodelujete „stránku článku". Modelujete entitu článek s poli titulek, perex, tělo, datum a autor. Vedle ní modelujete entitu autor s poli jméno, bio a foto. Stránka článku je až vykreslení těchto dat v konkrétním vizuálu. V Contemberu se na stejnou entitu můžeme dívat i přes API.

Dobrá praxe je mít malé znovupoužitelné typy, které se do stránek skládají. Cíl je obsah nezávislý na místě zobrazení. Ten samý autor se může objevit v článku, na detailu školení i v interním seznamu lidí.

Neznamená to, že prezentace je nedůležitá. Jen nesmí být jediným místem, kde obsah existuje. Text naformátovaný v obyčejném WYSIWYG editoru často funguje jen v jednom kontextu. Vezměte mu vzhled a zůstanou části obsahu, u kterých není jasné, co znamenají. Proto se strukturovaný obsah ukládá tak, aby z něj byl poznat význam, ne jen formát.

Reference, nebo komponenta

Jakmile modelujete entitami, pořád se vrací jedna otázka: má to být reference, nebo komponenta?

Reference je vztah na sdílenou entitu. Je to jeden zdroj pravdy. Typ post má titulek, tělo a metadata. Typ author má jméno, bio a foto. Do post přidáte referenční pole na autora a každý článek odkazuje na stejný záznam místo toho, aby si jméno a bio kopíroval k sobě. Když se autor přejmenuje, opravíte ho jednou a změna se propíše všude.

Komponenta je znovupoužitelný blok uvnitř stránky: CTA, carousel, citace, sada log partnerů. Nemá vlastní život mimo konkrétní stránku a nikdo na ni neodkazuje jako na samostatnou entitu. Je to stavební kámen layoutu.

Pracovní pravidlo je jednoduché. Co má existovat samostatně a sdílet se napříč obsahem, patří do reference: autor, produkt, lokalita, událost. Co je kus skládačky jedné stránky, patří do komponenty.

V Contemberu se s tímto rozlišením pracuje přímo. U statických webů děláte referenci na jinou kolekci a komponenty bývají označené části Markdownu konkrétní stránky nebo článku.

Obsah jako data

Celý princip se dá shrnout do hesla „treat content like data". Když zachytíte obsah nezávisle na prezentaci, přestane být majetkem jedné stránky. Dá se použít znovu, poslat přes API, vypsat v seznamu, lokalizovat nebo později zobrazit v jiném designu. Tomu se říká COPE: „Create Once, Publish Everywhere."

Často se u toho pletbou dva pojmy. Headless CMS je technické řešení, které odděluje správu obsahu od jeho prezentace. Obsah spravujete v administraci a do webu (nebo jiného kanálu) ho dodáváte přes API. Takhle funguje Contember.

Tradiční CMS, typicky WordPress, je navržené tak, že obsah a prezentace jsou uložené dohromady. To samo není nutně špatně, jen třeba u redesignu to znamená, že musíte sahat do jednotlivých článků.

Redakční proces

Modelováním typů to nekončí. Obsah žije v čase a prochází různými stavy: draft → review → publish → archive.

Draft je rozepsaný. Review čeká na schválení. Publish je živý obsah. Archive je obsah stažený z webu, ale nesmazaný. Typicky pokud něco z toho nemáme, dříve či později to někomu chybí. Často právě archiv. Obsah se pak buď maže, takže mizí historie i URL, nebo zůstává donekonečna živý, protože ho tým nemá jak bezpečně stáhnout.

A k tomu patří i role a oprávnění: kdo smí editovat, kdo schvaluje a kdo publikuje. Pro nás je to i technické rozhodnutí - pokud zákazník potřebuje role, budeme projekt stavět na Contemberu. Statický web na Nua site role zatím neumí a nepočítá s nimi.

Proč headless není svatý grál

Strukturovaný obsah je víc práce. Editor v headless modelu vyplňuje pole ve formuláři a často nevidí stránku přesně tak, jak bude vypadat venku. Ztrácí vizuální kontext, který v tradičním CMS s WYSIWYG měl. Musíme mu tvořit speciálně preview atd.

Headless přístup se vyplatí u složitějších webů, kde tým ocení role, schvalování a publikování do více kanálů. U jednoduchých webů může být lepší editovat přímo web a strukturou se netrápit víc, než je nutné. To je cílem Nua site.

Praktický checklist

• Existuje minimální obsahový model: typy obsahu jsou pojmenované jazykem týmu.
• Je jasné, kde se používá reference (sdílená entita) a kde komponenta (blok stránky).
• Opakované informace mají jeden zdroj pravdy, ne kopii v každé stránce.
• Redakční stavy zahrnují i archiv, ne jen publikováno/nepublikováno.
• Role a schvalování jsou rozhodnuté dřív, než se vybere CMS nebo statika.
• Lokalizace je vyřešená na úrovni pole nebo entity, ne slepou kopií celé stránky na jazyk.

Tři typické záměny

• Headless ≠ strukturovaný obsah. Headless je architektura dodání přes API. Strukturovaný obsah je modelovací princip. Jde mít blob v headless i strukturu v tradičním CMS.
• Strukturovaný obsah ≠ bez CMS. Strukturovaný obsah CMS nevylučuje, naopak ho předpokládá. Bez nástroje, který spravuje typy a stavy, je strukturování ruční práce.
• Reference ≠ komponenta. Sdílená entita s jedním zdrojem pravdy versus znovupoužitelný blok uvnitř stránky. Záměna vrací duplikaci, kvůli které se to celé dělalo.