Obsahový model a redakční postup

Editor otevře v CMS typ „Stránka O nás". Vyplní pole hero-nadpis, nahraje hero-foto, napíše blok-1, blok-2, přidá CTA. Hotovo. Za týden píše článek na blog a chce u něj fotku autora, kterou nahrával minulý měsíc do jiné stránky. Nahraje ji znovu. Pak se autor přejmenuje, a editor obíhá osm stránek a opravuje jméno na každé zvlášť.

Tahle scénka je celý problém v malém. Web je modelovaný jako sada stránek, kde každá stránka vlastní svůj obsah. Foto, jméno, bio nejsou samostatné věci, jsou to políčka uvnitř jedné konkrétní stránky. A protože tam bydlí, musí se duplikovat všude, kde jsou potřeba znovu. Obsahový model je rozhodnutí to obrátit. Obsah není stránka, je to entita s poli a vztahy, a stránka je jen jeden způsob, jak ji zobrazit.

Tahle kapitola je technický protějšek teze, že web je produkt, ne sada stránek. O úroveň níž to platí dál: produkt ≠ stránky, takže obsah ≠ stránky. Pojmy jako headless nebo typ obsahu tu znovu nevysvětlujeme, jednovětou definici má společný slovník. Tady jde o to, jak obsah modelovat.

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, a hlavně reference, která vytváří vztah mezi dvěma typy. Když modelujete blog, nemodelujete „stránku článku". Modelujete entitu článek s poli titulek, perex, tělo, datum, autor, a entitu autor s poli jméno, bio, foto. Stránka je až vykreslení té entity.

Model podle stránky dělá pravý opak. Typ „homepage" má pole pro hero, sekci s benefity a CTA blok, všechno svázané dohromady, protože model zrcadlí layout. Layout vlastní obsah. To je důvod té duplikace ze scénky výš: foto autora není entita, je to políčko uvnitř stránky, takže žije tolikrát, na kolika stránkách se objeví.

Modulární model to obrací. Místo typů, které reprezentují stránky, máte malé znovupoužitelné typy, které se do stránek skládají. Obsah je nezávislý na tom, kde se zobrazí. Sara Wachter-Boettcher tomu v Content Everywhere dala jméno. Obsah naformátovaný ve WYSIWYG editoru je navržený k zobrazení jediným způsobem, na desktopu. Vezměte mu formát a rozpadne se na nesouvislé bloky textu. Foto a popisek, které spolu na desktopu vyprávěly příběh, se na mobilu rozpadnou na nesouvisející obrázek a kus textu. Strukturovaný obsah má naopak zřetelné části, konzistentní kus od kusu. Ta samá vlastnost je předpokladem přístupnosti: alt text jako pole, semantické části místo jednoho blobu.

Reference, nebo komponenta

Jakmile modelujete entitami, narazíte na rozhodnutí, které se v každém schématu opakuje: tohle má být reference, nebo komponenta?

Reference je vztah na sdílenou entitu, jeden zdroj pravdy. Contentful to ukazuje na učebnicovém příkladu: typ post s poli titulek, tělo, metadata, a typ author se jménem, biem a fotem. Do post přidáte referenční pole „Author info", a každý článek napořád odkazuje na téhož autora místo aby si jeho jméno a bio kopíroval. Přejmenuje se autor? Opravíte ho na jednom místě a propíše se do všech článků. To je přesně to, co scénka na začátku neměla.

Komponenta je naopak znovupoužitelný blok, který se skládá do stránky a žije uvnitř ní. CTA blok, carousel, citace. Nemá vlastní život mimo stránku, nikdo na něj neodkazuje jako na entitu, je to stavební kámen layoutu. Pravidlo zhruba zní: co má existovat samostatně a sdílet se napříč obsahem, je reference (autor, produkt, lokalita). Co je kus skládačky konkrétní stránky, je komponenta. Splést si to bolí oběma směry. Z autora komponenta nadělá zase tu duplikaci. Z CTA bloku reference nadělá zbytečnou entitu, kterou nikdo nespravuje.

Sem patří i pole pro SEO: titulek, meta description, canonical jsou pole typu obsahu, ne dodatečně nalepená vrstva. A média jsou současně typ pole (mediální podklad) i vlastní typ obsahu s referencí do knihovny podkladů, což rozvádí média a podklady.

Obsah jako data, ne jako layout

Všechno tohle se dá shrnout do jednoho hesla: „treat content like data". Když zachytíte obsah nezávisle na prezentaci, přestane být majetkem jedné stránky a dá se použít kdekoli. NPR z toho udělalo princip jménem COPE, Create Once, Publish Everywhere. Vytvoříte a spravujete obsah na jednom místě a distribuujete ho všude přes API.

Není to teorie. COPE postavil Daniel Jacobson, tehdy Director of Application Development v NPR. NPR API šlo živě v roce 2008, princip COPE publikovali 2009. Připisuje se mu 100% růst zobrazení stránek během jednoho roku a zrychlení vstupu NPR do mobilu, jeden strukturovaný obsah dodávaný na web, mobil, sociální sítě i partnerské vydavatele bez duplikace. Jacobson pak odešel budovat Netflix API.

Tady stojí za to oddělit dva pojmy, které se pletou. Headless CMS je architektura dodání. Oddělí prezentační „hlavu" od „těla" obsahu a strukturovaný obsah poskytuje přes API do libovolného kanálu. Tradiční provázané CMS je naproti tomu navržené primárně pro web, jeden kanál. Ale headless a strukturovaný obsah nejsou totéž. Headless je o tom, jak se obsah dodá. Obsahový model je o tom, jak je obsah uvnitř postavený. Jde mít strukturovaný obsah v tradičním CMS, Drupal s COPE je důkaz, i nestrukturovaný blob v headless CMS. Tahle entita je vstupem do renderování, ať je statické, dynamické, nebo hybridní.

Redakční postup má stavy, ne jen tlačítko publikovat

Modelováním typů to nekončí. Obsah žije v čase a prochází fázemi: draft → review → publish → archive. Draft je rozepsaný, review čeká na schválení, publish je živý, archive je stažený z webu, ale nesmazaný. Nejčastěji chybí ten poslední stav. Obsah se buď maže (a mizí historie i URL), nebo zůstává donekonečna živý, protože ho nemá kdo stáhnout. Kdo a kdy stav archive reálně použije, řeší správa a údržba přes politiku vyřazování a datum revize.

Ke stavům patří role a oprávnění: kdo smí editovat, kdo schvaluje, kdo publikuje. A patří sem preview, náhled obsahu před zveřejněním. To je u headless modelu reálná bolest, ke které se hned dostaneme. Strukturovaný obsah s redakčním postupem je taky to, co dělá redesign snesitelným: rozhodnutí, co sloučit, co přesměrovat a co zahodit, je snazší, když je obsah entita se stavem, ne stránka, kterou buď máte, nebo nemáte.

Co se na headless rozbíjí

Strukturovaný obsah má cenu, kterou nesmíme zamlčet. Editor v headless modelu vyplňuje pole ve formuláři a nevidí, jak výsledek vypadá. Ztrácí vizuální kontext, který v tradičním CMS s WYSIWYG měl. A to není estetický nářek. Je to ztráta produktivity: pomalejší tvorba a víc nekonzistencí, protože člověk píše naslepo. Builder.io to pojmenoval bez obalu, „the problem with a headless CMS".

A druhá past hned vedle. Schéma nikdy nepředvídá všechny budoucí potřeby. Buď nadefinujete polí málo, a pak chodí nekonečné žádosti „přidejte pole na nový CTA, na carousel, na jiný layout", a každá je požadavek na vývojáře. Nebo polí moc, a každé je víc kódu, dokumentace, školení a vnořených formulářů. Vývojář se stává úzkým hrdlem, zásobník práce přetéká požadavky na obsah. Není náhoda, že 52 % týmů potřebuje rozsáhlé školení, aby headless CMS zvládlo. Myšlení ve strukturách lidem mimo vývoj nejde přirozeně. Vizuální editace nad strukturovaným modelem je rozvíjející se kompromis, ne hotová odpověď.

Není to zbytečné pro malý web?

„Entity, reference, schémata, to je aparát pro NPR, my máme pětistránkovou vizitku." A je to pravda. Pro pět stránek se stejným vzhledem je tradiční CMS s WYSIWYG efektivnější. Modelovat entity je tam zbytečně těžký aparát, a chybějící preview vás bude jen zdržovat.

Co se neškáluje, je otázka. „Jaké typy obsahu na webu reálně existují a co se opakuje?" platí pro vizitku stejně jako pro NPR. Když máte na webu tři autory a každý píše, jste přesně na hranici, kde se reference vyplatí, i kdyby zbytek modelu zůstal jednoduchý. Stejně jako u informační architektury a webu jako produktu: škáluje se aparát, ne otázka. Které typy obsahu reálně existují, odhalí už inventura v discovery.

Praktický checklist

• Je definovaný minimální obsahový model: typy obsahu pojmenované jazykem týmu.
• Je rozhodnuto, kde se používá reference (sdílená entita) a kde komponenta (blok stránky).
• Pole pro SEO (titulek, meta description, canonical) jsou součástí typu, ne nalepená vrstva.
• Lokalizace je vyřešená na úrovni pole, ne kopií celé stránky na jazyk.
• Redakční postup má stavy (draft, review, publish, archive), role a odpovědnosti.
• Existuje stav archivace, ne jen mazání.
• Preview má odpovědné schvalování, ne publikování naslepo.

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.

Zdroje

• Sara Wachter-Boettcher, Content Everywhere (2012) — „blob" problém, obsah bez formátu, zřetelné chunky.
• Daniel Jacobson / NPR — COPE, Create Once Publish Everywhere; API spuštěné 2008, princip 2009, 100% růst zobrazení stránek.
• Lullabot — výklad COPE, CMS vs. web publishing tool (Jacobsonovo rozlišení).
• Contentful — content modeling basics, reference field na příkladu post/author.
• dotCMS — content type jako kontejner polí, reference jako vztah.
• eight25media — modulární vs. page-shaped content modeling.
• Builder.io — „the problem with a headless CMS", ztráta preview, developer jako úzké hrdlo.
• Kentico — 52 % týmů potřebuje rozsáhlé školení; zbytečná složitost pro malý web.

Obsahový model je technický protějšek webu jako produktu a staví na informační architektuře, která je páteří, na níž typy obsahu visí. Vstup do něj dodává inventura v discovery, pojmy sjednocuje slovník. Média jsou jeden z typů obsahu, viz média a podklady, SEO pole jsou jeho součástí, viz SEO, a hotová entita je vstupem do statického, dynamického nebo hybridního renderování. Redakční postup draft → review → publish má technický protějšek v Gitu a CI/CD: Git-based CMS ukládá nepublikovanou změnu jako commit a PR a vede ji přes preview a review, ne přímo do produkce. A protože jen strukturovaný, na layoutu nezávislý obsah umožní COPE (jeden obsah na web, e-mail, RSS i sociální sítě), začíná marketingová distribuce právě v obsahovém modelu, ne až u tlačítka „sdílet". Stejné rozlišení typů obsahu je předpoklad segmentace reportingu podle typu stránky v analytice: bez rozlišení podle typu stránky v obsahovém modelu ukazuje dashboard jen průměr, který neplatí nikde.