Cloud Nine förklarar headless: Definition och fördelar
Headless har varit ett hett begrepp i den digitala världen i ett antal år nu. Men vad är headless och hur förhåller det sig till webbprojekt? I vår bloggserie “Cloud Nine förklarar headless”, tänkte jag försöka förklara begreppet och gå in lite mer på olika frågeställningar som brukar dyka upp.
Innebörden av headless e-handel
Vi börjar med lite bakgrund. Att en webbplats är “headless” innebär alltså att det bakomliggande systemet – i vår webbvärld oftast ett CMS eller en e-handelsplattform – ligger som ett separat system, medan presentationen av det till slutanvändaren är ett separat system. Informationen i systemet är frikopplat från presentationen. Hur det presenteras styrs sedan helt av ett fristående användargränssnitt (till exempel en webbplats) som inte “bryr sig om” varifrån informationen kommer och hur den skapats. Gränssnittet fokuserar istället bara på hur informationen ska presenteras för en besökare. Kommunikationen mellan systemen sker sedan via ett så kallat API (“Application Programming Interface”) som gör det möjligt för data att skickas fram och tillbaka mellan systemen.
Fördelar med headless
Så långt allt väl, men varför vill man göra på det viset? Vinsten med att innehållet inte längre är hårt knutet till presentationen, är att man nu har fritt fram att använda innehållet på andra sätt. Ska en mobilapp tas fram där samma innehåll ska användas, men presenteras på ett helt annat sätt? Behövs ett nyhetsflöde på en skärm i företagets lobby? Vill en partner presentera er information på sin webbplats? Den typen av saker möjliggörs helt plötsligt utan att man (åtminstone i teorin) behöver bygga om någonting. Att presentera information från samma system i flera kanaler är en av de stora fördelarna. Det behöver inte nödvändigtvis vara helt separata typer av kanaler heller, ett vanligt användningsområde är att ha ett bakomliggande system som tillhandahåller information till flera webbplatser, till exempel för en koncern med flera varumärken som har liknande behov men ska presenteras med helt olika grafiska profiler.
En annan aspekt är utbytbarheten. Om man vill göra om sin webbplats, behöver man inte nödvändigtvis byta ut allt; det räcker med att göra om presentationslagret. Detta gäller för hela webbplatsen, men går förstås också att applicera på enskilda delar av den. Man kanske bara vill byta ut startsidan eller hur produkter på en e-handel presenteras, och då kommer detta bli mycket enklare. Även små förändringar är lättare att göra, som att bara flytta runt eller göra om enskilda komponenter på en sida. Vill man byta ut CMS behöver man heller inte nödvändigtvis byta ut sitt presentationslager.
Många ser också fördelar med att när man inte behöver tänka på innehåll och design samtidigt, så är det svårare att göra fel. Ett klassiskt exempel är när redaktörer jobbar med innehåll som är strukturerat efter hur en sida kommer att se ut. Det medför ofta att man väljer att medvetet göra lite “fel” för att uppnå något specifikt. På många webbplatser kan det medföra att siten inte känns homogen och att designen spretar, men när man istället jobbar med innehåll utefter vad innehållet är snarare än hur det kommer att presenteras, är det inte längre ett lika stort problem.
/Ronnie Hillgren, Systemutvecklare