Når der skal vælges platform til bibliotekets website

Sådan hænger frugterne på CMS-træet for Horsens Kommunes Biblioteker.

Horsens Kommunes Bibliotekers website har tidligere været genstand for heftig diskussion og der er bestemt plads til forbedring.

Jeg er således ved at kigge nærmere på en række løsningsmodeller og har en stak platforme i kikkerten. Men frugterne hænger ikke lige højt på træet.

WordPress – Frugten hænger lavt og er lige til at plukke

WordPress har mange fordele.

Til gengæld er der umiddelbart kun mulighed for én blog. Det kan dog muligvis omgås ved kreativ brug af systemets kategorifunktionalitet.

Det er muligvis problematisk at præsentere flere indholdstyper på samme underside. F.eks. en sidebar med relateret information.

WordPress vil være nemt at komme i gang med og relativt hurtig at implementere.

Drupal – Lækker, moden frugt, der kan nås med lidt anstrengelse

Drupal er meget fleksibelt, eftersom det er et content management framework. Man kan skræddersy sit CMS på basis af dette system.

  • Det er open source og omfattende dokumentation foreligger.
  • Behandler indhold som information; dvs. applikation, indhold og præsentation er hermetisk adskilt.
  • Ingen begrænsninger – Alt er principielt muligt.

Drupals fleksibilitet er måske også dets akilleshæl. Der skal således tages stilling til alt. Det kræver indsigt at udvikle løsninger i, og der skal bruges en væsentlig mængde tid på at sætte sig ind i det.

Drupal ville være en optimal løsning og jeg ville elske at kaste mig over det.

Sitecore – Medbring en stige for at plukke denne frugt

  • Horsens Kommunes Bibliotekers website kører på Sitecore i forvejen.
  • Bibliotekets website kører i samme løsning som Horsens Kommune og giver derved mulighed for sparring med kommunes webfolk.
  • Det kan utvivlsomt alt det, det skal kunne.

Sitecore er dog relativt kompliceret at udvikle templates til. Det hostes eksternt, hvilket giver biblioteket ringe kontrol med løsningen. Det meste skal købes som konsulentydelser eller der skal købes kurser. Back-end’en er tung at arbejde med og svær at finde rundt i for redaktører og vi mangler desuden en sand box.

Sitecore er således ikke umiddelbart lige til at kaste sig over.

Axiell Arena – Svaret blæser i vinden

Axiell bebuder et nyt produkt, Arena, som angiveligt integrerer website og OPAC i hidtil uset omfang.

  • Understøtter græsning og “berrypicking” i OPAC’en.
  • Tilsyneladende gode inspirationsmuligheder i OPAC’en.
  • Giver mulighed for brugergenereret indhold (kommentarer, anmeldelser, tagging etc).
  • Leveres med et open source CMS’et Liferay.

Der loves meget, men vi ved ikke ret meget om det endnu. Kortene holdes tilsyneladende ret tæt til kroppen. Det rejser dog flere spørgsmål:

  • Skal biblioteket vente og satse på Arena?
  • Er OPAC-delen så adskilt fra CMS delen, at CMS delen f.eks. kan opdateres uden at komme på tværs af OPAC-funktionerne?
  • Er der vandtætte skotter mellem applikation, præsentation og indhold?
  • Etc.

Implementering har således lange udsigter. Inkl. sitestrategi allertidligst i foråret 2009.

Min vurdering

Jeg er absolut mest stemt for en Drupal løsning. Drupal rocks. Men der skal kastes relativt mange ressourcer efter det, og det vil være halsløs gerning, hvis vi alligevel ender med at skulle skifte system, når Axiell Arena bliver sat i søen.

Sitecore vil der også skulle kastes mange ressourcer efter. Til gengæld er jeg ikke sikker på, vi vil kunne opnå en tilstrækkeligt fleksibel og, for redaktørerne, brugervenlig løsning. Derfor er jeg ikke så begejstret for at gå i gang med det.

WordPress vil være nemt at sætte i søen. Jeg er noget i tvivl om skalérbarheden, men meget vil kunne opnås, og det vil være sjovt at arbejde med.

Axiell Arena. Ja, svaret blæser i vinden.

Er du uenig i min vurdering? Smid en kommentar.

14 kommentarer til “Når der skal vælges platform til bibliotekets website”

  1. Spændende. Lige kigget på det der Liferay, som jeg ikke kendte. Det ser meget spændende ud, og hvis den tid skulle komme hvor folkebibliotekerne hopper på en fælles vogn der, så skal vi have lavet et godt udviklernetværk 🙂 Men næppe løsningen nu.

    Drupal – jeg har jo leget med det på meget lavt niveau. Utroligt nemt at installere (i hvert fald på et standard webhotel = ingen specialkrav). Som du skriver, så kan det stort set alt – men det vil kræve arbejde, at lave andet end standardløsninger baseret på core plus et par enkelte moduler.

    Men det er såmænd også rigeligt, hvis målet er et good looking cms, med det antal emne- og personblogs man ønsker sig. Det er utroligt nemt med prædefinerede tags (egne taksonomier kan laves tilknyttes forskellige indholdstyper som krævede eller frie), og sidevisninger baseret på delmængder af disse tags, at genbruge ethvert indholdselement mange forskellige sider på sitet, fx så bibliotekar Bech i sin blog skriver et godt indlæg i sin personlige blog, så dukker det også op i musikbloggen/-siden, og måske på forsiden osv. Sideblokke kan styres på sideniveau osv.

    Odsherred Bibliotek havde en kort overgang et Drupal site, der så lovende ud, men lige kigget og nu var det noget andet ikke-drupal-underligt-noget. Men det så godt ud så længe det varede – for reference, se evt. http://www.drupaldanmark.dk/billede/christina/odsherred_bibliotek

    Drupal-udviklerne har først nu erkendt behovet for en native drupal wysiwyg-editor, så den kommer nok desværre først om et års tid. Men der er tredjeparts-editorer, fx TinyMCE, som virker i Drupal, som de også gør andre steder… 🙁
    Når de får en ægte Drupal-editor, der kan tage højde for at brugerne selv kan skabe forskellige inholdstyper med forskellige inputformat-tilladelser, så er det lidt af en killer-app. 🙂 … Bare det, at den æder php-script direkte hvis man tillader det 🙂

    Held og lykke dernede i Horsens. Vi holder i Randers fast i et lokalt cms indtil august, hvor vi skal cms-evaluere og kigge os lidt omkring igen 🙂

    Hvis du går i gang med det, så kunne jeg godt være interesseret i lidt sparring.

    Svar
  2. Hej Morten

    Ja nu er jeg jo lidt farvet – efter mit hop fra Roskilde Bibliotekerne til en stilling som systemkonsulent ved Pentia, der oprindeligt udviklede Sitecore og stadigvæk er meget tæt på søsterselskabet Sitecore.

    Derfor vil jeg heller ikke komme med nogen anbefalinger, og ja jeg vil med det samme give dig ret i din vurdering af, at Sitecore har en ret stejl indlæringskurve i forhold til en lang række Open Source CMS på markedet.

    Men det skal dog også ses i lyset af, at Sitecore ikke som sådan er et traditionelt CMS, men er klassificeret som et enterprise CMF (content management framework).

    Sitecore er stort set baseret som en direkte udvidelse på .NET frameworket og derfor har man både adgang til alle mulighederne i Sitecore frameworket og alle funktionerne i .NET frameworket (hvilket stort set vil sige uendelige udvidelses- og integrationsmuligheder).

    Der findes da også nogle ret langhårede Sitecore løsninger, som slet ikke har noget at gøre med hjemmesider. Typisk løsninger, hvor der indsamles data på tværs af en række business applikationer (BizTalk, SAP, CRM osv.), der fremstilles og håndteres som en samlet præsentation via Sitecore.

    Dermed er det også næsten sagt, at kompleksiteten i Sitecore er langt større end i mere dedikerede CMS systemer, der typisk fokuserer langt mere på, at gøre det nemt, at vedligeholde et website og derfor ikke er konstrueret som hele frameworks.

    Men til gengæld er jeg nu langt fra enig i din vurdering af, at man ikke kan opnå en tilstrækkelig fleksibel og brugervenlig løsning for redaktørerne med Sitecore. Vi brugte Sitecore i Roskilde i 5 år med gode erfaringer og da man stort set kan konstruere en Sitecore løsning som man ønsker, kan man også lave stort set de brugergrænseflader, man selv ønsker. F.eks. har jeg set eksempler på redigering direkte i websiden, wiki style interfaces og sågar redigering via andre programmer som f.eks. Word og InfoPath.

    Hilsen
    Bo Breiting

    Svar
  3. Spændende diskussion, og jeg er helt enig med Kalle i, at et fælles biblioteksudviklernet kunne være en spændende og inspirerende ting. Både i forhold til cms’er, men også i forhold til de andre webrelaterede, der findes på bibliotekerne.

    I Københavns området er de faktisk allerede så småt i gang i samarbejde med Inlead, der har skabt skalerbare løsninger for 15 biblioteker, bl.a. Frederiksberg, Gentofte og Gladsaxe.

    Svar
  4. Jeg ville kigge endnu en gang på WordPress – systemet er efterhånden så fleksibelt at den skalerbarhed du efterlyser kan findes enten ved kreativ brug af template-tags eller ved plugins. Vil man absolut smide penge efter konsulenter, kunne man jo få udviklet et plugin eller to hvis man har særlige behov – der er efterhånden hooks til plugins overalt i koden, så der er stort set ikke noget der ikke kan ændres. Og processen fra html til fungerende tema er rimeligt ukompliceret når man først lærer basics.

    Drupal er bestemt et sympatisk system, og mulighederne er også mange, men vejen fra html-skitse til færdig tema er noget længere.

    Vil du have endnu en mulighed med i bunken, kunne det være MODx, som har mange fine features, en særdeles fornuftig administrationsdel og en meget nem vej fra html-skitse til færdigt tema. Det er blevet kaldt “a designers CMS”, og det er ikke helt ved siden af.

    Mht. SiteCore har jeg arbejdet med det i flere sammehænge, og aldrig mere! Jeg har aldrig været udsat for et mere restriktivt, kreativitetshæmmende og modsat-intuitivt system. Der er også grund til panderynker, når deres egen side ikke validerer hos W3C (om end der er færre fejl nu end sidst jeg checkede).

    Jeg er også interesseret i et biblioteksudviklernet, og vil da gerne lægge nogle timer i at sætte noget op, hvis jeg ikke er alene om det. 😉

    Svar
  5. Jeg så et (noget teknisk) indlæg om WordPress, som var lidt bekymrende. Åbenbart er wordpress noget tungt for webserveren uden nogle ekstra moduler sat på. Den bruger enormt meget CPU-kraft out-of-the-box, som er noget man lige skal have for øje ved installationen. Se artiklen “Behold WordPress, Destroyer of CPUs” fra Coding Horror:

    http://www.codinghorror.com/blog/archives/001105.html

    Ikke noget som dog iøvrigt skal afholde nogen fra at bruge wordpress.

    Svar
  6. I Herning har vi den samme diskussion (nu uden mig). Kommunen tilbyder en hosted Sitecore-løsning. Jeg har tidligere arbejdet meget med Sitecore og var med lige fra begyndelsen af Sitecore. Det gør dog ikke at jeg blindt vil anbefale systemet. Jeg synes at det kommer meget an på behovet og målgruppen.

    Det er min (omend korte) erfaring at biblioteker er anderledes end de private virksomheder jeg har været en del af. Bibliotekerne holder af open source og vil gerne selv rode med tingene. Har jeg ikke ret? Bibliotekerne vil også som regel en hel masse med deres websites. Alle muligheder for formidling skal udnyttes, og det stiller naturligvis også krav til webplatformen.

    Jeg synes at Sitecore var rigtig, rigtig godt til den virksomhed, jeg arbejdede i dengang. Sitecore er mere en CMS-platform end et outofthebox CMS. Man skal have ressourcerne i orden for at udnytte alle de mange muligheder der findes. Enten ressourcer i form af udviklere eller økonomiske til at hyre eksterne udviklere med.

    Hvis i kaster jer over Sitecore, så overvej at få jeres egen installation. Jeg har hørt fra flere biblioteker at det kan være ekstremt tungt at skulle igennem kommunernes IT-afdelinger hver gang der skal udvikles noget. Man bliver nemt sidestillet med andre kommunale institutioner som svømmehaller og ældrecentre – og bibliotekerne har immervæk større og andre behov.

    Drupal har jeg ingen erfaring med.

    Jeg har arbejdet en del med WordPress efterhånden og jeg elsker virkelig det system. Men jeg ved ikke om jeg ville bygge et større website op om det? Måske, hvis I venter og ser hvad BuddyPress (http://buddypress.org/) kommer med, når den kommer i en stabil version – og evt. kombineret med WordPress MU (http://mu.wordpress.org/). Det er en trio jeg privat er begyndt at lege med.

    Arena blæser rigtig nok i vinden. Vi har set nogle smarte slagsslides og hørt at der sidder en hel bunke udviklere i Sverige og koder dag og nat 😉 – jeg synes at huske at jeg hørte at det snart kom i test i Kbh og andre steder – nogen der kan bekræfte?

    Arena bygger rigtig nok på Liferay og der er ingen tvivl om at Axiell gerne ser at man skifter hele bibliotekets website ud med Arena. Men de har også bekræftet at man kan integrere dele af systemet i andre CMS-systemer. Husk blot her at systemet skal supportere Servlets for at kunne integrere Arena-dele.

    Jeg har også hørt godt om Umbraco, men ikke selv arbejdet med det.

    Hmm, det blev vist lidt rodet. Jeg har ikke noget svar, for vi fandt aldrig selv en løsning. Jeg tror jeg ville sætte tid af til at lave testimplementationer af forskellige systemer og så teste om de kunne leve op til behovene.

    Og det fører mig frem til at jeg mener man skal fokusere på at kortlægge behov og ønsker inden man overhovedet begynder at tænke på teknikken.

    Svar
  7. @ Ewan: det er jo ikke just en videnskabelig undersøgelse, snarere en mand der har haft en dårlig oplevelse – det er uundgåeligt, når man ser på hvor udbredt WordPress er. Det kan ikke fungere lige godt på alle platforme og serversammensætninger, og ham her havde f.eks. ikke MySQLs indbyggede cache slået til, hvilket ikke just er WPs skyld.

    Ikke at jeg bilder mig ind at WP er verdens mest effektive stykke kode – langtfra, faktisk. Den underliggende PHP-kode er – i den grad jeg kan gennemskue den – noget rodet i det. Men man kan med rette beskylde stort set alle eksisterende CMS-systemer for det samme – når de når en vis alder, dukker der et eller andet fænomen op, som de skal presse ind i koden, hvilket meget nemt bliver til noget rod.
    Han nævner at WP laver over 20 databaseforespørgsler når der bliver hentet en side – den nyeste Drupal laver over 100 og føles stadig hurtigere end sin forgænger! Det er ikke et spørgsmål om hvor mange forespørgsler der bliver lavet, men om hvordan de bliver skrevet.

    Det drejer sig i mine øjne i sidste ende om hvilket system man helst vil udvikle til og så må man få det til at køre optimalt med ens serverløsning.

    Svar
  8. Tak for de mange gode bidrag. Der er masser af guldkorn imellem, som jeg har taget til mig.

    Om vi investerer i Arena, når den kommer på gaden, vil tiden (samt Axiell’s implementering, pris og betingelser) vise. Men vi er under alle omstændigheder nødt til at tage Arena med i overvejelserne. Derfor dur det ikke at kaste for mange ressourcer efter en løsning, der (måske) kun er midlertidig.

    Med WordPress kan vi opnå en fornuftig løsning, uden at skulle investere hele butikken i det. Derfor forventer jeg at vi ender på en WordPress løsning.

    Svar
  9. Af ren nysgerrighed: hvad kører I på i dag?

    Jeg håber at du vil skrive løbende omkring erfaringerne med WordPress som CMS-system. Jeg arbejder selv med det samme pt. både på job og privat.

    Svar
  10. Hej Morten
    Og tak for snakken i telefonen, som nævnt arbejder Kolding, Vejle, Aabenraa, Flensborg og Frederica på et samarbejde der på sigt skal kunne skaleres til alle biblioteker i Danmark (Danmarks digitale biblioteker – men det er naturligvis kun den beskedne målsætning 😉 – Projektet hedder BIBCMS.

    I fokus har vi mulighederne for etablering af samarbejde mellem bibliotekerne til både anskaffelse, opsætning, drift og udvikling, hvilket er et perspektiv du ikke er inde på i blog indlægget. Som vi snakkede om ligger der nogle rigtig gode muligheder i open souce systemerne, men hvad er holdningen derude? Er Arena eller Easy Site samarbejdet vejen frem? Eller ville det gavne bibliotekerne bedre hvis vi lavede et fælles udviklingsmiljø omkring en opensource løsning og hivlken, er Drupal det rigtige?

    Svar
  11. @DigitalMads: Vi kører faktisk på Sitecore nu, men vi mangler som sagt dels et lukket udviklingsmiljø og dels vil en ny løsning have relativt lange udsigter. Jeg skal nok skrive mere om vores erfarnger.

    @Gitte: Det lyder som et meget interessant projekt. Hvis open source er løsningen, tror jeg i hvert fald det gælder om at satse på et system, som har så tilstrækkeligt stor en udviklerbase, at det vil være nemt at finde dokumentation. Det vil også bedre kunne sikre systemets fortsatte udvikling. Og der er Drupal da et ret godt bud.

    Svar
  12. Til Gitte: Interessant projekt – hvor kan man finde flere oplysninger om projektet?
    For mig at se, så er der to mod det nærmest uundgåelige…
    Begge veje har at gøre med bibliotekssystemet som kernen i systemet.

    1. Arena-vejen.
    Egentlig ikke min kop te lige pt (for lukket og for speciel en platform), men den sidder forhåbentligt som en præsentationsmotor oven på deres bibliotekssystem. Hvis den gør det som default, så er den ret svær at slå.

    2. Open source vejen
    Open source cms-er skal enten have udviklet broer til bibliotekssystemerne, eller trække på dataudtræk fra bibliotekssystemet – sandsynligvis via enten webservice eller tredjeparts software.
    På den anden side, så er der jo ingen der siger, at DDE Libra eksisterer som bibliotekssystem i Danmark om 5-6 år…
    Drupal vil være et rigtigt fin cms for biblioteker, især hvis vi kan skabe et udviklermiljø omkring det. Udenlandske biblioteker bruger Drupal i større udstrækning end herhjemme (og open source ILS), og har firmaer, der tilsyneladende kan lave forretningsmodeller på open source til biblioteker, se fx http://www.chillco.com/
    Kombineres Drupal med fx Moodle-Mahara som single sign-on løsning, så er vi meget tæt på, at vi ikke får noget pive over, men kun positive udfordringer at arbejde med.

    3. Og et enkelt bud på det uundgåelige.
    Bibliotekerne har brug for løsninger der kan bruges direkte fra borger.dk – face it.
    Der er ikke så meget at gøre, og vores løsninger vil skulle kunne leve op til borger.dk kravene indenfor (et gæt) fire-fem år. Det bliver centralt arbejde – – – men kan vi byde ind indtil da, og klart sige, at features som der er gratis tilgængelige i Drupal, Moodle, Mahara – jamen det er minimum for bibliotekswebsites i fremtiden, så kunne man jo krydse fingre for, at man fra centralt hold kastede penge i integration og moduludvikling af disse internationalt orienterede super-programmer.

    Svar

Skriv en kommentar