Noget om publiceringssystemer

Denne artikel introducerer begrebet publiceringssystemer kort
Den forsøger så at afdække nogle af de forhold, man bør tage i betragtning ved valg eller opbygning af publiceringssystem. Den handler om virkemåde, brug og hvad der er fornuftig opbygning og kommer også ind på emner som regelbaseret publicering og workflow.
Den er ikke en anmeldelse af konkrete produkter, selv omd er omtales nogle få i artiklen.

Et publiceringssystem er et system, der rummer faciliteter til at redigere og publicere materiale til et websted. Det styres normalt via et sæt formularer på en internetside i en browser — ofte kaldet et intranet — eller et specifikt program på en maskine, som for eksempel kan være Microsoft Word eller en Lotus Notes klient.

Når man gemmer tekster, billeder og anden information i publiceringssystemet bliver oplysningerne lagret i en database eller på en anden struktureret måde.
Herfra hentes de samme oplysninger frem af et system, der kan vise dem frem på en webserver. Denne server skaber siderne, som sendes til brugerne. Det sker typisk ved at kombinere en skabelon med den lagrede information. Skabelonen beskriver udseende, skrifter, farver og så videre. En del af udseendet kan dog også bestemmes i redigeringen, hvilket giver lidt flere variationsmuligheder. Derom i afsnittet om regelbaseret publicering.

Lidt teknik.

Der er en række fundamentale dele i et publiceringssystem:

• Redigeringssystem
• Datalager
• Skabeloner
• Programmer
• Webserver

Processen er som følger:

Redigering og lagring
Informationer tastes ind i redigeringssystemet. Disse informationer kan foruden teksten være forskellige oplysninger om publiceringsdatoer, udseende, forfatter og så videre.

Redigeringssystemet gemmer det hele på et lager, som typisk er en database. Der kan gemmes andre elementer som for eksempel billeder, lyd og video. Det sidstnævnte lagres for det meste blot som løse filer, og det er så oplysningerne om filernes navne og beliggenhed, der ligger i databasen.

Skabeloner
Skabelonerne skabes normalt på forhånd ligesom man laver et layout til en trykt publikation. De bestemmer sidernes udseende og fundamentale opførsel.
Visse systemer tillader en efterfølgende justering af udseendet, men de store linier ligger normalt fast. I mange systemer alt for fast.

Skabelonerne består af forskellige dele, for eksempel grafik, HTML-kode, forudbestemte størrelser, menuer og mange andre ting.
Visse systemer tillader valg mellem mange skabeloner, andre er mere låst.

Programmer
Programmerne, som ofte kaldes scripts, er lavet i et sprog, der er specielt beregnet til formålet.

Sådanne sprog er for eksempel PHP, ASP eller CGI, der alle kører på serversiden. Det er derimod — trods navnet — ikke JavaScript, som kører på brugerens maskine og ikke er anvendeligt i denne sammenhæng.

Programmet kan også være et særligt system, som rummer de nødvendige faciliteter. Lotus Domino (Notes) er et kendt eksempel. Oracle Application Server er et andet.

Under alle omstændigheder ligger der et stort udviklingsarbejde i at lave disse programmer. De kan specialprogrammeres til formålet eller være hyldevarer, der rummer næsten alle faciliteter og måske tillader nogle tilpasninger i skabelonerne. Hyldevarerne kan være systemer som IT-factory (baseret på Lotus Domino), Synkron (lavet i ASP), Publicus (også ASP) eller andre.

Der findes også en række spændende gratis programmer, som kan bruges, for eksempel PostNuke og phpWebSite, der er forbavsende komplette systemer — og er helt gratis.

Programmerne kører normalt på en webserver eller rummer selv en webserver.
Programmernes opgave er at flette alle elementerne samme og skabe den HTML, som skal sendes til brugernes browser. Dette sker for det meste løbende og dynamisk, når brugerne klikker sig ind på siderne.
På visse meget belastede systemer laves siderne på forhånd, og lagres som statiske filer. Dette giver mulighed for at levere siderne hurtigere, hvilket ikke belaster serverne så meget.

Webserver
Webserverens rolle er at sende informationen i form af færdige HTML-sider til brugerne. Serveren kan også løse andre opgaver, som for eksempel at logge brugernes brug af siderne, rumme filer til download, streame video og lyd og meget andet.

Fordelene ved denne tilsyneladende komplekse opbygning er at det gør arbejdet med at redigere og publicere nemmere. Man kan vedligeholde store mængder af tekster og artikler centralt, og ændringer kan ske ét sted og have effekt mange steder.

Ved at isolere de væsentlige elementer

• data
• udseende
• logik

kan man skifte dem én ad gangen eller ændre dem uden at det påvirker de andre elementer. Fordelen ved det er tydeligst når man skal ændre design på et websted. Man fjerner blot udseendelaget og skifter et andet ind. Det behøver i princippet slet ikke involvere data (tekster og andet) eller logikken (programmerne).

Man kan også bruge flere forskellige logiksæt på de samme data og for eksempel publicere til nettet og til tryk fra de samme basisdata. Når der bliver behov for en PDA-udgave af webstedet skaber jeg blot udseende og logik til dette medier, og Vupti! hele mit websted er på PDA — inklusive alle gamle artikler fra det gamle system!

Systemet bør sikre at der kan gå så lidt galt som muligt. Hvis elementer er forkerte, mangler eller der sker tekniske fejl, så skal systemet kunne håndtere det. Et manglende eller for stort billeder skal ikke give fejl, men 'skjules' så godt som muligt.

På samme måde skal siderne kunne tilpasse sig varierende tekstmængder, forskellige antal punkter i lister, varierende rækkefølger og så videre.

Dette kaldes at systemet er regelbaseret.

Eksempel: I stedet for at forlange et billede til alle artikler, skal systemet tillade et billede. Hvis billedet ikke er der, skal der ikke være et hul. Der skal også være mulighed for at sætte mange billeder ind, hvis det ønskes.
Det skal heller ikke være et krav, at billederne skal have samme størrelse hver gang, fordi størrelsen er kodet ind ét eller andet sted af programmøren.
Programmøren er ikke den rette til at afgøre billedets størrelse og layoutet.
Hvis billedstørrelserne varierer, skal systemet kunne håndtere det. Er billedet lille, og der findes en større udgave, skal systemet lave en henvisning på det, som fører brugeren til det store billede. Hvis ikke, så er der ingen henvisning.
Billedtekster, ALT-tekster, tekstens forløb og ombrydning og alle andre elementer skal kunne føje sig efter disse forhold. Det giver frihed til at variere artiklers forløb og udseende.

I mange tilfælde skal brugerne også kunne diktere reglerne. Vis mig denne forfatters artikler. Vis mig nye artikler. Vis mig denne liste sorteret efter titel i stedet for dato.

Regelbaserede systemer er tunge at opbygge, fordi der skal ligge mange alternativer i koden. Men de har til gengæld også mange fordele:

• Præsentationen bliver mere varieret
• Der bliver plads til individuelle variationer
• Undtagelser er nemme at lave. Jesus lever!
• Der er ikke så mange regler at huske — dem husker systemet
• Det daglige arbejde bliver nemmere og mere udfordrende, fordi man lettere kan føre sine ideer ud i livet

Der er selvfølgelig en æg på den anden side af sværdet. Regelbasering kræver disciplin, fordi man kan variere så meget, at udseendet eller præsentationen bliver uignekendelig. Det er op ril skribenten og redaktøren at sikre, at det ikke sker.

For mange virksomheder eller medier er det vigtigt at følge en bestemt proces når noget udgives på nettet. Dette omtales ofte som workflow eller blot arbejdsgang på dansk.

Arbejdsgangen beskriver hvordan et dokument eller en artikel skal bevæge sig igennem publiceringssystemet og organisationen. De mennesker der er involveret tildeles nogle roller og rettigheder til at udføre forskellige aktiviteter.

Hvis vi sidestiller med en redaktion kan der for eksempel være journalister og en redaktionssekretær.
Journalisterne skriver og redigerer mens redaktionssekretæren godkender og publicerer. Det kan journalisterne ikke gøre selv.

I en virksomhed kunne det være medarbejderne der skrev, mens det kun var folk i kommunikationsafdelingen eller marketing, der kunne godkende og publicere. Deres godkendelse skulle måske endda vende omkring en afdelingsleder eller direktør. Godkendelsen sker i systemet, og behovet for en godkendelse kan for eksempel varsles med en e-mail.

Hvis der er behov for denne form for styring skal det være indbygget i publiceringssystemet. Det er ofte ideelt hvis det kan integreres med en personaledatabase, som kender folk. Det betyder nemlig at man kun skal opbevare data om medarbejderne ét sted.

Det er et svært valg! Jeg ville ønske at alle havde råd til at udvikle selv, for det kan give de bedste resultater. Det giver muligheder for det perfekt tilpassede system med nøjagtigt de faciliteter, der er brug for. Desværre er det dyrt.

Alternativet er færdige systemer, som ofte kan rigtigt meget fra starten, men til gengæld kræver tilpasning, hvis man har særlige ønsker — hvilket man næsten altid har.

Større virksomheder eller organisationer kræver for det meste en samklang mellem eksisterende IT-systemer og publiceringssystemer, hvilket kan diktere valget. Andre gange er det det tekniske fundament, der er afgørende. Man kan for eksempel have valgt Oracle eller Microsoft som platform, og ønsker at basere sit system på det.

Uanset hvilken vej man vælger skal man dog altid stræbe efter at definere sine behov ud fra ønsker og visioner, og ikke lade systemet bestemme hvad det skal kunne.

Det er nemmere sagt end gjort. Meget nemmere...