Spørsmål? Ring tlf 94 30 21 81
Lag websider med vår publiseringsløsning Autopublish
CMS basert på brukervennlighet, søkemotorvennlighet og tilgjengelighet
Spørsmål? Ring tlf 94 30 21 81
Et CMS består typisk av minst tre elementer:
Et Content Management System (CMS) er et system som støtter utforming og håndtering av webside-innhold. Webside-innhold kan være tekst, artikler, bilder, lydfiler etc. Innhold på web trenger alltid å bli 'gjort noe med. Du kan ha behov for et CMS forå lage innhold fra scratch, for å endre eller slette innhold, for å la flere mennesker redigere innhold sammen, for å vise innholdet i ønsket format, og for å la de rette menneskene gjøre de riktige tingene med informasjonen.
Et CMS er et system som håndterer innholdskomponentene på en webside.
Merk at dette går utover den rene lagringen av innhold - "management"-biten er vel så viktig!
Når oppstår behovet for et CMS?
Et CMS består som nevnt av 3 delsystemer. Det første delstystemet tar for seg innhold; hvordan det lagres, hvem som har ansvar for innholdets livssyklus etc. Innhold i et CMS går gjennom flere stadier, fra planlegging, utforming, testing, godkjenning og publisering. Det andre delsystemet har ansvar for metadata, altså data om innholdet.
Et CMS støtter distribusjon av ulike filer. Dette kan være Word-dokumenter, PDF-dokumenter, bilder, Flash-animasjoner, mp3-filer eller videoer. Det er i hovedsak to måter å distribuere disse filene på. Enten kan filen intengreres med annet innhold på en webside, feks ved at bilder eller Flash-objekter vises på en side i nettleseren der det også er tekst. Den andre måten er å gi brukeren en hyperlenke til filen, slik at filen åpnes i et egnet program på brukerens datamaskin. De siste årene har nettlesere som Internet Explorer blitt i stand til å presentere alle de nevnte filene.
En av de store utfordringene i utformingen av et CMS er at andre delsystemer må integreres i systemet. I praksis kaller man disse delsystemene for 'moduler'. Det er svært varierende i ulike CMS-er hva som betraktes som moduler. Dette skyldes gjerne en kombinasjon av utviklerenes abstraksjoner, og markedsføring av CMS-et. Om utvikleren ser på rolle-funksjonalitet som en egen modul, åpner dette for inn-/utplugging av denne modulen, slik at virksomheten kan selge den som ekstrafunksjonalitet.
Bare fantasien setter grenser for hvilke moduler som kan integreres i et CMS. Her følger en liste over moduler jeg har sett eksempler på i ulike CMS-er:
Dette er en lang og interessant liste. I ène enden finner vi helt elementære funksjoner på en webside, som sitemap og navigasjonshjelp og utskriftsvennlig versjon - funksjoner som det knapt krever ressurser å utvikle. I den andre enden finner vi omfattende systemer for ehandel og prosjektkommunikasjon. Mange av modulene har som oppgave å lagre og presentere enkle former for informasjon. Andre beveger seg imidlertid mot kjernen av et cms.
Her følger en ny liste over de modulene som gjelder selve håndteringen av informasjon:
Videre ser vi at mange av modulene fordrer til interaktivitet med den besøkende. Interaktivitet er et strategisk imperativ innenfor estrategi, og kan være avgjørende for suksessen på et nettsted. Disse modulene gjør at brukeren foretar aktive handlinger, heller enn å passivt bli presentert for informasjon. Dette kan vekke interesse hos brukeren, og kan bidra til at konverteringsraten tiltar: Målet med besøket nås. Slike moduler krever ofte begrenset med ressurser å utvikle, og kan ha høy nytte for nettstedet. Følgende moduler kan plasseres i kategorien 'interaktive moduler':
De fleste modulene er imidlertid utviklet for å forenkle repetive oppgaver, og å strukturere data som har mulighet til å struktureres. Her åpnes også muligheten for at en prosess kan integreres med andre prosesser i CMS-et.
Den aller største utfordringen i utvikling av et CMS er å integrere de ulike modulene med hverandre. Dette krever at man gjør omfattende analyser og kommer fram til gode, skalerbare abstraksjoner. Hvilke fellestrekk har for eksempel en ansatt, en webgjest og en kontaktperson? Hvilke konsekvenser vil det få om vi betrakter disse som underkategorier av samme kategori? Her må man lete etter både problemer og muligheter.
Gode abstraksjoner vil være gull verdt når systemet settes ut i drift. Har man et godt system for identifisering av personer åpner dette for store personifiseringsmuligheter, blant annet ved at brukeren slipper å identifisere seg mer enn èn gang per sesjon. Identiteten blir den samme: En ansatt kan logge inn, redigere en artikkel (automatisk identifisert forfatter), laste opp et Word-dokument (automatisk identifisert eier), sende en epost (automatisk identifisert epostadresse), chatte med andre besøkende (automatisk identifisert navn), legge inn en aktivitet i aktivitetskalenderen et cetera.
Før man påstarter utviklingen av et CMS bør man gjøre en grundig kost/nytte-analyse: Hvilke moduler skal utvikles? Dersom målgruppen er store virksomheter bør man ha et omfattende system for livssyklusen til de ulike innholdskomponentene. Dette innebærer at den som skal godkjenne innhold får automatiske meldinger når innholdet er klart. Dersom innholdet ikke godkjennes bør det skje en 'rollback' der forfatteren får beskjed om å gjøre de nødvendige endringer. Dersom målgruppen er mindre virksomheter kan livssyklus-arbeidsflyten være enklere.
Det er svært viktig at man utvikler kjernemoduler for produksjon, lagring og presentasjon av innhold før man påstarter utviklingen av ekstramoduler. Det første arbeidet bør bestå i å utvikle et logisk system for brukere, grupper og hvilke roller og rettigheter disse skal ha. Et eksempel: Brukeren Tim kan være del av gruppen ProsjektA. Tim kan ha tilgang til innholdA men ikke til innholdB. Siden Tim er en del av ProsjektA har han også tilgang til FilC. Neste steg er å utvikle et logisk system for innhold. Hvilke typer innhold finnes, og hvilke metadata skal registreres for ulike typer innhold? Hvordan skal de ulike formene for innhold struktureres i forhold til hverandre? Skal de ulike elementene i en artikkel betraktes som egne kategorier, slik at overskrift, ingress og tekst lagres hver for seg? Hva med spesielle elementer i en artikkel, som bilder og interne lenker? Skal disse lagres hver for seg? Og hva med innhold som ikke er artikler? Det er klart at dette er viktige, og avgjørende spørsmål for hvordan systemet kommer til å fungere. Faktum er at du vil ha store fordeler av å operere med abstraksjoner for hver innholdstype. Dette er et spørsmål om granularitet, hvor små biter med innhold skal systemet bestå av.
