Počet kanálů, přes které konzumujeme digitální obsah, neustále roste. Nejsou to už zdaleka jen smartphony a tablety, ale také chytré hodinky, virtuální a smíšená realita, chatboti nebo Internet věcí. Mít jen responzivní web tak firmám už zdaleka nestačí. Potřebují nástroj, který jim pomůže obsah pro velké množství zařízení tvořit a distribuovat ho do nich. Tradičnímu CMS zde ale dochází dech. Bude řešením tzv. headless CMS?
Tradiční CMS je navržený tak, aby obsah zobrazoval primárně jako webovou stránku. Jeho součástí je tedy template engine, který vzhled webové stránky řídí. Právě ten bychom mohli označit za „hlavu“ CMS, která určuje, jakým způsobem se obsah uživatelům zobrazí.
Pokud chcete se zákazníky komunikovat na různých zařízeních, máte v podstatě tři varianty řešení:
1) Pro každé zařízení využijete samostatné CMS.
2) Vytvoříte několikahlavou saň, tedy software s několika různými enginy, každý pro jednotlivé zařízení.
3) Nebo hlavu prostě useknete a využijete CMS bez enginu.
První i druhý způsob není zrovna ekonomický, navíc tvořit obsah na několika různých CMS je pracné i časově náročné. Oproti tomu headless CMS je k tvorbě obsahu pro více kanálů doslova stvořené. Umožňuje obsah připravovat a spravovat z jednoho místa. Samo ho pak nerenderuje, ale nechává to na aplikacích pro konkrétní zařízení. Do nich obsah distribuuje prostřednictvím API. Jasně tedy odděluje část přípravy obsahu od vývoje aplikací pro jednotlivá zařízení.
Jak už jsme zmínili v úvodu, svět se mění a kanálů přibývá. Nechme ale mluvit čísla.
Víc jak polovina lidí brouzdá na internetu častěji na svém chytrém telefonu, než na počítači.
Zdroj: StatCounter (2016)
V USA používá každý člověk v průměru 3,5 zařízení, na kterých konzumuje obsah.
Zdroj: Consumer Barometer (2016)
Zatímco v roce 2016 se trh virtuální a smíšené reality pohyboval okolo 5,2 miliardy dolarů, do roku 2020 se očekává jeho růst na 162 miliard.
Zdroj: IDC (2016)
Poznámka autora: Na základě komentářů pod blog postem jsem doplnil tento odstavec pro lepší vysvětlení.
Samotné headless CMS pouze spravuje obsah, takže aplikace („hlavy“) za vás nenaprogramuje. Ušetří vám ale spoustu peněz, práce a starostí s tvorbou a údržbou obsahu. Místo toho, abyste ho vytvářeli znovu a znovu v různých systémech pro různá zařízení, můžete obsah vytvořit jednou a použít ho opakovaně. Vyhnete se tak situaci, kdy například změnu adresy pobočky musíte provést na webu, v mobilní aplikaci, v chatbotu a v další kanálech samostatně.
Pokud vám stačí web a nepotřebujete využívat další komunikační kanály, nejspíše si vystačíte s tradičním CMS a nemusíte nic měnit. Jestli ale chcete tvořit obsah pro více různých zařízení, může pro vás být headless CMS ideálním nástrojem.
Jojo, kde jsou ty časy, kdy na Rootu vycházely zajímavé články o IT a o linuxu. Teď to tu zachraňují jen bezpečnostní novinky, občas zajímavé fotky a archiv...
To jsou zase píčoviny. To že musíte vytvořit pro každé zařízení novou hlavu (aplikaci) to je jistě ekonomicky míň náročné než mít třeba responsivní CMS. To je zas tahák (buzzword) na peníze jak kráva.
Dobrý den,
responzivní CMS vám pomůže pouze v prostředí webu. V okamžiku, kdy chcete publikovat na další kanály/zařízení, tak potřebujete responzivní, nebo ještě lépe adaptivní, obsah.
A to je právě základní premisa headless CMS - spravovat obsah ve formátu, který ho umožní použít nejen na webu (jako u tradičních CMS), ale i v mobilních aplikacích, chatbotech, digitálních asistentech (Amazon Echo, Google Home, apod.), atd.
Novou "hlavu" (aplikaci) musíte vyvinout tak jako tak. Peníze vám to ušetří v tom, že nebudete muset obsah duplikovat v různých systémech.
Petr Palas, Kentico
Zrovna sem pogooglil ten buz*word headless. Početl článek. Díky za něj, vysvětlení ujde.
Po přečtení jsem měl na jazyku stejné slovo. "Píčovina" ...
Ano určitě budeme všichni programovat API pro všemožný hodinky s vodotryskem, to se fakt vyplatí.
Nehledě na idiota, co by surfoval na hodinkách nebo displeyi od lednice, to musí být supr počtení.
>>Oproti tomu headless CMS je k tvorbě obsahu pro více kanálů doslova stvořené. Umožňuje obsah připravovat a spravovat z jednoho místa. Samo ho pak nerenderuje, ale nechává to na aplikacích pro konkrétní zařízení. Do nich obsah distribuuje prostřednictvím API.
A ty aplikace spadnou z nebe ?
Takže rozdíl mezi druhým atřetím řešením je že si koupím nové moderní (=dražší) CMS a ještě si musím zajistit ty aplikace (= různé enginy u bodu 2,) každý pro jednotlivé zařízení
.
souhlasím, že jde o špatně skrytou a špatně udělanou reklamu ...
A mně jako uživateli se to zase líbí. Dobře napsané api do emacsoveho workflow integruju lépe než blbě napsanou webovou stránku. Jen teda nevím jestli jsem reprezentativní use case.
A to řešení očekávám výrazně levnější když je bez frontendu, ne dražší, samozřejmě.
Což ale není headless, nýbrž řešení číslo dva. Jen s tím rozdílem, že si tu hlavu saně budete programovat vy sám v emacsu. Což, ruku na srdce, budete v téhle republice asi jediný.
Přesně. To třetí řešení neexistuje. Přes veškerou snahu autora je popisované to druhé. Tedy že mám jednu databázi, ta drží data a má nějaké API typu "vložit článek", "vložit komentář", "dej mi seznam komentářů k článku XY". Což je něco, co mají dnes CMS tak nějak obecně. Třetí typ předpokládá, že jakmile mám tohle API, tak se nějak samo zázračně začne používat a uživatel si pak může číst články na svém mobilu. Ale to se nestane, na to uživatel potřebuje klientskou aplikaci. Musím proto jít cestou druhého typu a napsat si klientské aplikace, které budou umět na jedné straně zobrazovat uživatelské rozhraní a na straně druhé volat výše zmínění API.
Pokrok směrem ke třetímu řešení by byl, kdyby CMS použil nějaké standardně uznávané API, pro které by někdo jiný psal klientské aplikace. Že by to šlo víme díky RSS apod. Tam provozovatel CMS opravdu řešil jen to API, čtečky psal někdo jiný a nebyly vázány na jeden konkrétní CMS.
Dobrý den,
omlouvám se, že to není z článku zřejmé. Základní koncept headless CMS je skutečně to, že máte jedno uložiště obsahu (typicky v SQL nebo dokumentové databázi) a tento obsah zpřístupníte aplikacím přes API.
Samotné aplikace musíte vyvinout pro každé zařízení nebo kanál sami. Takže si napíšete webovou aplikaci, nebo třeba chatbota či Alexa skill, který si přes API vyžádá potřebný content.
Výhodou je, že máte obsah uložený jednou a nemusíte ho spravovat zvlášť např. pro web a zvlášť pro chatbot.
Další velkou výhodou headless CMS je, že se nesnaží programátorům mluvit do toho, jak píší aplikace - můžete použít jakýkolik jazyk a nejste omezený na konkrétní templating engine, jako u tradičních CMS.
Petr Palas, Kentico
Ako mi v tomto brani napriklad API wordpressu? Tiez si klienta mozem napisat v jave/php/pythone/brainfucku.
Dobrý den,
ano, některé scénáře lze obsloužit i pomocí tradičního CMS rozšířeného o API. Není to ale ideální řešení, jak vysvětluju v jiném článku zde: https://kenticocloud.com/blog/what-makes-a-true-headless-cms
Ve stručnosti:
- headless CMS je navržené tak, aby bylo možné obsah používat napříč kanály, což u některých CMS úplně neplatí (často generují HTML kód, který není snadné použít např. v chatbotu a nejde jednoduše parsovat/konvertovat na jiný formát)
- headless CMS zpravidla přichází s CDN (content delivery network), která poskytuje obsah mnohem rychleji a je mnohem škálovatelnější než standardní CMS
- headless CMS je zpravidla poskytováno jako skutečný SaaS se všemi výhodami, které tradiční CMS kvůli své architektuře nedokáže poskytnout
Petr Palas, Kentico
Takze vase CMS neumoznuje zadavat html obsah? Neposkytujete wysiwyg editor?
Co mi zabranuje nainstalovat wordpress do "cloudu", vypnut mu frontend a cachovat GET requesty na REST API v CDN?
Poskytovat CMS ako SaaS je urcite vyhodnejsie - hlavne ale pre vas ako prevadzkovatela tejto sluzby, pretoze namiesto jednorazoveho poplatku za instalaciu riesenia si mozete uctovat 300 eur mesacne za poskytovanie sluzby.
Dobrý den,
headless CMS většinou umožňují základní HTML formátování pomocí WYSIWYG editoru. Nicméně jejich základní koncept je udržet obsah ve strukturované podobě, která umožní snadné použití v různých kanálech - viz můj komentář o HTML/CSS.
Ano, můžete si nainstalovat tradiční CMS jako WordPress do cloudu a nastavit si CDN, ale pak se o ten WordPress musíte taky starat (upgrady, security hotfixy, zajištění dostupnosti, apod.)
Co se týče finanční stránky: SaaS je obecně ekonomicky nejefektivnější model jak pro poskytovatele, tak pro zákazníky. Ono pokud jste firma a musíte platit zaměstnance, aby se vám o tu instalaci WordPressu staral, tak už to najednou tak zadarmo není.
Jinak většina headlessových CMS je dostupná ve Free variantě, kterou lze bez problémů použít i pro komerční projekty.
Petr Palas, Kentico
Dobrý den,
Není to tak dlouho co jsem zde na fóru řešil vlastně to samé. "CMS pro dokumenty do PDF či papír" https://forum.root.cz/index.php?topic=16525.0
Nicméně z Vašeho popisu je mi jasné že to tak vůbec nechápete, pro vás je jednoznačným cílem orientace na web a e-shop a různými cílovými platformami myslíte různě specifické web aplikace...
Dobrý den,
z headless CMS je možné obecně generovat i PDF, ale pro vámi popisovaný scénář není primárně určeno. Headless CMS je primárně určeno pro marketingovou komunikaci, ne pro generování rozsáhlých technických dokumentů - na to určitě najdete vhodnější specializovaná řešení.
Petr Palas, Kentico
Hlavne ze zabudol zakazat pridavanie nazorov.
https://forum.root.cz/index.php?topic=16658.msg232722;topicseen#new
Nevím jestli jsem to pochopil správně. Ale co až nastane situace, že těch zařízení bude časem třeba 50? Technologie se vyvíjí rychle. Nebude to spíše otrava? Dělat 50 drobných úprav?
Dobrý den,
tomu, že bude růst počet zařízení/kanálů, se nevyhneme. Takže je opravdu možné, že některé firmy budou muset vytvářet mnoho různých aplikací, aby byly tam, kde je zákazníci očekávají.
Výhodou headless CMS je, že obsah vytvoříte jednou a spravujete ho na jednom místě, místo toho, abyste ho duplikovali v těch 50 různých systémech.
Petr Palas, Kentico
A v com je rozdiel proti pouzitiu API napriklad wordpressu? Tiez nan mozem napojit X roznych "frontend" aplikacii a tahat z neho data?
Stáhl jsem si ten anglický manuál. Zajímavé, i když jen obecné informace. Spíš mne zarazilo něco jiného: Od kdy se do názvů souborů používají mezery, obzvlášť když jsou uloženy na Internetu ke stažení? Na druhou stranu znám borce co tam "nacpou" i diakritiku :-)
"Good advertising, nothing else."
Komercni clanek. Obsah nijak zajimavy.
V podstate jde o to, ze rozdelite cms na 2 casti. Jedna dela editaci a export treba do xml/csv a druha ty xml umi precist a vypsat na stranku. A ted je treba udelat nejaky jednotici prvek (propojeni atributu), aby slo prvni nebo druhou cast zamenit a poresit obsah, na ktery je nutne uzivatele prihlasit.
V podstate tak uz funguje heureka, zbozi a pod. Date mu link na xml a on pak umi do sveho katalogu pridat vase produkty a nejak je vyrenderovat.
U nas takhle funguje Stag, ma web-services (WS), ktere dokazi export z sql dotazu do xml, csv, xls. Pak je mozne napsat program, ktery pres php file_get_contents si stahne treba nekolik odlisnych exportu a vyrobi z toho vlastni stranku. Ma to jednu vadu, cileny sql dotaz je casto 10-100x rychlejsi nez skladani z nekolika file_get_content (u nekterych aplikaci mam treba 100-1000).
Za našich čias sa "hédles síemes" volalo servisne orientovaná architektúra :) Tento pojem, spolu s "několikahlavou sání" si zapamätám a budem tým baviť kolegov :)
Dobrý den,
servisně orientovaná architektura (SOA) je přesně typ architektury, kam headless CMS zapadá. Místo toho, aby firmy stavěly weby uvnitř CMS (monolitická architektura), staví je jako stavebnici z různých služeb poskytovaných formou API.
Na rozdíl od tradiční (monolitické) CMS architektury tak nejsou limitovaní konkrétní technologií a vyhnou se lock-inu na jednoho vendora.
Petr Palas, Kentico
Tak som si vytvoril testovaci ucet v tom vasom headless CMS. Dovolim si trosku analogiu s Wordpressom, ale myslim ze podobnu funkcost je mozne dosiahnut v drupale, typo3 a x dalsich bezplatnych CMS. Vase headless CMS je stale len CMS, neposkytuje viacero roznych sluzieb, stale je to monolit, akurat bez frontendu.
Pre tu srandu som si vyskusal zadefinovat si vlastny typ Contentu, ktorym by mal byt produkt. Skoncil som hned na zaciatku, pretoze sice poskytujete field typu Number, avsak nie je mu mozne nastavit ziadne validacne pravidla (napr. pocet desatinnych miest, celociselnost, len kladne cisla, max rozsah a podobne).
"Na rozdíl od tradiční (monolitické) CMS architektury tak nejsou limitovaní konkrétní technologií a vyhnou se lock-inu na jednoho vendora." - neviem ci myslite vazne tuto vetu, ale zjavne ano. Takze - firma je limitovana konkretnou technologiou - konkretne vasou technologiou a vami ako vendorom - fixne definovanym API, nemoznostou "exportu dat", nemoznostou rozsirovania CMS podla potreby.
Osobne by som vam poradil cely tento blog zmazat a skusit ho napisat znova, za rok, mozno dva, ked trochu vo vyvoji toho vasho uzasneho headless/useless CMS pokrocite. Pretoze aby som momentalne platil $299 MESACNE za CMS, v ktorom mozem mat max 10 pouzivatelov, to by som musel utrpet naraz tupym predmetom do hlavy.
Dobrý den,
děkuji za vyzkoušení a feedback.
Co se týče monolitu: není to monolit ve smyslu "mám dokupy CMS i prezentaci".
Co se týče validace: tento typ validace zatím neumožňujeme, je to v plánu do budoucna.
Co se týče vendor lock-in: Podstatou je, že vaše aplikace získává obsah přes jasně definované API. Pokud se rozhodnete přejít k jinému CMS řešení, můžete relativně snadno nahradit naše API za jiné. Tohle u tradičních CMS nejde - pokud postavíte web třeba na WordPressu, tak jediný způsob, jak ho převést na Drupal, je začít kompletně znovu.
Stejně tak můžete vyexportovat obsah přes naše API. Díky tomu, že je obsah vysoce strukturovaný, není problém ho pak naimportovat do jiného CMS.
Naše nové CMS řešení se neustále vyvíjí a stále je co zlepšovat. Už dnes na něm ale běží celá řada komerčních projektů a s tím, jak každé dva týdny vydáváme nové funkce a vylepšení, roste počet zákazníků, kteří si naše řešení kupují.
Petr Palas, Kentico
Bohuzial, neviem ci umyselne alebo neumyselne, kazdopadne rozpravate ale uplne bludy. V com je vase API lepsie ako API wordpressu?
Dobrý den,
rozdíl oproti headless WordPressu:
- především headless WordPress je stále postaven na konceptu práce s webovými stránkami a neposkytuje takovou úroveň strukturovanosti obsahu, jakou nabízí Kentico Cloud nebo jiná pokročilejší headless CMS a nepočítá s tím, že obsah bude adaptován na různé kanály
- headless WordPress není standardně SaaS - musíte se starat o CMS, upgrady, security, atd. (ano, můžete použít PaaS hostingy, ale ty zase mají zpravidla omezení ohledně pluginů, které můžete použít)
- headless WordPress nemá standardně CDN - bez toho bude přístup k API pomalý, zejména u mobilních aplikací nebo při vícenásobných voláních v JavaScriptu (ano, můžete si ji koupit, nakonfigurovat a spravovat sám)
Pokud budete chtít, tak WordPress samozřejmě ohnete pomocí různých pluginů k čemukoli.
Krása headless CMS je v jednoduchosti celé architektury z pohledu vývojáře a použitelnosti z pohledu koncového uživatele.
To, že si na webové službě spravujete obsah, nemusíte se vůbec starat o CMS a pouze použijete jeho API ve vlastním kódu, nad kterým máte jako vývojář plnou kontrolu - to je důvod, proč je koncept cloud-first headless CMS stále více populární.
Petr Palas, Kentico
Další pokus o oddělení obsahu a popisu zobrazení? Proč už nestačí HTML/různá CSS pro různá zařízení, XML/XSLT, nebo podobné? Psát pro každý typ zařízení zvláštní "appku" mi je dost proti srsti - jak z hlediska vývojáře, tak uživatele. A proč nehlídat změny třeba klasickým RSS?
Dobrý den,
jde o to, že obsah se může zobrazovat nejen na webech, ale i na jiných zařízeních, která ani nemusí s HTML/CSS pracovat. Příkladem můžou být chytré hodinky, smíšená realita/virtuální realita, chatboti, digitální asistenti s hlasovým rozhraním (např. Amazon Echo, Google Home) nebo různé informační tabule v obchodech a restauracích.
To znamená, že CMS musí umět pracovat s obsahem ve velmi strukturované podobě, kterou lze snadno formátovat do různých výstupů. Například HTML kód spravovaný v CMS by měl být co nejčistší, tak aby bylo možné ho v případě potřeby parsovat a transformovat do jiného výstupního formátu.
Mnoho tradičních CMS je postavena na konceptu "umožníme zákazníkovi editovat všechno pomoci WYSIWYG editoru, ať může dělat cokoli." To je krátkodobě pohodlné, ale z dlouhodobého hlediska to znamená, že vytvoříte hromadu obsahu, který už nelze automaticky jednoduše přeformátovat. Takže když se rozhodnete udělat například zmiňovaný chatbot, najednou zjistíte, že musíte spoustu obsahu znovu přepsat.
Petr Palas, Kentico
Od bežného CMS očakávam, že tam bude mať nejaký WYSIWYG editor a správu článkov. Aby toto headless bolo na niečo dobré, musí to mať nejako štrukturovaný obsah na daný kontext (multichannel) (napr normálne napíšem cena: 100, ale tu musím mať políčko cena a potom to nejako vložiť cez referenciu do článku). Toto si viem ale urobiť jednoducho s fieldami napr v drupali a téma môže generovať json namiesto html. No neviem, nevidím v tom nič prevratne, iba alternatívne riešenie.
Dobrý den,
ano, přesně toto headless CMS umožňuje - nadefinovat si svoje vlastní typy obsahu. Každý typ obsahu pak má vlastní strukturu políček, která mohou být typovaná (text, datum, číslo, apod.)
Když chcete, tak něco jako headless CMS můžete udělat z jakéhokoli CMS. Jenom to často postrádá eleganci a efektivitu čistého headless CMS (obzvlášť když ho ještě použijete jako SaaS službu).
Jak to výstižně pojmenoval jeden náš zákazník: na headless CMS je nejlepší to, co to neumí. To, že je headless CMS zaměřené pouze na poskytování obsahu přes API, znamená, že vývojáře ani editory nezatěžuje spoustou funkcí, které nepotřebují a které jim překáží při práci.
Petr Palas, Kentico
Ta myšlenka se mi líbí. Řešení jak ji dosáhnout - zda jde o Kentico, WP API, popřípadě cokoliv jiného je v podstatě úplně jedno. Pokud stavím aplikaci, ke které se přistupuje z různých kanálů, dokážu si představit že se s tím pracuje super. Krásně strukturované data, jednoduchá dokumentace - pošlu specifikaci API, dodavateli iOS aplikace, Android aplikace, atd. a ten za předpokladu, že je to standartizovaný systém bude z velké pravděpodobnosti mít hotové napojení a nebude muset nic moc vymýšlet a ve finále vývoj těchto věcí může být levnější.
Nicméně nedokážu si na druhou stranu představit zaškolení klienta v tom systém používat. Je to dost abstraktní :-) Celkem by mě ale zajímala nějaká case study, nebyla by?
Dobrý den,
to je skvělý bod, který v blogu nezmiňuji, ale je pravda, že headless přístup vyžaduje jiný způsob uvažování. Editoři obsahu už nemohou uvažovat pouze v intencích "jak upravit text na této stránce," ale musí začít uvažovat o obsahu na obecnější úrovni.
Nicméně v okamžiku, kdy se přes toto přenesou, oceňují jednoduchost a přímočarost uživatelského rozhraní.
Tady je jedna z case studies, která obsahuje feedback od uživatelů: https://kenticocloud.com/case-studies/family-business-awards
Petr Palas, Kentico
Nemyslím si, že rozumná firma potřebuje vytvářet informační kanál, přes který distribuuje podobný obsah do monitoru, hodinek i brýli na VR. Neznám totiž žádného vola, který by si na zjišťování adresy obchodu bral brýle na VR nebo četl statistiky v PDF na hodinkách...
Že je něco možné neznamená, že je to potřebné.
Dobrý den,
samozřejmě není nutné ani vhodné mít veškerý obsah na všech možných kanálech.
Ale když jsme u té adresy nebo otevírací doby obchodu: představte si, že jedete autem a zeptáte se virtuálního asistenta "kde najdu nejbližší Tesco, které má ještě otevřeno?" A on vám odpoví na základě stejných aktuálních informací z headless CMS, které máte současně dostupné na webu, v mobilní aplikaci, v chatbotu, apod.
Petr Palas, Kentico
Petr Palas založil Kentico Software v roce 2004. Od té doby z něj vybudoval firmu s více jak dvěma stovkami zaměstnanců a s pobočkami na třech kontinentech. Řešení Kentico každý den pomáhá tisícům firem efektivně oslovovat zákazníky pomocí webových stránek, e-shopů a kampaní, které v něm marketéři připravují a spravují. Koncem loňského roku uvedl Kentico Software na trh nové SaaS CMS, Kentico Cloud, které umožňuje tvořit a publikovat obsah nejen na webu, ale na libovolném zařízení.