Headless CMS: Alt du trenger å vite

Tradisjonelt CMS

Hva er den vesentlige forskjellen mellom et tradisjonelt CMS og et headless CMS? Kort og godt: Et tradisjonelt CMS har en tett kobling mellom innhold og presentasjon, mens headless kutter denne forbindelsen.

I tradisjonelle CMS-er har redaktørene tilgang til full forhåndsvisning, redigering av landingssider, URL-håndtering, detaljert tilgangskontroll og mediabibliotek. Samtidig kan utviklerne kode, teste og distribuere både redaksjonell og brukermessig funksjonalitet samlet. Dette er mulig på grunn av en tett kobling mellom leveringslaget og CMS-et.

En ulempe med tett kobling i tradisjonelle publiseringsløsninger er en problematisk tilstedeværelse i flere kanaler. En standard nettleser for skrivebord, en mobilapp, en smartklokke, digital skilting og tingenes internett-enhet (IoT) kan ikke lese og presentere innholdet på like vilkår når presentasjonslaget er laget eksklusivt for nettet.

Det er her headless CMS kommer inn i bildet.

Headless CMS

Oppblomstringen av mobilapper, sosiale medier, smartklokker, digital skilting, selvbetjeningsmaskiner, roboter og utallige IoT-enheter endrer måten vi konsumerer digitalt innhold på. Alle disse plattformene har unike egenskaper og forskjellige metoder for å presentere og håndtere innhold.

Problemet med flerkanalslevering, samt fremveksten av rike front-end-rammeverk som blidgjør utvikleren er akkurat det et headless CMS imøtekommer.

Med et headless CMS forblir det strukturerte innholdet det samme, mens hver klient – som en app, en duppeditt eller en nettleser – vil være ansvarlig for hvordan innholdet presenteres. Utviklere koder vanligvis ikke i selve headless CMS-et, men bruker API-et og koder i et annet rammeverk etter eget valg.

Pingpong-utviklingen av CMS

Historien til publiseringsløsninger er delt mellom tradisjonelle og hodeløse uttrykk. Det kan sammenlignes med en bordtennismatch, hvor ballen slås fra den ene spilleflaten og over til den andre. Hvor ett felt gleder én gruppe ansatte i organisasjonen din, gjør det en annen gruppe kolleger misfornøyd. Og omvendt.

Mønsteret er som følger:

• Tradisjonelt CMS: Redaktøren er fornøyd, men utvikleren er misfornøyd
• Headless CMS: Utvikleren er fornøyd, men redaktøren er misfornøyd

I et tradisjonelt CMS, inkludert markedsføringssuiter og digitale plattformer, kan redaktøren jobbe lykkelig i et brukervennlig redaksjonelt miljø. Funksjoner inkluderer visuell sideredigering, trestrukturer og kontekstuell forhåndsvisning. Utvikleren, derimot, blir tvunget til å jobbe innenfor et fastsatt system, hvor CMS-et og front-enden er tett sammenknyttet.

Med fremveksten av første generasjon headless CMS, har bordet snudd. Her er front-end skilt fra CMS-et, noe som lar utvikleren jobbe med sine foretrukne verktøy og rammeverk. Redaktøren må derimot nå streve med skjemabasert innhold, samt med begrensede muligheter for visuell redigering av sider, forhåndsvisninger og URL-håndtering.

Ikke alle headless CMS-er er like!

Headless CMS er ikke en strengt homogen kategori. Noen er "første generasjon" eller "skybaserte," som betyr at de kun er tilgjengelige som skytjenester og ikke som programvare. Tilnærmingen "headless som en tjeneste" forenkler skalering, overvåking, sikkerhetskopiering og mer, men ofrer fleksibilitet og kontroll.

Andre hodeløse publiseringsløsninger kan kalles "neste generasjon" eller "hybride," men hva er disse?

Neste generasjons headless CMS – composable CMS

Som nevnt er et "rent" headless CMS mer eller mindre en database med et API og et grensesnitt. Med API-et kan du levere innholdet ditt eller utdrag til forskjellige klienter, som stemmeassistenter, armbånd, smartklokker, AR-briller eller som en del av tredjeparts nettsteder.

Et headless CMS av første generasjon vil mest sannsynlig tilby deg minimal hjelp til å bygge komplette nettsteder, ettersom båndet mellom innhold og presentasjon er helt kuttet.

De fleste organisasjoner trenger primært nettsteder, men første generasjons headless fokuserer ikke på innholdsrike nettsteder. Dette betyr at organisasjonen din kan trenge flere systemer som kjører for å håndtere ting som strukturert innhold, sidekomposisjon, URL-er og alt annet som kreves.

Som en reaksjon på å måtte bruke flere systemer, kommer neste generasjons headless CMS inn i bildet. Et headless CMS av neste generasjon kan strukturere innhold og komponere nettsteder – i ett system.

Alle de lette headless-funksjonene er der, men med (valgfri!) tilleggsfunksjonalitet som visuell redigering av sider, forhåndsvisning, hierarkisk trestruktur, URL- og SEO-håndtering, sidemaler, detaljerte tillatelser, back-end-integrasjoner og tilpasning av API.

Et slikt CMS kalles også et komponerbart eller composable CMS, da det lar deg orkestrere eller dirigere dine API-er og digitale opplevelser fra selve CMS-en. Her er utviklerne fornøyde med det separerte front-endet, og redaktørene er fornøyde med et brukervennlig og visuelt orientert redaksjonelt miljø, som i tillegg kan håndtere integrasjoner og API-er.

Sammenligning side om side

Innholdsforvaltning

Ting på et høyt nivå i systemet, fra fundamental struktur til grunnleggende muligheter og funksjoner.

Web and Presentation

The look and feel of things, and how the triad copes with stuff like presentation, previews, and URLs.

Drift

Det mest tekniske innholdet til slutt, med fokus på programvare, nettsky, CDN og andre aspekter.

Innhold er en grunnleggende byggestein i headless CMS. Utover å bli beskrevet som en "database + API", hva er spesielt med innholdet som headless-løsninger håndterer?

Først og fremst forvalter et headless CMS strukturert innhold. Dette er informasjon organisert på en forutsigbar måte og oftest klassifisert med metadata.

Innholdstyper

Å være "strukturert" betyr at hvert innholdselement av samme type har samme struktur (duh!). De har alle de samme feltene og den samme logikken. Dermed kan alle innholdselementer av samme type behandles på en uniform og forutsigbar måte i forskjellige scenarioer.

Eksempler på innholdstyper kan være artikkel, side, person, case studie, oppskrift, bil, bok, kurs, video, kontor, produkt, arrangement og lyd.

Strukturert eksempel

La oss illustrere prinsippet om strukturert innhold med et enkelt eksempel: et blogginnlegg. Denne innholdstypen inkluderer vanligvis felt for tittel, bilde, ingress, forfatter, dato, brødtekst, kategori og stikkord.

Ettersom hvert innholdselement inkluderer de samme feltene, kan CMS-et nå behandle dem som ett. La oss si at du ønsker å vise en liste over dine nylige blogginnlegg. CMS-et kan da trekke ut data fra feltene tittel, bilde og ingress, samt bruke datofeltet for kronologisk oppføring.

I dette enkle eksemplet har redaktørene opprettet blogginnhold én gang, som deretter gjenbrukes i en bloggliste et annet sted på nettsiden. Dette er det grunnleggende prinsippet bak skalering, gjenbruk og gjentakbarhet av innhold i et headless CMS.

Et ekte headless CMS støtter ikke bare tilstedeværelsen av innholdstyper. Det er en forutsetning for dets eksistens.

Bilde- og mediehåndtering

Som nevnt ovenfor skal også bilder og andre mediefiler betraktes som innholdstyper i et headless CMS med ekte strukturerte innholdsegenskaper. Hvorfor? Fordi prinsippet om gjenbruk gjelder like godt for bilder, videoer og lydfiler som for enhver annen innholdstype.

Disse filene kan ha flere felt for metadata, som kan brukes til å trekke ut for eksempel geodata for en app som viser frem media for ulike steder i verden.

Metadata og bruksområder er én ting. En annen viktig sak for bilde- og mediehåndtering er de innebygde verktøyene i et gitt headless CMS. Som i mange andre tilfeller er ikke alle headless CMS like på dette området.

Å redigere bilder med f.eks. beskjæring og fokuspunkt er funksjoner innholdsredaktører setter pris på. Det gjør det enklere for dem å levere akkurat det de ønsker å uttrykke uten å involvere tredjepartsverktøy.

På den andre siden har utviklere API-er for bilder som gjør det mulig for dem å bruke filtre, opprette URL-er til forskjellige bildestørrelser, osv.

Sørg for å undersøke om slike redigeringsfunksjoner er til stede i alle headless CMS-er du vurderer.

Blokkredigerer

Selv om det er ganske enkelt å forstå hvilken rolle felt og innholdstyper spiller når det gjelder strukturert innhold, blir ting litt mer kompliserte med blokkredigerere. Mange organisasjoner ønsker muligheten til å skape komplekst innhold som fortsatt er svært strukturert, og det er her en blokkredigerer kommer inn i bildet.

Et headless CMS som støtter blokkredigerere gjør det mulig å legge til eller fjerne felt fra innsiden av et såkalt "sett" i en gitt innholdstype. Dette kan for eksempel være en artikkel som tillater redaktører å sette inn blokker for riktekst, bilde, videointegrering, kontaktpunkt, tabell eller andre krav man måtte ha.

Ideen er å gjenskape muligheten til å ha rikt innhold og sideredigerer-lignende kontroller, samtidig som man gjør innholdet svært strukturert for gjenbruksformål. Noe som samsvarer godt med headless-verdenen.

Nå som vi har dekket den første delen av "headless-ligningen" [database + API], er det nå på tide å rette fokuset mot den andre delen: API. API står for "applikasjonsprogrammeringsgrensesnitt" (litt av en munnfull!), og er et databehandlingsgrensesnitt som lar ulike systemer kommunisere med hverandre.

For å si det enkelt, et API er lenken mellom ditt innhold (database) og enhver enhet eller plattform som viser det frem (klient). Informasjon om API-et er ofte det utviklere verdsetter mest i ethvert headless CMS. Det sier seg selv: API-et må være veldig godt og fleksibelt for å imponere.

La oss ta en titt på noen av de populære API-teknologiene.

GraphQL

GraphQL er et API-spørringsspråk utviklet av Facebook. Med sterkt typede og selv-dokumenterende egenskaper muliggjør det at klientutviklere kan be om akkurat den informasjonen de trenger i så få forespørsler som mulig. Det passer perfekt for headless CMS.

Med andre ord, et godt headless-API basert på GraphQL lar deg øyeblikkelig få tilgang til dataene dine fra enhver enhet eller klient. Det bør gi deg nøyaktig det du trenger med én enkelt forespørsel. Et slikt API kan til og med tilpasses og utvides for å møte dine spesifikke krav hvis ditt headless CMS støtter dette.

REST

REST har blitt brukt i hele programvareindustrien og er et allment akseptert sett med retningslinjer for å opprette tilstandsløse, pålitelige web-API-er. Et web-API som overholder REST-begrensningene blir uformelt beskrevet som "RESTful". RESTful-web-API-er er vanligvis løst basert på HTTP-metoder for å få tilgang til ressurser via URL-kodede parametere og bruk av JSON eller XML for å overføre data.

Lyder noen av disse nøkkelordene, som skalérbarhet, uavhengig distribusjon, web-API-er, JSON og XML, kjent? Det er fordi RESTful-API-er er nok en nyttig teknologi som gir styrke til gode headless-publiseringsløsninger.

Ulempen med REST sammenlignet med GraphQL er at front-end- og back-end-utviklere må samarbeide for å implementere det eksakte API-et som trengs av front-end. GraphQL-tilnærmingen bare eksponerer alt, og lar front-end utvikleren hente det som er nødvendig.

Å velge det rette hodeløse CMS-et for deg, ditt team og din organisasjon kan være en overveldende oppgave. Men det behøver ikke å være umulig. Her er noen nøkkelfaktorer du bør vurdere i din anskaffelsesprosess.

Infrastruktur og teknologi

Et fremtidsrettet headless CMS bruker moderne teknologi og er åpent for integrasjon med de beste verktøyene. Dette betyr å tilby fleksible API-er, være nøytral til front-end-rammeverk og bruke skytjenester for smart skalering. Det innebærer også kompatibilitet med verktøy for redaksjonelt virke, markedsføring og analyse.

Denne modulære infrastrukturen sikrer at headless-løsningen ikke bare løser dagens utfordringer, men at den også er fleksibel og smidig nok til å tilpasse seg fremtidige problemstillinger.

Vurder nøye organisasjonens behov. De fleste kan være fornøyde med en løsning levert som en tjeneste (skyløsning), men din organisasjon kan ha krav til drift i egne miljøer. Hvis dette siste alternativet er aktuelt, bør du undersøke headless-leverandører nøye, da ikke alle kan tilby programvare som kan være selvdriftet.

Et must for ethvert headless CMS er et omfattende og fleksibelt API for å samle, opprette og vedlikeholde innhold. Hvis du må tilpasse eller bygge API-er skreddersydd for organisasjonens krav, bør du sørge for at CMS-et støtter dette.

Utviklerøkosystem

Utviklere er hovedmålgruppen for et headless CMS. De ønsker å vite hvordan CMS-et passer inn i organisasjonens eksisterende digitale portefølje og rammeverk, samt alle detaljene i løsningen selv.

Utviklere liker også å delta i fellesskap hvor de kan motta og gi hjelp, samt vise frem sine løsninger bygget med CMS-et. Et aktivt fellesskap, sammen med et profesjonelt supportsystem fra leverandøren, vil gjøre utviklerne dine mer fornøyde.

I tillegg må du lære opp de ansatte som skal bruke og drive CMS-et i årene som kommer. Å la utviklere og redaktører gjennomgå opplæring i headless-løsningen vil spare organisasjonen din for tid og penger i det lange løp.

Til slutt bør headless CMS-et du velger ha et økosystem med ferdige integrasjoner og utvidelser. Dette kan inkludere biblioteker for utviklere, integrasjoner med andre systemer og utvidelser til CMS-et.

Enkel Innholdsproduksjon

Det er fristende å lytte til stående applaus fra utviklere når det kommer til en gitt hodeløs publiseringsløsnings fortreffelighet. Men ikke glem den andre gruppen som er ment å arbeide med løsningen på daglig basis: innholdsredaktørene.

Spør deg selv hvor lang tid det vil ta for innholdsteamet å forstå headless CMS-et for å maksimere produktiviteten. Det redaksjonelle grensesnittet til et headless CMS bør først og fremst gjøre innholdsredaktørene dine produktive og effektive.

Mange førstegenerasjons, skybaserte og "rene" headless CMS-løsninger tilbyr den fryktede databasen og skjemabasert redigering – og lite annet rett ut av boksen. Selve innholdet bør selvfølgelig være i sentrum, men redaktører liker å se og føle hvordan deres innhold vil bli presentert. Akkurat som en filmregissør liker å se og høre sin film på storskjerm, i motsetning til samme fortelling i et manus.

Med andre ord, du bør forsikre deg om at løsningen du velger kan komponere innhold innenfor en kontekstuell forhåndsvisning (sammen med både visuelle elementer og tjenester). Samtidig bør den være responsiv, tilby en logisk oversikt som en trestruktur, og støtte arbeidsflyt og tillatelser. I tillegg sparer gjenbruk av innhold – en grunnpilar i headless – både tid og ressurser.

Sikkerhet og pålitelighet

Et headless CMS gir bedre sikkerhet ved å redusere antall eksponerte komponenter tilgjengelig for sluttbrukere. Inngangspunkter for ondsinnede "gjester" er begrenset når bare noen få deler av løsningen er synlige. Denne sikkerhetsfunksjonen styrkes ytterligere hvis leverandøren bruker en statisk side på et CDN (innholdsleveringsnettverk).

Det eneste tilgjengelige elementet for sluttbrukere er flere ledd fra kritiske komponenter. Prosessen med å skape innhold for deretter å distribuere det involverer mange bevegelige deler, og i tradisjonelle publiseringssystemer skapte dette ofte et sårbart back-end.

Med et headless CMS er opprettelsen og leveringen av innhold alltid separate prosesser. Dette gjør det svært vanskelig for sluttbrukere å få tilgang til baksiden av løsningen din. Faktisk tillater fleksibiliteten til et headless CMS enda strammere sikkerhet gjennom et skybasert oppdateringsregime. Med en modulær arkitektur kan du planlegge oppdateringer og vedlikehold med liten eller ingen nedetid.

Å holde ditt innhold og kundedata sikre bør selvfølgelig være en av dine høyeste prioriteringer. Vurder organisasjonens krav til hvor data skal lagres, hvem som har tilgang, og leverandørens sikkerhetssertifiseringer. Du bør også sørge for at leverandøren regelmessig tester for sikkerhetsproblemer og raskt distribuerer oppdateringer og sikkerhetsfikser.

Påliteligheten til en headless-løsning hviler på flere faktorer, inkludert hva som skjer med dine digitale opplevelser under og etter vedlikehold. I tillegg, som en del av en pålitelighetsvurdering bør du verifisere leverandørens historikk gjennom dokumentasjon, tilbakemeldinger fra kundegruppen og analytikerrapporter.

Som et siste forslag i denne delen bør du sørge for at ditt valgte headless CMS støtter utviklingsprosessen din og tilbyr flere miljøer – for eksempel for testing, oppsett og produksjon.

I likhet med det meste i livet kommer headless CMS med både fordeler og ulemper. Vi har diskutert mange av fordelene med et headless CMS, men hva ligger på skyggesiden? Er det noen reelle utfordringer?

Et rent, første generasjons headless CMS kan vanligvis ikke:

• Bruke en visuell landingsside-redigerer
• Organisere nettstedsstrukturen
• Håndtere URL-er
• Forhåndsvise innholdet
• Håndtere brukerrettigheter og tillatelser
• Håndtere SEO
• Håndtere kompleks bildebehandling

I tillegg må utvikleren for hver nye klient takle flere problemer, inkludert:

• URL-håndtering (igjen)
• Formatteringsproblemer og maler
• Caching og "lazy loading"
• Tillatelser
• Feilhåndtering
• Synkronisering mellom CMS-et og klienter
• «Tvungne» oppdateringer fra skyleverandøren

Avhengig av leverandøren og valgene du tar i det digitale prosjektet kan mer tilpasset utvikling også være nødvendig hvis du bruker headless-tilnærmingen for tradisjonelle nettsteder. Og fordi mange headless-løsninger er skybaserte, er det kanskje ikke et alternativ å drifte programvaren selv.

La oss gå mer i dybden på noen av utfordringene. Merk: Disse varierer fra leverandør til leverandør, og hvorvidt de tilbyr muligheten til et neste generasjons headless CMS, dvs. kombinere lettvektsfordelene med headless med et valgfritt, men kraftig tillegg av redaksjonelle verktøy.

Forhåndsvisning

Siden redaktører arbeider i en database og ikke på en faktisk nettside, vet de egentlig ikke hvor innholdet vil ende opp eller hvordan det vil se ut før publisering.

Utviklere kan faktisk lage en standard forhåndsvisning som en rask referanse, noe som letter innholdsredaktørens sinnstilstand. Bare husk at forhåndsvisningen kanskje ikke ser nøyaktig ut som den endelige presentasjonen på hver kanal.

Trestruktur

Mange headless-leverandører tilbyr ikke en hierarkisk trestruktursoversikt over innholdet. Denne typen navigasjon er kjent fra operativsystemer og lar brukeren bla gjennom innhold ved å åpne og lukke underordnede innholdselementer under et overordnet innholdselement.

Som nevnt tidligere er en headless CMS mer eller mindre en database. Organisering av innhold eller å oppnå en ryddig oversikt i større prosjekter kan bli vanskelig basert på en slik standard databasevisning.

Utviklerdrevet

En stor utfordring med headless CMS er dette følgende faktum: Innholdsredaktørene ba ikke om det. Hvilken innholdsredaktør drømmer om å lage og vedlikeholde innhold kun i en skjemabasert database?

Headless CMS er hovedsakelig utviklerdrevet. Frikoblingen mellom innholdslaget og presentasjonslaget gir mer moro og smidighet for utviklere, men utgjør en reell utfordring for innholdsredaktører. Dette skyldes spesielt grensene i første generasjon headless for hva slike brukere kan gjøre og tilpasse innen plattformen.

Drift og sikkerhet

De fleste rene headless-leverandører tilbyr sine løsninger som SaaS, noe som betyr at du logger inn på en skytjeneste for å redigere innhold. Med dette kommer fordelene med skydrift i form av lynraske hastigheter og skyskalering for trafikktopper.

Men ikke alle headless-leverandører er like. Hybridleverandører tilbyr for eksempel en rekke driftløsninger. Noen er SaaS, mens andre kan være PaaS eller til og med lokalt. Den generelle trenden er imidlertid at stadig flere leverandører flytter til skyen for å øke brukeropplevelsen og hastigheten. Fordi de fleste headless-løsningene er basert på sky, kan drift av programvaren selv være utenfor rekkevidde.

Hvis prosjektet ditt involverer rikt webinnhold, URL-håndtering, omfattende redaksjonelle krav, spesielle driftsbehov og gjenbruk på tvers av forskjellige kanaler, kan et composable CMS være løsningen du leter etter.

Mer kode å vedlikeholde

Den utviklerprimære tilnærmingen til headless CMS kan faktisk innebære mer hardkoding for utviklerne, og innholdsredaktørene er mer avhengige enn noen gang av hva utviklerne har tatt hensyn til. Det er muligheter for hardkodede og tilpassede brytere og kompleks konfigurasjon, men dette gjør plattformen mer avansert enn nødvendig.

I noen headless-tilfeller må utvikleren gjøre alt det tunge løftet – inkludert å bygge og vedlikeholde en større kodebase. Siden et rent headless CMS bare er et API, kan det å lage et fullstendig nettsted utgjøre en reell utfordring.

Videre må mye praktisk håndteres – som URL-håndtering, dyplenking og feilhåndtering. Avhengig av dine valg kan et første generasjons headless CMS faktisk føre til høyere kompleksitet, ved å gå fra ett system til flere for å håndtere ulike oppgaver.

I tillegg til dette må alle de ulike systemene integreres, synkroniseres og håndteres, og der har du en reell hodepine.

***

Mange av disse utfordringene med headless CMS kan enkelt overvinnes ved å undersøke og velge den riktige løsningen for deg. Noen leverandører har tatt hensyn til disse faktorene og tilbyr et alternativ i neste generasjon: Å ta det beste fra begge verdener ved å frigjøre utvikleren og berike redaktøren.

Headless CMS gir mening i en verden der du ikke nødvendigvis vet hvor informasjonen din vil bli presentert i morgen. Kombinasjonen av en database + et API for distribusjon til hvilken som helst kanal er uslåelig.

Som vi har sett, er ikke headless CMS uten sine utfordringer. Vi mener imidlertid at disse kan overvinnes med smarte strategier som involverer funksjoner fra neste generasjon.

Innhold er i bunn og grunn data. Å ha en metode for å behandle data enkelt og forutsigbart vil ikke bli utdatert eller gå av moten. Det ligger i selve grunnlaget for kommunikasjon. Spørsmålet er i hvilken grad headless CMS vil nærme seg hva det opprinnelig distanserte seg fra: Det tradisjonelle CMS-et.

Vi tror at fleksibilitet vil være den viktigste ingrediensen for suksessrike leverandører i årene som kommer. Fleksibiliteten til å velge komponentene du trenger for å tilfredsstille både utviklere og innholdsredaktører til enhver tid, i et stadig skiftende miljø.