Råd om publiceringssystemer

Disse råd handler om redigerings- og publiceringssystemer – ikke om store indholds- og dokumenthåndteringssystemer som Vignette, BroadVision, Open Market, Documentum eller ligende. Sådanne systemer er i en helt anden liga – selv om mange af reglerne her også gælder for dem.
I denne artikel er der tale om systemer, hvis primære formål er at publicere tekster på nettet i én eller anden sammenhæng. Der kan være tale om aviser eller magasiner, men også om ydmygt tekstindhold på et firmas profilerende hjemmeside. Selv om der refereres til journalister, redaktion og andre begreber, der antyder en professionel, journalistisk arbejdsplads, så kan reglerne lige så godt gælde nyheder på et firmas websted, som vedligeholdes af en enlig HK'er.

Mange redaktioner eller arbejdspladser, hvor der publiceres materiale, har allerede måde at gøre tingene på. Content management systemet skal lægge sig helt tæt op ad denne måde. Systemet skal tilpasses, så man i princippet ikke arbejder anderledes end man plejer.

Det kan ikke undgås, at der er forskel på håndteringen. For eksempel skal indhold sikkert ind i nogle webbaserede formularer, men i store træk bør arbejdet foregå som det plejer.

De roller og arbejdsmetoder, der allerede er på arbejdspladsen eller på mediet, skal kunne benyttes fortsat i systemet – forudsat de er formålstjenlige.

Det der under et kaldes workflow – arbejdsgang, ansvar, adgangsrettigheder, roller og så videre – skal kunne rumme de roller, som kendes allerede. Disse roller kan for eksempel være skribent, redaktør, redaktionssekretær som det kendes fra klassiske redaktioner. Skribenten skriver, redaktøren redigerer og redaktionssekretæren godkender og publicerer.
Rollerne kan også være produktmedarbejder, sekretær, afdelingsleder – igen skrivende, redigerende, godkendende. Man definerer de forskellige medarbejderes roller og kompetencer eller rettigheder i systemet, som så kan styre processen fra skrivning til offentliggørelse.

Opbygning af tekst, artikeltyper, kategorisering, forsidestruktur og så videre skal alt sammen dikteres af mediets eller produktets form og udgivernes ønsker, ikke af systemets eventuelle begrænsninger.

Hvis der rent formidlingsmæssigt er en bestemt form, som indholdet skal antage, så er det denne form, som publiceringssystemet skal benytte.

Hvis man ikke har en veldefineret form - for eksempel fordi man starter fra bunden - skal denne defineres før man vælger publiceringssystem, så den ikke tager form efter mulighederne eller begrænses af dem.

Intet er gratis, og publiceringssystemet giver ikke nødvendigvis mindre arbejde med at publicere. Det kan giver langt bedre styring og højere kvalitet og i flere tilfælde også spare ressourcer, men man får ikke gode produkter ikke uden en indsats fra medarbejdernes side.

Man skal lære systemet at kende. Det er et nyt værktøj og for mange et nyt medie. Det vil kræve en investering – som det er tilfældet med alle nye værktøjer.
Filosofien er, at der skal lægges et stykke arbejde i klargørelsen af materialet. Det er netop essensen i publicering: redaktionen lægger et stykke kvalificeret arbejde i at klargøre indholdet for brugerne eller læserne.

Det koster tid og arbejde.

Publiceringssystemet gør ikke dette princip anderledes.

Det skal være fælles retningslinier og personlige ambitioner, der sætter grænsen for, hvordan de færdige sider ser ud, og ikke begrænsninger i publiceringssystemet. Der skal selvfølgelig sættes et centralt style sheet op, og der skal ikke være ubegrænset råderum for kreative sjæle.

Så går det hele amok.

Men der skal være mulighed for at bruge billeder i mange størrelser. Mere end ét billede pr. artikel. Mulighed for at placere billeder flere forskellige steder – og for eksempel ikke kun i øverste højre hjørne.
Variationen i layoutet gør hjemmesiden levende og giver journalisterne mulighed for at lavere budskabet langt bedre.
Artiklernes struktur skal kunne varieres. Hvad hvis der ikke bruges mellemrubrikker? Kan en artikel være lutter billeder uden billedtekster? Kan man udelade dele af artikler uden at systemet laver fejl?

Det er — modsat hvad mange tror og mener — ikke fuldkommen udelukket at tillade HTML-koder i publiceringssystemer. Det er heller ikke ønskeligt.

Masser af publiceringssystemer arbejder med deres egne koder, som efter producenternes udsagn er meget nemmere og bedre at arbejde med. De ligner i bund og grund HTML, og rummer ofte de samme muligheder, men er blot anderledes kodet og opbygget.

Der er ingen grund til at skifte koderne ud med nye, ukendte special-tags. Koderne for fed og kursiv er ganske fine, og mere avancerede af de eksisterende koder kan også sagtens tillades. Systemet skal blot fordøje dem, og sikre, at de ikke laver ulykker. For eksempel er ulovlige henvisninger eller ikke eksisterende billeder et problem. De skal checkes og eventuelt bearbejdes før koden sendes videre til browseren. Derimod vil de fleste med lidt HTML-kendskab byde muligheden for at lave et skema med HTML's <TABLE> koder ganske velkommen. Skemaer i teksten er noget af de som gængse publiceringssystemer håndterer dårligst.

Der skal altså kunne tastes HTML ind i alle tekstfelter, som vises i artiklen. Det giver mulighed for at lave specielle effekter, skemaer, overstyring af layout og meget mere. Mulighederne her skal begrænses af en fælles politik og ikke af systemet.

Det kan af og til være ønskeligt at begrænse visse muligheder, for eksempel indsættelse af scripts – JavaScript, CGI, PHP, ASP – ikke mindst på grund af de ulykker sådanne scripts kan forårsage. Men igen er en fælles politik bedre en tekniske hindringer.

Alle artikler og eventuelt dele af artikler skal kunne tidsstemples. Der skal ske en automatisk tidsstempling ved oprettelse og redigering. Dette skal suppleres af en manuel stempling som oplyser om publiceringsdato og den dato, hvor indholdet eventuelt skal tages af igen.
Eksponeringsperioden skal kunne udtrykkes som en periode eller som en absolut slutdato.

Hvis artikler har flere faser – for eksempel forside, underforside, sektion, arkiv – så skal disse datoer eller perioder kunne angives individuelt.
Artikler eller dele af artikler – for eksempel illustrationer – skal kunne skjules eller fjernes manuelt fra offentlig beskuelse.

Billeder og andre mediefiler skal kunne lægges ind i de enkelte artikler, men bør opbevares i en central mediebase. Denne mediebase skal kunne aktiveres direkte fra hver enkelt artikel, men skal også kunne startes som en applikation for sig selv.
Mediedatabasen bør rumme oplysninger om selve filerne foruden afledte oplysninger: kategorisering, billedtekster, beskrivelser, nøgleord og så videre. Mediefiler skal kunne bruges sammen med mange artikler på hjemmesiden. Mediefilerne kan skjules og vises manuelt, og fjernes en mediefil, skal det selvfølgelig ikke give fejl i artiklen.

Man skal kunne redigere fra enhver Internet-tilsluttet maskine og i alle browsere. Systemet skal kunne arbejde i alle tænkelige browsere. Ofte sidder en bruger ved en fremmed maskine med en fremmed browser, når en fejl opdages, og derfor skal systemet være robust. Der skal heller ikke lukkes af for redigeringen på netværksniveau, så man for eksempel kun kan redigere indefra. Principielt skal systemet kunne benyttes fra enhver Internet-café eller biblioteksmaskine.
Der er altid behov for at redigere, og redigeringen skal kunne aktiveres direkte fra artiklen, så en bruger med tilstrækkelige rettigheder straks kan redigere i den. Redigeringsdelen er selvfølgelig sikret med password, og selv om udefra kommende skulle finde henvisningen til redigeringen, kan pågældende ikke komme til den.

Med reference til ovenstående skal systemet heller ikke være afhængigt af ydre elementer eller programmer. Det er almindeligt at benytte Microsoft Word som redigeringsværktøj eller lade systemet overføre en særlig Java-applet til redigeringen. Det lyder umiddelbart besnærende med de faciliteter disse systemer tilbyder, men erfaringen viser at brugerne i store træk ikke er tilfredse med sådanne systemer.
Publicering direkte fra Word betragtes af mange som klodset og giver rent teknisk mange fejlmuligheder. Overførsel af særlige redigeringsværktøjer er ikke nok til at kunne give fuld magt over redigeringen. Desuden følger værktøjerne ikke de gængse standarder, og er derfor ikke nødvendigvis til stor gavn for brugerne.

Hvis systemet er skabelonbaseret, det vil sige at artikler dannes med udgangspunkt i et standardlayout, skal det være muligt at vælge mellem flere forskellige skabeloner ligesom man skal kunne tilføje flere skabeloner uden yderligere programmering.

Alle koder – titler, META-koder og så videre – skal skabes automatisk af systemet ud fra artiklernes udstyr såsom overskrifter, indledninger og så videre. Der skal være plads til at taste nøgleord ind i redigeringssystemet.

Systemet skal rumme mulighed for at styre sidens elementer manuelt, for eksempel titler. META-koder, alternativtekster til billeder.
Betydningen af dette kommer oftest til udtryk i forbindelse med sidens titel. En smart lydende overskrift er sjældent den rette titel på siden, og derfor skal man kunne taste en tekst ind, som bliver sidens titel, når den vises.

Systemets tre væsentlige dele skal være helt adskilt. Indholdet skal ligge i en database, og ikke rumme noget design ud over eventuelle referencer til style sheets.

Designet bør isoleres i et eller flere style sheets og i centrale og begrænsede dele af scriptet. Definitionen af designet kan også ligge i databasen, men skal så vidt muligt ikke ligge i selve indholdet eller spredt i scriptkoden.

Det betyder at designet kan ændres uden at det påvirker indholdet. Det betyder også at indholdet med stor sandsynlighed kan flyttes til et nyt publiceringssystem eller at funktionerne i det eksisterende kan ændres fundamentalt uden at det påvirker de to andre elementer. Muligheden for at skifte den ene del uden at skifte andet er fundamentalt vigtig for levedygtigheden af både systemet og indholdet.