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.

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.

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.