Tips

Så väljer du CMS

Vilket CMS ska vi ha?

Det är ofta den första frågan som ställs när man ska påbörja ett nytt webbprojekt - och det är inte så konstigt.

Man vill veta vad det kostar, vad man kan göra, hur det ser ut och hur det är att jobba i. Men att starta ett projekt med val av CMS är att börja i fel ände. Det är trots allt bara ett verktyg och i det avseendet är det ingen skillnad mellan ett CMS och andra typer av verktyg.

Bestäm först vad du vill göra.
Välj därefter rätt verktyg för att göra det.

Att slå i en spik med en skruvmejsel är hopplöst. Men den som av olika anledningar sitter fast i fel CMS känner säkert igen sig i liknelsen.

Projektets storlek

Den förväntade storleken på projektet kan ge oss massor av ledtrådar för att avgöra vad som är ett lämpligt CMS. Du vill välja ett CMS som varken är för litet eller för stort för dina behov. Ett projekts storlek kan mätas på en mängd olika sätt:

Förväntad mängd trafik
Antal webbplatser/domäner och språk
Den sammanlagda mängden sidor/information
Antal integrationer med andra system och deras komplexitet
Antal redaktörer som ska vara inne och jobba med webbplatsen

Vi kan ta två typiska exempel för att ge en bild av vad vi menar:

Företag A är verksamt inom tjänstesektorn och ser framför sig en ganska enkel webbplats med max 150 sidor. Webbplatsen ska administreras av en till två medarbetare på företagets enda kontor. Webbplatsens primära språk kommer att vara svenska, men man vill ha några sidor på engelska. Man har behov av att koppla på två andra system: anmälan till nyhetsbrev som ligger i MailChimp och pressreleaser som ska läsas in automatiskt från MyNewsdesk.

Företag B är ett B2B-företag inom industrin och har ett flertal kontor och närvaro i alla länder i Skandinavien samt Tyskland och Polen. Varje land ska ha en egen lokal webbplats under eget domännamn och information som är unik för just den marknaden. Företaget har ett gemensamt affärssystem där bl.a. alla produkter, deras lagerstatus och priser finns för respektive marknad. Detaljerade produktbeskrivningar och bilder ligger i ett separat PIM-system som är kopplat till affärssystemet. Varje land ska ha en ansvarig huvudredaktör och två till tre andra medarbetare som ansvarar för olika delar av webbplatsen. Man förväntar sig en stadig trafikvolym som framför allt drivs av det stora antal produkter man har i sin produktkatalog - över 100 000 artiklar. Dessa ska gå att beställa direkt från webbplatsen.

Det är ganska stor skillnad mellan dessa båda företags behov. Det ska man ta hänsyn till när man väljer CMS. Företag A klarar sig förmodligen med ett förhållandevis enkelt CMS och standardfunktionalitet. Företag B kommer att behöva ett CMS som kan hantera flera olika webbplatser i samma installation. Det ska ha ett väl utbyggt språkstöd, vara förberett för flera tunga integrationer och kunna hantera en stor trafikvolym kontinuerligt. Dessutom vill man förmodligen ha en e-handelsmodul kring vilken man bygger all funktionalitet kopplad till produkter och beställningar.

Det kan vara lockande att ta i ordentligt och välja ett CMS som innehåller långt mer funktionalitet än man har behov av i dagsläget bara för att man inte vill riskera att slå i taket senare. Och ett visst utrymme för tillväxt är bra, men inte för mycket. Tänk ungefär som när man ska välja skor till barnen: det ska finnas gott om plats att vicka på tårna, men det ska inte vara som när man klär ut sig och lånar mammas eller pappas skor.

Flexibilitet kontra enhetlighet

Vill man ha mycket frihet och kunna bygga sidor efter eget tycke eller vill man ha ett enhetligt utseende som inte lägger så mycket ansvar på redaktören avseende sidornas utformning? Detta är inte enbart en egenskap hos själva CMS:et utan också ett vägval man gör när man utvecklar webbplatsen. Men det är trots allt så att olika CMS har olika förutsättningar för att antingen bygga ut eller strama upp redigeringsmöjligheterna för redaktörerna.

Även här kan det vara lockande att bara lämna allt öppet för redigering - flexibilitet är ju generellt en bra egenskap. Men om vi tittar på Företag A och Företag B igen så kommer de förmodligen ha lite olika behov även här.

Företag A:s webbplats ska administreras av max två personer. De sitter på samma kontor och träffas dagligen. Dessutom arbetar båda med marknadsföring och en har en bakgrund som grafisk formgivare. Förutsättningarna för att kunna hantera stor flexibilitet i CMS:et är med andra ord mycket god. De kommer själva vilja utforma sidorna i hög grad och därför är ett mer öppet och flexibelt administrationsgränssnitt att föredra.

Företag B kommer att ha redaktörer utspridda över hela norra Europa. En del, men inte alla har erfarenhet av redaktörsarbete på webben sedan tidigare. Någon är säljare, en annan produktchef. De kommer att ha flera parallella webbplatser för olika marknader på olika språk. Det är viktigt att alla kunder, oavsett land, får samma känsla för varumärket och känner igen företagets grafiska identitet och tonalitet i bilder och texter. För Företag B:s redaktörer är det snarare jobbigt med allt för stor flexibilitet. Hur ska det se ut egentligen? Därför är det en trygghet att veta att sidornas utformning följer företagets uttryck redan från början och lämnar lite utrymme för tveksamheter.

Funktioner i CMS:et som är relevanta att titta på när man ska utvärdera utifrån flexibilitet/enhetlighet är till exempel:

Funktionalitet för flexibla layouter, t.ex. att man kan bygga upp unika sidor genom en blockstruktur.
Möjligheter att arbeta med bildredigering.
Möjlighet att automatiskt styra hur långa texter får vara.
Möjlighet att kontrollera typografi, t.ex. rubrikstorlekar, färger på text och olika former av listor och indrag.

Det normala är att alla ovanstående funktioner implementeras när man bygger webbplatsen i CMS:et, men man balanserar graden av flexibilitet beroende på vad behovet är.

Kostnad

Vad kostar det? En jätteviktig fråga. För att förstå vad ett CMS kostar behöver man titta på olika typer av kostnader. Det kan finnas:

En engångskostnad för inköp
En löpande licensavgift
Kostnad för hosting
Kostnad för support

Den största faktorn som påverkar kostnaden är CMS:ets licensform, dvs. om det är ett kommersiellt CMS eller om det är licensierat som öppen källkod. Det förekommer även hybrider där viss basfunktionalitet är öppen källkod, men vill man ha vissa specifika moduler så får man betala för dem.

Kommersiellt eller öppen källkod?

CMS baserade på öppen källkod kommer alltid att vara billigare än Kommersiella CMS. Det är omöjligt att vara billigare än gratis. Men man ska vara medveten om att licenskostnaden bara är en av de kostnader man har när man ska bygga och hosta en webbplats. Återigen är det behoven som styr och kommer att avgöra vad som blir dyrt eller billigt i det långa loppet. Låt oss titta lite på hur förutsättningarna ser ut för de två alternativen.

Kommersiella CMS har ett företag bakom sig som tjänar pengar på att licensiera sin mjukvara. För att kunna ta betalt måste de ha en konkurrenskraftig produkt. Det innebär dels att de kontinuerligt måste vidareutveckla och förfina sin mjukvara för att inte gå under, dels att de måste hålla sina befintliga kunder nöjda med välfungerande support, utbildningar, hosting och andra tjänster kring produkten. Episerver är ett bra exempel på ett CMS som faller under denna kategori.

Öppen-källkod-CMS fungerar enligt helt andra principer. Man låter vem som helst använda mjukvaran gratis, men kan samtidigt inte garantera att den ständigt underhålls och är buggfri och konkurrenskraftig. Det är i mångt och mycket upp till frivilliga krafter, ofta de som använder produkten, att fixa buggar eller bidra med ny funktionalitet. Den dokumentation som finns är också till stora delar framtagen av användarna själva. Support får man från andra användare, oftast via forum.

Det finns dock exempel på hybrider, dvs. företag som har anställda och en kommersiell verksamhet samtidigt som deras produkt är licensierad som öppen källkod. Umbraco är ett bra exempel på det. Företaget Umbraco HQ ansvarar för att koordinera utvecklingen och marknadsföringen av Umbraco som CMS och säljer samtidigt hosting, tilläggstjänster, utbildningar och support kopplat till CMS:et. På så vis kan de ha en hög grad av kontroll över CMS:ets utveckling samtidigt som användarna slipper betala licenskostnader.

Var ligger kostnaderna?

Oavsett vilket CMS man väljer så kommer man att ha kostnader. Generellt kommer de att vara lägre för CMS baserade på öppen källkod, men man tar samtidigt en större risk utan en kommersiell garant som står bakom produkten. Kommersiella CMS tenderar också att vara bättre förberedda med färdig och väl genomtestad funktionalitet för lite mer avancerade tillämpningar. Det man betalar via licenskostnaden kanske man då slipper lägga på konsulttid som går till att fixa instabil kod eller till att utveckla funktionalitet som helt enkelt inte finns i grundprodukten.

Hosting och support kostar alltid oavsett vilken lösning man väljer. De flesta CMS erbjuder idag molnbaserad hosting vilket är smidigt eftersom man får en hostinglösning som är både skalbar och beprövad. Support tillhandahålls nästan alltid via den partner som byggt webbplatsen. Varken Umbraco eller Episerver erbjuder support direkt till slutanvändare. Skulle du anlita Limetta så är det alltså vi som tar emot alla supportärenden. Kan vi lösa dem på egen hand så gör vi det, annars tar vi det vidare med CMS-leverantören i egenskap av deras partner.

Alltså: det är generellt billigare med öppen källkod, men det finns en risk att det kan blir dyrt ändå i slutändan om man behöver utveckla mycket funktionalitet som inte redan finns färdig eller om produkten inte utvecklas i den takt man bör förvänta sig.

Dåligt gränssnitt - en dold kostnad

Det finns också en kostnad som är dold, men som kan växa sig stor på sikt utan att man ens är medveten om det. Om CMS:et fungerar dåligt - allt är väldigt krångligt och det tar lång tid att göra även grundläggande saker - så kommer redaktörer att lägga oproportionerligt mycket tid bara på att försöka lösa problem. Varje extra timme som läggs på bökig bildhantering, editorer som strular och sidor som inte ser ut som de ska kostar pengar.

Två timmar extra varje vecka till följd av strul är inget unikt. Slå ut det på tre år så får du cirka 300 timmar. Det motsvarar nästan en hel årslön för en junior medarbetare!

Användargränssnitt

Det fanns en tid då användargränssnitten skilde sig radikalt från ett CMS till ett annat. Det gjorde det till en stark faktor när man skulle välja CMS. Idag är det inte en lika stor faktor eftersom CMS:en tenderar att likna varandra mer och mer både i utseende och funktionalitet. Man har ett mediebibliotek där man laddar upp bilder och dokument, man har ett sidträd där man skapar och flyttar runt sidor osv.

Men exakt hur man laddar upp en bild eller flyttar en sida kan fortfarande skilja sig en hel del. Olika funktionalitet tenderar också att vara mer eller mindre utbyggda i olika CMS beroende på vad utvecklarna har valt att lägga fokus på. Några saker att titta på och ta ställning till är:

Bildredigering Ladda upp, skala, beskära, optimera, automatisk storleksanpassning, sätta fokuspunkt i bilden osv.
Blockbaserade layouter Möjligheten att skapa innehållsblock och kombinera dessa för att bygga upp sidor. Även möjlighet att skapa block som man kan återanvända på flera olika sidor.
Drag and drop Finns det och fungerar det på likartat sätt oavsett man man flyttar sidor, laddar upp bilder eller flyttar block?
Antalet moment eller klick för att göra rutinsaker Hur lång tid tar det att komma i ett läge där man kan göra det man skulle göra, t.ex. kan byta ut en bild eller ändra en text? För många steg för att ens komma dit du vill kan bli irriterande i längden.
Navigation och menyer Hittar man bland funktionerna? Heter saker det man förväntar sig att de ska heta? Finns det kontextmenyer eller snabbkommandon?
Användare och rättigheter Är det begripligt hur man skapar användare och ger dem rättigheter i CMS:et? Går det att koppla till ett centralt system för användarhantering, t.ex. Microsoft Active Directory?

Kan du det sedan tidigare?

Om man som redaktör har erfarenhet från ett visst CMS sedan tidigare och har lärt sig alla knep i det är det en inte helt oviktig faktor att ta i beaktning. Att lära om kan att bli en tröskel att ta sig över i samband med att man byter CMS. Samtidigt blir det fel i prioriteringen att välja CMS enbart utifrån redaktörernas tidigare kunskaper, men med allt annat lika kan det vara en fördel att välja ett CMS som man vet att man behärskar.

Vilka är de vanligaste CMS:en?

I undersökningen "Hur mår Sveriges webbplatser" har man under ett antal år frågat företag, statliga verk, kommuner, landsting och organisationer runt om i Sverige vilket CMS de använder. Där ser man tydligt att det finns en handfull CMS som återkommer år efter år. Dessa är (i storleksordning):

Optimizely (fd Episerver)
SiteVision
Wordpress
Drupal
Umbraco och SiteCore på delad femteplats

Optimizely (fd Episerver), SiteVision och SiteCore är kommersiella CMS medan Wordpress, Drupal och Umbraco är öppen källkod. Överlägset störst enligt undersökningen är Episerver, men det beror delvis på att man har frågat ett begränsat antal (runt 500) intressenter. Hade man t.ex. frågat alla Sveriges företag så hade listan förmodligen sett väldigt annorlunda ut.

Men den är fortfarande relevant. Vi känner igen samtliga CMS på listan, men kommer oftast i kontakt med Episerver och Umbraco, vilket inte är så konstigt eftersom det är de två primära CMS:en som vi har valt att fokusera på och marknadsföra oss mot.

Teknisk bas för de olika CMS:en

Alla CMS är i sin tur utvecklade i programmeringsspråk och utvecklingsmiljöer. Tittar vi på vår topplista så ser det ut som följer:

Optimizely (fd Episerver) - Microsoft .NET
SiteVision - Java
Wordpress - PHP
Drupal - PHP
Umbraco och SiteCore - Microsoft .NET

De vanligast förekommande utvecklingsmiljöerna finns alla representerade i listan ovan. Detta är en faktor som man kommer behöva väga in när man ska välja ett nytt CMS, framför allt om man vill integrera CMS:et med andra system som man redan har eller om man har tänkt sig att använda en befintlig hostingmiljö. Generellt är det enklare att integrera olika system om de har samma tekniska utvecklingsmiljö, speciellt om systemen är dåligt förberett för integrationer med andra system. Men det behöver inte vara ett stort problem om det redan finns väl dokumenterade och API:er för integrationer. Oavsett så bör man titta på detta och göra en analys innan man väljer CMS så man inte fastnar i en integration som blir onödigt krånglig.

En annan långt viktigare faktor är kunskapen om utvecklingsmiljön i teamet som ska bygga webbplatsen. De flesta utvecklare är specialiserade på en miljö eftersom det är svårt att behålla en hög kompetensnivå om man har för många olika plattformar att bevaka och vidareutbilda sig inom. Ser man på Limetta som exempel så har vi valt att fokusera på Microsoft .NET och CMS:en Episerver och Umbraco just av den anledningen. Det innebär att val av CMS och dess teknisk basmiljö alltid kommer att ha en direkt koppling till val av samarbetspartner för att bygga webben.

CMS:ens historia

Precis som många andra produktkategorier har CMS:en utvecklats i faser. Årtalen och faserna är såklart inte exakta, men ger en ungefärlig bild av hur utvecklingen har sett från början ut fram till idag.

Specialbyggt (1995-2000)

Från allra första början utvecklades i princip alla administrationsverktyg specifikt för det enskilda webbprojektet. Även om man fick exakt de administationsmöjligheter som projektet krävde var det både tidskrävande och dyrt att bygga och underhålla. Ovanpå det fick man inlåsningseffekten, dvs. att man som kund blev bunden till den leverantör som utvecklat systemet eftersom det ansågs för komplext för någon annan att ta över. Valde man trots allt att vända sig till någon annan var rekommendationen i nio fall av tio att skrota allt och bygga om det från grunden.

Återanvänt (2001-2005)

Så småningom upptäckte man att administrationsbehoven var likartade oavsett projekt. Många webbyråer tog då det egenutvecklade system man var mest nöjd med och började återanvända det i flera projekt för flera kunder.

Eftersom systemet från början var byggt för en viss kund i en viss bransch så kunde man ofta se spåren av detta i hur systemet var uppbyggt. Om den ursprungliga kunden t.ex. var en tidning så byggde mycket i CMS:et på ett redaktionellt tänk. Om kunden däremot var en designbyrå eller ett premiumvarumärke så låg fokus mer på finish och design. Under denna tid var val av CMS verkligen avgörande eftersom variationen var så stor.

Till en början var det i stort sett en byrå - ett CMS som gällde, dvs. alla hade sitt eget CMS och försökte övertyga kunderna om dess förträfflighet. Men ganska så snart började CMS:en leva sitt eget liv.

Fristående produkter (2006-2018)

Under denna period försvinner majoriteten av de egenutvecklade CMS:en sakta men säkert. Många dör när byrån som utvecklat dem lägger ner eller köps upp. Andra fasas bara ut till förmån för mer standardiserade lösningar.

En del blir dock kvar och vidareutvecklas antingen inom ramarna för öppen källkod eller som kommersiella produkter. Det är flera starka krafter som sammantaget bidrar till denna konsolidering på marknaden:

Byråer som tröttnar på att underhålla och vidareutveckla sina egna CMS.
Kunder som inte vill betala för standardfunktionalitet eller vara bundna till en specifik leverantör.
En öppen-källkodsrörelse som växer.
Ekosystem som växer upp kring de mest framgångsrika CMS:en med support, utbildningar, certifieringar, dokumentation och insticksprogram.

Fram växer också ett allt mer standardiserat sätt att se på innehållshantering på webben. De mest dramatiska skilnaderna mellan produkterna slipas gradvis ner och CMS:en kommer med tiden att likna varandra mer och mer både avseende funktionalitet och användargränssnitt. Den segmentering som fortfarande finns kretsar mer kring nivå på installationen (enterpriselösning kontra enkelt bloggverktyg) och krav på prestanda, integrationsmöjligheter och avancerade tilläggsfunktioner inom t.ex. e-handel, internationalisering eller SEO .

Standardprodukter (2019-nu)

Under många år presenterade det amerikanska konsultföretaget Gartner rapporten "Magic Quadrant and Critical Capabilities Reports for Web Content Management systems" där man jämförde olika CMS och lyfte fram de man ansåg vara ledande i branschen. Men från och med 2019 års rapport är det slut med det. Gartner konstaterar krasst att skillnaden mellan olika CMS är för liten för att det ska vara relevant att jämföra dem på det sätt som man har gjort tidigare.

Det betyder inte att CMS:ens tid är förbi utan bara att marknaden har mognat och en viss standard kring CMS:en har etablerat sig. Behovet av att kunna publicera information kvarstår. I och med att allt fler av företagens andra system får någon form av koppling till webben så stärks CMS:ets roll. Man vill kunna erbjuda sina kunder alla sina tjänster på ett enda ställe oavsett om det gäller information eller funktionalitet och i det sammanhanget fungerar CMS:et ofta som en central knytpunkt.

Headless CMS

Headless CMS är ett samlingsnamn för CMS som till skillnad från traditionella CMS inte genererar några sidor på egen hand. Istället exponerar de den information redaktörerna lägger in via ett API som man i sin tur kan använda för att skapa sidor helt separat från CMS.et. Man har alltså brutit den starka kopplingen mellan CMS:et och sidorna som kännetecknar traditionella CMS och säger istället att CMS:et hanterar innehåll - ett annat system får avgöra vad man ska använda innehållet till och hantera vyerna. Eller på teknikspråk: man har separerat backend och frontend.

Headless är lite av ett modeord just nu och därför kan man lockas att använda denna arkitektur enbart för att känna att man ligger i framkant tekniskt. Men i grund och botten är det bara en sedan länge etablerad arkitektur (API:er) som har applicerats på ett CMS.

När det gäller headless CMS så finns det framför allt två scenarion där denna typ av arkitektur kan ge stora fördelar:

Du har flera olika kanaler som ska servas med information från ett enda centralt CMS. Du kanske har två olika webbplatser och en app som alla ska förses med innehåll från samma källa. Genom att sätta upp ett headless CMS får du ett enda system i vilket du administrerar innehållet och så hämtar alla webbplatser och appar sin information därifrån. Vill du lägga till ytterligare en kanal i efterhand så går det alldeles utmärkt så länge som den kan prata med det API som headless CMS:et exponerar.
Du har en datadriven webbapp där CMS-funktionaliteten inte är det centrala i projektet. Om du ska bygga en applikation vars huvudsakliga datakälla inte är ett CMS så ska man överväga headless. Troligtvis kommer den redan från början vara byggd för att hämta sin information direkt från API:er och kunna generera vyer utifrån den. Att då haka på ett API som exponeras av ett headless CMS parallellt med andra data-API:er är förhållandevis enkelt.

Men om du bara har en vanlig webbplats så finns det inga direkta fördelar med att välja headless.

Att införa denna arkitektur kommer också med ett pris i form av nackdelar. En stor nackdel är att du inte kan förhandsgranska den information du lägger in i CMS:et eftersom CMS:et i sig inte genererar några sidor. Det innebär också att all den funktionalitet som finns inbyggd i vanliga CMS för att generera sidor måste byggas helt separat.

Avslutningsvis

Vi har i denna artikel lagt mycket tid och kraft på att sammanställa vår samlade erfarenhet kring val av CMS. Förhoppningsvis har du fått lite bättre kunskap om vad du ska titta på när du jämför olika CMS i syfte att hitta det som passar era behov bäst.