Gå videre til hovedindhold

Til kunderne
For partnere
En personaliseret tilgang En personaliseret tilgang

Hvad er konsolløs CMS?

Alt hvad marketingfolk og udviklere har brug for at vide om konsolløs, adskilt og API-first content management-systemer

1. Hvad er konsolløs CMS?

2. CMS-arkitektur 101

3. Hvad (og hvem) er konsolløs CMS nyttig for?

4. Hvad er ulemperne ved konsolløs CMS?

5. Indfør hybrid, konsolløs cms

6. Få mere at vide om konsolløse værktøjer

1. Hvad er konsolløs CMS (den korte version)?

Konsolløs CMS-arkitektur adskiller back-end-indholdsfunktioner (som for eksempel oprettelse, administration og lagring) fra front-end-funktioner (eksempelvis præsentation og levering).

OK, but really: What is a headless CMS?

Okay, men helt ærligt: Hvad er konsolløs CMS?

Så hvad betyder det egentlig? Hvorfor er konsolløs arkitektur vigtig for fremtidens digitale oplevelse?

Konsolløs arkitektur er til dels svaret på den måde, webindhold har udviklet sig. I lang tid blev det meste webindhold leveret via en browser, ofte som et website. Men der kommer hele tiden nye forbundne enheder på markedet.

Målgrupperne har i dag adgang til indhold gennem nye interfaces med forskellige formfaktorer – for eksempel smartphones, bærbare enheder, AI-aktiverede stemmeassistenter og endda virtual reality-headsets.

Konsolløs CMS-arkitektur er altafgørende for at kunne tage fat på disse nye indholdsmæssige udfordringer. Det betyder, at du nemt kan oprette og administrere flere ting og levere dem til flere steder.

Men før vi bliver for tekniske, så lad os begynde med det grundlæggende.

Headless CMS architecture is foundational to addressing these new content challenges. It means you can easily create and manage more things and deliver them to more places.

But before we get too technical, let’s start with the basics.

Here’s an overview of two fundamental architecture decisions –

and how they impact how content is created, stored, managed, delivered, and even personalized.

Hvilken indvirkning har CMS-arkitekturen på, hvordan indhold ser ud på en side?

Find ud af forskellen på sidebaseret og objektbaseret arkitektur, og hvorfor din AI-aktiverede stemmeassistent ikke er nær så smart, som det lyder.

Hvordan påvirker CMS-arkitektur den måde (og hvor) indhold bliver præsenteret for målgruppen?

Få mere at vide om forskellene på konsolløs og ikke-konsolløs arkitektur, og find ud af, hvordan du undgår at skulle vælge mellem personalisering og analyser, som konsolløse systemer normalt tilbyder.

Helt overordnet handler back-end-delen af et CMS-system om, hvordan indhold bliver administreret, og front-end-delen handler om, hvordan det bliver præsenteret. Tænk på det som et butiksvindue.

Front-end-opgaverne omfatter alt det, du kan se, når du går forbi butikken på gaden: produktudvalget, og hvordan produkterne er præsenteret, samt de tilhørende skilte.

Back-end-opgaverne omfatter logistikken – der skal laves skilte, lageret skal fyldes op, og produkterne skal flyttes rundt og stilles op i butikken.

Hvis vi kigger på et grundlæggende website, vil det betyde, at back-end-aktiviteterne blandt andet kunne omfatte:

en enkel grænseflade til oprettelse af indhold
en database til lagring af digitale aktiver
et applikationslag til udarbejdelse og anvendelse af designstruktur

Front-end-delen vil hjælpe indhold, lagrede aktiver og design igennem og udgive dem på en HTML-side.

Hvad er adskilt CMS?

Traditionelt har CMS front-end- og back-end-funktioner været fastlåst til hinanden. Brugere kan oprette, lagre, administrere og udgive indhold, alt sammen inden for rammerne af ét interface.

For ikke-tekniske brugere, der skulle udgive simpelt indhold – som for eksempel en blog – var dette et fantastisk, problemfrit setup.

Men i takt med at den digitale oplevelse udvikler sig, bruger udviklere så meget tid på at finde måder at omgå systemerne på, så de kan levere sofistikeret indhold til flere forskellige enheder.

Adskilt CMS opsplitter back-end- og front-end-opgaverne. I praksis betyder det, at udviklere hurtigt kan kode og designe front-end-oplevelser i deres foretrukne sprog uden at være bundet af restriktive back-end-teknologier. Da kan i stedet anvende Application Programming Interfaces (APIs) til at oprette forbindelse mellem back-end-funktionerne – såsom lagring og administration af indhold – og alle front-end-leveringsmiljøer.

I de tilfælde hvor adskilte CMS-systemer separerer back-end- og front-end-funktioner, indeholder de stadig nogle front-end-leveringsværktøjer, såsom sideskabeloner eller modulintegration.

API-first CMS-løsninger er funktionelt set det samme som konsolløs CMS, da de ikke har nogen standard-front-end. Udviklere kan frit oprette så mange leveringslag, de har brug for (i deres foretrukne sprog), for at aktivere indhold på alle tænkelige nye kanaler.

API-first CMS-løsninger er fantastisk, hvis du har et team af dygtige udviklingsfolk, der er klar til at tage skridtet – CMS-løsningen administrerer helt enkelt indholdet og venter på et API-opkald fra et front-end-leveringslag, der er opbygget af udviklingsteamet.

Adskilt CMS passer på den anden side til virksomheder, der ønsker den fleksibilitet, de kan få med opsplittede front-end- og back-end-aktiviteter, men som måske stadig har brug for support i forbindelse med udgivelse af indhold.

Først bliver det digitale indhold mere sofistikeret, og brugernes forventninger stiger. Du er nødt til at opbygge smukt, responsivt og interaktivt indhold for at skille dig ud – og du skal kunne gøre det hurtigt.

Dernæst dukker der nye kanaler og brugerenheder op hele tiden. Det er ikke tilstrækkeligt af skabe smukke sider – du skal også sørge for, at du kan levere alle steder så effektivt som muligt. Konsolløs CMS-systemer betyder, at marketingfolk og udviklere kan oprette fantastisk indhold i dag og – mest vigtigt – fremtidssikre driften af indholdet, så de kan levere konsistent og fremragende indhold alle steder.

Det er en fantastisk løsning til marketingfolk, udviklere og brugere.

Det er fantastisk for marketingfolk, fordi …

… de kan nøjes med at oprette indhold én gang og så sætte deres udviklere i gang med at få det vist alle steder. Det betyder, at de bruger mindre tid på administration og mere tid på at opbygge smukke, sammenhængende oplevelser.

Det er fantastisk, ford …

… de slipper for back-end-systemets restriktioner i forhold til de programmeringssprog, hvor de mangler ekspertise. I stedet kan de arbejde med udseende og funktionalitet i forhold til brugeroplevelsen ved hjælp af de værktøjer, de kender og synes om (for eksempel JavaScript-biblioteker og -frameworks) og derefter aktivere indholdet hvor som helst gennem de nyeste API'er.

Det er fantastisk, fordi …

…they’re released from the back-end restrictions of programming languages where they lack expertise. Instead, they can build the look, feel, and functionality of user experiences using tools they know and like (e.g. JavaScript libraries and frameworks), and then push content out anywhere using the latest APIs.

Den første er, at hvad du opnår i fleksibilitet, mister du i tilgængelighed. Da præsentationen er overladt til udviklere, der skriver i JavaScript, kan ikke-tekniske marketingfolk ikke bruge What You See Is What You Get-baseret (WYSIWYG) oprettelse og redigering.

Den anden er en større udfordring.

Der sker noget drastisk, når du skærer toppen af et CMS-system: Du afskærer dig muligheden for at sende data om kundeinteraktion mellem front-end- og back-end-delen i realtid.

Det betyder, at du ikke kan personalisere oplevelsen eller gennemføre aktiviteter såsom indholdsanalyser.

Personalisering har flyttet sig fra at være et "nice-to-have"- til et minimumskrav. Kunderne er ved at finde ud af, hvor fantastisk personalisering føles, for eksempel fra førende virksomheder som Amazon, Netflix, Spotify m.fl.

Hvis du ikke kan levere ensartede oplevelser, vil kunden sandsynligvis gå andre steder hen – og det snart. Så hvad er svaret?

5. Indfør hybrid, konsolløs cms

Den ideelle CMS-arkitektur kombinerer fleksibiliteten og skalerbarheden ved konsolløs CMS – med de personaliserings- og indholdsanalyser, som traditionel adskilt CMS tilbyder.

Det er præcis, hvad Sitecores konsolløse leveringsindstillinger leverer.

Flere konsolløse løsninger understøtter front-end-udviklere, når de etablerer løsninger og apps, som gengiver indhold på alle enheder og browsere. Uanset om udviklere bruger JavaScript-biblioteker såsom Vue.js, React.js og Angular.js eller udnytter nye ASP.NET Core SDK- og konsolløse renderingshostarkitektur, kan de vælge, hvad der er bedst for dem.

Disse muligheder er også indeholdt i en API, som er forbundet til Sitecores kontekstuelle system til levering af indhold. Systemet bruger oplysninger fra Sitecores Experience Database™ til at understøtte enheder og browsere, så de kan omsætte både indhold og regler for personalisering i realtid. Det vil sige, at brugerne ser forskelligt indhold baseret på profiloplysninger, tidligere interaktioner m.m.

6. Få mere at vide om konsolløse muligheder

Konsolløs i aktion

Sådan gjorde de

Ikke alle CMS-løsninger er opbygget på samme måde

CMS-arkitektur påvirker funktionalitet, integration, skalerbarhed og meget mere. Få mere at vide om grundlæggende CMS-arkitektur for at forstå, hvordan konsolløse systemer leverer. Læs e-bogen

Next up on your reading list

Get more insights into the basics

CMS 101: det grundlæggende (20 minutters læsning)

Fortsæt med at læse

En effektiv platform til digitale oplevelser

Oplev vores komplette content management- og commerce-løsninger.

Find arrangementer i nærheden

Brug min aktuelle placering

Skift min placering

Anvend