Det er en interessant artikel fordi systemet er interessant. Det anskuer nemlig begrebet onlinepublicering på en måde, som ikke er helt mage til de måder, der er brugt før.
Vi skal ikke afvise, at der findes tilsvarende systemer - vi har bare ikke set dem.
Men det bliver altså ikke mere sexet af at man oversætter det til engelsk. I bund og grund er content management det, som vi allesammen har lavet i mange år, når vi har publiceret på nettet. Nu har branchen bare fundet et salgbart navn til det.
Content management i webbranchen er alt fra en flad database og et sæt simple formularer til et komplet, avanceret styringsværktøj, der rummer mulighed for at opbygge og redigere et websted — inklusive allehånde fjerdegenerations programmeringssprog og udvidelsesmuligheder.
De mest avancerede værktøjer kræver næsten lige så meget viden som det kræver at opbygge et system som dette, der er baseret på SQL, PHP og HTML.
Selv om de kommer køreklare ud af pakken, så overraskes de fleste kunder af, hvor mange dyre konsulenttimer, der alligevel skal til at få det køre. Og taler vi tilpasninger, så løber omkostningerne for alvor løbsk.
Den virkelige kunst i publiceringssystemer er dog ikke at opbygge inddateringssystemet, men at gøre det nemt og overskueligt — og interessant — for brugerne at bruge den lagrede information.
Vores system benytter ikke sådan en struktur. Tekst er tekst, og strukturen kommer via nøgleord.
Nøgleord er valgfrie - men omhyggeligt udvalgte - ord, der knyttes til en tekst. Nøgleordene kan beskrive indhold, form eller andre aspekter af teksten. Nøgleordene kan så bruges til at samle relaterede tekster. Nøgleord for form kan for eksempel være:
Nøgleord for indhold kan være hvad som helst, for eksempel:
Strukturen er altså hvad læseren gør den til.
Fordelen er at artikler kan klappes ud og ind, tekster kan let redigeres, afsnit kan fjernes og meget andet, som gør det let at vedligeholde indholdet.
De fleste journalister og skribenter er vant til, at en artikel er én lang køre. Men sådan er det ikke på nettet. her skal tingene brydes ned, fordi fremvisningen og måde folk læser på varierer.
Vertikals system har allerede nu mange forskellige måder at vise en artikel på, for eksempel som artikel, som Q&A og som præsentation. Vi vil med andre ord prøve at få afsenderens intentioner og tekst til at mødes med læsernes ønsker og krav — alt sammen under hensyntagen til systemets mere eller mindre uforudsigelige mangler. Det er der os bekendt ikke så mange systemer der gør.
Databaser er ikke noget man skal undvige, men noget man skal stræbe efter. Opdelingen af tekst som denne i enkeltelementer, lagring i en database og efterfølgende opslag for at genskabe teksten i sin helhed, er vejen til fuldkommen styr på tingene. Vi forsøger at normalisere teksterne. Ikke ned til enkelte ord, men i det mindste ned til nogle fornuftige delelementer.
Teksterne her er delt op i afsnit. Dem lagrer vi hver for sig. Hver artikel og hvert afsnit har en række egenskaber, som også lagres. De har betydning for, hvordan teksten vises — renderes, som det hedder i fagjargonen. Vi viser den samme tekst på mange måder og genbruger ivrigt den struktur, der bliver lagt i systemet, når teksten indskrives i sine enkeltdele.
Desuden opbevarer vi meget anden information, som er relevant for teksterne. Det er for eksempel nøgleordene, som vi holder nøje øje med. Vi holder også styr på henvisningerne i teksterne, så vi ved hvad der ansporer læserne til at forlade en artikel.
Systemet er regelbaseret, og stiller egentlig meget få krav til en fast form. Hvis man undlader at lave afsnitsoverskrifter — mellemrubrikker — som det hedder, så tager systemet sig ikke videre af det. Steder hvor de vises, ser man en bid af afsnittets tekst, hvis der ikke er en overskrift. Billeder kan også valgfrit indsættes og fjernes. Den øvrige tekst føjer sig efter det. Billeder, der forsvinder — eller navngives forkert — medfører ikke en fejl, men ignoreres blot. Læserne skal ikke plages af vores fejl og utilstrækkelighed. Systemets opgave er at dække så meget som muligt over tekniske uregelmæssigheder.
Desuden kan systemet vise artikler på flere forskellige måder, enten automatisk eller på skribentens bestilling. Den første rigtigt alternative måde er som Q&A — spørgsmål og svar. Vi havde en del artikler, der allerede var lavet på denne form, og havde brug for at lægge dem ind i systemet. Inddateringen er den samme og databasen er den samme. Det er renderingen af den færdige artikel, der er forskellen.
En Q&A kan selvfølgelig sagtens vises som en almindelig artikel, og det går slet ikke så galt endda.
Artikler kan også vises på mange andre måder, som er mindre iøjnefaldende. Oversigten over artikler på forsiderne er én og listen over artikler — med eller uden korte resumeer — er faktisk to andre.
Systemet kan udbygges, og vi har sikkert ikke udtænkt den sidste måde en artikel kan vises på endnu.
Vi har ret nøje analyseret os frem til et meget begrænset antal faciliteter, som vi ønskede af systemet, og dem har vi bygget ind i det.
Der er lidt flere på vej, som vi er kommet i tanke om, men skulle vi få flere ideer (og de gør vi helt sikkert), så er problemet ikke stort. Vi har selv lavet systemet, og kan selv bygge videre på det.
Forkeeeert!
Meningen er at det skal være lettere for læserne.
Det skader selvfølgelig ikke at systemet er nemt at redigere i, men vi kan som skribenter og redaktører ikke forvente et let liv. Det er vores opgave at bruge masser af energi og hårdt arbejde på at gøre stoffet så godt som muligt, og læsernes udbytte så stort som muligt. Det skal publiceringssystemet hjælpe med til.
Opgaven er ikke primært at gøre vores liv lettere — selv om det formodentlig er motivet for indførelsen af sådanne systemer de fleste hvor det sker. Vi må forvente, at vi skal bruge energi på at lære systemet at kende. Oven i det skal vi bruge energien på at arbejde med det. Og set skal altså lægges oven i den energi der allerede skal bruges på at skabe fundamentet for det vi skriver — research, interviews, rettelser, inspiration, transpiration og alt det det.
Ideen med at publicere — her og i andre medier — er for pokker at en enkelt person eller en lille gruppe mennesker har brugt masser af energi på at spare en masse mennesker — læserne — for at bruge den samme energi.
Det er vores lod.
Vejen frem er at rydde op i dem. Rent teknisk er det meste baseret på objektorienteret programmering i PHP, og kunsten er nu at gøre det virkelig robust og let at vedligeholde.
Lige nu er de fleste skærmtekster placeret inde i koden. Det duer ikke! De skal ud i en database, således at man for eksempel kan skifte sprog.
Der er også flere væsentlige elementer, der ikke er objekter. Det duer heller ikke! De skal friskes op, eller laves fra bunden igen. Objekter er det eneste rigtige.
SQL-delen er heller ikke optimeret. SQL er ikke noget man lærer ordentligt på et år, og hvis man virkelig skal kunne håndtere mange data og mange brugere, så skal databasemaskinen udnyttes ordentligt.
Vores trafik er overskueligt, og det går fint lige nu. Men på sigt skal SQL'en og databaseadgangen optimeres.
Vi arbejder på det.