10 største trender i innhold og teknologi

Thomas Sigdestad er CTO og medgründer av Enonic, et norsk IT-selskap som tilbyr innholdforvaltning og plattformtjenester i ett. Med over 20 års erfaring fra bransjen har Thomas sett trender komme og gå.

Vi lever i en tid med digital transformasjon, og trendene skjer nå raskere enn noensinne. Vi spurte Thomas hva han anser som de største trendene i innhold og teknologi i den nærstående fremtiden.

1. ContentOps

Hei, Thomas. La oss begynne mykt, med nyheter for innholdsredaktørene. Hva mener du er den fremste trenden for innholdsforvaltning i dag?

Hei, og takk for at jeg får være her. I bransjen tenker vi nå annerledes om innhold. Den digitale sfæren blir stadig mer fragmentert på grunn av et ubegrenset antall enheter og kanaler å konsumere innhold på, og produksjonsmetodene bør reflektere dette.

Gjenbruk av innhold er en grunnleggende utfordring, men spørsmålet oppstår da om å produsere innhold for en headless verden.

Så den viktigste trenden for digitalt innhold i dag må være content operations, eller ContentOps. Dette er et sett med prinsipper for innholdsproduksjon som tar sikte på å fylle gapet mellom strategi og leveranse, ved å integrere mennesker, prosesser og teknologi.

Hovedpoenget er å skape kvalitetsinnhold som er effektivt, gjentakbart og skalerbart. Med andre ord: en innholdsproduksjonsmetode som passer for gjenbruk og headless levering.

Hos Enonic har vi for eksempel implementert en "issue tracker". Issues, eller saker, dekker innholdsprosessen fra idé til publisering og hjelper innholdsteamet med å spore elementer og fremdrift fra start til slutt.

2. Innhold først

Jeg observerer at behandlingen av innhold vokser i betydning over hele bransjen, fra små blogger til de store digitale plattformene. Er dette en korrekt antakelse?

Helt klart. Det vi ser stadig oftere nå er det jeg kaller en "innhold først"-tilnærming. Nesten alle seriøse leverandører modellerer nå innhold for gjenbruk, med innhold først og presentasjon senere.

Atombasert innholdsdesign er et prinsipp innen innholdsforvaltning som er verdt å nevne her. Ifølge dette prinsippet bør strukturert innhold brytes ned til de minste meningsfulle delene, klare til å gjenbrukes i større sammenhenger via metadata.

Innhold først er på mange måter like gammelt som datamodellering i seg selv. Den store forskjellen er at redaksjonelt innhold er mer dynamisk og endrer seg raskere enn tradisjonelle applikasjonsdata.

Les mer: Atombasert innholdsdesign: Intervju med daglig leder i Conteir »

3. Composable CMS

Med alt fokuset på innhold og nettskyen er det umulig å ikke nevne composable CMS.

Sant. Selv om headless CMS har vært en stigende stjerne de siste årene, fjerner et rent headless CMS bevisst mye kontroll fra redaktøren, og plasserer vanligvis "standard" funksjoner som forhåndsvisning og trestrukturer utenfor rekkevidde. Etter min mening er et headless CMS optimalt når bruksområdet ditt er strengt definert, og behovet for avansert funksjonalitet, redaksjonell kontroll og sikkerhet er begrenset.

I tillegg til å lage kanalagnostisk og gjenbrukbart innhold, behøver de fleste organisasjoner fortsatt å håndtere tradisjonelt nettinnhold. Ofte behøver vi faktisk begge deler.

Composable CMS gir deg det beste fra begge verdener: innhold først og headless levering, sømløst kombinert med alt du elsker ved tradisjonelle CMS-er – pluss en API-gateway til tredjeparts tjenester.

Kort sagt utvider et composable CMS seg betraktelig utover headless CMS. Det reduserer også antallet verktøy du må integrere og administrere daglig for din digitale drift.

Men vær oppmerksom, for i markedsføringsjungelen er et composable CMS ikke alltid det det utgir seg for å være. Noen leverandører tilbyr sideorienterte, eldre CMS-er med et API limt på, og posisjonerer seg fortsatt som headless eller composable.

For å skille mellom et composable CMS og et tradisjonelt CMS med et API, bør du raskt vurdere følgende:

• Kan nye innholdstyper enkelt defineres og brukes (som i et headless CMS)?
• Er det innholds- eller sideorientert? Snakker vi om innholdstyper eller sidetyper?
• Støtter det rike innholdsmodeller, som referanser og nestede felt?
• Får du en kraftig søkefunksjon, helst ned til attributtnivå på innholdet ditt?
• Får du dynamisk bildelevering med autofokus og beskjæring?
• Og til slutt, passer de tradisjonelle funksjonene for nettinnholdsforvaltning sømløst på toppen av denne modellen, eller er det en midlertidig løsning?

Et composable CMS bør gi deg alle fordelene til headless, og gå lenger ved å støtte tjenesteorkestrering, front-end-agnostisisme, URL-håndtering, navigasjon, landingssider – og kanskje like viktig – muligheten til å distribuere tilpasset logikk og kode når det trengs.

Vår egen Enonic-plattform er trygt plassert i kategorien composable CMS. Det blir interessant å se om headless-leverandørene klarer å motstå fristelsen til å legge til flere funksjoner i denne retningen fremover.

Les også: Headless CMS forklart »

4. Next.js og serverside-rendering

Hva kan du fortelle om trendene innen frontend-rammeverk?

Frontend-rammeverk som muliggjør rike grensesnitt og smidige brukeropplevelser har sett noen betydelige forbedringer i løpet av det siste tiåret.

Denne trenden har likevel en pris. Spesielt når det gjelder initialiseringstid, da nettleseren må håndtere alt: først hente applikasjonen, initialisere den, og deretter hente dataene. En lasteanimasjon kan være akseptabel for en nettapplikasjon, men ingen ønsker dette på nettstedet sitt. Google har til og med begynt å straffe sidens rangering hvis "tid til første interaksjon" er forsinket.

Løsningen ligger derfor i å levere første forespørsel som god, gammeldags HTML for øyeblikkelig respons, og deretter overlate videre interaktivitet til frontend-rammeverket.

Resultatet er at den gode, gamle serverside-renderingen (SSR) av sider er tilbake, men med en ny vri. Backenden din må nå støtte behandling av frontend-rammeverkets maler og kode. Ettersom disse rammeverkene i hovedsak er JavaScript-drevne, vil ditt gamle Java/.NET/PHP-CMS sannsynligvis ha vanskeligheter med å støtte det.

Her kommer Next.js inn i bildet. Det tilbyr en løsning ved å muliggjøre serverside-rendering (SSR) med Node.js, slik at React-komponenter behandles på serversiden og dermed leverer HTML direkte ved sideforespørsler.

Denne tilnærmingen unngår behovet for klientside-rendering og forbedrer lastetidene. I tillegg støtter Next.js statisk generering, ved å forhåndsgenerere og distribuere nettstedfiler globalt via content delivery-nettverk for forbedret hastighet.

Selv om dynamisk generering, som genererer HTML ved første forespørsel og cacher for fremtidige forespørsler, er mer vanlig på grunn av fleksibiliteten med innholdsoppdateringer og planlagt publisering, kan det være tidkrevende for store nettsteder.

Next.js introduserer også statisk inkrementell generering, som kombinerer det beste fra statiske og dynamiske metoder. Dette tillater selektiv statisk generering med muligheten til å oppdatere ikke-statisk eller endrede elementer dynamisk. Det fungerer som en avansert cache-mekanisme og tilbyr en balansert tilnærming til sidegenerering og innholdslevering.

Vi forutså denne trenden tidlig. Vi gjorde JavaScript til en førsteklasses komponent av Enonic-plattformen, noe som muliggjorde SSR og gjenbruk av kode både på frontend og backend. Vi tilbyr også beste praksis-startpakker som React4XP og Next.XP.

5. Statiske sidegeneratorer

Når vi snakker om ytelse. Internett begynte med enkle HTML-tekstfiler. Vender dette på en måte tilbake med de såkalte statiske sidegeneratorene?

Ja, statiske nettstedsgeneratorer (SSG-er) utgjør et alternativ til serverside-rendering (SSR), der renderingen gjøres én gang og deretter publiseres. Begge har sine fordeler og ulemper.

Det vi ser i dag er faktisk den tredje bølgen av SSG-er. Fordelen ligger i bruken av flate filer. Disse kan distribueres globalt med superrask ytelse og færre problemer med høy trafikk.

Ulempen med SSG-er er selvfølgelig at de er statiske. Man må regenerere og publisere hele nettstedet for hver minste endring – nesten som programkode. Tiden dette tar øker med antall sider som må genereres. Dessuten vil de fleste nettsteder og applikasjoner fortsatt måtte håndtere backend-servere, for eksempel for søk, transaksjoner eller tilgang til begrenset informasjon.

De nye SSG-ene er smarte og fleksible, og ikke minst tett integrert med populære frontend-rammeverk. De kan enkelt samle data fra ulike kilder som innholdshubber, og tilbyr vanligvis et stort utvalg av plugins.

En av de mest populære SSG-ene i dag er Gatsby.js. Hos Enonic tilbyr vi allerede en Gatsby-plugin som fungerer sømløst med vårt headless-API.

6. Progressive web-apper

Apropos nettet og frontend-rammeverk, hvordan passer applikasjoner inn i regnestykket?

Ja, vi må ikke glemme å snakke om den største trenden i applikasjonslandskapet: Progressive web-applikasjoner! Hvis du ønsker å være fremtidsrettet i leveringen av innhold og tjenester, er PWA-er fremtiden for applikasjoner, og de fungerer på alle plattformer.

Det som er flott med PWA-er, er at de kombinerer det beste fra web og apper. Nettadresser, ingen installasjonsprosess eller nedlastinger, starter umiddelbart, ingen app-butikker trengs osv. Når de er laget riktig, kan du ikke se forskjellen mellom en PWA og en mobilapplikasjon etter at den har startet. Det er fortsatt områder som krever en mobilapp, men listen blir mindre for hver dag.

Hos Enonic har vi jobbet med PWA-er i årevis, og vi har til og med bygget en åpen kildekode-PWA for alle foosball-spillere der ute. Office league kjører på Enonic og er gratis for alle å bruke!

Lær mer: Statusen for progressive web-apper »

7. Designsystemer

Gjenbruk av innhold er en klar trend. Kan du dele dine tanker om designsystemer i denne sammenhengen?

Så klart. Et designsystem er et rammeverk for å bygge og gjenbruke komponenter og design på tvers av flere kanaler. Designsystemer er naturlig nok en ekstremt populær trend. Hvis det gjøres riktig, kan det bli mye enklere å ha en konsekvent brukeropplevelse og design på tvers av alle kanaler og enheter. Og hvem vil ikke ha det?

Designsystemer gjelder ikke bare visuelle elementer, siden du kan sette designet ditt inn i kode. Derfor omfatter designsystemer CSS, designhåndbøker og til og med gjenbrukbar kode. Konklusjonen er at designsystemer er bedre for brukeren og bedre for å spare både tid og penger.

Til slutt gjør moderne frontend-rammeverk det mulig for utviklere å kompilere alle aspekter av et designsystem til kode, noe som gjør det lettere å konsekvent produsere samme resultat på tvers av alle digitale kontaktpunkter.

8. GDPR og kundedataplattform

Med GDPR har bevisstheten rundt personvern eksplodert og er på alles lepper. Hvordan bør innholdsforvaltere forholde seg til dette?

Mange CMS-er samler data og bygger brukerprofiler, noe som skaper nye siloer og personvernutfordringer. En kundedataplattform (CDP) er en type ferdig programvare som lager en enhetlig kundedatabase som er tilgjengelig på tvers av alle systemer i organisasjonen din, inkludert CMS-et. Data hentes fra flere steder, renses og kombineres for å gi et samlet overblikk over kunden. Med en CDP får du færre siloer og færre systemer som må kommunisere med hverandre.

CDP-er er i hovedsak utformet for store organisasjoner med mange systemer. Ikke bare får du dataene som trengs for å skape relevant personalisering og innhold, du får også bedre kontroll over personvernutfordringer. Med syndikerte kundeprofiler kan både du og kundene få umiddelbar tilgang til denne informasjonen ved behov.

Som sådan vil en riktig implementert CDP gi deg en større trygghet med tanke på GDPR og lignende regelverk, samtidig som du oppnår bedre kommunikasjon og tillit med kundene.

Tro det eller ei, men dette er et område jeg brenner for. Jeg er medformann i teamet som laget spesifikasjonen for kundedataplattformer, som har som mål å forenkle integrasjonene mellom CDP-er og andre systemer. Akkurat nå implementerer vi standardens API på toppen av verdens eneste åpen kildekode-CDP, Apache Unomi. Hos Enonic planlegger vi også å tilby CDP som en integrert del av Enonic Cloud.

9. "Edge computing"

Kan du også dele dine tanker om betydningen av hastighet og såkalt "edge computing"?

En av de viktigste bekymringene til Google i dag er hastigheten på nettsteder, en rangeringsfaktor som er tydelig inkludert i deresLighthouse-verktøy. Tiltak for å øke hastigheten inkluderer JAMstack, Gatsby og "edge computing".

Hva er "edge computing", spør du? La oss si at du har et nettsted i Storbritannia. Når du besøker dette nettstedet fra samme region, startes en server og du kan hente data raskt. Men en besøkende som sitter i Singapore kan oppleve en langsommere forbindelse fordi han er langt unna den samme serveren. Dette problemet har tradisjonelt blitt løst av innholdsleveringsnettverk (CDN). CDN-leverandører har dermed servere over hele verden og henter automatisk en IP-adresse nærmere sluttbrukeren.

Cloudflare er et eksempel på dette. De cacher filer på en lokal server og utfører proxy-caching. Disse handlingene kan være en form for edge computing, men ikke nødvendigvis. Edge computing handler nemlig om å kjøre kode på denne kanten – "edgen," altså den lokale serveren.

Personalisering er et eksempel på edge computing. En form for kommunikasjon kan skje nærmere brukeren og avlaste kjerneserverne. Noen ganger kan du være proaktiv og skyve filene til de lokale serverne først, og prosesseringen der ute utgjør edge computing. I alt dette må du finne en balanse: Hva skal kjøres på serveren, hva skal kjøres på kanten, og hva skal kjøres i nettleseren?

Se også: Hvordan innføre content operations i din organisasjon »

10. "Digital experience stack"

Til slutt, hva tenker du om å føre alle disse trendene sammen?

Det har vært økt prat rundt "digital experience stacks" (DES) i bransjen. Denne trenden handler om å levere moderne digitale opplevelser gjennom mange tjenester, ikke bare gjennom én plattform fra én leverandør på ett sted. På mange måter kan dette ses som en oppsummering av alle de andre trendene.

Det som er mer presserende enn noen gang, er at løsningsrammeverkene og kompleksiteten i arbeidet vårt er større enn før. I tillegg kommer et nytt JavaScript-paradigme, ytelseskrav, behov for kontroll, gjenbruk av innhold og alle de andre trendene vi har diskutert.

Dette leder oss direkte til digital experience stacks, som handler om å bruke de riktige verktøyene for deg og stable dem riktig. En DES kan tilpasses dine spesifikke behov, men dette forutsetter at du velger verktøyene nøye. Husk at hvert nye verktøy er en "byrde" å vedlikeholde og drifte.

I Enonic arbeider vi med denne tilnærmingen. Vi sikter på å gi kundene de mest sentrale verktøyene for å lykkes. Vi jobber etter prinsippet om "innhold først" og tilbyr et composable CMS som lar kundene våre opprette og bruke innhold og tjenester på tvers av kanaler.

Takk, Thomas, for å ta deg tid til å snakke om disse trendene.

Bare hyggelig.

Først publisert 18. mars 2020, oppdatert 18. februar 2024.