Det er ikke en disciplin, som man lærte på Journalisthøjskolen, dengang jeg gik dér ( fra 1992 – 1996) : valg af cms – måske fordi world wide web – det grafiske internet – kun så småt var brudt bredt igennem dengang. Jeg håber, det er tilfældet nu – fordi det er en nødvendig kunnen for onlinekommunikatører, som er ansvarlige for udviklingen af deres hjemmesider.
Jeg er langt fra ekspert i den ædle kunst at vælge et cms, men jeg har prøvet det et par gange. Desuden har jeg i mere end 12 år brugt mine arbejdsdage på at bruge, twiste og udvikle på diverse hjemmesiders publiceringssystemer – og dét i samarbejde med de aktuelle leverandører af sådanne systemer.
Det har så også givet mig – nogle gange dyrtkøbte – erfaringer med “do’s and don’ts” i forbindelse med leverandører, kontrakter og supportaftaler.
Overskrifterne for de mange elementer, der skal tages stilling til, er :
- Cms-arkitekturen
- Community
- Integration
Cms-arkitekturen
Stil og/eller overvej følgende spørgsmål til de cms, der bliver screenet. Følgende spørgsmål går på flere tekniske forhold ved et system :
- Er systemet fra starten tænkt som et cms til store såvel som små hjemmesider – eller er systemet tænkt som eksempelvis et intranetsystem, hvorefter det er blevet tilpasset det eksterne net? Det første er et absolut krav, hvis man skal undgå at kæmpe med medfødte fejl i systemet m.h.t. evne til at håndtere mange sider og ændre dem løbende
- Hvilken søgemaskine gør cms brug af, og hvor stor er fleksibiliteten i at kunne skrue på søgeparametre og resultatsider?
- Hvilket kodesprog er cms kodet i – fx php eller ruby on rails ? Et system kodet i et populært og fleksibelt kodesprog gør livet lettere for webredaktøren
- Er CMS’et designet til avanceret brug af tagging og taxonomi ?
- Er det stabilt?
- Er det skalérbart ? D.v.s. kan sitet udvides drastisk m.h.t. trafik og kompleksibilitet uden at det påvirker performance?
- Er det nemt at oprette mini- og kampagnesites?
- Følger cms best practice for kode jf W3C?
- Er backenden brugervenlig – d.v.s. er det nemt at forstå, hvordan nye sider bliver udgivet?
- Er systemet søgemaskineoptimeret, så dit indholdt nemt bliver fundet af Google, Bing mv.?
- Hvordan optimerer leverandører systemets loadtider?
- Er systemet gjort klart til at blive kodet i HTML5?
Community
Det er vigtigt, at det system man vælger har et aktivt community af udviklere og brugere, der løbende udvikler på systemet i takt med fremkosten af nye teknologier på nettet.
Et levende community af kodere og brugere, der diskuterer, inspirerer og deler viden er alfa og omega for et velfungerende system, som løbende udvikler sig. Det kan så være omkring et produkt – ejet og kultiveret af et firma eller et produkt skabt af brugerne som open source.
Det vigtigste er, at der ER et community med aktivitet. Det kan bl.a. hindre, at organisationen bliver bundet til een leverandør, såfremt firmaet tillader flere mindre firmaer om at stå for udvikling og implementering.
Integration
Endelig er det væsentligt, at et cms nemt kan kobles til og integreres med andre systemer. Det skal kunne bindes sammen med andre forretningssystemer , så data kan udveksles og præsenteres gnidningsfri . Endvidere skal det være muligt at binde cms sammen med nye teknologier, der bliver udviklet – sålænge disse har nogle åbne tekniske snitflader (API) .
Dermed bliver organisationen mindre afhængigt af at blive i det samme system, fordi et nyt system også kan kobles på virksomhedens forretningssystemer ( økonomistyringssystem, medlemssystem mv. )
Det spiller også ind med:
- Licens: skal brugeren betale licens for systemet, og hvor meget koster det om året?
- Udviklere: Hvad koster det per time at ansætte en koder til at foretage tilpasninger på systemet mv. Det hjælper ikke, at man betaler en billig penge for systemet – for dernæst at meget for at få udviklet selv den mindste service.
Eksperterne
Markedet oversvømmes i Danmark ikke i kurser i at vælge cms og stille de rette spørgsmål undervejs. Nedenfor er dog samlet nogle navne på firmaer, sites og personer, som jeg har arbejdet med eller fulgt – og som jeg i hvert fald kan anbefale:
Jboye ( konsulentfirma med mange erfaringer med cms og intranet )
Open Source CMS ( site hvor du kan teste hundredevis af open source-cms)
Børge Kristensen (pionér inden for brugervenlighed og webkommunikation. )
Klean (rådgiver i valg af cms)
Ole Nørskov (ekspert i onlinekommunikation og i opsætning af cms Drupal)
Advice Digital (konsulenthus digital kommunikation)
Det var mine umiddelbare tanker – og du er velkommen til at skrive nye forslag ind i kommentarfeltet nedenfor.
Godt overblik Kim. Derudover tænker jeg at CMS’er har en levetid – som ikke nødvendigvis er så lang som CMS’ets indhold. Derfor må en anden overvejelse gå på om det er vigtigt at systemet er godt til migrering:
1) Kan indhold importeres fra andre CMS’er (direkte eller via åbne standarder)?
2) Kan indhold eksporteres via åbne API’er eller åbne standarder?
3) Kan adressen (URL’en) på indholdet vælges/designes eller er det fastlåst af systemet. Hvis CMS’et vil bestemme hvordan adresser til indhold opbygges, kan en migrering betyde:
– at søgemaskiner skal re-indeksere indholdet
– at interne referencer mellem indhold knækker
– at indgående links og brugeres bookmarks ikke længere virker
Hej Jens
Du har da helt ret; det skal være muligt at hive data ud af systemet igen, den dag hvor man skifter til noget nyt. Det var faktisk een af mine bevæggrunde for blogwise at vælge WordPress.
Mht URL’en er det klart vigtigt. Jeg har set et cms for nyligt, hvor url’en er fuldstændig SEO-umulig – og eksporterede man f.eks. mit indhold derover ville alle referencer blive slettet.
Det er tre vigtige forhold, som du peger på – og som man ( vi = mig ) kan hænde at overse, fordi vi fokuserer på, at vi vælger noget for en lang periode – og glemmer, at vi skal kunne hive data ud igen, den dag vi skifter.
Hvis du går ned i detaljer som søgemaskineoptimering skal du også gå ned i detaljer som billed- og videohåndtering. Nu har jeg lavet en hel del store Drupal-sites i virkeligheden og billedhåndtering (antal pr. artikel, upload-workflow, beskæringsmuligheder, formatforhold osv. osv.) er lige så vigtig som søgemaskinehåndtering (fornuftige, autogenererede URL’er, XML sitemap osv. osv.)
Din tjekliste er meget god men kan også godt kombineres med en anden teknik til udvælgelse af CMS
1. Hvad er Open Source?
2. Hvad er populært blandt medier af min type?
3. Hvilke leverandører kan, med konkret udgangpunkt i konkret eksisterende hjemmesider, vise mig hvad jeg konkret får ud af at skifte til det ny CMS?
Jeg mener at redaktionen skal vælge CMS ud fra konkrete kig på konkret løsninger – kærligt vejledt af It-afdelingen. I praksis kommer redaktionene til at bruge 50 timer i CMS’et for hver time IT-afdelingen pusler om det.
Der står vist noget om det i en gammel artikel
http://vertikal.dk/a190
Nørskov skriver også at man ikke kan læse eller sammenligne sig til et godt resultat. Man skal have fat i kolleger eller eksperter og se virkeligheden før man kan vælge rigti klogt:
http://drupalog.dk/indhold/s%C3%A5dan-v%C3%A6lger-du-cms
Vi har heldigvis også gjort også overvejelser om eksempelvis ideerne bag Open Source – og hvad det kan give af fordele og ulemper.
Godt at du peger på håndteringen af billedsiden, fordi det er vi ( jeg ) nok ikke skarpe nok til at inddrage i overvejelserne på den rigtige måde, nemlig ud fra at vi er vant til , at det “da bare er inkluderet og kører” .
Til gengæld har jeg i min søgen efter CMS-muligheder husket at mødes med brugere af kød og blod, der sidder og redigerer sites i nogle af de systemer, der er blevet overvejet, sammen med udviklere som vedligeholder disse systemer.
Og et par enkelte eksperter har jeg også haft forbi, bare så jeg ikke forelskede mig i een vej, uden at tjekke om den fører det rette sted hen 🙂
Hej Kim, super spændende emne. Du rammer lige mit yndlingsemne 🙂
Som du Kim har jeg slået mine professionelle folder i diverse publiceringssystemer de senere år, og som du har jeg prøvet at hugge hæle og tæer i dagligdagen for at ramme et godt slutresultat.
Så jeg læste nøje din gennemgang, som jeg synes lægger op til en grundlæggende antagelse om at ét system skal løse alle nuværende og fremtidige udfordringer. Det tror jeg er en umulighed. – forstået på den måde at risikoen for alligevel at ende ud med noget, der ikke på operationelt niveau formår at indfri de strategiske forventninger er meget stor.
Når jeg vælger cms for en kunde, er der groft sagt kun følgende fire overskrifter i kravspec.
– indholdsstyring
– brugerorganisering
– udviklerressourcer
– serverkapacitet og it struktur
Inden man vælger, er det mest vigtigt, man gør sig umage med de strategiske og operationelle mål, som systemet skal hjælpe dig i land med. Og det er en rigtig god ide som Steven er inde på at bruge mere tid på at undersøge hvad de andre bruger og hvorfor, end at bekymre sig om detaljer i et bestemt cms, man måske har fået anbefalet. Og så er jeg enig i, at man skal vide hvordan man får sit indhold UD igen på en kløgtig facon, men igen: er det ikke også en detalje? Det er vel blot at kræve et xml-output, tænker jeg.
Hvis man står og skal igang er der iøvrigt et godt best practise papir at hente hos Jboye, som jeg kan se står på din liste.
Tak for et spændende indlæg. Det er ikke så tit, indlæg får mig i blækhuset 😉
Kære Elisabeth
Jeg beklager, hvis mit indlæg kunne læses som om, at jeg advokerer for “one size fits all” eller “one system to rule them all”. Det er bestemt ikke, hvad jeg mener.
I den store cms-implementering, som jeg er i gang med lige nu er mit og mine kollegers fokus nemlig kun at bruge systemet til det, som det er bedst til – og så vælge andre systemer til det, som de er udviklet til.
Eksempelvis vælge et video-cms til video frem for at tweake cms’et til det eller bruge et dedikeret blogsystem til blogging frem for at tvinge cms’et til det.
bh