CMS: Alt du trenger å vite om publiseringsløsninger

La oss starte med begynnelsen: Hvorfor skal markedsførere og innholdsredaktører bry seg om hvilke verktøy de jobber med? Hva betyr det om du skriver i Word, Docs eller Pages, utfører beregninger i Excel, Sheets eller Numbers, eller lager presentasjoner i PowerPoint, Slides eller Keynote? De er jo bare verktøy som utfører visse oppgaver. Eller er det sånn?

Tror du snekkere bry seg om hvilke verktøy de bruker, som hammer, sag og skrutrekker? Tror du de er likegyldige til kvaliteten og funksjonen til verktøyene sine? En god hammer kan slå inn og trekke ut spiker med presisjon, mens en dårlig hammer slår i ubalanse, trekker dårlig eller kanskje til og med brekker under arbeidet.

Det samme prinsippet gjelder for alle andre yrker. Lastebilsjåfører, leger, frisører og programmerere. Alle disse fagfolkene bryr seg om kjøretøyene, skalpellene, saksene og datamaskinene sine.

Og det bør du også gjøre.

Du bør bry deg om verktøyene dine. Særlig organisasjonens publiseringsløsning (CMS).

Nesten alle bedrifter, foreninger og institusjoner har et nettsted. Nettsteder er ikke lenger det enkeltsidige visittkortet fra tidlig på 90-tallet med primitiv HTML og design.

Dagens nettsteder er ofte komplekse økosystemer med sider, bilder, lenker, systemintegrasjoner, selvbetjening, netthandel og andre funksjoner. Og alle disse elementene må samles og organiseres av en publiseringsløsning.

Så bør du bry deg om verktøyene som leverer innholdet ditt på nett og i andre kanaler?

Selvsagt bør du det!

La oss nå fortsette med en definisjon av et CMS, ettersom vi må vite nøyaktig hva vi snakker om.

Definisjon av CMS

Et content management system, eller CMS for kort, er et dataprogramvaresystem som organiserer opprettelse, endring og publisering av digitalt innhold som dokumenter og bilder, ofte i et samarbeidsmiljø, med sikte på å presentere det på et nettsted eller en app.

Litt av en munnfull!

Et slikt system kan også være kjent under andre termer, som «web content management» (WCM) eller «digital experience platform» (DXP).

Hvis du har jobbet med nettsteder på en eller annen måte de siste 20 årene, har du mest sannsynlig støtt på et CMS i en eller annen form.

Redaksjonen i nettaviser bruker det, det digitale markedsføringsteamet i bedrifter bruker det, og avdelinger i offentlige etater bruker det.

Alle bruker CMS.

Til og med private bloggere og småbedrifter. De redigerer ikke enkle HTML-filer og laster dem opp på nettet manuelt. I stedet bruker de et bestemt system for å håndtere dette og mange relaterte oppgaver i et dynamisk miljø.

Bloggere som driver med mote, matlaging eller bare sin egen hverdag, trenger selvfølgelig ikke å tenke på de tekniske eller organisatoriske aspektene ved å drive et nettsted.

CMS-et gjør mye av grovarbeidet for dem på en elegant måte, enten det er på deres eget hostede nettsted eller for eksempel på en bloggingplattform. CMS-et automatiserer og setter opp maler for en masse tekniske IT-greier, slik at bloggere, markedsførere og innholdsredaktører slipper å bry seg om det.

Praktisk talt alle som er til stede på nettet, har et CMS, og CMS-et utfører en rekke oppgaver, både synlige og usynlige.

La oss se på noen av de vanligste funksjonene som publiseringsløsningen tilbyr. Et CMS administrerer:

• Tekstredigering
• Metadata
• Design
• Generell sidehierarki
• URL-logikk
• Medier
• Publiseringsdatoer
• Brukerroller
• Innholdselementhierarki
• Historikkredigering og versjonskontroll
• Indeksering
• Søk
• Henting

Noen av disse funksjonene kan alle brukere endre, legge til eller fjerne, selv om de kanskje har begrenset teknisk kunnskap. Andre funksjoner er vanligvis forbeholdt nettredaktøren eller utviklerne.

Eksempler på den første gruppen er artikkeltekst, bilder, URL, publiseringsdato, plassering i hierarkiet og enkelte metafelt. Eksempler på den sistnevnte gruppen inkluderer malverk, design, sidehierarki, brukerroller og søk.

Alle disse funksjonene håndteres av CMS-et, noe som er en stor fordel og tidsbesparelse for alle produktive redaksjons- og markedsføringsteam.

Andre fordeler med CMS inkluderer:

• Redusert behov for koding fra bunnen av
• Enkelt å skape et helhetlig uttrykk
• Versjonskontroll
• Administrasjon av redigeringstillatelser

Ulemper kan inkludere:

• Begrenset eller ingen mulighet til å skape funksjonalitet som ikke var tenkt på i det opprinnelige CMS-et, slik som oppsett, nettapplikasjoner osv.
• Økt behov for spesialkompetanse og opplæring for innholdsprodusenter

Formålet med et CMS

Nå vet vi hva en publiseringsløsning er: Det er programvare for innholdsforvaltning med sikte på å vise det frem gjennom en digital kanal.

Formålet med et CMS kan sies å være mer eller mindre direkte nevnt i definisjonen vår. For ordens skyld og for å oppnå en mer fullstendig forståelse av begrepet, vil vi imidlertid diskutere hensikten med systemet i denne avsnittet.

Som vi har sett, kan du med et CMS legge inn alt slags innhold på et nettsted, enten det er enkel tekst, bilder og videoer, eller mer kompleks innhold i form av søkbare databaser, interaktive verktøy og avansert personalisering.

Hvilket innhold som skal plasseres hvor, hva som skal være synlig for hvem, når innholdet skal utløpe, og så videre, er spørsmål som løses av CMS-et.

Dermed er formålet med et CMS først og fremst innholdsforvaltning. Du og organisasjonen din bestemmer hva, når og hvor innholdet skal distribueres, i tillegg til hvordan i form av presentasjon.

Formålet er å levere informasjon effektivt til målgruppen din, i tillegg til å åpne opp for å motta informasjon tilbake fra de besøkende, slik som brukerpreferanser, atferd, utfylte skjemaer osv.

Dette leder oss til den helhetlige nettstedopplevelsen. Innholdet er én ting, men tjenestene, selvbetjeningsfunksjonene, URL-ene, designet, malverket og så videre er også en del av pakken.

Et nettsted er en integrasjon av innhold og presentasjon, og CMS-et har ansvaret for begge aspektene. Dette kan forekomme i ulik grad avhengig av typen CMS, som vi skal se nedenfor.

CMS-et kontrollerer direkte eller indirekte opplevelsen for både deg og de besøkende når det gjelder nettstedet ditt eller en relatert tjeneste. Formålet er å håndtere dette «møtestedet» effektivt og sikre at nødvendig kommunikasjon leveres begge veier.

Du vil kanskje hjelpe kundene dine eller målgruppen din, og kundene eller potensielle kunder ønsker å løse oppgaver som organisasjonen din og det digitale tilbudet ditt kan bistå med.

Forskjellen mellom CMS og digital opplevelsesplattform

Du har kanskje hørt begrepet «digitale opplevelser» i forbindelse med CMS. Forrester definerer en digital opplevelsesplattform (DXP) som «programvare for å administrere, levere og optimalisere opplevelser på en konsistent måte på tvers av ethvert digitalt berøringspunkt».

Uansett om en gitt kunde eller potensiell kunde samhandler med merkenavnet ditt digitalt via den gode, gamle datamaskinen, smarttelefonen, nettbrettet, bærbare dingser, beacons eller ansiktsgjenkjenningsteknologi, bør opplevelsen deres være helhetlig, forutsigbar og herlig.

Samtidig bør all denne informasjonen fra forskjellige kanaler analyseres for å gi teamet ditt en mer fullstendig forståelse av kundens identitet, intensjoner og følelser når de samhandler med merkevaren din. Det er her programvare for digitale opplevelser kommer inn i bildet.

En digital opplevelsesplattform (DXP) leverer en enhetlig opplevelse på tvers av ulike digitale kanaler. Samtidig bruker den analyse for å forstå de besøkende slik at den kan forbedre seg kontinuerlig.

En DXP kan hjelpe organisasjonen din med å samkjøre strategier, prosesser, team og teknologier mot en enda mer kundesentrert tilnærming.

Den viktigste forskjellen mellom et CMS og en DXP er omfanget av tjenesten. Et CMS kan for eksempel utstyre et nettsted med tredjeparts markedsføringsverktøy for SEO, analyse og markedsføringsautomatisering.

Et CMS kan også levere svært spesialisert funksjonalitet på nettstedet, som et velfungerende innholdsarkiv, avansert søk, netthandelsfunksjoner, brukerprofiler med filarkiv og mye mer.

En DXP kan derimot tilby integrasjon mellom flere forskjellige nettsteder og digitale berøringspunkter som alle må kobles sammen og kommunisere.

Om organisasjonen din trenger en DXP eller ikke, er et annet spørsmål. Er organisasjonen din medlem av et globalt nettverk med strenge retningslinjer for merkevare og risiko, kan en DXP være det rette valget for deg for å kontrollere og levere et bredt spekter av nettsteder og funksjonalitet over hele kloden.

Håndterer du litt enklere, men likevel avanserte prosjekter, er et agilt og fleksibelt CMS med mulighet for å integrere ulike verktøy sømløst sannsynligvis det beste alternativet.

Husk at et CMS er kjernen i enhver DXP, men alt avhenger av antall komplekse operasjoner og behov som organisasjonen din eller medlemsbedriftsnettverket ditt har.

Ulike typer CMS-er

Hvilke forskjellige typer CMS-er finnes det? På hvor mange måter kan du administrere og organisere opprettelse, endring og publisering av digitalt innhold for presentasjon på et nettsted?

Det viser seg at svaret er «mange».

Her vil vi gå gjennom noen av de vanligste og mest særegen formene for publiseringsløsninger som finnes.

Merk: Det finnes flere måter å klassifisere publiseringsløsninger på. Vi har valgt å klassifisere dem etter sentrale tekniske funksjoner som bestemmer forholdet mellom innhold og presentasjon.

On-premises vs. hostet

La oss si at organisasjonen din har bestemt seg for å utvide sin tilstedeværelse på nettet. Først og fremst ved å tilby et flott og fremtidsrettet nettsted som oppfyller behovene til kundene dine.

Det første du må bestemme deg for, er hvor du vil drifte det digitale tilbudet ditt. Skal det være on-premises eller hostet av et tredjepartselskap?

For de fleste koker dette grunnleggende spørsmålet vanligvis ned til alternativet «managed vs. hostet CMS». Et managed CMS leveres som en tjeneste. Alt det tekniske håndteres av leverandøren, som Shopify, Weebly eller WordPress.com.

Fordelene med et managed system er aktiv støtte, kontinuerlig utvikling og programvare som alltid er oppdatert. Ulempene inkluderer manglende kontroll over visse designelementer, funksjoner, innholdseierskap og en rekke andre faktorer.

Et hostet CMS er derimot en «frittstående» programvare som kan tas i bruk på din egen eller en tredjeparts server.

Den største fordeler med et hostet CMS er kontroll: Utviklerne dine kan få alt til å fungere på nettstedet ditt nøyaktig slik du ønsker. Med integrasjoner kan du også utvide funksjonaliteten. Ulempen er at du er overlatt til deg selv når det gjelder oppdatering, sikkerhet og design fra starten av. Dette er imidlertid sjelden et problem for profesjonelle organisasjoner.

De fleste organisasjoner og bedrifter vil stå overfor alternativet «on-premises vs. hostet», heller enn «managed vs. hostet». «On-premises» betyr at din egen organisasjon tar seg av driften av nettstedet og relaterte produkter, med fysiske servere på et sted du kontrollerer.

Fordelene vi så fra «hostet» vedvarer, med den ekstra bonusen av økt sikkerhet, datakontroll og en mer forutsigbar kostnadsplan. Ulemper inkluderer at en større del av organisasjonens ressurser settes av til drift, og en større andel risiko ved å drifte dataene selv.

Nå som du har hatt tid til å vurdere alternativene for hvordan og hvor du skal drifte publiseringsløsningen din, kan du begynne å se nærmere på ytterligere forskjeller.

Tradisjonelt CMS

Et tradisjonelt CMS er noe de fleste av oss har hørt om. I denne typen publiseringsløsning er det en tett sammenheng mellom funksjoner for redaktørene og funksjoner for utviklerne.

Redaktørene har vanligvis tilgang til full forhåndsvisning, landingssideredigering, URL-håndtering, detaljert tilgangskontroll, mediearkiv og mer.

Samtidig kan utviklerne kode, teste og rulle ut både redaksjonell funksjonalitet og sluttbrukerfunksjonalitet samlet, noe som gjøres mulig av en tett kobling mellom leveringslaget og CMS-et.

Funksjonssettet til slike CMS-er har vokst over tid, og mange kan betraktes som fullskala markedsføringssuiter. Dette har resultert i det vi diskuterte ovenfor: programvare for å administrere, levere og optimalisere opplevelser på en konsistent måte på tvers av alle digitale berøringspunkter (DXP).

Det er noen begrensninger eller ulemper med det tradisjonelle CMS-et. For eksempel gjør den tette sammenhengen mellom presentasjon og innhold tilstedeværelse i flere kanaler til et skikkelig slit.

Dette skyldes at en standard nettleser for stasjonære datamaskiner, en mobilapp og en IoT-enhet (Internet of Things) ikke alle kan lese og presentere innholdet når presentasjonslaget er laget utelukkende for nettet.

Hvis alt organisasjonen din trenger, er et enkelt nettsted, er det tradisjonelle CMS-et sannsynligvis det riktige alternativet for deg. Hvis du er på jakt etter på tvers-plattform-integrasjoner eller mer komplekse løsninger, er det her alternativet med headless CMS kommer inn i bildet.

Headless CMS

Fremveksten av mobilapper, sosiale medier, smartklokker, digital skilting, selvbetjeningsmaskiner, roboter og andre IoT-enheter endrer måten vi konsumerer digitalt innhold på.

Alle disse plattformene har unike egenskaper og ulike metoder for å vise og administrere innhold på. Så hvordan sørger du for at innholdet ditt presenteres riktig? Å lage én versjon for hver nødvendige plattform er tidkrevende, dyrt og ineffektivt.

Enter den såkalte «headless»-løsningen.

Hovedtanken bak et headless CMS er å skille presentasjon og innhold. «Headless» refererer til presentasjonslaget som hodet og innholdet som kroppen. Med headless CMS-er forblir innholdet det samme, mens hver enkelt klient (app, enhet, nettleser) har ansvaret for hvordan innholdet presenteres.

Utviklere koder vanligvis ikke i selve det headless CMS-et, men bruker i stedet et applikasjonsprogrammeringsgrensesnitt (API). Et API er et verktøy som gjør det mulig for to programvaretjenester å kommunisere og dele data med hverandre.

Ved å gjøre dette definerer det headless systemet alltid innholdsmodellen, og redaktørene kan begynne å legge til innhold. Samtidig konsumerer utviklerne innholdet gjennom et definert API, for eksempel for å presentere innholdet på en minibank eller til en app på smarttelefonen din.

Selv om fordelen med et headless CMS kan oppfattes som en «én størrelse passer alle»-tilnærming, finnes det begrensninger også her, særlig når det gjelder den første generasjonen leverandører. For hver nye klient og enhet må utvikleren håndtere lenkehåndtering, formateringsproblemer og malverk, mellomlagring (caching), tillatelser med mer.

For markedsførere og redaktører håndteres heller ikke forhåndsvisning av innholdet i selve CMS-et lenger, men på hvert enkelt relaterte API-prosjekt. Uten å gå seg altfor bort i tekniske diskusjoner, inkluderer andre ulemper manglende trestruktur, URL-håndtering, landingssidebygging med mer.

Hybrid CMS

Headless CMS har opplevd en vekst i popularitet de siste årene. Som en reaksjon på denne konkurransen har flere tradisjonelle CMS-leverandører lagt til nettbaserte innholds-API-er.

Dette har introdusert det såkalte hybride eller dekoblede CMS-et. Et hybrid CMS kommer med et presentasjonslag (hode), men det er valgfritt å bruke det. Dette betyr at du kan ha et standard nettsted, samtidig som du kontrollerer presentasjonsutdataene på andre kanaler.

Tilbudene fra leverandørene varierer, og det å ha et API er ikke tilstrekkelig i seg selv for å kvalifisere skikkelig som et hybrid CMS. Et hybrid CMS av høy kvalitet bør prioritere forvaltning av strukturert innhold fremfor sidebygging, og støtte rik mediehåndtering. Det bør også inkludere API-er med støtte for et bredt spekter av programmeringsspråk.

Når du skal velge hva slags CMS

Å velge riktig CMS betyr noe. Hva skal du da velge når du står overfor trikotomien tradisjonelt, headless og hybrid CMS?

• Velg et tradisjonelt CMS hvis du bare trenger et enkelt nettsted
• Velg et headless CMS hvis prosjektet ditt er rettet mot en app eller IoT med begrenset redaksjonelle krav
• Velg et hybrid eller neste generasjon headless CMS hvis prosjektet ditt involverer rikt webinnhold, URL-håndtering, omfattende redaksjonelle krav, spesielle driftsbehov og gjenbruk av innhold på tvers av prosjekter

Fortsatt forvirret? Kanskje dette forenklede flytskjemaet kan hjelpe deg med å navigere i det ukjente terrenget:

Du besitter nå grunnleggende kunnskap om konseptet publiseringsløsning (CMS).

Et CMS administrerer opprettelse, endring og publisering av digitalt innhold som dokumenter, bilder, videoer og annen funksjonalitet for visning på et nettsted.

Formålet med et CMS er innholdsforvaltning og å kontrollere den helhetlige nettstedopplevelsen for sluttbrukeren, og skiller seg fra en digital opplevelsesplattform (DXP) når det gjelder omfanget av tilbudet.

Det finnes tre hovedtyper av CMS-er, der det tradisjonelle er for enkle nettsteder, headless for apper og hybrid for en blanding.

Hva kan du nøyaktig gjøre med et CMS? La oss dykke ned i detaljene!

Metadata og SEO

Du har hatt det gøy med å fylle nettstedet ditt med engasjerende tekster og vakre bilder. Nå er det på tide å gå videre til de mer tekniske – og noen vil si «kjedelige» – oppgavene i de daglige CMS-rutinene.

Ja, du har en gjennomtenkt artikkel, ja, du har sterke visuelle elementer, men du har ennå ikke gjort innholdet ditt fullt ut synlig for søkemotorene. Programvaren som gjør det mulig for ekte mennesker å finne innholdet ditt i utgangspunktet.

Det er her metadata kommer inn i bildet. Metadata er felt og verdier som brukes til å tagge, kategorisere og beskrive innholdet ditt. Hvis CMS-et er biblioteket og innholdet ditt er bøkene, er metadata arkivsystemet og tilhørende etiketter.

Metadata hjelper til med følgende:

• Søk: Ved å legge til nøkkelord i metadataene kan brukere finne den aktuelle artikkelen, bildet eller PDF-en raskere og enklere.
• Distribusjon: Noen verdier indikerer når og hvor et gitt stykke innhold skal deles. Det avgjør oppførselen til visse applikasjoner som kan distribuere innholdet.
• Tilgang: Har du noen gang forsøkt å få tilgang til en bestemt fil, men blitt nektet? Dette skyldes restriksjoner som er satt av metadataene. De forteller systemet at det skal blokkere alle som ikke oppfyller et spesifikt krav.

Vanlige metadatafelt i et CMS inkluderer:

• Tittel
• Ingress/beskrivelse
• Publiseringsdato
• Forfatter
• URL
• Innholdstype

Noen avanserte CMS-er kan inneholde en hel haug flere felt som må fylles ut, som vanity-URL-er, omdirigeringsregler, av- og på-tider og mye mer. Hvorvidt denne mengden av felt er valgfri eller ikke, avhenger av hva utviklerne dine har bestemt, og hva som er mulig i CMS-et.

For deling i sosiale medier finnes det en standard som kalles Open Graph protocol, som «gjør det mulig for en hvilken som helst nettside å bli et rikt objekt i en sosial graf.» På folkelig språk betyr dette at du forteller plattformer for sosiale medier nøyaktig hvilken tittel, beskrivelse og bilde du vil skal vises på f.eks. Facebook eller LinkedIn.

Meningen med all denne taggingen og kategoriseringen er å optimalisere nettstedet ditt for søkemotorer, også kjent som søkemotoroptimalisering eller SEO. SEO er et komplekst felt hvor det er like mange eksperter som det er råd.

For å gjøre ting enda mer komplisert er den stadig utviklende naturen til SEO. Google er den mest berømte søkemotoren og endrer alltid sine søkealgoritmer. Årsaken skal angivelig være å gjøre søk bedre, mer presise og mer relevante for sluttbrukerne.

Markedsføringsautomasjonsverktøy

Evnen til å opprette nettsider i nettleseren imponerer sannluksynligvis hverken deg eller organisasjonen din slik den kanskje ville gjort i 1998. Selv om webinnholdsforvaltning er et absolutt krav, forventer brukere i dag noe mer av et CMS; de forventer at det også tilbyr en løsning for markedsføringsautomasjon.

Markedsføringsautomasjon er en felles betegnelse for verktøy som bidrar til å levere riktig budskap til riktig målgruppe til riktig tid. Og alt gjennom en automatisert prosess basert på brukeradferd og dataanalyse.

Du, markedsføreren, oppretter innholdet og definerer nøkkelparametere. Deretter slipper du den automatiserte maskinen løs på nettstedets besøkende, e-postlesere og brukere av sosiale medier. Hvis du har opprettet visuelt innhold, kan du dra nytte av TikTok for engasjement. Skaff deg noen TikTok-følgere for å utvide rekkevidden din.

I dag tilbyr noen CMS-er integrerte verktøy for markedsføringsautomasjon, mens andre tilbyr integrasjoner gjennom utvidelser eller apper. Noen CMS-er har ikke verktøy for markedsføringsautomasjon eller muligheten for dem i det hele tatt, og må tilpasses av utviklere.

Hvis markedsføringsautomasjon er relevant for organisasjonen din, må du sørge for at ethvert CMS du vurderer har evnen til å integrere med denne typen verktøy på en eller annen måte.

Verktøy for markedsføringsautomasjon gir deg muligheten til å utføre følgende funksjoner, blant andre:

• Effektiv levering av meldinger og oppfølging av leads
• A/B-testing
• Personalisering
• Analytiske verktøy
• Innholdsmarkedsføring

Design

Designet eller presentasjonen er nært knyttet til CMS-et ditt. Men som vi så under «headless CMS» ovenfor, er det mulig å separere presentasjon og innhold.

Målet er å sende redaksjonelt innhold til andre plattformer og enheter der tradisjonelle visuelle elementer for skrivebord eller mobil nettleser ikke gjelder.

For våre formål her vil vi snakke om designet og innholdet sammen. CMS-et utfører både formen og stilen, spesielt hvis det er et tradisjonelt eller neste generasjons headless CMS hvor du kan velge når og hvor det skal gjøres headless.

Hva betyr dette? Er ikke designet på nettstedet kontrollert av CSS og HTML uansett?

En ting er å dekorere skyskraperen din med fine fronter, detaljer og berøringer, men hva avgjør bygningens blåkopier og støttebjelker?

Arkitekturen.

Og arkitekturen i vår digitale markedsføringsverden er databasen og selve CMS-et. Den legger ut retningslinjene og det grunnleggende, hvorpå HTML (strukturen) og CSS (layouten) legger til noen nødvendige avsluttende detaljer. Det samme prinsippet gjelder for responsivt og adaptivt design.

Backend påvirker frontend

Når du vurderer et CMS, bør du være oppmerksom på strukturen og hierarkiet til innholdet i backend.

For eksempel er det i WordPress et strengt skille mellom det som er kjent som «innlegg» («posts») og «sider» («pages»). Disse to forskjellige innholdstypene avgjør visse væremåter, plasseringer og funksjonalitet på det ferdige nettstedet.

I Adobe Experience Manager kan du strukturere hele nettstedet ditt i en tremeny, bestemme ulike innholdstyper, som «temaside», «tjenesteside», «nyhetsartikkel» osv. Deretter kan du håndheve regler for hvilke typer sider som har lov til å vises hvor på det live nettstedet.

Husk på hvordan de tilsynelatende interne reglene i et CMS angående strukturering av sider og filer mest sannsynlig har en direkte innvirkning på hvordan du kan sette opp nettstedet ditt, og hvordan det ser ut.

Hvis du er på utkikk etter et nytt CMS for organisasjonen din, må du sørge for at det gir deg fleksibilitet i hvordan du setter opp hele nettstedet. Dette inkluderer full kontroll over trestrukturen, kategoriorganiseringen, tildelingen av innholdstyper og så videre.

Dette løser flere oppgaver for deg. Det gir også innholdsteamet ditt en sandkasse med retningslinjer for hvilke elementer designet ditt bør prioritere for å fremheve det viktigste innholdet ditt, tilbudene dine osv.

Malstøtte for endrede design

En mal er en rask og enkel måte å lage en profesjonell CV i et tekstredigeringsprogram eller en nydelig lysbildeserie i et presentasjonsprogram. Malbruk gjelder også for nettsider.

Ditt valgte CMS bør tilby en måte å lage maler for hele sider på, i tillegg til individuelle moduler eller elementer på tvers av sider.

Maler gjør det enkelt å endre utseendet på nettstedet ditt, men også å implementere ny funksjonalitet raskt og enkelt. Dette skyldes at du bare trenger å endre én parameter i stedet for å kopiere og lime inn lange linjer med HTML.

Å sette opp og kvalitetssikre forskjellige maler er en måte å gjøre innholdet ditt i samsvar med både merkevareretningslinjer og tekniske krav.

Støtte for malverk gjør driften av et nettsted ikke bare fleksibel for nettstedet som helhet, men også for alle de modulære delene. Disse kan du bruke og gjenbruke på tvers av nettstedet i løpet av få sekunder.

En rask sjekkliste for designvurderinger bør være på sin plass. Et designvennlig CMS bør gjøre deg i stand til å:

• Enkelt frikoble presentasjonslaget (designet) fra innholdslaget
• Sette opp en hierarkisk nettstedsstruktur som kan fungere som en blåkopier eller støttebjelker for det live nettstedet
• Legge til fleksibilitet for utviklerne, slik at de kan innovere og legge til kode uten å ødelegge presentasjonsdelen av nettstedet eller appen
• Støtte malverk for enkle endringer og modulær virkemåte for designet

Designsystem

Med inntoget av smartere og mer fleksibel teknologi har CMS-verdenen opplevd en oppblomstring av designsystemer. Et designsystem kan sikre merkevaresamsvar på tvers av digitale opplevelser, og kan defineres som følger:

Et designsystem opprettholder på ett sted de visuelle og funksjonelle elementer til en organisasjon, og oppfyller dens merkevareprinsipper gjennom design, realisering og utvikling av produkter og tjenester.

Et designsystem er mer enn et merkevarelager. Det er et system med både retningslinjer og ferdiglaget kode for å levere det visuelle og funksjonalitet inn i dine digitale opplevelser gjennom et CMS.

Innholdet i et designsystem kan brukes av redaktørene, designerne og utviklerne dine i ulike, men merkevarekonforme forhåndsinnstillinger på nettstedet eller appen din.

Designsystemet kan inkludere følgende innhold:

• Organisasjonsprinsipper: De mest abstrakte elementene. Detaljerer visjon, formål, verdier og tonefall.
• Designprinsipper: Mer konkrete. Inkluderer designformål, merkevareidentitet, stilguide og språkretningslinjer. Tenk farger, skrifttyper, former, ikoner, bilder og lyder.
• Komponenter og mønstre: Byggeklossene. Komponenter kan inkludere knapper, kort, tekstfelt og fremdriftslinjer, mens mønstre spesifiserer hvordan man bruker komponenter konsekvent.

Det finnes ulike typer designsystemer, som varierer fra strenge og sentraliserte til løse og distribuerte:

• Strenge eller løse: Omfattende dokumentasjon vs. et generelt rammeverk med mer rom for eksperimentering.
• Modulære eller integrerte: Utskiftbare og gjenbrukbare deler for rask skalering vs. faste deler for stabilitet.
• Sentraliserte eller distribuerte: Ett team med ansvar vs. flere fagfolk som bidrar fra flere team.

Hvorvidt organisasjonen din bør bruke et designsystem med CMS-et ditt, avhenger av dine spesifikke behov. Må du for eksempel ha et fast grep om merkevaren din, trenger du raskt å skalere designelementer, eller er den enkle og tradisjonelle CMS-tilnærmingen tilstrekkelig?

Generelt nettstedshierarki

Vi nevnte at rekkefølgen på nettsider i et CMS er avgjørende for utseendet og følelsen til det ferdige produktet ditt. Design er én ting, og et annet viktig aspekt ved et CMS sin kontroll over nettstedshierarkiet er for din egen bekvemmelighet: Orden.

De fleste liker sannsynligvis å holde en viss orden og ryddighet i hjemmene sine, hodene sine og sine daglige gjøremål. Hvorfor skulle verktøyet for dine digitale opplevelser være noe annerledes?

Ethvert flott CMS holder innholdet ditt i ordnede former, med et tydelig hierarki av mapper og filer som gir deg en følelse av kontekst. Hensikten med dette er å gjøre det mulig for deg og teamet ditt å enkelt bla gjennom og hente publisert og upublisert innhold. I tillegg til å få et helhetsbilde av hvilken oppgave nettstedet ditt er ment å fylle.

Hvordan du organiserer nettstedet ditt er helt opp til organisasjonen din. Men det valgte CMS-et ditt bør i det minste ha følgende funksjonalitet i nettstedshierarkiet:

• Et panel for en fullstendig oversikt over nettstedets elementer (sider, bilder, fragmenter osv.)
• Enkel navigering i nevnte oversikt
• Sorteringsalternativer for et bredt spekter av preferanser, f.eks. manuell sortering, alfabetisk og kronologisk
• Nært tilknyttet en verktøylinje som lar deg enkelt søke, opprette, slette, redigere, duplisere, flytte og forhåndsvise innhold

Finnes det noen beste praksis når det gjelder å organisere innholdet ditt innenfor nettstedshierarkiet? Alt avhenger av hva du trenger.

Hvis CMS-et ditt har en flott søkefunksjon eller til og med et enterprise-søk, er det ikke sikkert at stram hierarkisk organisering for nettlesing er nødvendig.

Noen CMS-er bruker en separat, siloaktig metode for opplasting, lagring og henting av bilder i det samme komplekset av mapper og undermapper. Igjen gjør en god søkefunksjon dette unødvendig.

Hvis du bare ønsker å få en oversikt over nettstedets tilbud, vil kanskje et XML-sidekart gjøre jobben i stedet for rigid strukturering i CMS-et.

URL-logikk

En annen finurlig funksjon du kan kontrollere fullt ut med et CMS, er URL-logikken. Dette er nøye knyttet til nettstedshierarkiet, ettersom du i de fleste CMS-er må sette opp sider og undersider på samme måte som de vil vises i adresselinjen, også kjent som URL-en.

La oss for eksempel si at du jobber for en bank som har en temaside om investering, med undersider om aksjer, obligasjoner og verdipapirfond.

Temasiden om investering har adressen «example-bank.com/investing», mens de andre tre har henholdsvis «example-bank.com/investing/stocks», «example-bank.com/investing/bonds» og «example-bank.com/investing/mutual-funds».

For å oppnå denne logikken under normale omstendigheter, må du plassere alle de tre undersidene under temasiden i CMS-nettstedshierarkiet:

• example-bank.com
  • investing
    • stocks
    • bonds
    • mutual-funds

Vanity-URL

Når du jobber med URL-er i et CMS, kan du også ha hørt om noe som kalles vanity-URL-er. Hva er det?

Kort sagt er en vanity-URL en unik nettadresse som er forkortet for å passe til et markedsførings- eller brukervennlighetsformål. Et eksempel kan være som følger:

• Original URL: example-bank.com/blog/how-invest-your-money-financial-sector
• Vanity-URL: example-bank.com/investing

Formålet er å gjøre URL-er for viktige sider kortere og enklere å huske, samtidig som den opprinnelige nettstedstrukturen holdes intakt. Vanity-URL-en omdirigerer til den opprinnelige URL-en, men ofte kan du velge å beholde eller forkaste den nye og kortere URL-en i adresselinjen.

Headless CMS har tatt verden med storm. Det har begeistret utviklere over hele verden ved å frigjøre dem fra monolittiske lenker og la dem jobbe med den frontenden de ønsker.

Men hva er egentlig et headless CMS? Hvorfor bør du bruke det? Hvilke bruksområder finnes? Og er det noen utfordringer du bør være oppmerksom på? Lær mer om disse og mange andre temaer i denne komplette guiden til headless CMS!

Definisjon av headless CMS

Før vi går i detalj om headless, er det lurt å forstå hva vi snakker om på et grunnleggende nivå. La oss begynne med en foreløpig definisjon, slik at vi har et felles utgangspunkt:

Et headless CMS er et programvaresystem som organiserer digitalt innhold ved å skille det fra presentasjonen, slik at innholdet kan gjenbrukes i alle kanaler.

La oss nå utvide denne definisjonen:

Et headless CMS er et programvaresystem som organiserer digitalt innhold ved å skille innholdslaget fra presentasjonslaget. Dette lar redaktører lage innhold som sendes til flere kanaler via API-er, og lar utviklere bygge frontender og klienter med rammeverket de foretrekker.

Hva mener vi når vi snakker om lag? Se for deg at du redigerer en nettside i et tradisjonelt CMS. Du endrer tekst, bilder, oppsett og mer avanserte komponenter i et visuelt redigeringsverktøy. Selve innholdet og hvordan det vises, er tett knyttet sammen i ett lag.

Selv om moderne nettsteder bygget med et tradisjonelt CMS har responsivt design og kan tilpasse presentasjonen til ulike skjermstørrelser, har de fortsatt bare ett lag. Prøv å vise en bestemt side på smartklokken din eller automatisk gjenbruke et tekstfelt fra et sideoppsett på et annet nettsted. Det går ikke.

Det er her skillet mellom innhold og presentasjon kommer til sin rett. Ved å holde innholdet i et eget lag og presentasjonen i sitt eget lag blir følgende mulig:

• Innhold kan struktureres, kategoriseres i typer og behandles logisk og forutsigbart
• Det strukturerte innholdet kan gjenbrukes i ulike kanaler gjennom et API
• Frontendutviklere kan bruke verktøyene og rammeverkene de foretrekker, til å presentere innholdet på ulike klienter (kanaler)
• Innholdet har dermed én kilde, der du kan opprette, redigere og vedlikeholde det, mens presentasjonen har ubegrenset med kanaler: fra kroppsnær teknologi og IoT til nett- og stemmegrensesnitt

Hvorfor kalles det «headless»?

Når presentasjonslaget (hodet) skilles fra innholdslaget (kroppen), får du en hodeløs kropp som er klar til å distribueres til flere forskjellige «hoder».

Disse hodene er kanaler som nettsteder, mobilapper, smartklokker, TV-skjermer, digitale skiltsystemer, stemmeassistenter eller til og med kaffemaskinen din. Et «hodeløst» CMS er i virkeligheten et CMS med mange hoder, som den mytiske hydraen.

En annen forklaring på headless kan oppsummeres slik: Et headless CMS er i bunn og grunn en database med et API (et API er en verktøykasse som får ulike plattformer til å snakke sammen).

[youtube url="https://www.youtube.com/watch?v=dhksx6rlM1Y"/]

Bakgrunn

Ideen bak headless CMS er egentlig ikke ny. Å skille innhold (data) fra presentasjon har vært beste praksis blant utviklere i flere tiår. Den norske informatikeren Trygve Reenskaug innførte faktisk begrepet «model view controller» (MVC) allerede i 1979.

I vår sammenheng fungerer et headless CMS som en spesialisert database. Det har et grensesnitt som lar redaktører opprette og videreutvikle innholdet sitt. Dette tilsvarer «modellen» i MVC-konseptet.

Headless lar utviklere bygge klienter med favorittverktøyene sine. Klienten kobler seg til headless-API-et, henter innholdet den trenger, og tar seg av presentasjonen («view» og «controller») lokalt.

Nesten alle de tidlige publiseringssystemene var dermed «headless» i denne betydningen. Disse banebrytende systemene fokuserte på redigering og publisering av skjemabasert innhold, ofte i form av nyhetsartikler.

Høres det kjent ut? Det er likevel noen vesentlige forskjeller mellom den gang og nå:

• Klienten var som regel et nettsted som hentet og listet opp artikler
• Både klienten og CMS-et befant seg bak den samme brannmuren
• I noen løsninger var «API-et» ganske enkelt databasen. Løsninger med et API var sjelden eksponert på det åpne nettet
• Data ble utvekslet gjennom XML eller binære formater, fremfor JSON

Etter hvert som publiseringsløsningene modnet og kundenes krav ble mer komplekse, vokste løsninger for innholdsforvaltning på nett (WCM) og digitale opplevelsesplattformer (DXP) frem.

Disse monolittiske gigantene tilbød et rikere funksjonsutvalg for å tilfredsstille redaktørene, som visuell redigering og markedsføringsverktøy. Utviklerne fikk også en enklere, men mer begrenset tilnærming til utvikling.

Dette fungerte fint i en verden der nettlesere på stasjonære og bærbare datamaskiner dominerte. Men teknologien står aldri stille. Vi har sett en oppblomstring av tjenester utviklet med skyen som utgangspunkt, sammen med fremveksten av omnikanal gjennom mobiltelefoner, IoT, kroppsnær teknologi og frontendrammeverk med funksjonsrike nettklienter. Dette fikk både etablerte og nye CMS-leverandører til å se behovet for en headless-tilnærming.

Som følge av dette har WCM- og DXP-leverandører lagt til nettbaserte innholds-API-er for å møte konkurransen fra rene headless-leverandører.

Headless CMS sammenlignet med tradisjonelle CMS-er

Tradisjonelt CMS

Hva er den grunnleggende forskjellen mellom et tradisjonelt CMS og et headless CMS? Enkelt sagt: Et tradisjonelt CMS opprettholder en tett kobling mellom innhold og presentasjon, mens headless bryter denne koblingen.

Redaktørene har tilgang til full forhåndsvisning, redigering av landingssider, URL-håndtering, detaljert tilgangskontroll og et mediearkiv. Samtidig kan utviklerne kode, teste og produksjonssette funksjonalitet for både redaktører og sluttbrukere samlet. Dette er mulig takket være en tett kobling mellom leveringslaget og CMS-et.

En ulempe med den tette koblingen i tradisjonelle publiseringsløsninger er at den gjør tilstedeværelse i flere kanaler utfordrende. En vanlig nettleser på en datamaskin, en mobilapp, kroppsnær teknologi, digitale skilt og en enhet i tingenes internett (IoT) kan ikke lese og presentere innholdet på like vilkår når presentasjonslaget er laget utelukkende for nettet.

Det er her headless CMS kommer inn i bildet.

Headless CMS

Fremveksten av mobilapper, sosiale medier, smartklokker, digitale skilt, selvbetjeningsautomater, roboter og utallige IoT-enheter endrer måten vi bruker digitalt innhold på. Alle disse plattformene har unike egenskaper og ulike metoder for å presentere og håndtere innhold.

Det er nettopp utfordringen med levering til flere kanaler, sammen med fremveksten av funksjonsrike frontendrammeverk som begeistrer utviklerne, et headless CMS løser.

Med et headless CMS forblir det strukturerte innholdet det samme, mens hver klient, enten det er en app, en enhet eller en nettleser, har ansvaret for hvordan innholdet presenteres. Utviklere koder vanligvis ikke i selve headless-CMS-et, men bruker API-et og skriver kode i et annet rammeverk de selv velger.

Pendelutviklingen innen CMS

Publiseringsløsningenes historie veksler mellom tradisjonelle løsninger og headless-løsninger. Det kan sammenlignes med en bordtenniskamp der ballen slås fra den ene banehalvdelen til den andre. Der den ene banehalvdelen tilfredsstiller én gruppe ansatte i virksomheten, skuffer den en annen gruppe kolleger. 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øringspakker og digitale opplevelsesplattformer, kan redaktøren jobbe godt i et brukervennlig redaksjonelt miljø. Funksjonene omfatter visuell sideredigering, trestrukturer og kontekstuell forhåndsvisning. Utvikleren er derimot tvunget til å jobbe innenfor et fastlagt system der CMS-et og frontenden er tett knyttet sammen.

Med fremveksten av første generasjons headless CMS er rollene byttet om. Her er frontenden skilt fra CMS-et, slik at utvikleren kan jobbe med verktøyene og rammeverkene vedkommende foretrekker. Redaktøren må derimot streve med skjemabasert innhold, med begrensede muligheter for visuell sideredigering, forhåndsvisning og URL-håndtering.

Alle headless CMS-er er ikke like!

Headless CMS er ingen ensartet kategori. Noen er «første generasjon» eller «skybaserte fra grunnen av», noe som betyr at de bare er tilgjengelige som skytjenester og ikke som programvare. «Headless som en tjeneste» forenkler skalering, overvåking, sikkerhetskopiering og mer – men på bekostning av fleksibilitet og kontroll.

Andre headless-publiseringsløsninger kan betegnes som «neste generasjon» eller «hybride», men hva innebærer det?

Neste generasjons headless CMS – composable CMS

Som nevnt er et «rent» headless CMS mer eller mindre en database med et API og et redigeringsgrensesnitt. Med API-et kan du levere innhold eller innholdsutdrag til ulike klienter, som stemmeassistenter, aktivitetsarmbånd, smartklokker, AR-briller eller som en del av tredjeparters nettsteder.

Et headless CMS av første generasjon vil sannsynligvis gi deg minimal hjelp til å bygge komplette nettsteder, siden koblingen mellom innhold og presentasjon er brutt fullstendig.

De fleste virksomheter trenger først og fremst nettsteder, men første generasjons headless fokuserer ikke på innholdsdrevne nettsteder. Det betyr at virksomheten din kan måtte holde flere systemer i gang for å håndtere strukturert innhold, sidekomposisjon, URL-er og alt annet som kreves.

For å løse behovet for flere systemer kommer neste generasjons headless CMS inn i bildet. Et headless CMS av neste generasjon kan strukturere innhold og komponere nettsteder – i ett og samme system.

Alle de smidige headless-funksjonene er på plass, men med ekstra (og valgfri!) funksjonalitet for visuell sideredigering, forhåndsvisning, hierarkiske trestrukturer, URL- og SEO-håndtering, sidemaler, detaljerte tilgangsrettigheter, backendintegrasjoner og API-tilpasning.

Et slikt CMS kalles også et composable CMS, siden det lar deg samordne eller styre API-ene og de digitale opplevelsene dine fra selve CMS-et. Her er utviklerne fornøyde med den frikoblede frontenden, mens redaktørene er fornøyde med et brukervennlig og visuelt orientert redaksjonelt miljø som også kan håndtere integrasjoner og API-er.

Sammenligning side om side

Innholdsforvaltning

De overordnede aspektene, fra grunnleggende struktur til sentrale muligheter og funksjoner. 

Nett og presentasjon

Utseende og brukeropplevelse, og hvordan de tre alternativene håndterer presentasjon, forhåndsvisning og URL-er.

Drift

De mest tekniske aspektene til slutt, med vekt på programvare, sky, CDN-er og andre forhold.

Fordeler

Sammenlignet med et tradisjonelt CMS har et headless CMS flere fordeler. Dette skyldes delvis at ansvaret for brukeropplevelsen flyttes til klienten, som en nettleser eller en app.

Men la oss først se på hvorfor headless CMS i økende grad blir den foretrukne teknologien blant publiseringsløsninger.

Hvorfor headless er populært

Et tradisjonelt CMS kan være frustrerende for utviklere. Den tette koblingen mellom innhold og presentasjon gjør det vanskelig, om ikke direkte umulig, for en utvikler å lage løsninger på tvers av kanaler som gjenbruker det samme innholdet. Å bygge separate siloløsninger for hver kanal øker utviklerens unødvendige arbeidsmengde ytterligere.

Tradisjonelle publiseringsløsninger kan også ha lite hensiktsmessige API-er som er lagt til i etterkant, og de er i overveiende grad sideorienterte.

En tredje årsak til at headless vokser, er fremveksten av funksjonsrike frontendrammeverk. Hvorfor skal en utvikler ta bryet med å lære seg et proprietært og sannsynligvis tungvint CMS-rammeverk? Særlig når det er fritt frem å velge mellom Next.js, Nuxt, SvelteKit, React, Vue og alle de andre alternativene i frontendverdenen?

Med et headless CMS jobber utviklere med strukturert innhold. Dette er innhold som er organisert på en forutsigbar måte og klassifisert med metadata. Med fremveksten av omnikanal jobber utviklere nå med data fremfor HTML og sideoppsett – og gjenbruker dem der det er behov.

Men ulike enheter og ulike behov er ikke hele forklaringen. Som nevnt har innovasjon innen frontendrammeverk også banet vei for headless ved å legge til rette for funksjonsrike nettopplevelser.

Tenk bare på Gmail, Facebook eller nettbanken din. Funksjonaliteten i disse tjenestene går utover det klassiske nettstedet og fungerer som en applikasjon med raske lastetider og spesialisert drift.

Funksjonaliteten i mange moderne og funksjonsrike nettopplevelser kodes i nettleseren ved hjelp av utviklerens foretrukne frontendrammeverk. Her egner headless CMS seg spesielt godt til å levere innhold.

Et headless CMS gjør innhold som hjelpetekster, infobokser, etiketter og annet redaksjonelt innhold fra en sentral database tilgjengelig for ulike kanaler og frontendrammeverk.

Andre fordeler

I tillegg til fordelene vi allerede har omtalt, finnes det flere andre:

• Fleksibel utvikling – Headless er uavhengig av frontend og lar utviklere bygge nettsteder, apper og løsninger på ulike plattformer med programmeringsspråkene de foretrekker.
• Bedre opplevelser – Ved å frigjøre frontendutviklere fra backendstrukturene får de mer tid og energi til å bygge rikere og mer responsive digitale opplevelser.
• Økt hastighet – Å flytte presentasjonen til klienten effektiviserer backendprosessene og gjør at applikasjoner kan kjøre raskere enn før.
• Lavere driftskostnader – Selv om dette avhenger av kundens valg, kompleksiteten i det konkrete oppsettet og leverandørens prismodell, er headless i utgangspunktet rimeligere enn et tradisjonelt CMS.
• Kortere tid til markedet – Skillet mellom frontend og backend forkorter utviklingstiden frem mot lansering, men det samme prinsippet gjelder innholdsteamet: Oppmerksomheten rettes nå mot selve innholdet og ikke hvordan det vil se ut i ulike frontendlag, samtidig som én kilde muliggjør gjenbruk.
• Brukervennlighet – Siden et headless CMS i bunn og grunn er en database, kan det gi innholdsskaperen færre valg i form av brytere og skyveknapper. Igjen er det selve innholdet som står i sentrum, fremfor en overflod av presentasjonsmuligheter.
• Fleksibilitet – Headless gir utviklere fleksible API-er og muligheten til å hente ut bestemte data til klientene de foretrekker.
• Skalerbarhet i skyen – De fleste headless-systemer er klargjort for skyen. Det betyr at skalering i takt med langsiktig vekst og trafikktopper kan håndteres gjennom flere miljøer, klynger, CDN og annen moderne teknologi.
• Systemsikkerhet – Leverandøren er ansvarlig for å håndtere sikkerhetsproblemer. API-et gir dessuten ofte bare lesetilgang og kan ligge bak flere lag med kode. Til slutt ligger administrasjonsgrensesnittet til et headless CMS ofte på en annen server og et annet domene enn hovedløsningen.

Fremtidssikker teknologi

Som vi har sett, gjør egenskapene til headless CMS det svært godt egnet til å fremtidssikre virksomhetens teknologi. Derfor er det en sentral komponent i MACH Alliance, som «presenterer og fremmer et åpent økosystem av virksomhetsteknologi med de beste løsningene innen hvert område». «MACH» står for «Mikrotjenestebasert, API først, Cloud-native SaaS og Headless».

Alle elementene i MACH Alliance henger sammen, men headless er spesielt relevant for API først, sky og selvfølgelig headless i seg selv. Med et ekte headless CMS er all funksjonalitet tilgjengelig gjennom et API, og det kan drives helt i skyen, med fordeler innen lagring, drift, skalering og oppgradering.

Men det virkelig verdifulle for utviklere er at frontendpresentasjonen er frikoblet fra backendlogikken. De virkelig fremtidssikre headless-leverandørene er uavhengige av rammeverk og API-er. Det lar utviklerne bygge løsninger med akkurat de verktøyene de foretrekker.

Strukturert innhold

Innhold er en grunnleggende byggestein i headless CMS. Utover at løsningen beskrives som en «database + API», hva er spesielt med innholdet headless-systemer håndterer?

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

Innholdstyper

At innhold er «strukturert», betyr at hvert innholdselement av samme type har den samme strukturen (selvsagt!). Alle har de samme feltene og den samme logikken. Dermed kan alle innholdselementer av samme type behandles på en ensartet og forutsigbar måte i ulike situasjoner.

Eksempler på innholdstyper er artikkel, side, person, kundehistorie, oppskrift, bil, bok, kurs, video, kontor, produkt, arrangement og lyd.

Eksempel på strukturert innhold

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

Siden hvert innholdselement har de samme feltene, kan CMS-et nå behandle dem samlet. La oss si at du vil vise en liste over de nyeste blogginnleggene dine. CMS-et kan da hente data fra feltene for tittel, bilde og ingress, og bruke datofeltet til å sortere innleggene kronologisk.

I dette enkle eksemplet har redaktørene laget blogginnhold én gang, som deretter gjenbrukes i en bloggliste et annet sted på nettstedet. Dette er grunnprinsippet bak skalering, gjenbruk og gjentatt bruk av innhold i et headless CMS.

Et ekte headless CMS støtter ikke bare innholdstyper. De er en forutsetning for at det skal kunne eksistere.

Bilde- og mediehåndtering

Som nevnt ovenfor skal bilder og andre mediefiler også betraktes som innholdstyper i et headless CMS med fullverdig støtte for strukturert innhold. Hvorfor? Fordi prinsippet om gjenbruk gjelder like mye for bilder, videoer og lydfiler som for alle andre innholdstyper.

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

Metadata og bruksområder er én ting. Et annet viktig aspekt ved bilde- og mediehåndtering er de innebygde verktøyene i et gitt headless CMS. Som på mange andre områder er headless CMS-er også forskjellige på dette punktet.

Innholdsredaktører ønsker seg bilderedigering med funksjoner som beskjæring og angivelse av fokuspunkt. Det gjør det enklere å formidle akkurat det de ønsker, uten å bruke tredjepartsverktøy.

Utviklere har på sin side bilde-API-er som lar dem opprette URL-er til ulike bildestørrelser, bruke filtre og så videre.

Undersøk om slike redigeringsfunksjoner finnes i headless-CMS-ene du vurderer.

Blokkredigering

Selv om det er nokså enkelt å forstå rollen til felt og innholdstyper når det gjelder strukturert innhold, blir det litt mer komplisert med blokkredigering. Mange virksomheter ønsker å kunne lage komplekst innhold som fortsatt er godt strukturert, og det er her blokkredigering kommer inn i bildet.

Et headless CMS som støtter blokkredigering, gjør det mulig å legge til eller fjerne felt i et såkalt «sett» i en gitt innholdstype. Dette kan for eksempel være en artikkel der redaktørene kan sette inn blokker for riktekst, bilder, innebygde videoer, kontaktpunkter, tabeller eller andre behov de måtte ha.

Tanken er å gjenskape muligheten for rikt innhold og kontroller som ligner dem i en sidebygger, samtidig som innholdet holdes godt strukturert for gjenbruk. Dette passer godt med headless-verdenen.

Støtte til innholdsproduksjonen

En vanlig bekymring blant innholdsredaktører er at headless CMS gir dem dårligere tilgang til smidige, visuelle verktøy for å opprette, redigere og vedlikeholde innhold. Å gå fra trestrukturer, WYSIWYG-sidebyggere og markedsføringspakker til en «database og et API» høres ikke spesielt fristende ut.

Det stemmer at enkelte «rene» headless-leverandører har lite å tilby markedsavdelingen. Mange headless-leverandører tilbyr imidlertid funksjoner som støtter innholdsproduksjonen. Dette er det vi kaller «neste generasjons headless CMS».

Samarbeid

Samarbeidsverktøy omfatter muligheter til å kommunisere, tildele oppgaver og se hva kollegene dine har gjort i CMS-et. Noen av disse funksjonene kan enkelt håndteres av tredjepartstjenester som Slack og Google Docs. Men hvis teamet ditt ønsker en tett integrert opplevelse for redaksjonelt arbeid og samarbeid, bør du undersøke hvor godt aktuelle headless-løsninger støtter dette.

Arbeidsflyt

Arbeidsflyt er en annen funksjon som kan forsvinne når innholdsproduksjonen bare foregår i en database. En arbeidsflyt er imidlertid et uvurderlig verktøy for det digitale teamet, slik at de enkelt kan se statusen til hvert innholdselement.

Er det et utkast, er det klart til publisering, er det sendt til gjennomgang, eller er det allerede publisert og alt i orden? Om slik informasjon vises som visuelle signaler eller tekststatuser, kan variere mye fra leverandør til leverandør. Som alltid bør du teste alle aktuelle løsninger grundig.

Versjonshistorikk

Alle som redigerer Wikipedia, vet at muligheten til å se en artikkels versjonshistorikk og sammenligne endringer er både nyttig og tidsbesparende. Å raskt kunne identifisere endringer og gå frem eller tilbake mellom versjoner av et innholdselement er avgjørende for en smidig og effektiv redaksjonell prosess. Denne funksjonen er et must for innholdsteamet.

Content operations

Alle disse funksjonene som støtter en bedre innholdsproduksjon, samles egentlig i ett prinsipp: content operations, eller ContentOps. Dette er et prinsipp for innholdsproduksjon som beskriver steget mellom strategi og levering, og som knytter sammen mennesker, prosesser og teknologi. ContentOps tar produksjon og forvaltning av innhold like alvorlig som utviklere tar det å skrive og gjennomgå kode.

ContentOps-prinsippet kan oppsummeres slik: Hvor godt klarer du å samordne mennesker, prosesser og teknologi i virksomheten for å planlegge, lage og vedlikeholde innhold best mulig over tid?

Og hvordan passer headless CMS inn i dette? Det er et avgjørende element i teknologikategorien. Det må spille sammen med faktorene som bidrar til å levere fremragende innhold og tjenester til målgruppen din. Disse omfatter tekstforfattere, fageksperter, interessenter, strategi, arbeidsmøter, skriving, filming, gjennomgang, CRM og automatisering av markedsføring.

API-er

Nå som vi har gått gjennom den første delen av «headless-ligningen» [database + API], er det på tide å rette oppmerksomheten mot den andre delen: API. Et applikasjonsprogrammeringsgrensesnitt er et datagrensesnitt som lar ulike systemer kommunisere med hverandre.

Enkelt forklart er et API bindeleddet mellom innholdet ditt (databasen) og enheten eller plattformen som viser det (klienten). Informasjon om API-et er gjerne det utviklere er mest opptatt av i et headless CMS. Det sier seg selv: API-et må være svært godt og fleksibelt for å imponere.

La oss se på noen av de populære API-teknologiene.

GraphQL

GraphQL er et spørrespråk for API-er utviklet av Facebook. Med sterk typing og innebygd dokumentasjon lar det klientutviklere be om akkurat den informasjonen de trenger, med så få forespørsler som mulig. Det passer perfekt for headless CMS.

Med andre ord lar et godt headless-API basert på GraphQL deg få umiddelbar tilgang til dataene dine fra enhver enhet eller klient. Det skal gi deg akkurat det du trenger, og ikke noe mer, med én enkelt spørring. Et slikt API kan til og med tilpasses og utvides for å oppfylle dine spesifikke krav, dersom headless-CMS-et ditt støtter dette.

REST

REST brukes i hele programvarebransjen og er et bredt akseptert sett med retningslinjer for å lage tilstandsløse, pålitelige nett-API-er. Et nett-API som følger REST-begrensningene, omtales uformelt som RESTful. RESTful-nett-API-er bygger vanligvis løst på HTTP-metoder for å få tilgang til ressurser via URL-kodede parametere, og bruker JSON eller XML til å overføre data.

Høres noen av disse nøkkelordene kjente ut, som skalerbarhet, uavhengig produksjonssetting, nett-API-er, JSON og XML? Det er fordi RESTful-API-er er nok en nyttig teknologi som legger til rette for gode headless-publiseringsløsninger.

Ulempen med REST sammenlignet med GraphQL er at frontend- og backendutviklerne må samarbeide om å implementere akkurat det API-et frontenden trenger. GraphQL gjør i stedet alt tilgjengelig, slik at frontendutvikleren kan hente det som trengs.

Frontendrammeverk

Selv om et headless CMS i bunn og grunn består av en database, et redigeringsgrensesnitt og et API, er dette selvsagt ikke hele historien. En av drivkreftene bak suksessen til headless de siste årene er at frontendutviklere kan jobbe fritt med favorittverktøyene og rammeverkene sine.

Frontendrammeverk lar utviklere bygge strukturen, designet, oppførselen og animasjonen til alle skjermelementer på nettsteder og i apper. De har blitt enormt populære de siste årene, utvilsomt fordi JavaScript er en del av nettets kjerneteknologi sammen med HTML og CSS.

Et headless CMS kommuniserer med et frontendrammeverk gjennom API-er, så undersøk API-støtten når du vurderer ditt neste CMS.

Noen populære frontendrammeverk

Det finnes et nesten uendelig utvalg av frontendrammeverk å velge mellom når du skal bygge en headless-løsning. Nedenfor presenterer vi noen av de mest populære alternativene.

Next.js

Next.js er et utviklingsrammeverk med åpen kildekode bygget på Node.js. Det gir React-baserte nettapplikasjoner funksjonalitet som serversiderendering og generering av statiske nettsteder. Next.js løser vanlige behov som ruting, datahenting, integrasjoner og statisk generering.

Ved å flytte all koding til et eksternt rammeverk blir det enklere for utviklere å bygge CMS-drevne nettsteder på samme måte som rene nettapplikasjoner. Det krever også mindre CMS-spesifikk opplæring. Dette løser en stor utfordring i digitale prosjekter: tilgang til utviklerressurser.

Nuxt.js

Nuxt.js er et gratis JavaScript-bibliotek med åpen kildekode, basert på Vue.js, Node.js, Webpack og Babel.js. Nuxt er inspirert av Next.js, et rammeverk med lignende formål som er basert på React.js. Nuxt.js lar utviklere bygge applikasjoner som rendres på serversiden. En Node.js-server leverer HTML til klienten basert på Vue-komponenter, fremfor å kjøre JavaScript på klientsiden.

SvelteKit

SvelteKit er et fullstackrammeverk der siden rendres på serversiden ved første besøk, mens påfølgende sider rendres på klientsiden. SvelteKit gir deg kontroll over hvilken av disse renderingsmetodene sidene dine bruker.

React

React er et JavaScript-bibliotek for frontend med åpen kildekode, beregnet på å bygge brukergrensesnitt eller grensesnittkomponenter. Det vedlikeholdes av Facebook og et fellesskap av enkeltutviklere og selskaper. React kan for eksempel brukes som grunnlag for utvikling av enkeltsideapplikasjoner eller mobilapper.

Angular

Angular er et gratis, TypeScript-basert rammeverk med åpen kildekode for nettapplikasjoner, ledet av Angular-teamet hos Google og et fellesskap av enkeltpersoner og selskaper.

Vue.js

Vue.js er et JavaScript-rammeverk for frontend med åpen kildekode, basert på model-view–viewmodel, for å bygge brukergrensesnitt og enkeltsideapplikasjoner. Det ble laget av Evan You og vedlikeholdes av ham og resten av de aktive medlemmene i kjerneteamet.

Viktige ting å vurdere i et headless CMS

Å velge riktig headless CMS for deg, teamet ditt og virksomheten kan være en krevende oppgave. Men det trenger ikke å være umulig. Her er noen viktige faktorer du bør vurdere i anskaffelsesprosessen.

Infrastruktur og teknologi

Et fremtidssikkert headless CMS bruker moderne teknologi og er åpent for integrasjon med de beste verktøyene innen hvert område. Det innebærer å tilby fleksible API-er, være uavhengig av frontendrammeverk og bruke skytjenester for smart skalering. Det innebærer også vanligvis å være kompatibelt med verktøy for innholdsproduksjon, markedsføring og analyse.

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

Vurder virksomhetens behov nøye. De fleste kan være fornøyde med en løsning levert som en tjeneste (en skyløsning), men virksomheten din kan ha krav om drift i egne miljøer. Hvis det siste gjelder, bør du undersøke headless-leverandørene grundig, siden ikke alle tilbyr programvare som kan driftes på egen hånd.

Et omfattende og fleksibelt API for å hente inn, opprette og vedlikeholde innhold er et absolutt krav til ethvert headless CMS. Hvis du må tilpasse eller bygge API-er som er skreddersydd til virksomhetens krav, må du sikre at CMS-et støtter det.

Utviklerøkosystem

Utviklere er den primære målgruppen for et headless CMS. De vil vite hvordan CMS-et passer inn i virksomhetens eksisterende digitale portefølje og rammeverk, og kjenne alle detaljene i selve løsningen.

Utviklere liker også å delta i fellesskap der de kan få og gi hjelp, samt vise frem løsningene de har bygget med headless-CMS-et. Et aktivt fellesskap, sammen med profesjonell støtte fra leverandøren, vil gjøre utviklerne dine mer fornøyde.

I tillegg må du lære opp de ansatte som skal bruke og drifte CMS-et i årene fremover. Å la utviklere og redaktører få opplæring i headless-løsningen vil spare virksomheten for tid og penger på lang sikt.

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

Enkel innholdsproduksjon

Det er fristende å lytte til utviklernes stående applaus for hvor fremragende headless CMS er. Men ikke glem den andre gruppen som skal jobbe i løsningen til daglig: innholdsredaktørene.

Spør deg selv hvor lang tid innholdsteamet vil bruke på å forstå headless-CMS-et godt nok til å arbeide så produktivt som mulig. Redigeringsgrensesnittet i et headless CMS bør først og fremst gjøre innholdsredaktørene dine produktive og effektive.

Mange «rene» headless-CMS-løsninger av første generasjon, utviklet for skyen, tilbyr den fryktede databasen med skjemabasert redigering – og lite annet som standard. Selve innholdet bør riktignok stå i sentrum, men redaktører vil gjerne se og oppleve hvordan innholdet blir presentert. Akkurat som en filmregissør vil se og høre filmen sin på kinolerretet, fremfor å oppleve den samme historien i et manus.

Du bør med andre ord sikre at den valgte løsningen kan komponere innhold i en kontekstuell forhåndsvisning (sammen med både visuelle elementer og tjenester). Samtidig bør den være responsiv, gi en logisk oversikt, som en trestruktur, og støtte arbeidsflyt og tilgangsrettigheter. Gjenbruk av innhold – selve kjernen i headless – sparer dessuten både tid og ressurser.

Sikkerhet og pålitelighet

Et headless CMS gir bedre sikkerhet ved å redusere antallet eksponerte komponenter som er tilgjengelige for sluttbrukere. Inngangene for ondsinnede besøkende begrenses når bare noen få deler av løsningen er synlige. Denne sikkerhetsfordelen styrkes ytterligere hvis leverandøren bruker et statisk nettsted på et CDN (innholdsleveringsnettverk).

Det eneste elementet sluttbrukere har tilgang til, er atskilt fra kritiske komponenter av flere lag. Prosessen fra innholdsproduksjon til produksjonssetting omfatter mange bevegelige deler, og i tradisjonelle publiseringsløsninger førte dette ofte til en sårbar backend.

Med et headless CMS er produksjon og levering av innhold alltid separate prosesser. Dette gjør det svært vanskelig for sluttbrukere å få tilgang til løsningens backend. Fleksibiliteten i et headless CMS gir dessuten mulighet for enda bedre sikkerhet gjennom et skybasert oppdateringsregime. Med en modulær arkitektur kan du planlegge oppdateringer og vedlikehold med lite eller ingen nedetid.

Å holde innholdet og kundedataene dine trygge bør selvsagt være blant dine høyeste prioriteringer. Vurder virksomhetens krav til hvor data skal lagres, hvem som har tilgang, og leverandørens sikkerhetssertifiseringer. Du bør også sikre at leverandøren tester regelmessig for sikkerhetsproblemer og raskt ruller ut oppdateringer og sikkerhetsrettelser.

Påliteligheten til en headless-løsning avhenger av flere faktorer, blant annet hva som skjer med de digitale opplevelsene dine under og etter vedlikehold. Som del av vurderingen bør du også undersøke leverandørens historikk gjennom dokumentasjon, tilbakemeldinger fra brukermiljøet og analytikerrapporter.

Som et siste punkt i denne delen bør du sikre at headless-CMS-et du velger, støtter utviklingsprosessen din og tilbyr flere miljøer – for eksempel for testing, klargjøring og produksjon.

Bruksområder

Hvis det ikke er helt klart hva du kan bruke et headless CMS til, kan konkrete bruksområder hjelpe både deg og sentrale beslutningstakere i virksomheten. Disse eksemplene kan gjøre det enklere å forstå konseptet og hvordan det kan skape forretningsverdi.

Plattformspesifikke apper

Plattformspesifikke apper var den opprinnelige drivkraften bak fremveksten av headless CMS. Et tradisjonelt CMS er helt uegnet til å levere innhold til en app, mens et headless CMS gjør jobben. Headless er det ideelle valget når iOS- eller Android-appen din har innhold du må oppdatere regelmessig. Her tilbyr headless-CMS-et også funksjonalitet for innholdsforvaltning som bildehåndtering, godkjenninger i arbeidsflyten, publiseringsdatoer og taksonomi.

Nettapper

Nettapplikasjoner kan være et bruksområde for headless fordi de ikke trenger å være spesielt innholdsdrevne. En nettbankapp kan for eksempel kreve tilpasset kode og backendintegrasjoner, og utviklere ville ikke bygget noe slikt med et tradisjonelt CMS. Appen trenger likevel innholdsforvaltning for hjelpetekster, etiketter, bilder og lokalisert innhold, og her kan et headless CMS bidra.

Nettsted

Selv tradisjonelle nettsteder kan lages med headless CMS, samtidig som både frontendutviklere og innholdsredaktører blir fornøyde. For det første kan utviklerne lage designet, funksjonaliteten og tjenestene med rammeverket de foretrekker. For det andre kan brukerne på forretningssiden konsentrere seg om selve innholdet og slippe å tenke på all den visuelle pynten.

Men – og dette er viktig – et headless CMS trenger ikke å være en ren database for redaktøren. Noen leverandører tilbyr det vi kaller «neste generasjons» headless CMS, med ekstra og valgfrie funksjoner som trestruktur, URL-håndtering, visuell sideredigering og kontekstuell forhåndsvisning.

Selv utviklerne får noe ekstra, i form av en backend der de kan utvikle og produksjonssette kode for å tilpasse API-er og kjøre planlagte oppgaver, i tillegg til andre integrasjoner.

Dokumentasjon

Dokumentasjon er materiale som formidler beskrivelser, forklaringer eller instruksjoner om egenskapene til et objekt, system eller en prosedyre, for eksempel deler, montering, installasjon, vedlikehold og bruk.

Et dokumentasjonsnettsted fungerer i bunn og grunn som et slags oppslagsverk, med lave krav til avanserte landingssider og høye krav til oppdatert og strukturert innhold. Det høres ut som et perfekt bruksområde for et headless CMS.

Netthandel

Som følge av digital transformasjon og endret forbrukeratferd har netthandel for alvor fått fotfeste i B2C-markedet. Handel er nå en like naturlig del av opplevelsen i sosiale kanaler og IoT som på nettsteder, og tradisjonelle forhandlere er under press for å tilpasse seg den nye handelshverdagen.

Headless CMS tilfører netthandel verdi ved å legge til rette for redaksjonelt innhold og forvaltning av landingssider knyttet til produkttilbudet ditt, slik at du kan levere en komplett handleopplevelse.

Redaksjonell database

Noen ganger vil du bare at en avgrenset gruppe redaktører skal utføre en bestemt oppgave – som å oppdatere anbefalinger for medisinsk behandling eller en forskrift. Av sikkerhetshensyn eller på grunn av manglende opplæring ønsker du ikke å gi disse redaktørene tilgang til hoved-CMS-et. Dermed oppstår behovet for en avgrenset kunnskapsbase.

I eksemplet vårt trenger redaktørene bare tilgang til å redigere bestemte deler av innholdet, og ikke hele nettstedet. Med headless CMS kan dette løses ved å konfigurere innholdstypene du trenger, og gjøre innholdet tilgjengelig for nettstedet eller andre aktuelle kanaler gjennom API-et ditt.

Utfordringer

Som med det meste i livet har headless CMS både fordeler og ulemper. Vi har diskutert mange av fordelene med et headless CMS, men hva finner vi på baksiden? Finnes det reelle utfordringer?

Et rent headless CMS av første generasjon kan vanligvis ikke:

• Tilby en visuell sidebygger for landingssider
• Organisere nettstedets struktur
• Håndtere URL-er
• Forhåndsvise innholdet
• Administrere brukerrettigheter og tilganger
• Håndtere SEO
• Håndtere avansert bilderedigering

For hver ny klient må utvikleren dessuten håndtere flere problemstillinger, blant annet:

• URL-håndtering (igjen)
• Formateringsproblemer og malhåndtering
• Mellomlagring og utsatt lasting
• Tilgangsrettigheter
• Feilhåndtering
• Synkronisering mellom CMS-et og klientene
• «Tvungne» oppdateringer fra skyleverandøren

Avhengig av leverandøren og valgene du tar i det digitale prosjektet, kan det også kreves mer spesialutvikling hvis du bruker headless til tradisjonelle nettsteder. Og siden mange headless-løsninger er skybaserte, er det ikke sikkert at du kan drifte programvaren selv.

La oss gå nærmere inn på noen av utfordringene. Merk at disse varierer fra leverandør til leverandør, og avhenger av om de tilbyr et CMS av neste generasjon – altså en kombinasjon av de smidige fordelene med headless og et valgfritt, men kraftig sett med redaksjonelle verktøy.

Forhåndsvisning

Siden redaktører jobber i en database og ikke på et faktisk nettsted, vet de ikke egentlig hvor innholdet vil havne eller hvordan det vil se ut før publisering.

Utviklere kan imidlertid lage en standard forhåndsvisning som gir en rask pekepinn og gjør innholdsredaktøren tryggere. Husk bare at forhåndsvisningen kanskje ikke er helt lik den endelige presentasjonen i alle kanaler.

Trestruktur

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

Som nevnt er et headless CMS mer eller mindre en database. I større prosjekter kan det bli vanskelig å organisere innhold eller få en ryddig oversikt med en slik standard databasevisning.

Utviklerdrevet

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

Headless CMS er først og fremst utviklerdrevet. Frikoblingen mellom innholdslaget og presentasjonslaget gjør arbeidet morsommere og smidigere for utviklere, men skaper en reell utfordring for innholdsredaktører. Dette skyldes at særlig første generasjons headless begrenser hva disse brukerne kan gjøre og tilpasse i plattformen. 

Drift og sikkerhet

De fleste rene headless-leverandører tilbyr løsningene sine som SaaS, noe som betyr at du logger inn i en skytjeneste for å redigere innhold. Dette gir fordelene ved skydrift i form av svært høy hastighet og skalerbarhet ved trafikktopper.

Men alle headless-leverandører er ikke like. Hybridleverandører tilbyr for eksempel ulike driftsløsninger. Noen er SaaS, mens andre kan være PaaS eller til og med lokalt installerte. Den generelle trenden er likevel at stadig flere leverandører flytter til skyen for å gi bedre brukeropplevelse og høyere hastighet. Siden de fleste headless-løsninger er skybaserte, kan muligheten for å drifte programvaren selv være utelukket.

Hvis prosjektet ditt omfatter rikt nettinnhold, URL-håndtering, omfattende redaksjonelle krav, spesielle driftsbehov og gjenbruk på tvers av kanaler, kan et headless CMS av neste generasjon være løsningen du ser etter.

Mer kode å vedlikeholde

Utviklerfokuset i headless CMS kan faktisk innebære mer hardkoding fra utviklerne, og innholdsredaktørene er mer avhengige enn noen gang av hva utviklerne har tatt høyde for. Det finnes muligheter for hardkodede, tilpassede brytere og kompleks konfigurasjon, men dette gjør plattformen mer avansert enn nødvendig.

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

I tillegg må mange praktiske forhold håndteres – som URL-håndtering, dyplenking og feilhåndtering. Avhengig av valgene dine kan et headless CMS av første generasjon faktisk gi høyere kompleksitet ved at du går fra ett system til flere for å håndtere ulike oppgaver.

Legg til at alle de ulike systemene må integreres, synkroniseres og forvaltes, så har du litt av en nøtt å knekke.

***

Mange av disse utfordringene med headless CMS kan enkelt løses ved å undersøke og velge riktig løsning for deg. Noen leverandører har tatt hensyn til disse faktorene og tilbyr et alternativ av neste generasjon: det beste fra begge verdener, der utvikleren får frihet og redaktøren får flere muligheter.

Prismodeller

Kostnaden for et headless CMS kan være vanskelig å beregne, fordi SaaS-leverandører ofte er lite transparente og bruker en forespørselsbasert prismodell.

Det du må spørre deg selv om, er hva systemets forventede levetidskostnad er, og om det vil gi avkastning på investeringen på lang sikt. Sørg for at du vet hvordan løsningen du foretrekker, prises (bare spør leverandøren), hvilke faktorer som driver kostnadene, og hva den estimerte levetidskostnaden er.

Ikke la deg lure av løfter om gull og grønne skoger. Et headless CMS kan være rimelig i starten, men når trafikken tar seg opp, må du åpne lommeboken. Prisen baseres ofte på antall forespørsler, og utviklere kan utilsiktet doble antallet gjennom måten de skriver koden på.

Populære headless-løsninger ligger stort sett på samme prisnivå som tradisjonelle publiseringsløsninger. Avhengig av leverandørvalget kan du dessuten trenge flere løsninger i tillegg til den rene databasen. Dette kan for eksempel være presentasjonsløsninger, og disse må også tas med i beregningen.

På den andre siden inkluderer et headless CMS av neste generasjon med utvidet funksjonalitet et valgfritt presentasjonslag for nettsteder, noe som fjerner deler av behovet for flere løsninger fra prisberegningen.

Avsluttende betraktninger om headless

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 og et API for distribusjon til enhver kanal er uslåelig.

Som vi har sett, har headless CMS sine utfordringer. Vi mener likevel at de kan løses med smarte strategier, som å ta i bruk funksjonalitet fra neste generasjon.

Innhold er i bunn og grunn data. En metode for å behandle data enkelt og forutsigbart vil ikke bli utdatert. Den er en del av selve grunnlaget for kommunikasjon. Spørsmålet er i hvilken grad headless CMS vil nærme seg det det opprinnelig tok avstand fra: det tradisjonelle CMS-et.

Vi tror at fleksibilitet vil være nøkkelen for leverandører som lykkes i årene fremover. Fleksibiliteten til å velge komponentene du trenger for å tilfredsstille både utviklere og innholdsredaktører til enhver tid, i stadig skiftende omgivelser.

Bonus: Headless CMS forklart for markedsførere

Headless CMS er i sin natur et svært teknisk konsept, og det kan være vanskelig å forstå. Her skal vi forsøke å forklare konseptet tydelig for folk uten teknisk bakgrunn, hvorfor det oppsto, og hva det betyr for deg.

Bakgrunn

Tre sammenhengende faktorer bidro til fremveksten av headless CMS: overlessede DXP-er, omnikanal og teknologisk utvikling.

Overlessede DXP-er

Mange innholdsredaktører kjenner nok til trege og uhåndterlig store DXP-er, med en million funksjoner og en hastighet som en isbre. Alt lå til rette for at et lett og lynraskt CMS kunne erstatte den overlessede herskeren.

Omnikanal

Den andre faktoren, omnikanal, bør være like kjent. Alle som har fulgt litt med, har merket seg strømmen av digitale enheter og kanaler de siste tiårene.

Datamaskinen er ikke lenger alene. Nå har den selskap av mobiltelefoner, smartklokker, ringeklokker, stemmeassistenter, signalgivere i butikker og ting vi ennå ikke har drømt om. Så hvordan leverer man innhold konsekvent fra én kilde til en million forskjellige kanaler?

Teknologisk utvikling

Den tredje faktoren, teknologisk utvikling, er nok mer uklar for folk flest. Kort fortalt har det skjedd nyvinninger innen funksjonsrike frontendrammeverk. Hva er det, spør du? Frontender bestemmer logikken, strukturen, designet, oppførselen og animasjonen til elementene på skjermen.

Denne teknologien har blitt så mye bedre at utviklere foretrekker å bygge digitale løsninger med favorittrammeverket sitt. Dette passer perfekt sammen med headless-teknologien, som vi skal se.

Hva er headless CMS?

Headless CMS kom på banen for å løse tre utfordringer: overlessede systemer, omnikanal og utviklerens nyvunne begeistring for sitt foretrukne frontendrammeverk. Hvilke egenskaper har headless CMS som svarer på disse behovene?

La oss først se på hva et headless CMS ikke er. Et tradisjonelt CMS er definitivt ikke headless, og det låser innholdet sammen med design og funksjonalitet. Du skriver for eksempel noen linjer inn i designet på en landingsside. Prøv så å overføre den visuelle landingssiden til stemmeassistenten din, IoT eller kroppsnær teknologi. Umulig.

Det headless CMS gjør, er å skille innhold fra design og funksjonalitet – også kalt presentasjon. Teksten du skrev og bildet du satte inn i skjemaer, kan nå hentes ut etter behov og vises gjennom noe som kalles API-er, i ulike kanaler.

Dette inkluderer den gode, gamle landingssiden, smartklokken og digitale skilt. Det gir for eksempel mening å vise alt innholdet på nettet, bare tekst på kroppsnær teknologi og de visuelle elementene på digitale skilt. Og alt kommer fra samme kilde!

Fortsatt vanskelig å forstå? La oss gi noen nyttige sammenligninger:

Se for deg at hver motor var uløselig knyttet til bilen sin. Da kunne ikke ingeniører og mekanikere brukt prinsippene fra en V8-motor i en Aston Martin Vantage i en Aston Martin DBS Superleggera.

De måtte laget en helt ny motor fra bunnen av. Heldigvis er motoren (innholdet) den samme i flere forskjellige biler (presentasjoner), noe som gir økonomiske fordeler.

Eller tenk deg at teksten i en roman var uløselig knyttet til de første fysiske, innbundne eksemplarene. Det ville gjort pocketutgaver, samlerutgaver, digitale utgaver og så videre umulige. Heldigvis er innholdet i virkeligheten skilt fra presentasjonen også her.

Hva det betyr for virksomheten

Et headless CMS skiller altså innhold og presentasjon. Det lar oss distribuere innholdet til alle markedsføringskanalene våre (og flere til), samtidig som ytelsen løftes med svært høy hastighet. Det høres bra ut så langt, men det er mer:

• Bedre kvalitet: Innholdsskaperne dine kan nå først og fremst konsentrere seg om selve innholdet, fremfor den konkrete visuelle plasseringen på for eksempel en nettside. Én felles innholdskilde kan også bidra til en konsekvent språklig profil på tvers av kanaler.
• Tidsbesparelser: Gjenbruk det samme innholdet i ulike kanaler, fremfor å gjøre det samme arbeidet flere ganger. Du slipper også å streve med designelementer og sideoppsett (la utviklerne ta den jobben!).

Samlet sett styrker headless CMS tilstedeværelsen din på tvers av kanaler, gjør tilbudene dine raskere, forbedrer innholdskvaliteten og sparer teamet ditt for tid (og penger).

Til sammen bør disse faktorene bidra til en bedre digital kundereise, som gir flere og mer fornøyde kunder – noe bedriftsledere forstår og setter pris på.

Vi vet nå hva en publiseringsløsning er, og hva du kan gjøre og bør gjøre med den. Men hvor beveger CMS-et seg hen? Hva er fremtiden for teknologien? La oss ta en rask titt på fortiden før vi dykker ned i fremtiden.

Kort historikk for CMS

På 1990-tallet laget de fleste organisasjoner og personer med en tilstedeværelse på nettet sine nettsider ved hardkoding av statiske HTML-sider. Mot slutten av 1990-tallet lot fremgangen innen programmeringsspråk redaksjoner redigere innhold på sine egne nettsider. Dette banet vei for fødselen til publiseringsløsningene.

Et CMS tillot brukere å skrive, kopiere, laste opp bilder og publisere til nettet uten å ha spesielt mye kunnskap om tekniske ting. De fleste organisasjoner skrev sitt eget skreddersydde CMS. Epoken vitnet imidlertid også om fremveksten av det kommersielle CMS-et, der et selskap solgte et støttet CMS til andre organisasjoner.

Tidlig på 2000-tallet begynte det å dukke opp flere åpen kildekode-baserte CMS-er. De økte i popularitet sammen med de kommersielle, proprietære CMS-ene hele veien opp til i dag.

Deretter, på slutten av 2000-tallet og begynnelsen av 2010-tallet, endret brukerbehovene seg. Det gikk fra å være i stand til å produsere og publisere på nettet til å inkludere mer rike markedsføringsevner og funksjoner. I tillegg til å løse problemet med flrerkanalstilstede-værelse.

Det er her vi er i dag.

Hva kommer etterpå?

Utviklingen av publiseringsløsninger har absolutt ikke stått stille siden 1990-tallet, men hva kan vi forvente oss det neste tiåret?

Sky

Historisk sett har lokale installasjoner dominert CMS-arenaen. Med den raskt voksende populariteten til skyen har CMS-leverandører begynt å tilby programvaren sin som en tjeneste (SaaS), noe som effektivt reduserer kompleksiteten ved installasjoner og drift. Som et resultat tilbyr leverandører som tidligere har vært rene programvareselskaper nå løsningene sine som en tjeneste.

Vær forsiktig når du velger løsning, ettersom rene skyløsninger vil låse deg inne sammenlignet med programvarebaserte løsninger og spesielt systemer med åpen kildekode.

Headless

Fremtiden for CMS vil fremdeles forbli tett knyttet til nettet. Antallet enheter og grensesnitt vi bruker til å konsumere og samhandle med innhold, har imidlertid eksplodert. Sosiale medier, apper, klokker, talegrensesnitt, virtuell og utvidet virkelighet og digital skiltning er bare toppen av isfjellet.

Det finnes tallrike måter å mate disse kildene med innhold på. Men for en organisasjon som ønsker å tilby konsekvent innhold på tvers av kanaler, oppsummeres svaret i tre bokstaver: API (applikasjonsgrensesnitt).

Innhold som leveres gjennom API-er, vil først og fremst være strukturert (som i atomistisk innholdsdesign). Dette betyr at oppsett og faktisk presentasjon må håndteres av hver enkelt klient og enhet.

Klienter må kunne hente innhold gjennom godt definerte API-er, og vi kan forvente å se mange forskjellige stiler av API-er – men nettbaserte API-er vil dominere fullstendig.

Nisjeområdet i CMS-verdenen er kjent som headless CMS, og antallet aktører som fokuserer på cloud-first headless CMS, har eksplodert. Tradisjonelle CMS-leverandører tilbyr også web-API-er for innholdet sitt, og dette omtales ofte som en dekoblet tilnærming.

Utover CMS

Den spennende teknologiske utviklingen på nettet, i både programvare og maskinvare, etterlater en del usikre faktorer om den umiddelbare og den mer fjerne fremtiden for CMS.

Men dette virker ganske sikkert: Flere CMS-leverandører har beveget seg utover enkel innholdsforvaltning på nettet, og mange tilbyr allerede et bredt spekter av markedsføringsverktøy eller integrerte markedsføringssuiter.

Aktører i dette komplekse spillet inkluderer Sitecore og Adobe, og tilbudene deres kan merkes som «digitale opplevelsesplattformer». Denne typen helhetlige løsninger søker å forvalte, levere og optimalisere sluttbrukerens digitale opplevelse på tvers av en rekke plattformer og kanaler, som apper for sosiale medier, klokker, talegrensesnitt og så videre.

I disse markedsføringspakkeløsningene kan vi observere et økt fokus på verktøy for personlig tilpasning og dynamisk, kontekstuell markedsføring. I tillegg til markedsføringsautomatisering og kontinuerlig optimalisering av bruker- og kundeopplevelsen.

Det fremtiden i hovedsak bringer for CMS, er derfor mer enn innholdsforvaltning på nettet, eksemplifisert ved integrerte markedsføringssuiter og innlemmet under begrepet «digital opplevelse».

Dette betyr en mengde forskjellige verktøy og tjenester, tilgjengelig gjennom flere forskjellige plattformer og kanaler. Og de vil rette seg mot forskjellige målgruppesegmenter – det rette innholdet til rett tid til de rette menneskene.

Du kan forvente at disse løsningene primært vil være tilgjengelige som skybaserte tjenester.

Progressive Web Apps

Helt siden Steve Jobs introduserte den opprinnelige iPhone i 2007, har internett vært delt i måten det presenteres på: Vanligvis viser dette seg ved at et merketilbud presenteres som en vanlig nettside i en nettleser på skrivebordet og som en dedikert app på iOS, Android osv.

Denne todelte (eller flerdelte) løsningen har vist seg å være både tidkrevende og ressurskrevende. Utviklere har i grunnen måttet lage det samme produktet to, tre eller enda flere ganger.

Flerplatatilstnærmingen er bortkastet tid og kan være forvirrende og frustrerende for sluttbrukerne. Hvorfor er funksjonalitet x tilstede i skrivebordsversjonen av nettstedet, men ikke i appen? Og omvendt. Hadde det ikke vært kjekt å bare ha én løsning som fungerer på flere plattformer og kanaler?

Enter progressive web apps. En progressiv webapplikasjon, eller PWA for kort, er en nettside som er i stand til å fungere som en innebygd mobilapp. Dette betyr at utviklerne lager én løsning, redaktørene publiserer i én løsning, og forbrukerne mottar en konsekvent opplevelse på tvers av enheter. En PWA er:

• Progressiv – fungerer for alle brukere, uavhengig av nettleser
• Responsiv – passer til alle formfaktorer
• Uavhengig av tilkobling – tillater arbeid offline eller på nettverk med lav kvalitet
• Raskere / bedre ytelse – utnytter hastighetsfordelene ved nettet
• App-lignende – føles som en app med interaksjoner og navigering i app-stil
• Slankere – mye mindre størrelse enn en innebygd app
• Fersk – alltid oppdatert på grunn av oppdateringsprosess for tjenestearbeider
• Sikker – leveres via HTTPS
• Søkbar – identifiserbar som «applikasjoner» og lar søkemotorer finne dem
• Installerbar – kan legges til på startskjermen uten å involvere en appbutikk (det er valgfrie å bli inkludert)
• Lenkbar – enkelt å dele via en URL og krever ikke en kompleks installasjon

Eksempler på PWA-er inkluderer Twitter, Tinder og Debenhams, og utviklingen av teknologien støttes av Google, Microsoft og Apple. Flere av de tidlige testtilfellene har rapportert om økte konverteringsraten, noe som gjør PWA-er til et must for enhver fremtidssikret organisasjon.

Et CMS for fremtiden bør støtte PWA-er. Når du undersøker din neste publiseringsløsning, må du sørge for at den er i stand til å fungere med progressiv webapp-teknologi.

Fremtidssikring av ditt CMS

Uansett hvilket CMS du til slutt velger, er det vanlige tekniske aspekter du bør vurdere for å gjøre CMS-et klart for fremtiden. Du har allerede lest flere tips gjennom denne guiden, og her er noen flere:

• Fleksibilitet – CMS-et ditt bør kunne tilpasses alle slags behov i organisasjonen din, enten i kjernen eller gjennom integrasjoner
• Støtte – CMS-et bør støtte alle design og typer innhold du kan kaste på det
• Bildeskalering – å håndtere bilder både i redigering og presentasjon er ingen luksus, det er en nødvendighet i en stadig mer mobil verden
• Språkstøtte – ettersom nettet mer eller mindre har gjort nasjonale grenser meningsløse, bør ethvert nettsted eller app tilby flerspråklig støtte, og backend er intet unntak
• Integrasjoner – med et tett forhold til fleksibilitet er integrasjoner nøkkelen til å ligge i forkant, ettersom CMS-et ditt ikke vil være i stand til å tilby alt til alle. Skreddersydde løsninger dukker alltid opp, og et fremtidssikret CMS tar hensyn til dette
• Skalering og ytelse – enten du driver en liten forening eller er en del av et stort selskap, må CMS-et vokse i takt med trafikken og behovene dine. Et CMS bør tilby et robust fundament. Du bør være i stand til å bygge og skalere elementer i systemet sømløst, i tillegg til å sørge for at den generelle ytelsen til systemet holdes god

Du kan også lese guiden vår om hvordan du fremtidssikrer dine digitale opplevelser for å få en mer fullstendig forståelse av skrittene du bør ta mot fremtiden.

Da har du det! Alt du trenger å vite om publiseringsløsninger. Bruk denne guiden som et oppslagsverk når du står fast eller har glemmer et eller annet viktig poeng mens du undersøker eller utforsker ditt foretrukne CMS. Lykke til i jakten på å finne det perfekte CMS-et for deg!