NYHEDER OM DIGITAL PUBLICERING

De første skridt på rejsen til en digital udgivelse

Skrevet af Claus Andersen d. 28-01-15 09:43

Find mig her:

Dette blogindlæg er skrevet til alle jer, som er interesserede i at få et indblik i nogle af de automatiserede IT-processer, som behandler jeres avis eller magasin bag Visiolinks vægge. God fornøjelse!

Man kan meget groft sagt koge Visiolinks SaaS kerne-backend ned til tre dele:

  1. Automatisk opsamling af de rigtige PDF-filer fra udgiverens FTP-konto på det rigtige tidspunkt og sætte dem i kø til videre behandling.
  2. Kø-baseret konvertering af PDF-filer til to andre formater for hhv. web og smartphones/tablets.
  3. En lang række web-services som web- og device-klienterne bruger til at trække data fra.

Jeg vil her fokusere på den første del, som i den sidste tid har været igennem en total omskrivning. Da ingen publikationer er ens, er deres deadlines, frigivelsestidspunkter og outputtet fra redaktionelle systemer det ofte heller ikke. Grunden til omskrivningen er netop nye krav til frigivelsestidspunkter, og at der kan være flere versioner af samme udgivelse.

Internt i vores verden kaldes dette system for en “normalizer”. Men hvad er det så, der bliver normaliseret? Følg med. Vores system forventer, at udgiveren uploader enkeltsidede PDF-filer til deres FTP-konto. Alle disse enkelte sider skal samles til en publikation og sættes i kø til videre processering, så de for det første kan vises i vores AUTHENTIC- og DYNAMIC-løsninger på web, smartphones og web, men hvordan?

rejsen_til_en_digital_udgivelse_-_visiolink

En publikation består naturligvis af en række sider, og hver side kan tilhøre en sektion. Derudover har en publikation også en publikationsdato, da der kan ligge filer for mange forskellige datoer. Derfor skal hver PDF-fil som minimum angive, hvilken side og dato, den tilhører. Hvis publikationen har flere sektioner, skal dette også angives. Derudover kan hver side findes i flere versioner, hvis redaktionen har behov for at ændre på indholdet i løbet af udgivelsesperioden. Alle disse informationer skal ganske enkelt indgå i filnavnene.

Da filnavngivningen, og herunder datoformatet, er forskellig fra udgiver til udgiver, håndteres dette med et sæt af specifikke regulære udtryk for hver kunde, hver indeholdende en “gruppe” for hver af de påkrævede elementer og eventuelt en fastdefineret sektion. Derudover kan man konfigurere en tolerancetærskel for antal manglende sider midt i en sektion, frigivelsestidspunkt og andre detaljer.

I de “gode gamle dage” var alting nemmere

I tidernes morgen var den eneste måde at udløse en afsluttet filopsamling på at uploade en såkaldt “XML-trigger”. Denne XML-fil skulle indeholde publikationsdatoen (samme dato som datoen i PDF-filnavnene), et udgivelsestidspunkt og en version. Denne fil skulle ofte forfattes og uploades manuelt, hvilket tit var årsag til forvirring og fejl. Den dag i dag er denne måde at afslutte en filopsamling på stadig aktiv for dem, som ønsker det.

Efterhånden som antallet af udgivelser på vores systemer voksede, kom der også flere krav til dette. Det vigtigste krav var automatisk opsamling af filer fra et bestemt tidspunkt på døgnet uden XML-trigger. Dette blev tilføjet og fungerede smertefrit i lang tid.

Alt dette var før, behovet i branchen om “early release” dukkede op, altså at publikationen kunne frigives dagen/aftenen før publikationsdatoen. Derfor var systemet bygget til kun at samle filer op fra den samme dato som kørselstidspunktet. M.a.o. blev der ikke differentieret mellem processerings- og publikationsdato. Hvis man eksempelvis var en aftenavis og ekstraordinært udkom lidt sent over midnat, ville filerne derfor ikke blive samlet op automatisk. Derudover var det heller ikke muligt at genkøre en avis med opdaterede sider, når den først var blevet kørt en gang. Begge dele kunne man dog naturligvis klare manuelt ved at logge ind i vores administrationsinterface og gennemtvinge en opsamling af en bestemt dato. Men vores fokus har altid været på at få automatiseret den samlede processing, så når nye krav og behov opstår i branchen, skal vi være i stand til integrere disse nye behov i vores automatiske processering.

Med tiden kom altså behovet i avisbranchen om early release. Dette krav kunne vi godt imødekomme vha. ovennævnte XML-trigger. Fordelen ved XML-trigger er nemlig, at kunden har 100 % kontrol over, hvornår filerne samles op. Ligeledes kan kunden også genkøre en publikation vha. XML-trigger. Som nævnt var der dog også en del ulemper ved XML-trigger, og da flere og flere kunder ønskede automatisk early release og genkørsler, valgte vi at bygge en ny normalizer.

JP_MacBook_Visiolink_497x350.jpg

I de “endnu bedre nye dage” blev det mere komplekst

Defor blev begrebet “file set” (“filsæt”) indført i den nye normalizer. Et filsæt består kort sagt af alle de filer for en bestemt dato, som er kandidater til at blive inkluderet. Den første større opgave i en normalizer-kørsel er derfor at finde alle filer på kundens FTP, matche dem med filnavnsreglerne og gruppere dem efter dato.

Ved hver kørsel persisteres information om hvert enkelt kendt filsæt, således at vi senere kan afgøre, om et filsæt er blevet ændret siden sidste kørsel. Hvis dette er tilfældet, og den øvrige konfiguration tillader det, vil filsættet blive samlet op og sat i kø til processering. Opsamlingskriteriet passer dog ikke helt, for et filsæt samles ikke op, hvis en fil er blevet uploadet eller slettet for nylig. Dette er en sikkerhed for, at vi ikke samler et filsæt op, mens kunden er i gang med at uploade eller slette filer. Så derfor venter vi med at samle filer op til lidt efter, at der er sket en ændring.

Uden at gå i detaljer er det med denne filsætsinformation og opsamlingskonfiguration relativt nemt for hver enkelt dato at finde ud af, om filer for denne dato skal samles op, når der er sket ændringer i filerne på FTP-kontoen.

Med beslutningen om at skrive systemet forfra kom også en del idéer til yderligere forbedringer, som blev implementeret. Af de vigtigste kan nævnes:

  • I stedet for kun at kunne samle filer op på dagen og aftenen før publikationsdatoen, blev systemet skrevet så generelt, at det er muligt at konfigurere et antal dage i hhv. fortiden og fremtiden ift. kørselstidspunktet, hvor der må samles filer op til en udgivelse. Især antal dage i fremtiden er meget brugbart for magasiner, som er færdige lang tid, før de frigives. Antal dage i fortiden kan bruges til genkørsler. Senere har vi også tilføjet et konkret klokkeslæt for denne grænse, som matcher det tidspunkt på døgnet, hvor udgivelsen har deadline, og vi bør have modtaget alle filer.

  • Frem for kun at kunne samle filer op automatisk mellem et bestemt tidspunkt af døgnet indtil midnat, blev det gjort muligt at konfigurere en eller flere vilkårlige perioder af døgnet. For mange udgivelser vil man blot konfigurere systemet til at opsamle filer døgnet rundt, så der ikke skal køres noget manuelt.

  • Tidligere var der kun log-information fra den sidste kørsel, som var tilgængelig. Med det nye system findes alle nylige logs, så man har adgang til information for hver enkelt kørsel. Dette gør, at vi f.eks. kan vise loggen for den seneste kørsel, og for den seneste kørsel, hvor der skete en filopsamling i administrationsinterfacet.

  • Vi har jo at gøre med vigtigt journalistisk indhold, hvilket betyder, at et filsæt vil blive betragtet som fejlbehæftet, hvis forsiden mangler. Derudover er det muligt at konfigurere, at der ikke må mangle sektionsforsider. Hvis filsættet sættes til processering, bliver de manglende sider nemlig senere i processeringen til blanke sider, hvilket ikke giver læseren den optimale oplevelse, bl.a. i en coverflow-visning. Generelt ved systemet jo ikke, hvor mange sider, der bør være i en given publikation, og derfor har vi ingen mulighed for at stoppe en opsamling, hvor der mangler sider/filer i slutningen af en sektion. Derfor er det også muligt at konfigurere, om antallet af sider i en sektion skal være deleligt med 2 eller 4, hvilket generelt er sunde tal for oprindeligt fysiske publikationer. Alle disse konfigurationsmuligheder er med til at hjælpe den enkelte udgiver med at have en høj kvalitet uden fejl og mangler i deres digitale udgivelser.

nordlys-early-release-visiolink-600

Perspektivering

Dette var kun en overfladisk gennemgang af det nye normalizer-system, og der er naturligvis masser af små finurlige detaljer, som har gjort det udfordrende og spændende at udvikle. Men vi tror på, at produktet kan give stor værdi for både vores kunder og os selv. Vi er nu ved at flytte de mange udgivelser over på den nye normalizer. Men selvom vi mener, at vi opfylder de fleste krav, som branchen stiller i dag, er vi helt sikkert blevet klogere igen om 5 år, helt ligesom tilfældet er i dag.

Topics: Knowledge

Abonnér på e-mail opdateringer


Visiolink at the World Publishing Expo 2015

New Call-to-action