Jag har aldrig använt en cirkelsåg, så jag föredrar att kapa brädor med borrmaskin. Att prova nya saker kan vara skrämmande, men om vi vågar ta steget utanför vår komfortzon och väljer vad som faktiskt passar för uppgiften istället för vad som instinktivt känns tryggt så kan vi nå bättre resultat på kortare tid och dessutom lära oss någonting på vägen!
Innan man funderar på vilken plattform man skall använda bör man samla in vilka behov man har. Med en tydlig kravställning på plattformen ökar sannolikheten att man väljer rätt. I denna artikel kommer vi gå igenom ett axplock av frågor som man gärna vill besvara innan man tar sitt beslut:
Tredjepartsintegrationer är ofta en ganska kostsam del av ett projekt. Framförallt initialt, men de kräver oftast också en del underhåll. Många tredjepartsintegrationer tillhandahåller moduler till olika programmeringsspråk och plattformar. Helst vill vi använda så många som möjligt av dessa, dels för att inte uppfinna hjul, men också för att slippa underhålla lösningarna själva. Om vi vet vilka tredjepartsintegrationer som kommer att användas så kan vi se vilka moduler som finns tillgängliga och genom vårt val maximera utnyttjandet av dessa. Vi kan också på förhand bedöma kvalitén på integrationerna och se huruvida de är användbara för den aktuella lösningen.
Många system är skräddarsydda för en specifik verksamhet och då saknas oftast användbara moduler för externa integrationer. När projekt till stor del innefattar integrationer av denna typ kan det vara klokt att välja en plattform som är enkel att skriva integrationer för. Här levererar generellt ramverken renare integrationer som är enklare att underhålla än motsvarande lösning implementerad i ett CMS. Detta eftersom ramverk fokuserar mer på flexibilitet än att leverera en snabb "one-size-fits-all"-lösning. Om du inte riktigt vet skillnaden på ramverk och CMS så kan du läsa mer om det här.
Om man bygger en kampanj som ska leva i en månad kan man med gott samvete välja den plattform som snabbast tar en i mål. Eventuella licenser spelar inte så stor roll i sammanhanget och hållbarheten i lösningen är inte prioriterad. Vill man däremot maximera livslängden i lösningen så finns det ett gäng faktorer att ta i beaktning:
Detta är bara ett axplock, vi har skrivit en artikel om att bygga hållbara lösningar om du vill läsa mer.
Olika plattformar kommer med olika ekosystem. Det kan finnas mycket att vinna på att utreda vad som gynnar en mest. Skall man t.ex. ha en katalog-webbshop så kan det vara kostnadseffektivt att välja WordPress med WooCommerce för e-handel. Vill man istället bygga ett API till en mobilapp så kanske en Django-lösning är ett bättre val. Bygger man ett multisajtnätverk med språkstöd kan Episerver/Optimizely CMS eller Umbraco CMS vara ett rimligt val. Vill man ha både ett bra headless API, en E-handel och ett multisajtnätverk med språkstöd så får man överväga vilket ekosystem som ger en mest "gratis" och så får man bygga resten själv.
För de flesta hyfsat statiska webbplatser så kan man med hjälp av cache klara mycket trafik mer eller mindre oberoende av vilken plattform man väljer. Men om man har inloggade lägen där mycket innehåll blir unikt för varje användare blir det lite klurigare. Här är det ofta bra att välja en plattform som gör det enkel att sprida ut lasten på flera servrar och där plattformen i sig är resurssnål. Generellt är det fördelaktigt att välja ramverkslösningar för applikationer som behöver servera många användare samtidigt med korta svarstider eftersom ramverk ofta är resurssnåla och skalbara av sin natur.
Om det är önskvärt att servera data till mer än konventionell web, t.ex. mobilappar, TV-skärmar, etc. så kan det vara fördelaktigt att välja en plattform där det är enkelt att definiera sina egna datastrukturer och leverera dessa via ett API. Här gör de flesta plattformar jobbet efter lite handpåläggning, men ramverkslösningar levererar generellt renare implementationer med snabbare svarstider.
Enkla och anpassade administratörsgränssnitt är väldigt viktigt för plattformar som är redaktionellt tunga och där innehåll produceras i stora volymer. Om det negligeras kan de administrativa kostnaderna springa iväg och mycket tid måste investeras i utbildning av systemet. I andra fall där man inte förväntar sig några större ändringar av innehållet efter lansering kan utvecklingstimmarna som krävs för att skapa en trevlig redaktionell upplevelse överstiga värdet som det tillför. Jobbar man med ett CMS är administratörsgränssnitten oftast ganska bra från början och kan bli väldigt bra med mindre handpåläggning. I ett ramverk behöver man göra mer för att få det bra, uppsidan är istället att man helt kan skräddarsy det redaktionella gränssnittet, både design- och flödesmässigt. Detta gör att ramverk ofta är bättre när innehåll skall kunna administreras av slutanvändare och att CMS ofta blir kostnadseffektivare när det kommer till att producera innehållstunga plattformar.
En annan aspekt kring administrationsgränssnitt är flexibilitet. En liten grupp administratörer med insikt i plattformens koncept, hur moduler ska användas och med ett öga för design har mycket att vinna på att gränssnittet är flexibilitet. Kan man lägga in vilka moduler man vill på vilka positioner man vill kan man lösa mycket utan att behöva blanda in utvecklare. Men flexibilitet kommer med ansvar: Om man är många administratörer behöver mycket tid sannolikt läggas på moderering och kvalitetssäkring av materialet. Flexibla gränssnitt tenderar också att ha en högre inlärningskurva och upplevs ofta som "svåra", varför det ofta är bra att istället reglera möjligheterna ganska hårt i administratörsgränssnittet.
När alla krav, behov och insikter samlats in kan vi börja leta efter tänkbara plattformar. Hos oss på Fröjd görs utvärderingen primärt av utvecklare eftersom det till stor del handlar om att läsa teknisk dokumentation, se helheten kring kommunikation mellan system och att uppskatta hur stora anpassningar som kommer att krävas för respektive lösning. Vidare presenteras vilka för- och nackdelar varje plattform innebär för hela teamet, från både Fröjd och kunden, som tillsammans beslutar väg framåt. I beslutsprocessen är det viktigt att utvecklare, redaktörer, IT och övriga stakeholders är involverade så att alla intressenters behov är representerade och projektets förmodligen största beslut får förankring.
Genom att följa de här frågeställningarna istället för att gå på vad utvecklarna och/eller redaktörerna "redan kan" ökar oddsen att välja rätt lavinartat. Det är läskigt att ge sig ut på okänt vatten, men en bit in i projektet kommer det att löna sig. Plattformsval är för viktigt för att lämnas åt slumpen.
Att kontinuerligt jobba med användningstester under design- och utvecklingsprocessen är väsentligt för att undvika frustrerade och missnöjda användare. Dessutom kan det bli väldigt tidskrävande och kostsamt att åtgärda “fel” när produkten är färdig och lanserad.
Efter offentlig upphandling inleder Sunne kommun och Fröjd ett samarbete för utveckling, support och förvaltning av kommunens webbplats sunne.se.
För att säkerställa att våra kunders digitala plattformar alltid är framtidssäkrade och presterar på topp, genomför vi regelbundet uppgraderingar och förbättringar. Ibland kommer en större versionsuppdatering av det CMS man använder vilket innebär att uppgraderingen kan bli mer komplex än vanligt. Det är viktigt att uppgraderingen genomförs, både ur ett säkerhetsperspektiv och för att kunna dra nytta av CMS:ets fulla potential. Ett aktuellt exempel är vårt arbete med Transportföretagen, där vi för närvarande uppgraderar deras applikation till Optimizely 12.
På Fröjd hjälper vi våra kunder att jobba smartare och mer effektivt med hjälp av AI. Med vår inspirerande workshop och en skräddarsydd roadmap säkerställer vi att ni får ut det mesta av AI-teknologin.
