– Jag tycker att headless är bra – för de som behöver det

Som teknikföretaget Dekode är att vi får många förfrågningar om vilken typ av strategi som är rätt för en given kund. Flera av dem som kontaktar oss har ofta varit i dialog med flera företag. De har också fått olika rekommendationer om vilken riktning de bör ta när det gäller teknik. En av de termer som oftast dyker upp i våra dialoger är Headless. Men vad innebär det egentligen att ha en headless webbplats?

Vad är huvudlös?

Direkt översatt är headless headless. Det betyder att webbplatsens visuella gränssnitt och administrationsgränssnitt är två olika system. Det vill säga att de är frikopplade från varandra och är utvecklade som två separata system. Samspelet mellan de två sker med hjälp av gränssnitt som underlättar kommunikation mellan datorer. Eller ett API som det kallas. Ofta körs systemen också på olika servrar. Tidigare har webbpubliceringssystem ansvarat för både innehållshantering och innehållspresentation. Det är just denna separation mellan hantering och presentation i olika system som är Headless. 

Så varför pratas det så mycket om Headless egentligen? Och vem borde ha en headless webbplats? 

Den första frågan jag tycker vi borde ställa oss är: Vad ska webbplatsen göra för min organisation?

Det behov som webbplatsen ska lösa är en avgörande faktor. Ska webbplatsen lösa ett kommunikationsbehov? Utlösa försäljning i form av tjänster? Driva direktförsäljning eller lösa komplexa användarbehov? I många organisationer kan det finnas mer än ett av dessa.

Vi kan göra detta lite mer konkret med ett exempel som är relevant för många av våra kunder. Vi i Dekode har många kunder inom samhällsnytta-segmentet. Organisationer som både har stora behov av kommunikation och att webbplatsen kan underlätta försäljning av produkter och insamling av pengar. Relativt stora uppgifter för en webbplats att lösa med många olika system i backend som vart och ett har sitt eget specialområde. En mängd system som ska lösa kommunikation, försäljning och kundhantering. Är headless rätt väg att gå för en sådan kund? 

Mikrotjänstarkitektur

Om vi ​​skulle lösa just detta exempel med headless, skulle vi kunna utveckla detta fall med en microservice-arkitektur. En annan term som många så småningom känner till. Istället för att skapa ett stort system är systemet uppdelat i många små delar som sys ihop för användarna. I en ideal värld märker användaren inte att de navigerar mellan dessa. Varje enskild del av webbplatsen har helt dedikerade uppgifter. En del av webbplatsen löser kommunikation, en annan del löser webbutiken. Den tredje delen löser fundraising och den fjärde tar hand om kunddata såsom personuppgifter och orderhistorik. 

Dessutom är det upp till det visuella teamet att knyta ihop detta. Men med det i åtanke kan vi behöva ett femte system som gör det möjligt för redaktörer att kombinera alla dessa datakällor så att det ser bra ut för användaren. För att användaren ska uppleva alla dessa delar som ett ekosystem är det också vettigt att ha ett designsystem som omfattar alla ovanstående delar av användarresan.

Genom att göra detta på rätt sätt kan man få ett välfungerande system som har färre uppgifter och dedikerade personer som underhåller de olika delarna. Webbteamet implementerar delkomponenterna och får dem att kommunicera med varandra. 

– Jag tror att det finns många som frågar efter headless utan att veta vad det betyder, och är influerade av att termen har blivit så populär.

I princip är headless en skalbar metod för att skapa webblösningar. Ändå finns det en möjlighet att du nu funderar på din egen organisation och funderar på om du har de nödvändiga resurserna för att genomföra ett sådant projekt. Och inte minst, om det har beaktats att de som ska arbeta med webblösningen har den nödvändiga kunskapen som behövs för att underhålla ett sådant system. Är det ens ekonomiskt lönsamt att ha så många dedikerade roller? 

Personligen har jag arbetat med headless i ett antal år i en organisation där headless var absolut rätt väg att gå. Jag arbetade i en organisation där produkten var en musikstreamingtjänst. Systemen för att driva en sådan organisation är inte direkt något man kan köpa från vilken leverantör som helst. Där implementerade vi mikroservicearkitektur och all data utbyttes via API:er. Vi hade dedikerade team för varje enskilt system och dedikerade designavdelningar för både webbplatsen och de appar vi sålde. 

Som jag tror att ni kan se tycker jag att headless är väldigt bra – för de som behöver det. Jag tror att det finns många som kräver headless utan att veta vad det betyder och är influerade av att termen har blivit så populär. Jag menar inte detta för att Dekode arbetar främst med WordPress. Det finns mycket goda möjligheter att göra headless med WordPress. Jag har själv valt headless WordPress för delkomponenter i ovanstående företag. Jag tror att beslut styrs av vad som är populärt och inte nödvändigtvis vad som är bäst för organisationen eller kunden.

Om vi ​​skulle vända på exemplet ovan med en välgörenhetsorganisation och implementera detta med WordPress, skulle vi kunna lösa presentationslagret för kommunikation, webbutik och insamling i ett system. Alla dessa skulle kunna hanteras i samma gränssnitt. Alla system som organisationen använder skulle uppdateras när kunder vidtar åtgärder på webbplatsen. Redaktörer kan arbeta med innehåll och kombinera alla delar de behöver utan att byta system. De använder visuella innehållsblock som är i linje med deras eget designsystem i ett gränssnitt som visuellt liknar det som kunderna kommer att möta. När vi ser att det är vettigt att skapa något headless, gör vi det som en integrerad del av webblösningen, men ser till att publicering och underhåll av webbplatsen är lättförståeligt och visuellt tilltalande.

WordPress eller headless WordPress?

Vårt tillvägagångssätt är att ha ett pragmatiskt förhållningssätt till kundens behov som löser organisationens behov på ett sätt som är hållbart för kunden. WordPress är ett system med öppen källkod. Det betyder dock inte att WordPress inte kan anpassas till kundens behov så att det blir kundens verktyg. Och ja, vi använder även tredjepartsleverantörer för att effektivisera datautbytet mellan olika system. Men då har vi alltid en gemensam källa som skickar datan – nämligen WordPress.

Vi i Dekode arbetar hårt med att skapa bra redigeringsverktyg. Vi är engagerade i att säkerställa att redigeringsupplevelsen ger bästa möjliga intryck av de färdiga sidorna under redigeringsprocessen. Vi gör detta genom att skapa bibliotek med innehållsblock eller moduler. För att underlätta detta kodar vi blocken i administrationsgränssnittet med React. Genom att använda headless måste alla dessa block också utvecklas för frontend-ramverket i det ramverk som används. När man utvecklar något headless måste man också ta hänsyn till att alla andra aspekter av att bygga en webbplats måste utvecklas från grunden, inklusive menystrukturer, URL-strukturer och allt som rör sökmotoroptimering. Man måste också fokusera på att utveckla alla verktyg som kommer att användas för kommersiella ändamål, såsom spårning och integration med analysverktyg.  

Ett pragmatiskt tillvägagångssätt

Dekode kan leverera både vanlig WordPress och headless WordPress, eller headless vad som helst för den delen – men vi har goda argument när vi väljer det. Istället för att påtvinga headless på en kund som inte behöver det.

Du bör vara pragmatisk med vilken teknik du väljer så att du inte låter tekniken styra hur organisationen fungerar. Om den görs på rätt sätt finns det mycket teknik som kan hjälpa organisationer att uppnå sina mål. Genom att vara medveten om var man ska börja från botten och vilka områden som bör underlättas så att redaktörer kan göra sitt jobb oberoende av ett utvecklingsteam – då tror jag att du har börjat i rätt ände.

Mollie

Vi har, i dialog med flera av våra kunder som önskat headless, gått igenom samma resonemang som beskrivits ovan. Genom att gå djupare in i kundernas behov finns det få fall där vi har kommit fram till att det är nödvändigt eller en bra resursanvändning att utveckla en headless-plattform. Ett av de sista fallen där vi hamnade med just detta val var för Mollie. Mollie är en holländsk betalningsleverantör. 

Mollies organisation kräver en kombination av flera typer av lösningar, både headless och icke-headless – men för sin globala webbplats valde de att använda WordPress på vanligt sätt. 

Detta val baserades specifikt på två viktiga faktorer; Mollie-redaktörer behöver ett verktyg som är skräddarsytt för deras behov och de förlitar sig på ett verktyg som har bred kunskap för dem som ska skapa innehåll. Och de ville ha en plattform där de kunde iterera snabbare utan att behöva underhålla flera kodbaser för att uppnå det designdrivna gränssnitt de vill att deras kunder ska möta.

Mollie är idag väl rustade att skala upp till nya marknader utöver de 7 där de är verksamma. Deras mål är att göra onlinebetalningslösningar enklare. Vi på Dekode är stolta över att kunna hjälpa företag som dem att uppnå sina mål.

Och inte minst, att skapa en bra lösning som passar deras behov – headless eller inte headless.