Slik forvalter du innhold for enkeltside-applikasjoner
Rike frontender og headless CMS er den neste store greia, men hvordan forvalter redaktører innholdet i denne typen løsninger?
Written by Vegard Ottervig on
Enkeltside-applikasjoner, eller single-page applications (SPAs), er webapplikasjoner eller nettsteder som kan interagere dynamisk med brukeren ved å omskrive den gjeldende siden, i stedet for å laste nye sider fra en server.
Formålet er å unngå avbrudd og sikre en jevn brukeropplevelse mellom påfølgende sider, slik at nettstedet oppfører seg mer som en app.
Samtidig med tilstrømningen av SPAs i den digitale verdenen, er det en parallell nykommer, nemlig headless CMS. Dette er i hovedsak en database med API-er for å levere innhold til hvilken som helst kanal.
Det er ikke vanskelig å se hvordan enkeltside-apper og headless CMS passer godt sammen: den gode brukeropplevelsen, den rene arkitekturen og det fleksible rammeverket til SPAs, kombinert med separasjonen av innhold og presentasjon i headless.
Imidlertid er ikke alt rosenrødt med enkeltside-apper og headless – spesielt når det gjelder innholdsredaktører. La oss ta en titt på utfordringene og de foreslåtte løsningene.
Sørg for å velge riktig CMS med vår praktiske sjekkliste:
Utfordringer med SPAs og headless
Innebygd i mange første generasjons headless CMS er mangelen på en forhåndsvisning. Tilsvarende står enkeltside-applikasjoner som er bygget med en headless-arkitektur overfor den samme utfordringen.
Innholdsredaktører er vant til å jobbe i plattformer som viser dem sluttresultatet umiddelbart, enten i en separat forhåndsvisning eller i selve redigeringsverktøyet.
Et tradisjonelt CMS gjør det også enkelt for redaktører å se innholdsstrukturen til det gitte nettstedet eller appen deres, mens et headless CMS bare er en “fritt flytende” database med innhold der redaktørene fyller ut skjemaer som brukes til å fylle inn innholdsfelt. Det samme prinsippet gjelder for redigering av sider og strukturhåndtering.
SPAs og headless CMS er primært utviklerdrevet. Frakoblingen mellom innholdslaget og presentasjonslaget gjør det morsommere og mer smidig for utviklere, men byr på en utfordring for innholdsredaktører. Dette skyldes begrensningene i første generasjons headless CMS for hva redaktørene kan gjøre og tilpasse innen plattformen.
Se også: Hvordan bygge et raskt og moderne nettsted med Next.js og headless CMS »
Den utviklerorienterte tilnærmingen fører faktisk til mer hardkoding fra utviklernes side, og redaktørene er mer avhengige enn noen gang av hva utviklerne har tatt hensyn til på forhånd.
Det finnes muligheter for mange hardkodede tilpassede brytere og komplekse konfigurasjoner, men dette gjør plattformen mer avansert og tungvinn enn nødvendig.
En siste utfordring å nevne med SPA/headless-arkitekturen er bildehåndtering. Mens en annen type CMS kan automatisere flere bildebehandlingsfunksjoner, er dette ikke like enkelt i et headless-miljø, på grunn av separasjonen av innhold og presentasjon (for ikke å nevne at innholdet kan presenteres i vidt forskjellige kanaler).
Dette fører til at redaktørene stadig må håndtere forskjellige bildestørrelser og beskjæring, noe som kan være en hodepine.
Hvordan overvinne utfordringene
Forhåndsvisninger
Når det gjelder forhåndsvisninger, er en beste praksis at utviklerne setter opp en standard forhåndsvisning, selv om det kanskje ikke tar hensyn til hvordan presentasjonen vil se ut på hver kanal du opererer på.
Velg nøyaktig hvordan innholdet vil vises i en forhåndsvisning, vær oppmerksom på forskjellene med andre kanaler, og bygg en mal for hvordan du vil at det skal se ut – i hovedsak det som gir mest mening for deg. Husk at denne forhåndsvisningen ikke nødvendigvis er identisk med hvordan den vil se ut i en SPA.
Visuell sidebygging
Når det gjelder sidebygging, vil den beste løsningen for deg sannsynligvis være en neste-generasjons headless CMS, som tilbyr alle fordelene med et headless CMS, men med noen ekstra fordeler.
Med en neste-generasjons headless-modell kan du levere de strukturerte dataene til din visuelle sidebygger, slik at innholdsredaktørene kan jobbe i et kjent og brukervennlig miljø.
Ikke gå glipp av: Hvorfor velge Enonic's headless CMS når du bygger et Next.js-nettsted »
SPA og tradisjonelle funksjoner
Er det mulig å kombinere en SPA med funksjoner fra et tradisjonelt CMS med en neste-generasjons headless-løsning? Hvis en del av appen trenger en landingsside eller tradisjonelt innhold, kan du kombinere appen med serverside-rendret innhold.
Selv om SPAs og headless absolutt er et utviklerdrevet rammeverk, bør du uansett legge til rette for samarbeid mellom redaktør og utvikler. Dette sikrer fleksibilitet i CMS-et: sammen bør dere lage grunnregler for å strukturere innholdet, noe som gjør det enklere for en innholdsredaktør å få jobben gjort.
Som et eksempel, hvis løsningen støtter tillegg av brytere, legg dem til der det gir mening, uten å overbelaste med for mange muligheter. På samme måte, etabler relasjoner mellom innhold og innholdstyper – slik at systemet blir ryddig og logisk.
Til slutt bør CMS-et ditt uansett støtte bildehåndtering. Dette inkluderer fokuspunkt og muligheten for utvikleren til å definere hvilken versjon av et bilde som går hvor.
Konklusjon
Sørg for at du har en fleksibel plattform som leverer en redaktørvennlig plattform for å levere enkeltside-applikasjoner.
Headless passer som hånd i hanske med SPAs, men et neste-generasjons headless CMS støtter både headless (til glede for utviklerne dine) og tradisjonelle CMS-funksjoner (til glede for redaktørene dine), kan det være den rette løsningen for deg.
Først publisert 8. mai 2019, oppdatert 26. september 2022.
