Råd om publiceringssystemer - Noget om Content Management Systemer

Vertikal.dk
203 artikler
82 nøgleord
10 salgstekster
254 billeder

Læsestof
Nyeste artikler
Mest læste artikler
Alle artikler
Nøgleord

Tjenester
Domænengeist
Så kendt er du
Så populær er du
Få en gratis titel

Steven Snedker og Martin Jørgensen til leje

Print Anbefal Kommentér Statistik

Artikelfakta:
Publiceret: 09/02/2002 12:02
Redigeret: 09/02/2002 12:02

Læst: 11306 gange

Nøgleord:
content management
publiceringssystem
redigeringssystem
råd om

Råd om publiceringssystemer

Den generelle regel for content management systemer er at det skal tilpasses til opgaven – og ikke omvendt.

Af Martin Jørgensen

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.

Mere om publiceringssystemer

Når man er nået til et vist stadie i udgivelser på nettet, er det på tide at sige farvel til statiske sider.
Uanset sammenhængen er det slut med FrontPage, GoLive, NetObjects eller håndkodet HTML. Livet er — som allerede skrevet mange før — for kort til statiske sider. Der skal automatik, databaser, skabeloner og alt det smarte til. Vi har allerede skrevet om publiceringssystemer flere gange på Vertikal.

Der er et kraftigt udfald mod statiske sider og en ode til de dynamiske i Den statiske side skal dø!
Læs en genrel introduktion i artiklen Noget om publiceringssystemer
Vi har også skrevet lidt om vores eget publiceringssystem
Der er en kursusintroduktion under titlen Databaser, publiceringssystemer og dynamiske websteder

Der er 14 punkter

Systemet skal afspejle arbejdsmåden – ikke omvendt
Systemet skal understøtte den eksisterende arbejdsgang – ikke omvendt
Systemet skal tilpasses udgivelsens struktur – ikke omvendt
Det kræver noget af brugerne at bruge et publiceringssystem
Content management systemet skal give mulighed for individuelt layout af artikler
HTML er ikke forbudt i publiceringssystemer
Der skal være fuldkommen styring af artiklers fødsel, synlighed og død
Systemet skal have tilknyttet en fuldt integreret mediedatabase
Redigeringen skal være browserbaseret og lettilgængelig
Systemet skal ikke være afhængigt af ydre programmer
Der skal findes mange forskellige skabeloner i systemet
Systemet skal skabe de rette koder automatisk
Systemet skal give mulighed for manuel overstyring
Indhold og design skal være skilt helt fra funktionerne

1 Systemet skal afspejle arbejdsmåden – ikke omvendt
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.

2 Systemet skal understøtte den eksisterende arbejdsgang – ikke omvendt
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.

3 Systemet skal tilpasses udgivelsens struktur – ikke omvendt
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.

Oversigt over et publiceringssystem

4 Det kræver noget af brugerne at bruge et publiceringssystem
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.

5 Content management systemet skal give mulighed for individuelt layout af artikler
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?

6 HTML er ikke forbudt i publiceringssystemer
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.

7 Der skal være fuldkommen styring af artiklers fødsel, synlighed og død
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.

8 Systemet skal have tilknyttet en fuldt integreret mediedatabase
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.

9 Redigeringen skal være browserbaseret og lettilgængelig
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.

10 Systemet skal ikke være afhængigt af ydre programmer
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.

11 Der skal findes mange forskellige skabeloner i systemet
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.

12 Systemet skal skabe de rette koder automatisk
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.

13 Systemet skal give mulighed for manuel overstyring
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.

Publiceringssystemets dele

14 Indhold og design skal være skilt helt fra funktionerne
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.

Læs mere om content management publiceringssystem redigeringssystem råd om
Weblogs om: content management publiceringssystem redigeringssystem råd om

Vi sælger skamløst viden om og assistance med

Ring inden den 31/05/2012 og få et ekstra godt tilbud!

Print denne side Anbefal denne side
© 2001-2012 Vertikal.dk Kenny Drews Vej 31, DK-2450 København SV, Denmark
Steven Snedker ss@vertikal.dk (55767603/51841548) og Martin Jørgensen martin@vertikal.dk (20666701)
Klik her for at gå til webbaseret kontaktformular ...om privatlivets fred