Le piattaforme usate dai giornali

Dopo i miei articoli su il nuovo sito web de “Il fatto quotidiano” un amico mi ha chiesto perché penso che WordPress non vada bene per il sito di un giornale (quotidiano o periodico in genere) e cosa invece penso che sia necessario per queste applicazioni. In particolare lo interessava sapere perché penso che Java sia meglio di altre tecnologie quando si tratta di gestire una redazione. Rispondo qui di seguito in modo che queste considerazioni siano visibili a tutti e che chiunque possa commentarle.

Differenze tra comunità e redazioni

Per capire dove nasce il problema è necessario capire come funziona la redazione di un giornale ed in cosa è diversa da una semplice comunità di utenti che collabora alla stesura di un sito web collettivo.

Gerarchia e Responsabilità

A differenza di una comunità autogestita, una redazione ha una precisa struttura gerarchica in cui ogni persona riveste un ruolo preciso e deve attenersi a delle precise responsabilità Questo significa, tra le altre cose, che deve esistere una accurata compartimentazione (l’utente A non deve essere in grado di vedere o modificare i materiali dell’utente B) ed una precisa gestione dei workflow (“flussi documentali”). In altri termini, prima di essere pubblicato un articolo deve passare una serie di verifiche e di controlli.

La compartimentazione e la gestione dei workflow sono disponibili in molti sistemi CMS di classe medio alta (Plone, HippoCMS, etc.) ma si tratta comunque di funzionalità che non possono essere date per scontate, soprattutto se si considerano i mille modi diversi in cui possono essere implementate (non tutti adatti allo scopo).

Accounting e Remunerazioni

Il lavoro dei redattori è retribuito (quasi sempre) e può essere retribuito in modi molto diversi. Non è raro avere redazioni in cui un “core” di 10 o 12 persone è assunta a tempo indeterminato e riceve uno stipendio fisso (+ incentivi) mentre altre 30 o 40 persone lavorano come collaboratori a contratto, a progetto o come “esterni”, dotati della loro partita IVA e pagati “a cottimo”. Il risultato finale è che bisogna poter “misurare” il contributo di una parte o di tutti i redattori e passare questi dati a chi gestisce le paghe.

Inutile dire che questa “feature” è un immondo casino nella quasi totalità dei casi (specialmente quando le paghe sono gestite da una società esterna che magari usa un AS/400).

Advertising

I giornali online vivono quasi solo di pubblicità per cui è necessario avere un sistema di gestione degli advertisement di grande flessibilità e di grande raffinatezza. Bisogna poter gestire banner globali (sulla “home”), inserti locali (nelle singole pagine), finestre pop-up, animazioni Flash e HTML5 e diverse altre diavolerie.

Francamente, non ho mai visto un sistema preconfezionato (un CMS) in grado di soddisfare le esigenze di advertisement di un giornale, anche piccolo.

Inserti, Short News e altri animali

A differenza di un normale CMS, che solitamente ha al massimo due diverse tipologie di notizie, come il normale “articolo” (lungo, ricco di contenuti) e la “news” (breve, solo testo), un giornale può avere 10 o 12 tipi diversi di contenuto, dalla “headline” con le “breaking news”, all’inserto di approfondimento fino alla “poll” per raccogliere le opinioni dei lettori.

Si può sicuramente “configurare” (o “sviluppare”) un CMS esistente, come Plone, per avere tutte queste tipologie di contenuti ma nessun CMS esistente fornisce di default, “out-of-the-box”, un insieme così ricco di tipologie di contenuti.

Flessibilità di impaginazione nello spazio e nel tempo

I contenuti devono poter essere piazzati nelle pagine in base alle logiche commerciali e redazionali del momento, non in base a criteri tecnici, come la loro dimensione o l’appartenenza a questa o quella categoria. Inoltre, l’impaginazione deve poter cambiare rapidamente nel tempo per adattarsi alle esigenze di visibilità dei singoli articoli, a volte anche sulla base di algoritmi automatici.

Nessun CMS esistente ha potenzialità così raffinate “out-of-the-box”.

Alimentazione dei contenuti

A differenza di quello che avviene coi siti di comunità, dove tutti i collaboratori usano la stessa interfaccia utente (TinyMCE o roba simile) per scrivere i propri articoli, i collaborati dei giornali usano le cose più diverse, dal pezzo di carta passato allo sgargino di turno, al “modem” (termine con cui spesso identificano un laptop dotato di connettività Internet di qualche tipo), fino al telefono cellulare e… alla dettatura dei testi al telefono.

Alla fine, nella stragrande maggioranza dei casi, il testo e le immagini vengono inserite via interfaccia web da uno sgargino ma questo non può essere dato per scontato.

In particolare, in quasi tutte le redazioni che seguono sia la versione cartacea che quella web di un giornale esiste la necessità di importare i materiali (e magari anche l’impaginazione) del sistema di publishing che gestisce la versione cartacea per riutilizzarli sul web o viceversa. E si tratta di sistemi di publishing industriale, non di banali sistemi DTP…

BTW: Riguardo a questi sistemi, io ho esperienza quasi solo di Arbortext (ora PTC) ma qui a “Typesetting Software” su Wikipedia ne trovate diversi altri.

Gestione dei partners e hosting di contenuti

Quasi tutti i periodici vantano decine di partnership con altre testate ed altri fornitori di contenuti, dai blogger alle aziende che forniscono le previsioni del tempo a quelle che forniscono i dati di borsa.

Questi contenuti devono essere ospitati sulle pagine del sito e gestiti in modo adeguato. Curiosamente, no si vedono quasi mai le pur ottime Java Portlets in questo genere di applicazioni.

Differenze tra CMS e sistemi redazionali

A questo punto, potete capire per quale ragione un “semplice” CMS, anche molto sofisticato, come Plone, Alfresco, Magnolia, HippoCMS e roba simile, speso NON è sufficiente.

In pratica, i siti web dei grandi giornali vengono quasi sempre costruiti ad hoc da team molto eterogenei di specialisti che vanno dalle 4 o 5 persone fino ad oltre 200 (+ i redattori). Solo le testate più piccole sono basate su CMS esistenti e quasi sempre sono pesantemente customizzati (nuovi tipi di contenuto, layout manager sofisticati, accounting, etc.).

Tra le modifiche che si rendono spesso necessarie posso segnalare le seguenti.

Gestione dei redattori e degli utenti

Quasi sempre è necessario ritoccare o riscrivere la gestione degli utenti per tenere conto del fatto che la gestione degli utenti, intesi come redattori, NON può essere mescolata senza rischi con la gestione degli utenti, intesa come lettori del giornale. A volte capita che venga mantenuto il sistema esistente (magari basato su LDAP) solo per la gestione dei redattori sul backend e che venga aggiunto un nuovo sistema separato per la sola gestione dei lettori e degli abbonati sul frontend.

Sicurezza

La gestione della sicurezza di un sito come Repubblica o Il Corriere è semplicemente un incubo. Là fuori c’è una enorme quantità di persone motivate (spesso dall’astio politico) a fare dei danni, molte delle quali possono vantare competenze tecniche di alto livello.

Per questa ragione molti giornali si tengono accuratamente alla larga da tecnologie che in passato hanno mostrato problemi di sicurezza, come PHP o Perl. Vengono spesso usate varie tecnologie di “hardening”, dalle librerie aggiuntive (per la verifica degli input utente e per la protezione da attacchi XSS e simili) fino al jailing del web server o addirittura alla gestione dell’intera baracca su server virtuali.

Gestione del Layout

Quasi sempre viene modificato, almeno in parte, il sistema di gestione del layout e nei casi più estremi ne viene implementato uno nuovo ad hoc, a volte di grande potenza e di grande raffinatezza.

Sistemi di quest’ultimo genere agiscono a volte come “filtri” sull’output e ricordano vagamente sistemi di templating come Apache Velocity o Struts Tiles.

Accounting

Viene spesso implementato un sistema di accounting e di misurazione dei contributi, a lato di quello di gestione degli accessi, spesso collegato al sistema di gestione delle paghe.

HA/HD

I sistemi dei giornali, specialmente quelli dei quotidiani, sono sempre sottoposti ad un carico enorme e devono restare visibile e funzionanti anche in caso di disastri. Di conseguenza, girano quasi sempre su cluster ad alta disponibilità ed alta affidabilità (High Availability / High Dependability).

Perché Java

Le ragioni per cui credo che Java sia più adatto a queste applicazioni sono le seguenti.

Team immortali

Come ho già detto in un post precedente, spesso le redazioni dei giornali sono supportate da piccoli team di sviluppatori che continuano a modificare ed aggiornare il sito mentre il giornale cresce. Questo vuol dire che il sistema software è un continuo work-in-progress, in un stato molto simile ad una Alpha.

Modularità e Gestibilità

Per gestire una situazione così fluida è necessario un sistema estremamente modulare e molto, molto facile da gestire. La “separation of concerns” deve essere rigorosa e la leggibilità del codice deve essere di ottimo livello.

Strumenti di lavoro

Sono anche necessari strumenti molto raffinati per il lavoro quotidiano, come ad esempio:

Eclipse come IDE (o NetBeans o IntellJ IDEA)

Maven (o Ant) per la gestione dei progetti, delle dipendenze software e dei deployement.

Hudson od un altro sistema di integrazione continua.

JUnit e Selenium per il testing

Vari framework per la costruzione del sistema (Apache Wicket, Spring, ACEGI security, Hibernate o JPA, etc.)

Molti di questi strumenti esistono (sotto altro nome) anche in ambienti non-Java, come Python e Ruby, ma solo in Java esiste una panoplia di strumenti altamente modulare, ben integrata e largamente condivisa come questa.

Metodologie di lavoro

Infine, anche se metodologie di lavoro come il TDD (Test-driven development) sono già da anni diventate comuni anche in ambienti non-Java, Java resta ancora oggi l’ambiente più orientato ad una corretta metodologia di produzione e ad una attenta progettazione dei sistemi.

Conclusioni

Questo è tutto. Se volete contribuire con le vostre riflessioni, usate il sistema dei commenti qui sotto.

Alessandro Bottoni

Comments
2 Responses to “Le piattaforme usate dai giornali”
  1. antonystar scrive:

    se pensi ad una redazione che parte web e resta web secondo me limiti molti dei problemi che invece hai su redazioni già strutturate per la carta e che vedono il web come un qualcosa di aggiunto o una opportunità di espansione.

    Ci sono redazioni che fanno molti lavori che se stessero solo su web non dovrebbero avere. In buona sostanza però concordo con te.

    Secondo te esistono piattaforme che ad oggi consentono di creare e progettare un vero e proprio timone virtuale (penso più ai settimanali e ai mensili che ai quotidiani) acquisire info da più fonti (mail, web access, word caricato in word tramite ftp ecc ecc ecc) e impagginare online/offline in maniera non dico professionale ma a buon livello? Sarebbe interessante investirci?

    • Si, esistono varie soluzioni tecniche di tipo industriale che permettono di svolgere tutte queste funzioni. Alcune sono soluzioni preconfezionate (ne hanno alcune a catalogo sia Adobe che Xerox, per esempio) ma la stragrande maggioranza sono soluzioni sviluppate ad hoc basandosi su linguaggi derivati da SGML o XML. E’ un settore tecnicamente interessante ma che conta solo pochi (4 o 5) clienti all’anno, tutti giganteschi (da 200 a 2000 dipendenti) e con esigenze tecniche da brivido (redazioni con centinaia di redattori, cicli di stampa da 4 o 5 milioni di copie al giorno, etc.).

      Tra le poche soluzioni preconfezionate che sono alla portata di un povero mortale come noi, una delle migliori è Ellington, basata su Django (Python). Un’altra è Krang, basata su Perl.

Lascia un commento

Inserisci i tuoi dati qui sotto o clicca su un'icona per effettuare l'accesso:

Logo WordPress.com

Stai commentando usando il tuo account WordPress.com. Chiudi sessione / Modifica )

Foto Twitter

Stai commentando usando il tuo account Twitter. Chiudi sessione / Modifica )

Foto di Facebook

Stai commentando usando il tuo account Facebook. Chiudi sessione / Modifica )

Google+ photo

Stai commentando usando il tuo account Google+. Chiudi sessione / Modifica )

Connessione a %s...

%d blogger cliccano Mi Piace per questo: